A framework is just a named way of working. Pick the lightest one that answers the question you have today. Each card below says what it is, when to use it, how a GRC practitioner might apply it, what goes wrong, and where to read more.
Cards start folded. Expand one at a time. The open card fills the width and the rest move below.
UK government risk
Orange Book
HM Treasury guidance on the principles of risk management in government, covering culture, appetite, governance and assurance.
When to use it
UK public sector risk governance conversations
Need a shared language with SRO and board
Designing appetite and assurance expectations
Example for a GRC
Anchor board risk conversations in Orange Book principles. Translate appetite into thresholds delivery can apply, and ensure material digital risks are visible to the SRO, not buried in a team RAID.
Things that go wrong
Quoting principles without changing decisions
Appetite posters with no exception authority
Parallel departmental frameworks that ignore Orange Book coherence
ISMS
ISO/IEC 27001
International standard for establishing, implementing, maintaining and continually improving an information security management system, with Annex A control reference.
When to use it
Need a certifiable or auditable ISMS spine
Supplier assurance requires a recognised management system
Control catalogue must sit under governance, not as a shopping list
Example for a GRC
Use ISO 27001 as the management system: risk assessment, SoA, internal audit, management review. Map Annex A controls to operated digital controls; do not pretend unused controls are 'applicable' without evidence.
Things that go wrong
Certificate chasing with shelfware procedures
SoA that does not match reality
Ignoring continual improvement between surveillance audits
Cyber outcomes
NIST Cybersecurity Framework
Outcomes-based framework organised around Identify, Protect, Detect, Respond and Recover functions for cyber risk conversations.
When to use it
Board or exec cyber reporting needs a clear outcome language
Mapping disparate controls into a shared story
Cross-organisation cyber maturity discussions
Example for a GRC
Translate engineering and GRC work into NIST CSF functions for exec updates. Use it to spot missing Detect/Respond capability even when Protect controls look dense on paper.
Things that go wrong
Maturity scores without operated evidence
Treating CSF as a mandatory control checklist
Ignoring Recover until after a major incident
Civil Service / UK cyber
NCSC Cyber Assessment Framework
NCSC outcomes-based framework used widely in UK government and critical sectors to assess cyber resilience.
When to use it
UK government or CNI-aligned cyber assurance
Need outcomes language engineers and assessors share
Preparing for departmental or sector cyber assessments
Example for a GRC
Map CAF outcomes to your operated controls and evidence sources. Prefer CAF for UK public-sector cyber conversations where NIST language is less familiar to assurance partners.
Things that go wrong
Paper conformance without resilience in practice
Leaving incident response outcomes until last
Duplicate CAF and ISO narratives that disagree
Data protection
UK GDPR / DPA 2018
UK data protection law setting principles, lawful bases, individual rights and accountability duties for personal data processing.
When to use it
Any service processing personal data
DPIA triggers for high-risk processing
Processor and international transfer decisions
Example for a GRC
Make lawful basis, minimisation, retention and rights operable in product and engineering. Ensure DPIA actions become backlog and architecture changes, and that breach reporting paths are practised.
Things that go wrong
Privacy notice as the only control
DPIA as a form that never changes design
Shadow processors and 'temporary' data hoarding
Assurance
Three Lines Model
IIA model clarifying first-line ownership, second-line oversight and third-line independent assurance.
When to use it
Unclear who owns control failures
Second line is operating what it should challenge
Board needs clarity on assurance coverage
Example for a GRC
Redraw accountabilities when GRC is both writing and 'assuring' the same controls. Push operation to first line, keep challenge in second, protect internal audit independence.
Things that go wrong
Org-chart labelling without behaviour change
Third line designing management controls
Second-line bottlenecks that freeze delivery
Control catalogue
CIS Critical Security Controls
Prioritised set of defensive controls commonly used as a practical starting catalogue for cyber hygiene.
When to use it
Need a pragmatic control baseline before a full ISMS
Prioritising technical hygiene with engineering
Supplier or internal minimum control expectations
Example for a GRC
Use CIS Controls as a conversation with DevOps/SRE about identity, logging and vulnerability management. Map chosen controls into your ISMS or CAF story rather than running a third parallel list.
Things that go wrong
Implementing all controls at equal priority
Catalogue without operators or evidence
Ignoring higher-risk business processes outside IT hygiene
IT governance
COBIT
ISACA framework for governing and managing enterprise information and technology, linking objectives to processes and practices.
When to use it
Enterprise IT governance redesign
Need to link business objectives to IT control processes
Audit and management need a shared process language
Example for a GRC
Borrow COBIT's goal cascade when execs ask how digital controls serve organisational objectives. Keep the adoption light: process intent over wholesale COBIT bureaucracy.
Things that go wrong
Heavyweight process documentation nobody reads
Using COBIT to justify more committees
Disconnect from how agile teams actually deliver
Quantitative risk
FAIR
Factor Analysis of Information Risk: a model for analysing frequency and magnitude of loss to support more quantitative cyber risk decisions.
Comparing treatment options with rough financial impact
Challenging gut-feel 'critical' labels
Example for a GRC
Use FAIR-style decomposition when two treatments compete for budget. Keep ranges honest and document assumptions; do not fake precision.
Things that go wrong
Pseudo-precision from invented numbers
Ignoring qualitative harm (trust, rights) that money poorly captures
Model theatre without decision change
Service management
ITIL change enablement
ITIL practices for enabling changes with appropriate risk assessment, authorisation and review without freezing flow.
When to use it
Operational change risk needs a clear path
CAB theatre is blocking safe continuous delivery
Need shared language with service management teams
Example for a GRC
Help redesign change enablement so standard changes flow through pipeline evidence, while high-risk changes get human review. Kill CAB as a weekly status meeting.
Things that go wrong
Every change treated as high risk
Change records that disagree with deploy reality
No feedback from incidents into change models
Civil Service standard
GDS Service Standard
Fourteen points on meeting user needs, providing a good service, and using the right technology, including privacy, security and openness expectations.
When to use it
UK public service build or iteration
Service assessment preparation
Need GRC evidence joined to product and design quality
Example for a GRC
Attach security, privacy and data evidence to Service Standard points continuously. Partner with Delivery Manager and Product Owner so assessment is not a GRC-only scramble.
Things that go wrong
Treating assessment as paperwork
Security evidence owned only by GRC, invisible to the service team
Leaving DPIA and access model to the week of assessment
Civil Service standard
GovS functional standards
Mandated government functional standards suite (including project delivery and related functions) using shall/should language for governance expectations.
When to use it
Government programme or organisational control design
Need to push back on invented local bureaucracy
Aligning PMO, risk and digital delivery expectations
Example for a GRC
Map your risk and assurance rhythm to relevant GovS shall clauses. Use the standard to insist on what is required and to refuse gold-plated local process that is not.
Things that go wrong
Gold-plating beyond the standard
Ignoring shall clauses until assurance arrives
Multiple functional standards interpreted into conflicting gates
Sector control standard
PCI DSS
Payment Card Industry Data Security Standard for environments that store, process or transmit cardholder data.
When to use it
Card payments are in scope
Need to minimise PCI scope via architecture
Supplier payment integrations require evidence
Example for a GRC
Push hard for scope reduction (tokenisation, hosted payment pages) before building a large PCI control estate. Treat residual in-scope systems with operated evidence, not annual panic.
Things that go wrong
Pulling card data into systems unnecessarily
Annual evidence scramble
Assuming SaaS shifts all accountability away
Change
ADKAR
Individual change journey: Awareness, Desire, Knowledge, Ability, Reinforcement. Useful when control adoption depends on staff behaviour.
When to use it
New control ways of working meet quiet non-compliance
Training alone is not changing behaviour
Policy refresh needs adoption, not only publication
Example for a GRC
When a new control fails in practice, diagnose ADKAR stage before writing a longer policy. Partner with Change Management on Desire and Reinforcement, not only Knowledge.