GRC Maturity Model

Most organisations run a governance, risk and compliance programme, but few can show with evidence how mature it is, or why the same audit findings come back every year. GRC usually grows one obligation at a time, each with its own spreadsheet, control set and evidence folder. This five-level model, using the same Ad hoc to Optimised scale as the NHI Mgmt Group NHI Governance Maturity Model, scores a GRC programme across ten dimensions and maps the levels loosely to the NIST CSF 2.0 Tiers. It is for CISOs, heads of GRC, risk managers and internal audit leads who need an honest baseline, a realistic target and a roadmap they can defend to the board.

Key takeaways

• Score ten dimensions separately: governance and accountability, risk management, policy management, control framework and mapping, compliance obligations, evidence and audit, third-party risk, metrics and reporting, tooling and automation, and culture.
• Evidence decides the level. A risk appetite statement nobody uses to make a decision is Level 2, however well it is written.
• Level 3 (Defined) is the right first target for most organisations: one control framework mapped to every obligation, one risk register, named owners and a repeatable audit cycle. It lines up roughly with CSF Tier 3, Repeatable.
• Test once, comply many is the step change between Levels 2 and 4. Mapping obligations to a common control set removes duplicate testing and duplicate evidence requests.
• Maturity must show in numbers: repeat audit findings, overdue risk treatments, controls tested automatically, exceptions past expiry and time to answer a regulator.

The five levels

The ten dimensions

Levels 2 and 4 sit between the descriptions shown; the roadmap below lists what moves you from each level to the next.

How the levels relate to NIST CSF 2.0 Tiers and other models

NIST CSF 2.0 describes four Tiers that "characterize the rigor of an organization's cybersecurity risk governance and management practices", and states that Tiers "should complement an organization's cybersecurity risk management methodology rather than replace it". OCEG's GRC Capability Model 3.5 (the Red Book) defines GRC as "the integrated collection of capabilities that enable an organization to achieve Principled Performance", organised into four components: Learn, Align, Perform and Review. ISO 31000:2018 gives principles and guidelines for risk management but cannot be used for certification, and COSO's Enterprise Risk Management: Integrating with Strategy and Performance places risk inside strategy setting. Treat the mapping below as a sense check, not an equivalence.

Dimension to framework mapping

Self-assessment questions

Score each dimension from 1 to 5 using evidence, not intent. Your overall level is the lowest score among the dimensions your regulators and customers care about most, not the average. Record the evidence behind each score and baseline the six metrics below at the same time.

• Governance: who signed the last high-risk acceptance, and were they senior enough to own the consequence?
• Risk management: does your appetite statement contain a testable threshold, such as maximum tolerable downtime? How many register entries have no owner or an overdue review?
• Policy: how many policies are past their review date, and how many exceptions have no expiry?
• Control framework: if ISO 27001, SOC 2 and NIS2 all require access reviews, is that one control tested once, or three tests by three teams?
• Obligations: could you list every law, regulation and contract clause that imposes a security requirement, with an owner for each, within a day?
• Evidence: what share of your last audit's evidence came straight from a system, and how many findings were repeats?
• Third-party risk: which suppliers could stop a critical service or reach sensitive data, and when was each last assessed?
• Metrics: does any metric you report to the board have a threshold that would trigger action?
• Tooling: how many control-owner hours did the last audit take, and how much was evidence chasing?
• Culture: do engineering and procurement teams ask GRC for input before a decision, or after it is made?

Moving up a level

From Ad hoc to Developing

1. Name a GRC owner with time to do the job, and agree who signs risk acceptances.
2. Start one risk register with owner, likelihood, impact, treatment and review date for each risk.
3. List your obligations: regulations, certifications and the security clauses in your largest customer and supplier contracts.
4. Assign an owner and review date to every policy, and retire templates nobody follows.

From Developing to Defined

1. Approve a governance charter, a risk methodology aligned to ISO 31000 and a risk appetite statement with testable tolerances (CSF GV.RM-02).
2. Choose one common control framework and map every obligation to it, recording the mapping rationale. See the Control Mapping Guide.
3. Define the evidence each control needs, its frequency and its source system, and start a planned internal audit cycle. See the ISO 27001 Certification Guide.
4. Tier suppliers by criticality and data access, and set due diligence per tier. See the Security Questionnaires Guide.
5. Move risks, controls, policies and evidence from spreadsheets into a structured repository with workflow. See the GRC Platform Buyer's Guide.

From Defined to Managed

1. Quantify the top five to ten risk scenarios in financial ranges so treatment spend can be compared with expected loss. See the Cyber Risk Quantification Guide.
2. Automate evidence for high-volume technical controls first: MFA coverage, privileged accounts, encryption, logging and patch status. Run automated tests alongside manual sampling for one audit cycle before relying on them, and keep the manual procedure as the fallback if an integration breaks.
3. Monitor critical suppliers continuously, and record critical ICT providers in a register (a legal requirement for financial entities under DORA Art. 28). See the DORA Guide.
4. Report key risk indicators against appetite thresholds to the board each quarter.

From Managed to Optimised

1. Roll cyber risks into the enterprise risk register using the approach in NIST IR 8286 Rev. 1, so executives see cyber next to financial and operational risk.
2. Hold controls, mappings and assessment results in a machine-readable format such as NIST OSCAL, so a new framework version becomes a mapping update rather than a project.
3. Run compliance checks in deployment pipelines and cloud policy, so non-compliant changes are blocked before audit finds them.
4. Feed incident, near-miss and audit lessons back into control design and appetite at least annually.

Metrics that show maturity

• Repeat findings: audit and assessment findings that recur from the previous cycle, as a percentage of all findings.
• Overdue treatment: risks above appetite with treatment actions past their due date.
• Automated evidence: percentage of in-scope controls whose evidence is collected from systems rather than by hand.
• Expired exceptions: policy exceptions and risk acceptances past expiry and still in use.
• Critical supplier coverage: percentage of critical suppliers assessed within their review period.
• Time to map: days from a new obligation taking effect to a completed gap assessment against the common control set.

Common failure patterns

• Framework silos: separate teams for ISO 27001, SOC 2 and PCI DSS ask control owners for the same evidence three times. See the SOC 2 Guide.
• Heat maps without a method: red, amber and green ratings with no defined scale cannot be aggregated, so nobody can tell whether risk is rising.
• Appetite on paper: a statement such as "low appetite for cyber risk" with no tolerances never stops a decision, so it is never tested.
• Questionnaire-only third-party risk: suppliers are assessed once at onboarding and never again, while their access grows. In the Marks and Spencer cyberattack, attackers impersonated a third-party user. See the Third-Party Access Guide.
• Tool before process: a GRC platform bought before the control framework and risk method are agreed digitises the spreadsheets, gaps included.
• Evidence without testing: a screenshot of a configured setting proves design, not operation. Access review evidence that shows a review was launched, not that revocations happened, is a common example. See the Access Reviews Guide.

Practitioner checklist

• Set Level 3 as the 12-month target, with Level 4 for risk quantification and evidence automation where regulators or major customers demand it.
• Agree a risk appetite with at least three testable tolerances and get it approved at board level.
• Adopt one common control framework and map every obligation to it before buying more tooling.
• Tier suppliers and focus continuous monitoring on the critical tier.
• Give every policy exception and risk acceptance an owner and an expiry date.
• Reassess annually and whenever a major new obligation, such as NIS2 or DORA, comes into scope. See the NIS2 Directive Guide.

Standards and references

• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• ISO: ISO 31000:2018 Risk management, Guidelines
• OCEG: GRC Capability Model 3.5 (Red Book)
• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management
• NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• NIST: SP 800-137, Information Security Continuous Monitoring
• NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security
• NIST: OSCAL Layers and Models

Related NHI Mgmt Group resources: GRC Platform Buyer's Guide · Control Mapping Guide · Cyber Risk Quantification Guide · NIST SP 800-53 Guide