Governance, risk and compliance (GRC): what it means and what the law asks of your board
Governance, risk and compliance (GRC) is the ability to reach your objectives, manage uncertainty and meet your obligations. Get the definitions from OCEG, ISO and COSO, the difference between risk appetite and risk profile, and what GDPR, NIS2, DORA and the UK Code ask of the board.
GRC is one of those terms everyone in compliance uses and almost nobody defines the same way. To some it is a software category. To others it is a department, a framework or simply a new label for risk management. That ambiguity has a cost, because it hides the question that actually matters: who decides how much risk the organisation will accept, and who can prove it stays within that limit?
This article takes its definitions from the people who wrote them: OCEG, ISO, COSO and the Institute of Internal Auditors. It then shows how GDPR, NIS2, DORA and, in the UK, the Corporate Governance Code place responsibility for governance, risk and compliance directly on the board. Finally, it walks through a fictional example where one risk hits three rulebooks at once. If you are choosing a tool rather than a definition, we have a separate guide to GRC software.
The short answer: what is governance, risk and compliance (GRC)?
Governance, risk and compliance (GRC) is an organisation's combined ability to steer towards its objectives, deal with uncertainty along the way and meet the obligations it is bound by. The most widely cited definition comes from OCEG: GRC is the capability, or integrated collection of capabilities, that enables an organisation to reliably achieve objectives, address uncertainty and act with integrity.
Each word answers a question. Governance answers who decides and who is accountable. Risk answers what could get in the way of the objectives, and how much of it you are prepared to live with. Compliance answers which obligations apply and whether you can show you meet them. GRC isn't a law, a standard or a system. It's the way the three disciplines work together. NIS2 has turned part of it into a legal duty. Once national law applies, management bodies in covered entities must approve and oversee cybersecurity risk management.
What GRC is, and what it isn't
Searches for "what is GRC" tend to mix terms from different categories. A standard, a law and a role model get mentioned in the same breath, as if one could replace another. They can't. The table below sorts the most common terms so you can see what is voluntary, what is mandatory and what you can be certified against.
| Term | What it is | Certifiable? |
|---|---|---|
| GRC | An approach and an integrated capability, defined by OCEG | No. OCEG certifies individuals, not organisations |
| ISO 37000:2021 | Guidance on the governance of organisations, 11 principles | No, guidance standard |
| ISO 31000:2018 | Risk management guidelines, 8 principles | No, guidance standard |
| COSO ERM (2017) | Enterprise risk management framework, 5 components and 20 principles | No |
| ISO 37301:2021 | Requirements for a compliance management system | Yes |
| ISO/IEC 27001:2022 | Requirements for an information security management system (ISMS) | Yes |
| Three Lines Model (IIA, 2020) | A model for roles in governance and risk management | No |
| GDPR, NIS2, DORA, UK Code | Legislation or regulatory codes with specific duties for the board | No. You comply with them |
| GRC software | A tool to document the work and follow it up | No |
The key point is that GRC has no checklist of its own. The content comes from the standards and laws that apply to you. GRC is the glue that makes sure they are handled in one place, with one method and with clear ownership.
Where does the term GRC come from?
The acronym is closely tied to the Open Compliance and Ethics Group (OCEG), a non-profit founded in 2002. OCEG says the ideas behind GRC were developed within the organisation in the early 2000s and that an expert panel later formalised the definition. The first scholarly article on the concept was published in 2007 by OCEG's founder, Scott L. Mitchell, in the International Journal of Disclosure and Governance.
OCEG's central phrase is principled performance. An organisation achieves it when it reliably achieves objectives, addresses uncertainty and acts with integrity. The wording is worth noticing because it starts with objectives. GRC isn't mainly about avoiding fines. It's about getting where the organisation wants to go without compromising on laws, values or promises. OCEG's open GRC Capability Model, known as the Red Book, describes how to do that in practice. Read OCEG's own explanation of GRC.
Governance: who decides, and who is accountable?
ISO 37000:2021, the first international standard on the governance of organisations, describes good governance as a human-based system by which an organisation is directed, overseen and held accountable for achieving its defined purpose in an ethical and responsible manner. It was published on 15 September 2021 and organises the field into 11 principles, with purpose as the first and central one. Oversight, accountability and risk governance are among the others. See ISO's announcement of ISO 37000.
Governance is increasingly codified. In the UK, the UK Corporate Governance Code 2024 applies to financial years beginning on or after 1 January 2025. Its Provision 29, which asks the board to declare whether material internal controls were effective at the balance sheet date, applies to financial years beginning on or after 1 January 2026. Across the EU, company law in each member state sets similar duties. Danish company law, for example, requires the board of a limited company to ensure adequate procedures for risk management and internal control.
In practice, governance in a GRC context comes down to four things:
- A clear allocation of decision rights, so it is obvious who may accept a risk.
- Policies approved at the right level and actually reviewed.
- Reporting that reaches the board in a form it can act on.
- Oversight that can show the whole thing works, not just that it is written down.
Risk: from uncertainty to decision
ISO defines risk as the effect of uncertainty on objectives. The definition appears in ISO 31000:2018 and in the vocabulary standard ISO 31073:2022, which replaced ISO Guide 73:2009. The effect can be positive or negative. Risk management is therefore not only about avoiding losses. It's about making decisions with your eyes open.
The two leading references are ISO 31000 and COSO. ISO 31000:2018 was published on 14 February 2018 and consists of principles, a framework and a process. It is now being revised, with a committee draft (ISO/CD 31000) out for comment until 1 March 2026, so expect a new edition. COSO's Enterprise Risk Management: Integrating with Strategy and Performance, released in June 2017, has five components: governance and culture, strategy and objective-setting, performance, review and revision, and information, communication and reporting. Governance is COSO's first component. Risk management without governance is just a list.
For the method itself, our article on information security risk management shows how one approach can serve GDPR, NIS2, DORA and ISO 27001 at once.
Risk appetite, risk tolerance and risk profile are not the same thing
A common mistake in GRC content is to describe the risk profile as the amount of risk the organisation is willing to accept. That's risk appetite. The risk profile describes the risks you actually have. The distinction isn't pedantry. The whole point of governance is to compare the two: if the profile sits above the appetite, someone has to act.
| Term | Meaning | Who sets it? | Example |
|---|---|---|---|
| Risk appetite | The amount and type of risk an organisation is willing to pursue or retain (ISO 31073) | The board or governing body | "We accept no high risks to patient safety." |
| Risk tolerance | The acceptable variation around a specific objective. COSO ties tolerance to objectives | Executive management, within the board's appetite | "Critical systems may be down for no more than 4 hours." |
| Risk capacity | The maximum risk the organisation can bear before it can no longer meet its objectives | Calculated, not chosen | Cash to survive a 10-day production stop |
| Risk profile | The composite view of the risks the organisation actually faces at a given level (COSO) | The output of risk assessment | "14 risks, 3 of them above appetite." |
COSO describes the risk profile as the composite view of risks related to a specific strategy or business objective at a particular level of the entity. Appetite is drawn as a line, the profile as a curve. Where the curve crosses the line, risk becomes too high. That comparison is what the board needs to see.
Compliance: obligations, not just laws
Compliance means meeting obligations, and in GRC the term reaches further than legislation. ISO 37301:2021 on compliance management systems talks about compliance obligations. They cover the requirements an organisation must meet and those it chooses to meet, such as customer contracts, industry codes or its own policies. A data processing agreement or a commitment in a tender is as much a compliance obligation as GDPR.
ISO 37301 was published on 13 April 2021, replaced ISO 19600:2014 and, unlike its predecessor, is a requirements standard you can be certified against. It shares its structure with ISO 27001, so anyone running an ISMS will recognise the pattern of context, leadership, planning, operation, evaluation and improvement. Like the other ISO management system standards, it received a climate action amendment in 2024.
For most organisations with 50 or more staff, the compliance portfolio is a handful of rulebooks: GDPR compliance, NIS2 if you're in scope, ISO 27001 if customers ask for it, plus contractual and sector requirements. The job is knowing which apply, who owns each one and how you evidence that it is met.
How the three fit together: the three lines
The most widely used model for how governance, risk and compliance map onto roles is the Institute of Internal Auditors' Three Lines Model. Published in July 2020, it replaced the older Three Lines of Defence. It rests on six principles and stresses that the lines are not structural elements but a useful differentiation of roles. Read the IIA's Three Lines Model.
| Role | Task in the model | Typically in a mid-sized organisation |
|---|---|---|
| Governing body | Accountable to stakeholders for oversight of the organisation | Board of directors, often the executive team in owner-managed firms |
| First line | Leads operations and owns risk in day-to-day activity | Department heads, IT operations, production, HR |
| Second line | Complementary expertise, support, monitoring and challenge | Compliance, risk management, CISO, data protection officer (DPO) |
| Third line | Independent assurance and advice, reporting to the governing body | Internal audit, often outsourced in smaller organisations |
| External | Additional assurance to satisfy legal and regulatory expectations | External auditor, certification body, supervisory authority |
The DPO sits in the second line as an adviser. Keeping the record of processing and notifying breaches are duties of the controller, not the DPO. And many organisations under 250 staff have no internal audit function at all. Then the third line has to come from an external review, or the board has to accept that independent assurance is limited.
What the law asks of the board on governance, risk and compliance
Ten years ago you could still argue about whether GRC was good practice or consultancy jargon. Legislation has settled the argument. Several regimes now place responsibility for risk management squarely on the management body, and some let supervisors pursue individual executives.
| Regime | Provision | What the board must do | Applies to |
|---|---|---|---|
| GDPR | Art. 5(2) and Art. 24(1) | The controller must be able to demonstrate compliance and implement appropriate measures | All controllers in scope of Art. 3 |
| NIS2 | Art. 20(1) and (2) | Approve the Art. 21 measures, oversee implementation, follow training. Members can be held liable | Essential and important entities, via national law |
| NIS2 | Art. 32(5)(b) | Authorities can impose or seek a temporary ban on a CEO or legal representative exercising managerial functions | Essential entities |
| DORA | Art. 5(2)(a) | The management body bears ultimate responsibility for managing ICT risk | Financial entities, from 17 January 2025 |
| UK Corporate Governance Code 2024 | Provision 29 | Monitor the risk management and internal control framework and declare whether material controls were effective | UK listed companies (comply or explain), financial years from 1 January 2026 |
| ISO/IEC 27001:2022 | Clauses 5.1 and 9.3 | Top management must demonstrate leadership and carry out management review | Voluntary, required for certification |
NIS2 is the sharpest of these. Article 20(1) of the NIS2 Directive requires member states to ensure that management bodies approve the cybersecurity risk-management measures, oversee their implementation and can be held liable for infringements. Article 20(2) requires members of management bodies to follow training, which our article on NIS2 training requirements covers in detail. Article 34 sets fines of a maximum of at least EUR 10 million or 2 % of worldwide annual turnover for essential entities, and EUR 7 million or 1.4 % for important entities.
How this lands depends on national law. Denmark's NIS2 Act (Act no. 434 of 6 May 2025) has applied since 1 July 2025, and its section 7 copies the board duties almost word for word. Transposition has been uneven elsewhere. In July 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify full transposition (IP/26/1499). The UK is outside NIS2. Its NIS Regulations 2018 remain in force, and the Cyber Security and Resilience Bill was at Report stage in the House of Lords in September 2026, according to the UK Parliament bill page. Our NIS2 introduction explains who is in scope.
For financial entities, DORA is even more explicit. Under Article 5(2), the management body must define, approve, oversee and be responsible for the implementation of all arrangements in the ICT risk management framework. GDPR says less about the board as such, but the accountability principle in Article 5(2) and the controller's responsibility in Article 24 of the GDPR require, in practice, a governance structure that can show who decided what.
An example: one risk, three rulebooks
Kystlab Medical A/S and its CFO Mette Holm are fictional. We invented them for this article.
Kystlab Medical A/S is a Danish manufacturer of medical devices with 240 employees. Manufacturing of medical devices is listed in Annex II of NIS2, and with more than 50 staff Kystlab is an important entity under the Danish NIS2 Act. It processes personal data about patients in complaint cases and about its own employees. A large hospital customer requires ISO 27001 certification in the contract.
Until this year, three people managed the same risk without knowing it. The IT manager had "ransomware on the production server" in the ISO 27001 risk register. The DPO had "loss of availability of complaint files" in the GDPR risk assessment. The production manager had "assembly line stopped for more than 24 hours" in the business continuity plan. Three registers, three scales, three owners and three reports to the board.
Mette Holm was asked to bring it together. First, the board adopted a one-page risk appetite:
- Patient safety and product quality: no risks above medium are accepted.
- Personal data: no high risks to data subjects are accepted without a data protection impact assessment.
- Operations: critical production systems may be down for no more than 24 hours. Administrative systems may be down for up to 3 working days.
The three risks were then merged into one risk with one owner, the production manager, and scored on one shared scale. The result was a single risk profile of 14 risks, 3 of them above appetite. Ransomware was the largest: likelihood 3 out of 5, impact 5 out of 5. The control chosen to reduce it was a tested offline backup with restore within 24 hours. That single control served three obligations:
| Obligation | Provision | What the control evidences |
|---|---|---|
| NIS2 | Art. 21(2)(c), business continuity and backup management | Backup and disaster recovery |
| GDPR | Art. 32(1)(c) | The ability to restore availability of and access to personal data in a timely manner |
| ISO/IEC 27001:2022 | Annex A 8.13 (information backup) | Backups maintained and tested in line with an agreed policy |
The board received one report instead of three. It showed that the risk was above appetite, that the control had been approved, that the first test was scheduled for November and who owned it. That is exactly what NIS2 Article 20 asks of the management body: approve the measures and oversee their implementation. Kystlab used the same scoring approach as in our guide to the risk assessment matrix, but only once.
The point isn't that one control covers everything. It doesn't. A backup won't give you a lawful basis under GDPR or meet NIS2's incident reporting deadlines. The point is that the risk only needs to be assessed, owned and reported once.
How to get started with GRC in six steps
GRC rarely starts as a big-bang programme. It usually begins when someone notices the same work being done three times. These six steps give a realistic order for an organisation with 50 to 500 staff:
- Map your obligations. List the laws, standards and contracts that apply to you and who owns each one. Check, for example, whether you are in scope of NIS2 or DORA.
- Get a risk appetite approved. One page, signed off by the board or executive team, with appetite per risk type. Without it, nobody can say whether a risk is too high.
- Pick one method and one scale. Use the same likelihood and impact scale across GDPR, information security and operations. ISO 31000 or COSO can be the starting point.
- Assign roles using the three lines. Clarify who owns the risks (first line), who advises and challenges (second line) and who provides independent assurance (third line).
- Map controls to obligations. Link every control to all the requirements it covers, so you can reuse evidence and see the gaps.
- Set up regular board reporting. Report risk profile against appetite, control status and exceptions at least quarterly, and put management review into a compliance calendar.
What GRC won't fix
GRC is easy to oversell. Three caveats are worth knowing before you start.
- GRC isn't a department. OCEG itself says integrated GRC doesn't mean a mega-department or one system for everything. It means the right people get the right information at the right time.
- One register can hide real differences. GDPR looks at risk to data subjects, while ISO 27001 and NIS2 look at risk to the organisation and its services. A shared scale mustn't make you forget that a low business risk can be a high risk to a patient.
- The three lines assume resources. In an organisation of 80 people, the CISO, compliance lead and DPO are often the same person. Independence between second and third line is then an illusion, and the board should know that.
Risk matrices have known weaknesses too, including giving the same score to very different risks. We cover them in our article on information security risk management. And certification isn't compliance. An ISO 27001 certification shows your management system works, but it doesn't discharge your NIS2 or GDPR obligations.
How .legal supports governance, risk and compliance
The practical challenge is rarely understanding GRC. It's keeping obligations, risks, controls and decisions together, so that one risk doesn't live in three spreadsheets.
In the .legal platform's Frameworks module you map one control to several rulebooks, such as GDPR, NIS2 and ISO 27001, and see where evidence is missing. Risk management uses one method across areas, and the information security module brings assets, risks and controls together for your ISMS. Policies are kept current and acknowledged in Policy Management, suppliers are handled in Vendor Management, and recurring tasks such as management review, policy review and control testing go into compliance task management.
The platform doesn't make decisions for you, and it doesn't make you compliant on its own. The board still has to set the risk appetite, and controls still have to work in practice. What the platform gives you is structure and traceability, so you can show who decided what. To see how it looks, book a demo.
.png?width=600&height=400&name=securitybreach-feature%20(1).png)
.legal compliance platform
Unify Your GRC with .legal Compliance Platform
-
Integrated governance, risk, and compliance management
-
Automated risk assessments and policy management
-
Real-time dashboards and compliance reporting
-
Framework support for ISO 27001, GDPR, and more
.jpeg?width=131&height=26&name=right_people_logo%20(1).jpeg){kind=small}
.jpg?width=58&height=26&name=Praktiserende%20L%C3%A6gers%20Organisation%20(1).jpg){kind=small}
.jpg?width=108&height=26&name=finans%20danmark%20(1).jpg){kind=small}
.jpg?width=89&height=26&name=klasselotteri%20(1).jpg){kind=small}
-1.png?width=34&height=26&name=bws_shipping_rgb%20-%20Kopi%20(2)-1.png){kind=small}
.jpeg?width=135&height=26&name=AH%20industries%20(1).jpeg){kind=small}
.jpg?width=225&height=26&name=KAUFMANN%20(1).jpg){kind=small}
