Practice 01 · Security GRC
Compliance proves you did the work. Governance proves you made the call.
Security governance, risk and compliance built around decisions: who may accept a risk, how much the business will tolerate, and what evidence shows the controls work. Rigorous enough for regulators and auditors, light enough for your teams to run.
The problem
Audits pass. The board still can't say what it has accepted.
GRC often grows as a collection of policies, questionnaires and registers. Each satisfies someone. Together, they rarely tell leadership where the business is exposed, or who decided that was acceptable.
Risk lands with the security team by default.
The people who run the controls end up owning exposures they have no authority to accept.
The register is updated, then filed.
Scores change quarterly, yet no investment, priority or design choice changes with them.
Each framework runs its own programme.
Overlapping obligations are evidenced separately, so teams repeat work and gaps hide between them.
Our approach
Start from the decisions. Build the framework around them.
Four steps, each ending in something leadership can see and agree.
Set decision rights
Agree who owns each critical service and information asset, and who may accept risk on its behalf.
Frame the exposure
Describe risk as business scenarios with consequences that owners recognise, and set appetite in the same terms.
Map controls once
One control framework, mapped to every standard and regulation that applies to you, with a named owner per control.
Prove it and report it
Define the evidence that shows controls work, and report to the board on decisions taken and exposures accepted.
What you get
Six artefacts. One governance system.
Each is written to be used: by the board, by risk owners and by the teams that operate the controls.
Governance model
Roles, committees, decision rights and reporting lines from the board to control owners.
Risk appetite statements
Tolerances in business terms that owners can apply when a decision is in front of them.
Risk scenarios and register
A short list of material scenarios, each with an owner, a treatment decision and a review date.
Policy and control framework
A coherent policy set and one control library, mapped to the standards and regulations that apply to you.
Assurance plan
The evidence each control must produce, how often, and who checks it.
Board reporting pack
A concise view of exposure, decisions needed and progress, built for a committee agenda.
Outcomes
What changes when governance works.
- Leaders know what they have acceptedResidual risk is a recorded decision by its owner, not an unspoken assumption.
- Audit and regulatory questions get one answerThe same mapped controls and evidence serve every framework you report against.
- Security has a clear mandateThe security function advises and operates; owners decide. Both know where the line sits.
- Board time goes on decisionsReporting shows exposure and choices, not a list of activity.
Engagement models
Start where the gap is.
Every engagement is scoped in a proposal before work begins. All ways to engage
GRC health check
An independent review of your governance, risk and compliance arrangements, with a short list of gaps ranked by consequence.
Best when: a new leader, audit finding or regulatory question needs a clear starting point.
GRC framework design
The governance model, appetite, scenarios, control framework and reporting, designed with your people and handed over to run.
Best when: GRC needs to be set up properly or rebuilt.
Governance leadership
Continued GRC leadership through a virtual CISO or advisory role: committees, reporting and the next audit cycle.
Best when: you need senior ownership without a full-time hire.
Questions
Security GRC, answered.
Is this an audit or a certification?
No. This is advice on how security is governed and how risk is decided. It can prepare you for audit or certification and draw on results you already have, but it does not replace an accredited auditor.
We already have policies and a risk register. Do we start again?
Rarely. Existing material is reviewed first and kept where it works. The work concentrates on decision rights, appetite and the mapping that connects what you already have.
Which standards and regulations do you map to?
The ones that apply to your organisation. Which ones apply, and how they overlap, is agreed during scoping.
Who needs to be involved?
An executive sponsor, the owners of your critical services and information, and the people who run security and compliance today. Time requests are agreed in the proposal.
Will our team be able to run it afterwards?
That is the aim. Every artefact is written for the people who will use it, with a handover so the cycle keeps turning without outside help.