The problem with cyber assurance becoming a paperwork exercise

James Bruckel·CEO, Wuluf

Paperwork is not the problem with cyber assurance. The problem begins when it creates the appearance of control but does not change a decision.

Assurance needs evidence.

Organisations should be able to show how risks are understood, which controls are operating, where gaps remain and who has accepted the residual exposure. The NCSC Cyber Assessment Framework gives organisations a consistent way to assess cyber security and resilience. GovAssure gives Government organisations a structured assessment process. Risk registers make ownership and exposure visible.

Each has a useful job.

Each can also consume a great deal of time while changing very little.

Assessments are completed and evidence libraries grow. Risks are recorded and governance packs become longer. Issues are discussed, carried forward and discussed again. The organisation gets better at describing its security position without getting better at managing it.

That is when assurance becomes paperwork.

Green and red reports can hide the same problem

Our practitioners have seen this across Government and private sector work, including high security environments. In some cases, senior executives had become suspicious of a long run of green reports. When we looked past the status colours and measured the facts against the actual requirements, the position was not green. In some areas it was nowhere near it.

We have also seen reports remain red for months while repeated discussion changed nothing. Neither pattern means the previous team was dishonest or unduly pessimistic. Often, people were expected to improve the report without being given the authority to improve the position.

Red, amber and green summaries have their place. Leaders still need to see the requirement, current coverage or performance, gaps in the evidence and the decision that is needed. The colour should summarise the facts. It should never replace them.

We report the evidence candidly and use it to help secure executive support for real change. Honest reporting matters. Helping leaders act on it matters just as much.

Assurance is supposed to create justified confidence

Cyber assurance should help a decision maker answer one practical question.

Do we have enough current evidence to rely on this service, control or security claim? If we do not, what happens next?

The answer will not always be positive. Good assurance may reveal uncertainty, challenge an optimistic assessment or show that reducing a risk is not currently economical. Its value is in giving the decision maker a clearer basis for acting.

That decision might involve any of the following.

• Fund remediation
• Change a design
• Strengthen a supplier requirement
• Delay or constrain a release
• Gather better evidence
• Add monitoring or recovery capability
• Escalate exposure to a more senior risk owner
• Accept a clearly understood residual risk

If an assurance activity produces none of these, it should at least confirm with credible evidence that existing arrangements remain effective. If it does neither, it is reasonable to ask what the activity achieved.

The framework is not the problem

Frameworks are easy to blame when assurance becomes bureaucratic. The NCSC Cyber Assessment Framework already makes a clear distinction between completing an assessment and managing risk.

CAF 4.0 describes several signs of weak risk management. They include assessments that are too complex for decision makers, one off activity, completing a risk assessment without considering its outcomes, arbitrary controls that are disconnected from risk and risks left unresolved while senior decisions or resources are awaited.

The framework already describes the paperwork trap.

The problem lies in how organisations use it. They pursue an assessment result, a completed template or a comfortable governance story when the real concern should be the cyber resilience of the essential function.

CAF, GovAssure, risk registers and evidence repositories are tools. They can structure thinking, support comparison and expose gaps. They cannot make decisions, allocate budgets, clarify accountability or complete remediation for the organisation.

Good assurance should reduce the burden on the business

Supporting documentation is necessary. The useful question is how much effort the organisation must spend producing it.

If every assessment requires teams to create artefacts from scratch, arrange new procurement for testing and attend bespoke meetings simply to assemble evidence, assurance is taking too much delivery capacity. Some new work is unavoidable, but repeated difficulty suggests that the security function could provide better support.

Where our practitioners have helped clients make assurance easier, they have taken on more of the heavy lifting. That has included standard reusable material, funded testing services that teams can access easily, tools that produce current evidence and governance that leaves more time for judgement and action.

Reusable products must still reflect the service being assessed. Their purpose is to remove repeated administration, not manufacture generic proof. The business should experience security as practical help, not another burden it must navigate alone.

How assurance turns into paperwork

Evidence volume is mistaken for confidence

Large evidence repositories can feel reassuring. There are policies, standards, screenshots, meeting minutes, test reports, supplier responses and control descriptions available for review.

Volume says little about quality.

Useful evidence should be all of the following.

• Relevant to the claim being made
• Current enough to reflect the service as it operates now
• Produced by a source that can be trusted
• Specific to the system, control or risk being assessed
• Sufficient to support a defensible conclusion
• Connected to an owner and a decision

A policy stating that privileged access is reviewed does not show that the review happened, covered the correct accounts or resulted in inappropriate access being removed. A penetration test report does not prove that every significant issue was fixed. A supplier certificate may give confidence in part of the supplier's environment without covering the service or dependency that matters to the organisation.

The purpose of evidence is not to fill a folder. It is to support or challenge a security claim.

The assessment is managed towards the desired rating

When assurance results are visible to senior leadership, oversight bodies or customers, pressure can shift from understanding the risk to improving the assessment.

Teams debate whether an indicator can be marked as achieved. Evidence is framed to support the most favourable interpretation. Gaps become actions with distant completion dates. Nuance is compressed into a red, amber or green status that is easier to report and harder to question.

This is not necessarily deliberate misrepresentation. It can grow from understandable incentives. Nobody wants their programme to be the outlier, delay an approval or create an unfunded remediation obligation.

An assessment engineered to reassure has stopped providing assurance.

A mature process makes uncertainty visible. It distinguishes between the following states.

• A control that is designed
• A control that is implemented
• A control that has been tested
• A control that is operating consistently
• A control that is producing the intended security outcome

Those are not interchangeable states.

The risk register becomes a waiting room

A risk register should connect identified exposure to ownership, treatment, escalation and review. Instead, it can become somewhere risks wait.

The same entries remain open across multiple reporting periods. Treatment plans depend on unallocated budgets. Actions are assigned to teams that cannot prioritise them. Acceptance is implied by inaction but never explicitly authorised.

CAF 4.0 treats risks left unresolved while waiting for senior decisions or resources as a sign of weak practice. The NCSC Board Toolkit also expects the cyber risk register to include ownership and escalation, and to reflect priorities and tolerances endorsed by the board.

Every significant risk should have all of the following.

• A clear description of the possible adverse outcome
• A named owner with appropriate authority
• An agreed treatment or explicit acceptance decision
• Funded and prioritised actions where treatment is required
• A realistic decision or completion date
• Defined escalation when progress stalls
• Review triggers when the service, threat or context changes

Recording a risk is not managing it.

Look at the dates not just the ratings

The dates on a risk register can reveal how it is being used. A risk that has existed for years is not automatically a problem. Some risks endure and require ongoing management. The question is whether ownership, treatment, evidence and review remain current.

If many risks have old review dates, unchanged treatment deadlines or no recent decisions, identification may have become disconnected from remediation. If most entries share similar dates, risk management may be happening as a periodic reporting task instead of part of normal work.

Neither pattern proves failure on its own, although both deserve challenge. Meetings held every few months should not be the only time risk is updated. Material changes need to be considered during the working week, not reconstructed later for the next governance pack.

Evidence describes a service that no longer exists

Assurance evidence begins to age as soon as it is produced.

Architectures change. New integrations are added. Suppliers update their platforms. Teams alter configurations. Vulnerabilities emerge. Threat actors adapt. People and responsibilities move.

Assessments often rely on evidence gathered for the previous review, followed by confirmation that nothing material has changed. That judgement may be made without a dependable view of the technical estate or clear criteria for what counts as material.

Continuous assurance does not require every control to be retested every day. It requires the organisation to understand when its confidence should be reconsidered.

Useful triggers include the following.

• Material architecture or configuration changes
• New suppliers, integrations or data flows
• Changes in use or criticality
• Significant vulnerabilities or incidents
• New threat intelligence
• Control failures or missed operating activities
• Changes to legal, regulatory or contractual obligations
• Expiry of evidence that has a limited useful life

Without those triggers, an evidence library can be comprehensive, orderly and wrong.

Assurance is separated from delivery

Assurance teams are sometimes engaged after decisions have been made and delivery deadlines fixed. They are asked to assess a service but have little influence over its architecture, contracts, roadmap or budget.

This produces a familiar cycle.

Assurance identifies a gap.

Delivery explains why it cannot be resolved within the current plan.

The gap becomes a risk or exception.

Governance records it.

The programme continues largely unchanged.

Independent challenge still matters. The evidence also needs to reach delivery early enough to affect decisions.

Security claims and evidence expectations should be considered during requirements, procurement, architecture and planning. Issues should enter normal delivery backlogs with owners and priority. Material risks should compete openly with cost, schedule and functionality instead of circulating in a separate security process.

Evidence does not reach somebody able to act

A technically accurate assurance report can still fail if it is written for the wrong audience.

Senior decision makers need to understand the possible impact on the service, mission or organisation. They need credible scenarios that could create that impact, the available options and the consequences of delaying action.

They do not always need every control reference or technical detail in the primary report. Those details should remain available, but the decision must be clear.

Useful assurance reporting separates five things.

• The conclusion and the confidence that can reasonably be taken from it
• The exposure, including what could happen and why it matters
• The evidence supporting the conclusion and the places where it is weak
• The options that can be changed, funded, constrained or accepted
• The decision, who must make it and when it is needed

If the person reading the report cannot tell what decision is required, the assurance process has stopped one step too early.

Actions are closed administratively

An assurance action is not complete merely because a document has been updated or evidence has been uploaded.

Closure should show that the underlying issue has been addressed. Depending on the issue, that may require technical validation, observation over time, retesting, confirmation from an independent party or evidence that a new process is operating consistently.

Weak closure asks, “Has the action owner supplied something?”

Strong closure asks, “Does this evidence justify changing our conclusion about the risk or control?”

That distinction prevents activity from being mistaken for improvement.

From paperwork to assurance fit for decisions

Five tests for every assurance activity

Before commissioning another assessment, requesting more evidence or adding another governance return, ask these questions.

What decision will this activity inform?

Who has the authority to make that decision?

What claim are we trying to support or challenge?

What evidence would be sufficient? How current must it be?

What will happen if the evidence is weak or the conclusion is negative?

If those questions cannot be answered, the organisation may be creating paperwork without a route to action.

What leaders should expect from cyber assurance

Leaders should not expect assurance to promise that a service is secure. That conclusion would rarely be defensible.

They should expect it to show all of the following.

• The organisation’s most important cyber security and resilience claims
• The strength and limitations of the evidence behind them
• The material gaps, dependencies and uncertainties
• Whether risks are within agreed tolerance
• Which decisions or investments are required
• Who owns the response
• How confidence will be maintained as the service changes

Good assurance can be uncomfortable. It may expose weak evidence, unresolved dependencies or decisions that have been deferred for too long. That does not mean the assurance team has failed. It means the process has revealed something the organisation needs to address.

A small investigation can support a better investment decision

A common engagement in our practitioners' experience is a focused investigation into a client's cyber health, often supported by technical testing. It gives leaders better information before they commit to a larger investment.

The investigation is not proof that the whole organisation is secure. Its scope and limits matter. Its value comes from replacing assumptions with evidence about the area examined. The client can then decide where further assessment or improvement is justified.

This has a direct commercial consequence. A proportionate initial exercise supports a more prudent investment decision. It may justify further spending or show that money is better directed elsewhere. Either way, the next decision rests on better information.

The test is what changes

CAF assessments, GovAssure, risk registers and compliance evidence all have a useful role. Used well, they create a shared language, expose gaps and give leaders a defensible basis for managing cyber risk.

Producing an artefact does not complete the assurance work.

Look at the decision or action that followed.

Useful assurance can change how a risk is understood, clarify ownership, improve a control, redirect investment, challenge a supplier, change a release decision or secure authorised acceptance of residual risk.