What is GRC (governance, risk and compliance)?

GRC is three words, and the explanations stop there and move to software. Of the seven pages ranking for the term in September 2026, six could be read, and every one of them names governance, risk and compliance and then describes a product. What makes the three words one job is a chain of records: an obligation produces a control, the control collects evidence, an assessment of that evidence produces a finding, a finding nobody can fix this quarter becomes a risk with an owner and an expiry date, and the rule people have to follow becomes a policy with an acknowledgement against it. Keep that chain in one place and the three words describe one piece of work. Keep it in three places and three teams maintain three copies of the same facts, and the copies disagree by the second quarter.

OCEG, which publishes the GRC Capability Model, has defined the term since its founder, Scott Mitchell, published it in an academic paper in 2007. Its definition is "the integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity", and it names the goal Principled Performance. The load-bearing phrase is "integrated collection of capabilities". Not a department, and not a product.

Why GRC matters

Six kinds of reader ask an organisation to account for itself, in different words and at different times of the year: a customer's security questionnaire before a contract is signed, a certification body's auditor at a surveillance visit, a regulator after an incident, an insurer at renewal, an acquirer's diligence team, and the board's risk committee each quarter.

Two of those readers work in opposite directions, and the pair is the whole design problem. The auditor wants each promise traced to a control and each control traced to evidence. The board wants the risks that remain, in a page, with names on them. A program built only for the first produces a binder nobody can summarise. A program built only for the second produces a slide nobody can substantiate.

Every figure on this page draws one organisation: a 250-person health software company whose product schedules clinical appointments for hospitals. It holds ISO/IEC 27001:2022, and on 3 February 2026 a hospital customer asked for a SOC 2 type 2 report as a condition of renewing. A type 2 report is one in which a service auditor reports on how controls operated across a period, so the company committed to an observation window running from 1 July to 31 December 2026. The worked example below follows one requirement, the quarterly access review, through both frameworks at once.

The cost of running those two as separate projects shows up first in the evidence. The access review produces one artefact a quarter: an export listing who could reach each system, what was removed, and who signed it off. Three have been produced in 2026, on 14 January, 14 April and 14 July, and the fourth is due on 9 October. Five readers want one or more of them this year. Three have already asked: the hospital customer's security questionnaire on 9 March, the cyber insurance renewal on 2 June and the SOC 2 readiness assessment on 6 August. Two are booked: the service auditor's interim testing on 20 October and the certification body's surveillance audit on 17 November, which will ask for all four. Ten requests between them, and every one lands on Ravi Nair, the IT manager who runs the review.

Attach the export to the control once and those ten requests are ten reads of one record. Run compliance as a series of projects and they are ten retrievals, each one a message to the person who administers the system, each one re-explaining what the export covers and what it leaves out. That is the pay-twice problem in its smallest form. Its larger form is the same control built twice because two frameworks asked for it in different words, and then audited twice because nobody wrote down that they were the same control.

Governance, risk and compliance are separable jobs on paper. Governance decides who decides, what the rules are, and how much exposure the organisation will carry: in this company that is the access control policy and one line the board wrote, which is that no risk rated above 10 may be carried without a recorded acceptance from a named person. Risk management finds what could stop the rules being kept, rates it, and records a decision. Compliance proves the arrangement to somebody outside, in the words the outsider uses.

They stop being separable at the record. All three write into and read from the same four: controls, risks, policies and evidence. In this company that is control CTL-14 and its quarterly export EV-221, risk R-31, and access control policy POL-03, and the three jobs sit with three people: Yusuf Demir, the chief information security officer, Sofia Marchetti, the head of data, and Hana Ito, the compliance lead.

COSO, the Committee of Sponsoring Organizations of the Treadway Commission, makes the same argument at board level and states it more bluntly than a vendor would. Its Enterprise Risk Management framework, updated in June 2017, defines enterprise risk management as "the culture, capabilities, and practices that organizations integrate with strategy-setting and apply when they carry out that strategy, with a purpose of managing risk in creating, preserving, and realizing value", and then says in its own summary that enterprise risk management "is not a function or department" and "is more than a risk listing". Two of its twenty principles are the ones a GRC function gets judged on: principle 7, that the organisation defines risk appetite, and principle 12, that it prioritises risks as the basis for selecting responses.

One limit belongs here rather than at the end, because it decides what else you need. GRC starts from the obligation. It tells you what you promised and whether you kept it. It does not tell you how the system is built, which design decisions produced the controls, or whether anyone reviewed the architecture those controls sit in. That work sits beside GRC and not inside it, and it has its own guide: what is security architecture.

How a GRC program works, step by step

The chain is ten steps, and each one leaves an artefact behind.

1. Decide what you are held to. Frameworks, customer contracts, laws, and your own policy. This is the governance step, and it is the one people skip on the way to buying something.
2. Install each obligation in the publisher's own wording. A paraphrase survives until an auditor reads it next to the source.
3. Turn each requirement into a control with one named owner who can actually change the system.
4. Attach evidence to the control, dated, with a state that says whether it is still current.
5. Assess the control on that evidence. Compliant, partial, non-compliant or not assessed, decided by an assessment and not by a dropdown anyone can set.
6. Turn what fails into a finding with a severity, an owner and a due date.
7. Turn what cannot be fixed inside that date into a risk register entry: owner, rating, response, and an acceptance with conditions and an expiry if that is the decision.
8. Turn the rule people have to follow into a published policy with an acknowledgement recorded against the version.
9. Report to both audiences. The auditor reads the chain from obligation to evidence; the board reads the risks that remain.
10. Reassess on a planned interval and whenever something significant changes, and keep the dated result.

Step 4 carries the other nine. An artefact becomes evidence when it has a date on it and a state that says whether the date still holds, and that state is what schedules the next collection instead of leaving it to be found at the audit.

Each control on the list runs that cycle on its own dates, and the tenth step is what keeps the assessment moving with it.

Those ten steps produce one chain, and the chain is easier to see on a single requirement than in the abstract. Here it is on the health software company's access review: the requirement as two publishers word it, control CTL-14 owned by Ravi Nair, the quarterly export EV-221, the assessment that found four of six systems reviewed, then finding F-07 and risk R-31 on one side and the scope rule and policy POL-03 on the other, with the auditor reading the chain in order and the board reading the risk at the end of it.

The return path matters as much as the forward one. ISO/IEC 27001:2022 clause 8.2 asks an organisation that holds or seeks the certificate to run its risk assessments at planned intervals and when significant changes are proposed or occur, with the documented results retained, so the chain is a loop and not a project with an end date.

The first ninety days

A program that starts with a tool selection spends its first quarter in demonstrations. A program that starts with the obligation list has something to show the first person who asks. Each step below leaves an artefact behind, and the dates overlap on purpose: step 2 begins while step 1 is still being argued about.

A worked example: one access review, two frameworks

The health software company holds ISO/IEC 27001:2022 and is preparing for a SOC 2 type 2 examination across the second half of 2026. Both frameworks ask about access review, in their own words, and the company answers both from one control.

ISO/IEC 27001:2022 states Annex A control 5.18, Access rights, as "access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organisation's topic-specific policy on and rules for access control". It names review as one of four acts and sets no frequency, so the frequency comes from the company's own policy. SOC 2's common criterion CC6.3 reads "the entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives", and one of its points of focus is that "the appropriateness of access roles and access rules is reviewed on a periodic basis for unnecessary and inappropriate individuals with access and access rules are modified as appropriate". Same practice, two publishers, two sets of words.

The control that answers both is CTL-14: every quarter, the owner of each system holding patient scheduling data reviews who can reach it, removes what is no longer needed, and signs the result. Six systems are in scope on paper: the production cloud account, the scheduling application's admin console, the code repository, the identity provider, the support desk and the analytics warehouse. Ravi Nair, the IT manager, owns the control. He can change every one of those systems, which is what makes him the owner and not the person who noticed the gap.

The evidence is EV-221, the export from the review completed on 14 July 2026. It carries a ninety-day freshness state, so it expires on 12 October 2026 and the October cycle has to produce its replacement. Evidence with no expiry becomes a screenshot of a console that has since been redesigned.

On 5 August 2026 Hana Ito, the compliance lead, assesses CTL-14 against both requirements and marks it partial. The review covered four of the six systems. The support desk was never added when it moved off the old helpdesk product, and the analytics warehouse was never in scope at all. Finding F-07 records the gap at medium severity, assigned to Ravi Nair, due 30 September 2026.

Half of it closes inside the due date. The support desk is added to the review scope on 22 September, and the October export, due on 9 October, will list it. The analytics warehouse cannot be fixed the same way: every analyst reaches it through one shared service account, so an access export lists a single name where eleven people work. Moving those eleven onto individual accounts is real engineering, scheduled into the first quarter of 2027, and no amount of review discipline changes what the export can show before then.

So the second half of the finding becomes a risk. R-31 opens on 12 August 2026, owned by Sofia Marchetti, the head of data, because the warehouse and the work to fix it are hers. It rates likelihood 3 and impact 4 on the company's five by five scale, a 12, above the line the board wrote at 10. On 19 August, Yusuf Demir, the chief information security officer, accepts it for one quarter. The acceptance names its scope, the analytics warehouse alone, and expires on 31 December 2026, and it carries two conditions: Sofia Marchetti exports the warehouse's access list monthly and reviews it by hand, attaching each month's result to CTL-14, and the shared service account closes when individual accounts ship, after which the warehouse joins the quarterly review from the March 2027 cycle.

The policy changed too, because the scope argument was a policy argument. Access control policy POL-03 went to version 4 on 2 September 2026, naming all six systems in the review scope line instead of describing them as "production systems", which is what let the support desk fall out of scope for two quarters. The 18 people who own or administer one of those systems acknowledged the new version by 16 September.

That is one obligation, four records, and a fifth artefact if you count the monthly manual review the acceptance requires. What makes it one piece of work instead of two projects is the crosswalk underneath it.

Evidence crosses; status does not. EV-221 is attached once and read by both frameworks, which is the saving. The two assessments stay separate, because each framework is assessed on its own wording: the Annex A control was partial at the August assessment, with two of six systems outside the review, while the SOC 2 position is a different statement altogether, since a type 2 examination reports on the suitability of design and operating effectiveness of controls throughout a specified period and includes the service auditor's tests and their results. By the close of the window that record holds two review cycles, what each one covered, and the dated decision that excluded the warehouse from the second.

At its 8 October meeting the board's risk committee reads one line about all of this: R-31, owned by Sofia Marchetti, accepted by Yusuf Demir until 31 December 2026, with the monthly manual review as its condition. At the surveillance audit booked for 17 November, the certification body's auditor reads the same facts in the other direction: control 5.18, the control that answers it, the exports behind it, the assessment, the finding and where the finding went. One record, two readings, and nobody rebuilt anything for either of them.

Common mistakes

Eight failure modes turn up again and again, and each one has a fix that costs less than a tool.

1. The tool is bought before anyone writes down what the organisation is held to. The obligation list is the input to a selection, not an output of one. Write it first, on paper if necessary, and take it to the demonstrations.
2. Frameworks are installed as headings for someone to fill in. A scaffold is a project, not a product. Load the publisher's control text and start on day one from assessment instead of data entry.
3. Control status is set by hand. If anyone can mark a control compliant from a dropdown, the dashboard reports what people wish were true. Status should follow from an assessment or an automated check against the system itself.
4. Evidence lives in a shared drive with no owner and no expiry. The audit finds the stale screenshot before you do. Give every artefact an owner, a date and a freshness state, and act on the notice before it expires.
5. Compliance is treated as the whole of GRC. Risk becomes a spreadsheet updated before board meetings, governance becomes a policy folder, and the first real question from a regulator finds both.
6. Status propagates across a crosswalk. Sharing evidence between frameworks is correct and is where the saving comes from; sharing status is wrong, because each framework is assessed against its own wording and its own scope.
7. Certification is confused with compliance. No tool certifies anyone. An accredited certification body issues a certificate after an audit, in Australia one accredited by JAS-ANZ, and a tool's job is to make that audit short.
8. GRC runs beside engineering instead of in front of it. When the controls describe a system nobody designed on purpose, every assessment turns into an argument about what the system actually does.

The third and fourth mistakes are one argument about one row. Here is the access review from the worked example kept the two ways: the line in a spreadsheet that records that it happened, and the record that says who owns the control, what proves it, when it was last assessed and what failed.

Those four fields are the fix, and none of them needs a purchase. Give a control somewhere to keep its owner, its dated evidence and the assessment that produced its status, and nobody has to take the row on trust.

GRC compared with its neighbours

The terms below are sold next to each other because they overlap. Two questions separate them: what each one starts from, and how much of the organisation it answers for.

Integrated risk management is the nearest point to GRC there, which is why the same products appear on a shortlist under both names. The rest of the distances are worth a line each.

Standards and references

Each of the three jobs has a document behind it. The distinction that matters is not age or length, but whether an accredited body can certify you against it, and only two of the six below can.

ISO 37301:2021, Compliance management systems. Requirements with guidance for use (published 13 April 2021). The compliance pillar's management system standard. It replaced ISO 19600:2014, and the substantive change is that ISO 19600 gave recommendations while ISO 37301 gives requirements, which makes it certifiable by an accredited body. It follows the usual management system structure, clauses 4 to 10: context, leadership, planning, support, operation, performance evaluation, improvement. Sold, not published.

ISO/IEC 27001:2022, clauses 6.1.2, 6.1.3 and 8.2 (October 2022). The information security pillar, and the one a cyber GRC program is audited against when a certificate is in play. Clause 6.1.2 asks for risk criteria including acceptance criteria, consistent and comparable assessments, identified risks and named risk owners; clause 6.1.3 carries the treatment side into the Statement of Applicability and the risk treatment plan; clause 8.2 asks for reassessment at planned intervals and on significant change, with the results retained. Those clauses bind an organisation that holds or seeks the certificate. Sold, not published.

ISO 31000:2018, Risk management. Guidelines. The risk pillar. It is guidance rather than requirements, so nobody certifies against it and it obliges nobody by itself. Its value is a common vocabulary that the other documents borrow. Sold, not published.

COSO, Enterprise Risk Management: Integrating with Strategy and Performance, Executive Summary (June 2017). The board-level model, developed with PwC and sponsored by five accounting and auditing bodies. Read the Executive Summary for the definition, the five components, the twenty principles, and the "setting the record straight" passage that says enterprise risk management is not a function or department. The Executive Summary is free; the full framework is sold.

OCEG, GRC Capability Model 3.5 (released 2023). The field's own model, and the source of the definition at the top of this page. Organised as GRC Concepts, GRC Capabilities and a GRC Glossary, with the four components quoted above. A free edition is downloadable; a premium edition sits behind a paid membership.

NIST IR 8286r1, Integrating Cybersecurity and Enterprise Risk Management (December 2025). Free, and the published account of how cyber risk reaches the board: system-level registers roll into organisation-level registers, then into an enterprise risk register and the risk profile drawn from it. This revision withdrew the October 2020 original in its entirety, so check the edition before citing it.

Three access notes, because they shape what this page could verify. ISO sells its standards and iso.org answers automated requests with HTTP 403, so every ISO clause and Annex A control quoted here comes from a dated secondary explainer and should be checked against a licensed copy before anyone quotes it word for word. The SOC 2 criteria quoted here come from the AICPA's TSP Section 100, 2017 Trust Services Criteria, in the edition marked "includes March 2020 updates"; the AICPA's current edition carries revised points of focus dated 2022, which was not read for this page. Gartner's integrated risk management entry could not be read either, for the same HTTP 403 reason, which is why the comparison above cites no Gartner wording.

How Alvor helps

Alvor sits beside the categories a GRC shortlist is drawn from instead of inside one of them. It keeps every record a GRC tool keeps, and it adds the security architecture and design review that produce the controls in the first place, so a control traces back to the design decision that created it. The buyer's guide at how to choose a GRC tool has the four market categories, the usual names in each and ten tests to run in a week.

What an organisation can do with it maps onto the chain this guide describes. Frameworks install with their official control text, so the first day is assessment and not data entry, and you can add any framework in the publisher's own structure. Evidence is uploaded once and linked to every control it satisfies, with a freshness state and a notice before it expires. A control is compliant, partial, non-compliant or not assessed on its own evidence, and posture is counted from those states, never typed in. An audit has a scope, named auditors and an assessment per control; what fails becomes a finding with a severity, an owner and a date, and escalating it creates a risk that keeps the link on both records, so closing the risk marks the linked findings compliant. Crosswalks let one piece of evidence answer several frameworks while each is still assessed on its own wording.

The rest of the chain lives in the same system. A risk carries a live verdict against the appetite threshold set for its category, and an acceptance is a typed decision with a nominated acceptor, conditions, a scope and an expiry date. A policy maps to the controls it supports, and an acknowledgement is recorded per person with time, IP and session. Vendor assessments run from the vendor's side through a hardened portal, and every submission writes to the hash-chained audit log. Compliance covers the module that holds the control set and the evidence.

The AI Assistant is bring-your-own-model, and it drafts and proposes while a person accepts or rejects every write, so no control, risk or acceptance is ever decided by a model. Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers, or air-gapped, with every module included in each of the three.