GRC (governance, risk and compliance) explained: the three parts, GRC in cyber security, GRC vs ERM vs IRM, the EU, UK and South African rules that expect it, a maturity model, a 90-day build plan and a worked example.
Last updated: 31 October 2026
GRC stands for governance, risk and compliance: the joined-up way an organisation sets direction, manages the risks that could stop it reaching its goals, and proves it meets the laws, regulations and standards that apply to it. The industry body OCEG, which popularised the term, defines GRC as "the integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity" (OCEG). In practice, a GRC programme replaces separate spreadsheets, policies and audit folders with one shared view of risks, controls, obligations and evidence.
This guide explains what GRC means, what each part covers, how it differs from ERM and IRM, which laws push organisations towards it (including in the EU, UK and South Africa), and how to build a working GRC programme in 90 days, with a worked example.
GRC meaning: the three parts
GRC is easiest to understand as three questions an organisation must be able to answer at any time.
| Part | The question it answers | Typical activities | Typical owners |
|---|---|---|---|
| Governance | Who decides, and how do we know decisions are followed? | Board and committee charters, policies, delegated authority, risk appetite, reporting to the board | Board, executive team, company secretary |
| Risk management | What could stop us achieving our objectives, and what are we doing about it? | Risk identification, assessment and scoring, risk registers, controls, treatment plans, key risk indicators | Risk manager, CRO, business unit heads |
| Compliance | Are we meeting our legal, regulatory and contractual obligations, and can we prove it? | Obligation registers, control testing, assessments, audits, evidence collection, issue remediation | Compliance officer, DPO or Information Officer, internal audit |
The word that matters most is "integrated". Most organisations already do some governance, some risk management and some compliance work. GRC is the decision to connect them, so that a policy links to the risks it addresses, each risk links to the controls that reduce it, and each control links to the regulations it satisfies and the evidence that shows it works.
What is GRC in cyber security?
In cyber security, GRC is the management layer around technical security work. Security engineers configure firewalls and fix vulnerabilities; the GRC function decides which risks matter most, maps controls to frameworks such as ISO 27001, SOC 2 or NIST CSF, collects evidence for auditors and customers, and reports security risk to leadership in business terms.
Cyber GRC usually covers:
- Security policies and standards, approved and reviewed on a cycle
- An information security risk register with likelihood, impact and owners
- Control mapping so one control (for example, multi-factor authentication) is tested once and counted against every framework that requires it
- Third-party risk, because suppliers with access to your systems or data extend your attack surface (see our vendor risk assessment guide)
- Incident and breach records, including regulatory notification decisions
- Audit readiness, with evidence stored against each control
EU law now makes this a board-level matter. Under the NIS2 Directive, the management bodies of essential and important entities must approve cybersecurity risk-management measures, oversee their implementation and "can be held liable for infringements" (NIS2 Article 20). Members of those management bodies must also follow training.
GRC vs ERM vs IRM
These terms overlap and vendors use them loosely. The practical differences are scope and starting point.
| Term | Starting point | Scope | Common reference |
|---|---|---|---|
| GRC (governance, risk and compliance) | Obligations and accountability | Policies, risks, controls, compliance evidence across the organisation | OCEG GRC Capability Model |
| ERM (enterprise risk management) | Strategy and performance | All risks to strategic objectives, including financial, market and operational risk | COSO ERM, ISO 31000 |
| IRM (integrated risk management) | Technology and data | A software-led approach that combines risk data from across the business in one platform | Analyst term, no single standard |
| Compliance management | Legal and regulatory obligations | Identifying obligations, controls and evidence | ISO 37301 |
For a mid-sized organisation, the distinction rarely matters. What matters is that risk and compliance information sits in one place, with clear owners, and that leadership sees it.
Why GRC matters: the laws and codes that expect it
No single law says "you must have a GRC programme". Instead, many laws require accountability, risk-based controls and the ability to demonstrate compliance, which is exactly what GRC provides. A sample of the most common drivers:
| Jurisdiction | Requirement | What it expects | Source |
|---|---|---|---|
| EU and UK | GDPR / UK GDPR Article 5(2) accountability | The controller must be "responsible for, and be able to demonstrate compliance with" the data protection principles | GDPR Art. 5 |
| EU | NIS2 Articles 20 and 21 | Board approval and oversight of cybersecurity risk-management measures; appropriate and proportionate technical, operational and organisational measures | NIS2 |
| EU | DORA Article 5 (financial entities, applies from 17 January 2025) | The management body must "define, approve, oversee and be responsible for" the ICT risk management framework | DORA |
| EU | EU AI Act Article 9 | Providers of high-risk AI systems must establish, implement, document and maintain a risk management system | EU AI Act |
| UK | UK Corporate Governance Code 2024, Provision 29 | Boards of companies applying the Code declare the effectiveness of their material internal controls, for financial years beginning on or after 1 January 2026 | FRC |
| South Africa | POPIA section 55 | The Information Officer is responsible for, among other duties, ensuring the body complies with POPIA | Information Regulator |
| South Africa | King V Code on Corporate Governance | Voluntary governance code from the Institute of Directors in South Africa, applied on an "apply and explain" basis; it replaced King IV for financial years starting on or after 1 January 2026 | IoDSA |
Penalties give these duties teeth. For example, NIS2 requires Member States to set maximum fines of at least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher, for essential entities, and at least EUR 7 million or 1.4% for important entities (NIS2 Article 34).
If you operate in South Africa, our POPIA compliance guide shows how POPIA's conditions turn into controls you can track.
The core components of a GRC programme
Whatever framework you follow, working GRC programmes share the same building blocks. Use this as a checklist.
- Objectives and risk appetite. A short statement of what the organisation is trying to achieve and how much risk it will accept in pursuit of it.
- Policy library. Approved policies with owners, review dates and version history.
- Obligations register. The laws, regulations, standards and contracts that apply, broken down into specific requirements.
- Risk register. Each risk with a description, owner, inherent score, controls, residual score and treatment plan.
- Control library. Each control with an owner, frequency, test method and the obligations and risks it maps to.
- Assessments. Structured questionnaires for recurring checks: vendor risk assessments, DPIAs, AI system assessments, control self-assessments.
- Issues and actions. Findings from audits, assessments and incidents, each with an owner, due date and status.
- Evidence. The documents, screenshots and logs that prove a control operated.
- Reporting. A regular view for leadership: top risks, overdue actions, compliance status by framework.
Who owns GRC? Roles in a typical programme
Many organisations describe accountability using the Institute of Internal Auditors' Three Lines Model:
- Governing body (the board): sets direction and risk appetite, and holds management to account.
- First line (operational management): owns and manages risks day to day, and runs controls.
- Second line (risk, compliance, privacy, security functions): provides frameworks, expertise, monitoring and challenge.
- Third line (internal audit): gives independent assurance that the first two lines work.
In smaller organisations one person may cover several roles. The point is not headcount but clarity: every risk, control and obligation has a named owner.
A GRC maturity model
Use this five-level model to place your organisation honestly and decide what to fix next. It is our own practical scale, not a formal standard.
| Level | Name | What it looks like | Typical next step |
|---|---|---|---|
| 1 | Ad hoc | Compliance happens when an auditor or customer asks. Knowledge sits with individuals. | Create a single risk register and obligations list. |
| 2 | Documented | Policies and a risk register exist, usually in spreadsheets, but are rarely updated. | Assign owners and review dates; start tracking issues. |
| 3 | Managed | Owners review risks on a schedule; assessments and audits feed one issue log. | Map controls to frameworks so evidence is reused. |
| 4 | Integrated | Risks, controls, obligations, vendors and evidence are linked in one system. Leadership gets regular reports. | Add key risk indicators and automate evidence collection. |
| 5 | Optimised | Risk information drives decisions on strategy, investment and suppliers. | Continuous monitoring and periodic programme review. |
Most organisations that come to GRC from spreadsheets are at level 2. Getting to level 3 is the biggest win, because it turns static documents into a working routine.
How to build a GRC programme in 90 days
This step-by-step plan suits a mid-sized organisation starting from level 1 or 2. Adjust the scope, not the sequence.
Days 1 to 30: scope and inventory
- Agree the scope and sponsor. Pick one executive sponsor and a programme owner. Decide whether you start organisation-wide or with one area such as privacy or information security.
- List your obligations. Identify the laws, regulations and frameworks that apply, for example GDPR, POPIA, NIS2, ISO 27001 or SOC 2, plus key customer contract requirements.
- Build the first risk register. Run short workshops with each department. Aim for 20 to 40 well-described risks rather than hundreds of vague ones.
- Inventory what you already have. Collect existing policies, previous audit findings, vendor lists and data maps. Most organisations have more than they think.
Days 31 to 60: connect and assess
- Define a scoring method. Use a simple likelihood x impact scale (for example, 1 to 5 on each) and document what each score means.
- Map controls to risks and obligations. For each key risk, list the controls that reduce it and the requirements those controls satisfy.
- Run your first assessments. Prioritise the highest-exposure areas: critical vendors (our vendor risk assessment questionnaire gives a tiered question set), high-risk processing activities, and any AI systems in use.
- Open an issues log. Every gap found becomes an issue with an owner and due date.
Days 61 to 90: operate and report
- Set review cycles. Monthly for high risks and overdue issues, quarterly for the full register, annually for policies.
- Collect evidence as you go. Store evidence against the control it supports so the next audit takes days, not weeks.
- Report to leadership. A one-page summary: top ten risks, trend since last quarter, overdue actions, compliance status by framework.
- Review and plan the next quarter. Extend the scope, for example from security into privacy rights handling and data subject access requests, or into website accessibility.
Worked example: GRC at a 300-person SaaS company
A B2B software company with offices in London and Cape Town sells to EU customers. It holds customer personal data and uses around 60 suppliers. Before starting, it had an ISO 27001 risk spreadsheet, a separate privacy folder and vendor contracts in a shared drive.
One risk, followed through the programme:
| Element | Entry |
|---|---|
| Risk | A critical supplier (cloud support desk tool) suffers a breach exposing customer personal data |
| Owner | Head of Customer Support (first line); Privacy Lead (second line) |
| Inherent score | Likelihood 3 x impact 5 = 15 (high) |
| Obligations | GDPR Art. 28 processor terms and Art. 32 security; POPIA s21 operator agreements and s19 security safeguards; ISO 27001 supplier controls; customer contract security schedules |
| Controls | Vendor tiered as critical; annual security assessment; signed data processing agreement; SSO and MFA enforced; quarterly access review |
| Assessment result | Vendor's SOC 2 report showed one exception on access reviews |
| Issue raised | "Confirm vendor remediation of access review exception", owner Privacy Lead, due in 60 days |
| Residual score | Likelihood 2 x impact 5 = 10 (medium), pending issue closure |
| Reported | Appears in the quarterly board risk summary under "third-party data risk" |
Without GRC, these facts sat in four places and nobody could answer the board's question "how exposed are we through our suppliers?" With the risk, vendor, assessment, issue and obligations linked, the answer takes one report.
Common GRC mistakes to avoid
- Starting with the tool, not the process. Software speeds up a working routine; it does not create one. Agree owners and scoring first.
- A register nobody reads. If leadership never sees the risk register, it will go stale. Build reporting into the plan from day one.
- Testing the same control five times. Map each control once to every framework it satisfies.
- Treating compliance as a project. Obligations change and controls drift. GRC is a cycle, not a finish line.
- Ignoring third parties. Suppliers often hold your data or have access to your systems, so their weaknesses become yours. Vendor risk belongs inside GRC, not beside it.
Frequently asked questions
What does GRC stand for?
GRC stands for governance, risk and compliance. It describes the integrated way an organisation directs itself, manages risks to its objectives, and meets and proves its legal, regulatory and contractual obligations.
What is a GRC framework?
A GRC framework is the structure an organisation uses to run its programme: the policies, roles, risk scoring method, control library and review cycles. Many organisations base theirs on recognised references such as the OCEG GRC Capability Model, COSO ERM, ISO 31000 for risk and ISO 37301 for compliance management, then add the specific frameworks they must meet, such as ISO 27001 or SOC 2.
What is the difference between GRC and compliance?
Compliance is one part of GRC. Compliance asks whether you meet your obligations. GRC adds governance (who decides and how) and risk management (what could go wrong and how you reduce it), and connects all three so the same controls and evidence serve every purpose.
What does a GRC analyst do?
A GRC analyst maintains the risk register, maps controls to frameworks, runs assessments such as vendor and privacy reviews, tracks issues to closure, gathers audit evidence and prepares reports for leadership. In cyber security teams, the role links technical controls to business risk and regulatory requirements.
Do small and mid-sized companies need GRC?
Yes, though the programme should be proportionate. Laws such as GDPR and POPIA apply regardless of size, and customers increasingly ask suppliers for security and privacy evidence. A small company can start with a single risk register, an obligations list and an issue log, then add structure as it grows.
What is GRC software?
GRC software is a platform that holds risks, controls, policies, assessments, issues and evidence in one connected system, with workflows, reminders and reporting. It replaces spreadsheets and shared folders once the programme outgrows them. For a sense of cost, see our pricing page.
Run your GRC programme in one place
Core GRC brings the parts of a GRC programme together: risk and issue registers, third-party and vendor risk management, privacy assessments (DPIA, PIA, LIA and TIA), data mapping and ROPA, AI governance, DSR management, policy and notice management, cookie consent and website accessibility. Core IQ, our agentic AI, helps teams work through assessments and keep records current. Explore the modules to see how they connect.
Cover photo by Christina @ wocintechchat.com M on Unsplash
