Many governance, risk and compliance programmes pass their audits and still fail to tell the organisation where it is exposed, because they manage documents and certificates rather than risk. The ten mistakes below recur in board reporting, audit findings and breach reviews. Each is tied to a published standard (the UK Cyber Governance Code of Practice, NIST CSF 2.0, NIST SP 800-53 or the SEC disclosure rules) or to a live breach in the NHIMG breach database. For each we give the issue, why it matters and what to do. It is written for GRC leads, CISOs, risk managers and internal auditors.
The Top 10 at a glance
The table lists ten common GRC mistakes, each with the standard or incident it is anchored to. Each mistake is then explained with the fix that matters most.
| # | Mistake | Anchor source or incident |
|---|---|---|
| 1 | Treating a certificate as proof of control | NCSC CAF outcomes; Change Healthcare 2024 |
| 2 | No agreed cyber risk appetite | Code action A3; CSF GV.RM-02 |
| 3 | A cyber risk register that lives outside ERM | Code action A2; NCSC Board Toolkit |
| 4 | Inconsistent risk scoring | CSF GV.RM-06; SP 800-53 RA-3 |
| 5 | Point-in-time evidence | SP 800-53 CA-7 |
| 6 | Exceptions and risk acceptances that never expire | SP 800-53 CA-5 |
| 7 | Third-party risk by questionnaire alone | Code action A4; CSF GV.SC-07; Marks and Spencer 2025; Snowflake 2024 |
| 8 | Leaving non-human identities out of scope | Cloudflare 2023 |
| 9 | Reporting activity instead of risk to the board | Code action E2; NCSC Board Toolkit |
| 10 | Untested incident and disclosure decisions | Code action D2; SEC Form 8-K Item 1.05 |
1. Treating a certificate as proof of control
The issue: an ISO/IEC 27001 certificate, SOC 2 report or policy set is taken as evidence that a control works on every system.
Why it matters: certification scopes and sample-based audits miss legacy and out-of-scope assets. The NCSC Cyber Assessment Framework (v4.0) is built around outcomes and indicators of good practice for this reason. At Change Healthcare in 2024, attackers used a stolen credential on a remote-access portal that, according to the CEO's written testimony to Congress, did not have multifactor authentication (see the Change Healthcare Breach 2024).
What to do: test key controls against the full asset inventory, not the audit scope, and report coverage as a percentage. See the NCSC Cyber Assessment Framework (CAF) Guide.
2. No agreed cyber risk appetite
The issue: risks are rated, but nobody has said how much risk is acceptable.
Why it matters: without appetite, every risk looks equally urgent and acceptance decisions are made ad hoc. Code action A3 asks boards to define and communicate a cyber risk appetite; CSF 2.0 GV.RM-02 expects appetite and tolerance statements to be established, communicated and maintained. The NCSC toolkit advises being specific, for example no significant risk to personal data but a day without email is tolerable.
What to do: agree a short, measurable appetite statement with the board. Use the Cyber Risk Appetite Statement Template.
3. A cyber risk register that lives outside ERM
The issue: the security team keeps its own register with its own scale, unseen by the enterprise risk function.
Why it matters: cyber risk never competes for funding with other business risks. Code action A2 asks for senior ownership and integration into enterprise risk management; the NCSC toolkit recommends a cyber risk register within the overall register, with owners and an escalation route covering suppliers, partners and subsidiaries.
What to do: give every cyber risk a business owner and record it in ERM. See the Risk Register Template.
4. Inconsistent risk scoring
The issue: each assessor uses a different scale or method, so a "high" in one business unit is a "medium" in another.
Why it matters: risks cannot be compared or aggregated, and board reporting rests on numbers nobody can reproduce. CSF 2.0 GV.RM-06 calls for a standardised method for calculating, documenting, categorising and prioritising cyber risks; SP 800-53 RA-3 requires documented risk assessments that are reviewed and updated.
What to do: one method, one scale aligned with ERM, calibrated against worked examples each year.
5. Point-in-time evidence
The issue: control evidence is gathered once a year, in screenshots, for the auditor.
Why it matters: controls drift within weeks, and the evidence describes a system that no longer exists. SP 800-53 CA-7 requires continuous monitoring with defined metrics and frequencies.
What to do: automate evidence collection from systems of record for the controls that matter most. See the Audit Evidence and Continuous Controls Monitoring Guide.
6. Exceptions and risk acceptances that never expire
The issue: exceptions are approved by email and never revisited.
Why it matters: temporary gaps become permanent, and the accepting executive has often left. SP 800-53 CA-5 requires a plan of action and milestones that is updated as remediation progresses.
What to do: every exception gets an owner, compensating controls, an expiry date and an entry in the register. See the Security Exceptions and Risk Acceptance Guide.
7. Third-party risk by questionnaire alone
The issue: suppliers are assessed once at onboarding by questionnaire, and the organisation's own use of supplier services is never assessed.
Why it matters: at Marks and Spencer in 2025, attackers got in by impersonating a third-party user, and M&S estimated a £300 million hit to profit (see the Marks and Spencer Cyberattack 2025). In the Snowflake Breach 2024, the gaps were on the customer side: accounts without MFA and stolen credentials that were never rotated. Code action A4 and CSF GV.SC-07 expect supplier risk to be assessed in proportion and monitored over the whole relationship.
What to do: tier suppliers by access and dependency, reassess critical ones at least annually, and assess your own configuration of each SaaS platform. See the Top 10 Third-Party Risk Mistakes.
8. Leaving non-human identities out of scope
The issue: access reviews, joiner-leaver controls and risk assessments cover people only; service accounts, API keys and tokens sit outside the GRC programme.
Why it matters: in the Cloudflare Thanksgiving Breach, one service token and three service account credentials exposed in the Okta support breach were not rotated because they were wrongly believed to be unused, and an attacker used them.
What to do: bring non-human identities into the control framework with owners, rotation evidence and review. See the Identity Security Metrics Guide.
9. Reporting activity instead of risk to the board
The issue: board packs count patches, blocked emails and training completions.
Why it matters: directors cannot tell whether risk is within appetite or what they must decide. Code action E2 asks boards to require formal reporting at least quarterly, with suitable metrics and agreed tolerances. The NCSC toolkit says metrics should map to key business functions and show where investment would help.
What to do: a fixed report of posture against appetite, [8 to 12] metrics with tolerances and an explicit decisions section. Use the Board Cyber Report Template.
10. Untested incident and disclosure decisions
The issue: the incident plan exists, but nobody has rehearsed who decides materiality, notification or taking a service offline.
Why it matters: SEC registrants must file Form 8-K Item 1.05 within four business days of determining an incident is material, and must make that determination without unreasonable delay. Code action D2 expects the plan to be exercised at least annually; SP 800-53 IR-3 requires incident response testing. Executives also carry personal exposure when disclosures are wrong (see the CISO Personal Liability Guide).
What to do: run an annual exercise that includes the board, legal and the disclosure committee. See the Tabletop Exercise Guide.
Mapping to NIST CSF 2.0 and the Cyber Governance Code
| Mistake | UK Cyber Governance Code | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 1. Certificate as proof | E4 | GV.OV-03 | CA-7 |
| 2. No risk appetite | A3 | GV.RM-02 | PM-9 |
| 3. Register outside ERM | A2 | GV.RM | PM-9 |
| 4. Inconsistent scoring | A5 | GV.RM-06 | RA-3 |
| 5. Point-in-time evidence | E4 | GV.OV-03 | CA-7 |
| 6. Exceptions without expiry | A3 | GV.RM-02 | CA-5 |
| 7. Questionnaire-only TPRM | A4 | GV.SC-07 | SR-6 |
| 8. NHIs out of scope | A2, A5 | GV.PO | PM-9 |
| 9. Activity reporting | E2 | GV.OV-01 | PM-6 |
| 10. Untested incident decisions | D2, D3 | ID.IM-01 | IR-3 |
For the full Code, see the UK Cyber Governance Code of Practice Guide.
Where to start
If you can fix only three things this quarter: agree a measurable risk appetite with the board (mistake 2), give every exception an owner and an expiry (mistake 6), and replace the board activity dashboard with posture against appetite (mistake 9). Then track four numbers each quarter: percentage of cyber risks with a business owner in ERM, number of expired exceptions, percentage of critical suppliers assessed in the last 12 months, and percentage of privileged non-human identities with an owner and rotation evidence. To score the programme overall, use the GRC Maturity Model.
Related NHI Mgmt Group resources: UK Cyber Governance Code of Practice Guide · Board Cyber Report Template · Cyber Risk Appetite Statement Template · CISO Personal Liability Guide · GRC Maturity Model