GRC · Playbook
GRC Playbook
A practical guide to proportionate control, not performative control. Standards describe what good looks like. Frameworks describe how you organise risk, controls and evidence. Keep those ideas separate so you do not bury a team in logos, or leave a regulated service with no defensible story.
MAP-01 Control maps
Control & risk maps
Know which framework answers which question before you mandate it.
Every framework below answers a different question. Mandates and standards set floors. Management systems organise how you run security and risk. Control catalogues give you building blocks. Mixing them up is the fastest way to invent parallel paperwork that delivery cannot operate.
Maps you will actually use
| Map | Answers | Shape |
|---|---|---|
| Orange Book | How should risk be governed in UK government? | Principles, appetite, culture, assurance |
| ISO 27001 | How do we run an information security management system? | ISMS requirements · Annex A controls |
| NIST CSF / NCSC CAF | How do we talk cyber outcomes with boards and engineers? | Identify to Recover · outcomes-based CAF |
| UK GDPR / DPA 2018 | What must we do with personal data? | Principles, lawful basis, rights, DPIA |
| Three Lines Model | Who owns, who oversees, who assures independently? | 1st · 2nd · 3rd line accountability |
| GovS / functional standards | What is mandated for government delivery and security? | Shall / should clauses across functions |
Choose in practice
- Board risk conversation: Orange Book principles and a written appetite statement first.
- Certifiable ISMS or supplier assurance: ISO 27001 as the management system spine.
- Engineering cyber outcomes: NCSC CAF or NIST CSF language, mapped to controls you already run.
- Personal data in a digital service: UK GDPR principles and DPIA before build hardens.
- Confused ownership of control failures: redraw Three Lines before adding another policy PDF.
Titles vary: Risk Manager, Compliance Lead, Information Governance, Security Governance, GRC Analyst. The accountability does not. Someone must translate appetite, design proportionate controls, and keep assurance honest. If that person is "the committee", you have theatre.
Accountability ladder (typical digital GRC path)
- Analyst / Associate: evidence packs, register hygiene, sampling under coaching.
- GRC / Risk / Compliance practitioner: accountable for a domain's control design and assurance readiness.
- Senior / Lead: complex or multi-team risk, coaches others, holds coherence across registers.
- Head of Risk / Compliance / Security Governance: owns the profession frame, appetite advice to the board, hiring bar.
What you stop and start doing as you grow
You stop doing
- Writing every control description yourself as the only path to quality
- Saying no to keep the peace, or yes to keep the peace, without residual risk stated
- Measuring your week by policies published
You start doing
- Coaching delivery leads so control evidence falls out of their normal work
- Publishing appetite and exception rules, inviting challenge on inputs
- Measuring your week by residual risk moved and findings that stay closed
Three questions to run every day
If any answer is "no" or "unclear" for more than a week, that becomes the priority over the next logo or policy refresh.
Vague worries clog registers and hide the few risks that need board attention. Write risks so a stranger can act. Separate issues (already happened) from risks (might happen). Link both to treatments with owners and dates.
Anatomy of a useful risk
| Element | Weak version | Strong version |
|---|---|---|
| Event | "Security concerns" | "Unauthorised access to citizen records via compromised privileged account" |
| Cause | "People make mistakes" | "Shared break-glass credentials; no MFA on admin paths" |
| Impact | "Bad for reputation" | "ICO enforcement risk, service suspension, trust loss measured via complaints" |
| Appetite | "We care about this" | "Outside appetite until MFA and access reviews land; residual then within" |
| Treatment | "Improve security" | "Mitigate: MFA by [date], owner [name]; accept residual X with review [date]" |
Risk hygiene
- Top risks reviewed with delivery leads weekly, not only before audit or board.
- Accepted risks have expiry or review dates. Acceptance without a review date is abdication.
- Probability and impact use a published scale. Challenge inflation the same way Product Owners challenge Confidence scores.
- When a risk becomes an issue, move it. Do not leave dual entries that disagree.
In government, map material risks to Orange Book principles and to the SRO's accountability. A risk the SRO has never heard of is not governed; it is hidden.
Prefer preventive and automated controls in the pipeline where the risk justifies the friction. Detective controls need response playbooks, not only alerts. Document the operator, frequency, evidence location and the risk it reduces. Floating controls in policy PDFs do not reduce risk.
Control design checklist
| Question | If unanswered |
|---|---|
| Which risk does this reduce? | It is decoration |
| Who operates it day to day? | It will fail silently |
| Where does evidence live without a special pack? | Audit will invent screenshots |
| What is the compensating control if we exception it? | Exceptions become holes |
| How do we know it still works? | Shelfware until the next incident |
Digital-native control patterns
- Pipeline gates (SAST, dependency scan, IaC policy) with clear fail criteria and override owners.
- Identity controls: MFA, least privilege, joiner-mover-leaver, privileged access timeboxes.
- Change and release controls aligned to how the team actually ships, not a waterfall CAB fiction.
- Logging and monitoring that feed incident response, not dashboards nobody watches.
- Consolidate duplicate controls. Two weak reviews are worse than one operated review.
The Three Lines Model is not an org chart decoration. It is a clarity tool for who designs, who operates, who oversees and who gives independent assurance. Digital delivery fails when second line writes the control, operates the control, and then "assures" the same control.
Who does what
| Line | Owns | Does not own |
|---|---|---|
| 1st (delivery, product, ops) | Risk identification, control operation, evidence in the flow of work | Independent opinion on their own adequacy |
| 2nd (GRC, risk, compliance, security governance) | Frameworks, appetite advice, challenge, thematic assurance, exception governance | Day-to-day control operation for the 1st line |
| 3rd (internal audit) | Independent assurance to board / accounting officer | Designing the controls they will later audit as if they were management |
Assurance that buys trust
- Plan assurance against material risk and change, not only against the calendar of easy samples.
- Reuse first-line telemetry (pipeline results, access reviews, incident metrics) before inventing questionnaires.
- Findings need cause, owner, date and verification of fix. "Agreed" without closure evidence is not assurance.
- Report themes to the board: systemic control failure beats a laundry list of low findings.
In government, join functional standards, Orange Book assurance expectations and any departmental audit committee cadence so you are not inventing a fourth parallel rhythm.
Personal data in digital services triggers UK GDPR and DPA 2018 duties. Your job is to make lawful basis, purpose limitation, minimisation, retention and rights operable for product and engineering, not to bury them in a privacy notice nobody reads.
What must be true before build hardens
| Topic | GRC / IG move | Delivery signal |
|---|---|---|
| Lawful basis & purpose | Documented, challengeable, tied to the service outcome | Stories do not invent new purposes silently |
| DPIA | Triggered early for high-risk processing | Risks and measures land in backlog and architecture |
| Minimisation | Challenge every field and retention period | Schemas and logs do not hoard "just in case" |
| Rights & deletion | Process and technical path exist | Support can fulfil, engineering can evidence |
| Processors | Contracts and due diligence before data flows | No shadow SaaS with citizen data |
- Sit DPIA actions next to RAID and design decisions. A DPIA that never changes the build is theatre.
- Partner with the Data Protection Officer; do not compete with them for the same advice channel.
- Treat accessibility of privacy information and clear user language as part of trust, not only legal cover.
- Incidents involving personal data have a clock. Know the reporting path before you need it.
Audit panic is usually a design failure: controls that only exist as Word documents, or evidence that lives in someone's inbox. Aim for evidence that is continuous, attributable and findable.
Evidence that travels
Prefer
- Pipeline results and policy-as-code outcomes
- Access review exports with tickets for exceptions
- Decision logs, change records, incident timelines
- DORA and reliability metrics next to change risk narratives
Avoid
- Screenshot archaeology the week before fieldwork
- Unsigned policies with no version history
- "We all know how it works" oral tradition
- Parallel evidence packs that disagree with the live system
Control: …
Risk linked: …
Operator: … · Frequency: …
Where evidence lives: …
Last tested: … · Result: … · Owner of gaps: …
ISO 27001 readiness without theatre
- Statement of Applicability maps to real controls, not hope.
- Internal audits find something real before the external auditor does.
- Management review discusses residual risk and resources, not only certificate dates.
- Nonconformities close with cause analysis, not only "training reminded".
Risk appetite is useless as a poster. It becomes useful when teams can decide "within / outside" on real choices: ship with this gap, delay, or compensate. Exceptions are how you stay honest when reality will not wait for the perfect control.
Exception hygiene
| Field | Good looks like |
|---|---|
| Request | Named control, named risk, why compliance is not possible yet |
| Compensating control | Something real and operated, not "we will be careful" |
| Approver | Matches appetite authority, not whoever is free in chat |
| Expiry | Hard date; renewal requires fresh residual risk view |
| Visibility | On the risk register and known to the SRO if material |
- Publish who can accept which residual risk levels. Ambiguity here creates shadow acceptances.
- Never let tooling exceptions (skipped scans, shared accounts) live only in a Slack thread.
- Track exception age as a metric. A rising pile is a control design problem, not a team attitude problem.
The facts do not change between a control workshop and an audit committee. The altitude, the framing and the ask do. GRC loses trust when it lectures in jargon, or when it hides bad news until fieldwork.
Audience calibration
| Audience | Detail level | What they want |
|---|---|---|
| Delivery / engineering | High, concrete control and evidence path | Clarity, proportionality, cover from noise |
| Product / SRO | Medium, residual risk and options | Trade-offs and a recommendation |
| Board / audit committee | Low, themes and appetite breaches | Honesty, trend, clear ask |
| External auditor | Precise, attributable evidence | Traceability from risk to control to sample |
Risk: [future event in one line]
Current residual: [RAG / score] because [single biggest driver]
Options: A / B / C with trade-offs
Recommendation: …
Decision needed by: … · Owner: …
Finding: …
Impact if unfixed: …
Root cause hypothesis: …
Fix: action, owner, date · Verify: how we will know it stuck
Words to drop
| Drop | Use |
|---|---|
| "That's non-compliant" | "Outside appetite / policy: residual is X. Options are…" |
| "Audit will fail us" | "Evidence gap on control Y. Close by [date] or exception with compensator" |
| "Security says no" | "[Named role] recommends delay / compensate because [risk]" |
The cheapest control is the one designed into the service. Late GRC reviews create either unsafe ship pressure or last-minute freezes. Neither builds trust.
Where to embed
Early
- Discovery: data, users, threat and obligation scan
- Architecture: trust boundaries, logging, identity
- Definition of Ready / Done: security and privacy criteria
Continuous
- Pipeline policy exceptions reviewed weekly
- Incident learnings fed into control changes
- Service assessment evidence kept warm in government
- Agree a lightweight review SLA so teams know when to engage you without booking a three-week gate.
- Prefer attending refinement for high-risk slices over inventing a separate "compliance backlog".
- Share one RAID language with Delivery Managers and Project Managers. Parallel registers are a finding waiting to happen.
- Celebrate early reds. Punishing honesty creates watermelon control RAG.
For UK public services, map control and privacy evidence to Service Standard and functional standards continuously. Assessment should not be the first time anyone asks where the DPIA or access model lives.
Under pressure, the instinct is to add another policy, checklist or steercase. Diagnose first. Checkbox compliance and control theatre are usually symptoms of unclear ownership, unoperable controls or appetite without teeth.
| Symptom | Likely cause | First move |
|---|---|---|
| Checkbox compliance: green matrices, unchanged risk | Controls not mapped to risks or not operated | Pick the top five risks. Trace each to an operated control or mark as gap today |
| Control theatre: heavy process, no evidence in the flow | Second line designing paperwork first line cannot run | Move one control into pipeline or existing ceremony this fortnight |
| Audit scramble | Evidence not continuous | Name evidence locations for material controls; kill screenshot week |
| Forever exceptions | No expiry authority or fear of saying no | Timebox all open exceptions; escalate aged ones to appetite owner |
| Delivery avoids GRC until go-live | You are seen only as a blocker | Publish a fast-path review SLA; join one discovery this week |
| Watermelon control RAG | Honesty is punished | Publicly thank the next early red; fix the reporting incentive |
| Duplicate risk registers | No shared taxonomy with DM / PM | Agree one material-risk list and owners this week |
| DPIA never changes the build | DPIA treated as a form, not a decision tool | Convert open DPIA risks into backlog items with owners |
| Findings reopen after "closed" | Symptom fixed, cause not | Require cause + verify step before closure |
| ISO / policy shelfware | Management system divorced from delivery | Rewrite one procedure from how the team actually ships |
The one-minute checklist
- Name the single biggest residual risk in one sentence.
- Is the pain ownership, control design, evidence, appetite or data protection?
- Which decision unlocks the most risk reduction, and who owns it?
- Tell the SRO / appetite owner before they hear a distorted version.
- Protect delivery from noise while you sort the control path.
Glossary anchors
- Orange Book: UK government risk management principles
- ISMS: Information Security Management System (ISO 27001)
- SoA: Statement of Applicability
- CAF: NCSC Cyber Assessment Framework
- DPIA: Data Protection Impact Assessment
- Three Lines: own, oversee, independently assure
- UK GDPR / DPA 2018: personal data law in the UK
- Residual risk: risk left after treatments
- Compensating control: alternative control when primary is exceptioned
- RAID: Risks, Assumptions, Issues, Dependencies
- RAG: Red, Amber, Green status
- SRO: Senior Responsible Owner
Companion: the cheatsheet distils every section into a one-screen field reference.