Cyber Risk & Compliance Guide: Controls, Evidence and Resilience for GRC Leaders

Share

Who this guide is for

This guide is written for risk, compliance, governance and internal audit leaders who must evidence that controls work, not merely that they exist.

What the risk and compliance function is actually responsible for

• Translating threats into risks with owners, treatment decisions and review dates.
• Defining control objectives that can be tested, rather than described.
• Collecting evidence of control effectiveness on a defensible cycle.
• Third-party risk: obligations, access rights and assurance over supplier controls.
• Managing exceptions and remediation so that accepted risk is genuinely accepted, not forgotten.

The decisions you own, and what you can delegate

• Own the control objectives, the evidence standard, and whether an exception is acceptable.
• Own the assurance plan and the escalation of overdue remediation.
• Delegate control operation and technical implementation.
• Delegate evidence generation, but define the format and the frequency.

Existence, design and effectiveness

Three questions separate a mature programme from a documented one.

1. Does the control exist and is it applied everywhere in scope?
2. Is the design capable of preventing or detecting the failure it claims to address?
3. Has it operated effectively over the period, with evidence that was not produced by the control owner alone?

Physical controls are attractive here because their state is observable. A path that is electrically broken is either broken or it is not, and the record of when it was opened is not a configuration setting that can be quietly changed.

Third-party assurance

• Map which suppliers hold live access, not just which hold data.
• Require evidence of access review, not a policy statement.
• Test whether supplier access can be revoked immediately, and by whom.
• Record the regulatory obligations that flow through to each supplier.

The questions to ask

1. For each principal control, what evidence would satisfy an external auditor without further explanation?
2. Which controls have never been tested independently?
3. How many exceptions are overdue, and who accepted them?
4. Can we produce an access record for third-party maintenance sessions over the last quarter?
5. If a regulator asked how we know our recovery works, what would we hand over?

The evidence checklist

• Risk register entries with owners, treatment decisions and dates.
• Control test results with sample sizes and exceptions.
• Independent assurance reports, internal or external.
• Immutable or offline evidence records for privileged and third-party access.
• Remediation tracking with agreed dates and escalation history.

What happens when preventative controls fail

Prevention buys time. It does not remove the need to answer a simple question: if an attacker holds your identity platform and your management console tonight, what still works tomorrow morning? Most organisations discover that their backup catalogue, their recovery credentials and their runbooks all depend on the systems that have just been taken. That is the dependency worth removing first.

No control removes the possibility of a serious incident. The realistic goal is a smaller blast radius, a recovery path that does not depend on the compromised estate, and evidence that both were tested.

Deciding what you actually need

Compliance frameworks set objectives. They do not, by themselves, deliver resilience, and no product creates regulatory compliance on its own. What a control can do is make the evidence easier to produce and harder to dispute. Firevault is the company. It provides three distinct things, and the honest answer is often that you need one of them rather than all of them.

• Offline Secure Storage® holds a defined set of critical records and clean recovery data physically disconnected from the live estate. It is a protected set, not a replacement for your backup infrastructure.
• Control Modules are a suite of nine purpose-built tools and techniques that give you physical control over the paths into and across your estate. Introduce only the modules that map to the risk you are treating.
• Control Blueprints are proven combinations of those modules assembled for a named outcome, such as containing a live breach or governing third-party access.

If your existing controls already deliver a tested recovery path that survives the compromise of your identity and management planes, and you can evidence it, you may not need any of this. Test that assumption before you buy anything. If you are unsure which of the three applies, the Firevault Concierge walks through the question set without a sales conversation.

The Control Blueprints most relevant to this role

Two blueprints do most of the work in a GRC context. Control by Firevault is a set of nine Control Modules, grouped into the FIRE layer (Firebreak, Isolate, Relay, Execute) and the VAULT layer (Validate, Archive, Unlink, Lock, Transfer). Seven Control Blueprints combine those modules for a specific outcome. You do not need all nine modules, and most organisations start with one blueprint.

• CP-03 Control Third-Party Access uses Validate, Relay, Lock. Read the control third-party access guide.
• CP-06 Prove Compliance Through Control uses Validate, Lock, Archive. Read the prove compliance through control guide.

The full set is on the Control overview and the Control Blueprints index.

CP-06 supports compliance evidence. It does not create compliance. Regulatory outcomes depend on scope, process and governance well beyond any single control.

Where to go next

For the board reporting view, read cyber security for boards. For the regulatory detail, see our NIS2 briefing and ISO/IEC 27001 mapping.

Sources and further reading

• ISO/IEC 27001
• NIST Cybersecurity Framework 2.0
• ICO guidance for organisations
• NIS2 and the UK equivalent regime explained
• NCSC Cyber Security Board Toolkit

About this guide

Author Mark Fermor, Firevault. Reviewed by Firevault compliance review. Last reviewed 28 August 2026.

This guide draws on primary regulatory and technical sources together with Firevault's own field work on physical isolation and offline recovery. It is guidance, not legal advice. Where a legal or regulatory duty is in question, take advice on your own circumstances.

Other guides in this series are listed on the role guide hub.

How Firevault would handle this

A recovery copy an attacker cannot reach

Offline Secure Storage® keeps a clean copy of your data on hardware that is physically disconnected, so backup and recovery do not depend on systems an intruder can touch.