Clause 6.1.2 (Risk Assessment): Why Most Corporate Risk Registers Fail

Executive answer

Most risk registers do not fail because organisations lack enough risks.

They fail because the risks recorded in them do not lead to better decisions.

A typical corporate risk register contains dozens or hundreds of entries, each with a description, likelihood score, impact score, risk rating, owner and treatment plan. It looks rigorous. It can even produce impressive dashboards.

Then nothing happens.

The highest-rated risks remain open for months. Risk scores are adjusted during review meetings without materially changing the underlying exposure. Owners are assigned to risks they cannot actually influence. Treatment plans become collections of vague actions such as “improve monitoring” or “review controls”.

The register becomes an administrative artefact rather than a management instrument.

ISO/IEC 27001 Clause 6.1.2 requires organisations to establish and maintain an information security risk assessment process. That process needs defined criteria, consistent results and a method for identifying, analysing and evaluating information security risks.

The important word is process.

A risk register is only one output of that process.

If the organisation spends more effort maintaining the spreadsheet than making decisions from it, the spreadsheet has become the system instead of supporting the system.

The scoring illusion

One of the easiest ways to make a risk register look sophisticated is to add more numbers.

Likelihood: 4.

Impact: 5.

Inherent risk: 20.

Control effectiveness: 60%.

Residual risk: 8.

Risk appetite: Medium.

Everything appears measurable.

But measurement is not the same as understanding.

Consider a critical SaaS platform supporting the organisation’s primary revenue stream.

A risk assessment might calculate a moderate likelihood of prolonged service disruption and a high business impact. The resulting score is perhaps “High”.

Another system might calculate the exact same risk as “Critical”.

Neither number tells leadership what to do.

The useful questions are elsewhere:

What would actually cause the disruption?

Which business processes depend on the system?

Which assets and suppliers are involved?

What controls currently reduce the exposure?

Where are those controls weak?

How quickly could the organisation detect the failure?

How quickly could it recover?

Who owns the resulting business risk?

What treatment options exist?

What would each option cost?

What residual exposure would remain?

A numerical score can support those conversations.

It cannot replace them.

This is why two organisations can use identical scoring formulas and still produce radically different quality of risk decisions.

The mathematics is rarely the difficult part.

The difficult part is translating uncertainty into an informed organisational decision.

A risk register is not a list of things that could go wrong

Another common problem is treating every undesirable condition as a risk.

“Legacy systems.”

“Insufficient security awareness.”

“Third-party dependency.”

“Ransomware.”

“Cloud misconfiguration.”

These may all be relevant.

But they are not automatically well-defined risks.

A useful information security risk assessment needs to establish a relationship between a source of risk, an event or scenario and its consequences.

For example:

A third-party identity provider becomes unavailable, preventing employees from authenticating to critical business applications, resulting in prolonged operational disruption.

That description is considerably more useful than:

“Third-party risk.”

The difference matters because treatment depends on the scenario.

If the problem is supplier concentration, the treatment might involve architectural redundancy.

If the problem is insufficient contractual protection, the treatment might involve supplier requirements and contractual clauses.

If the problem is inadequate monitoring, the treatment might involve detection and escalation mechanisms.

If the problem is that nobody knows which critical services depend on the supplier, the first treatment may simply be establishing that dependency.

A risk statement that cannot explain what could happen is difficult to treat intelligently.

The hidden problem: risk ownership

Risk registers also inherit the ownership problem discussed in Clause 5.

A risk is assigned to someone.

That person attends the review meeting.

The risk remains open.

Another month passes.

The status is updated from “Open” to “In Progress”.

Nothing meaningful changes.

This often happens because the nominated risk owner is not actually the person with authority over the underlying decision.

A CISO might be assigned responsibility for a risk involving an unsupported business application.

But the CISO does not own the application.

The application owner does.

The CISO can assess the security exposure and recommend treatment. The application owner can decide whether to migrate, replace, isolate or retire the system, subject to the appropriate governance and resource decisions.

This distinction is essential.

A risk owner should not simply be the person who discovered the risk.

The risk owner should have sufficient authority and organisational context to make or influence the decision about how that risk is treated.

Otherwise the register records accountability without creating it.

What Clause 6.1.2 should produce

A mature risk assessment process should allow the organisation to move through a clear chain:

Identify → Analyse → Evaluate → Decide → Treat → Monitor

The risk assessment itself covers the identification, analysis and evaluation of risks.

The important transition comes afterwards.

What happens because the risk was assessed?

Suppose an organisation identifies that a critical supplier has excessive access to sensitive information.

The assessment establishes the exposure.

The evaluation determines that the risk exceeds the organisation’s acceptance criteria.

Now a decision is required.

The organisation could reduce the access.

It could introduce additional monitoring.

It could change the contractual arrangement.

It could migrate to another supplier.

It could accept the residual risk if an authorised decision-maker determines that acceptance is appropriate.

The assessment has therefore done its job when it enables a decision.

It has not done its job simply because the risk has been assigned a score.

The difference between inherent and residual risk

Another area where risk registers frequently become misleading is the relationship between inherent and residual risk.

The basic concept is straightforward.

Inherent risk represents the exposure before considering relevant controls.

Residual risk represents the exposure that remains after controls or treatments are taken into account.

The problem is that organisations sometimes treat these values as mathematical decorations rather than management concepts.

For example:

Inherent risk: 20 Control effectiveness: 80% Residual risk: 4

That calculation may look precise.

But what does “80% effective” actually mean?

Does the control prevent the scenario 80% of the time?

Does it reduce the impact by 80%?

Does it operate effectively 80% of the time?

Or was 80% simply selected because the control is considered “mostly effective”?

Without a defined assessment methodology, the number creates false precision.

A better approach is to establish what the controls actually change.

If multi-factor authentication reduces the probability of an account takeover scenario, the assessment should consider that reduction.

If immutable backups reduce the consequences of ransomware, the assessment should consider that reduction.

If neither control addresses the specific scenario, their existence should not automatically make the residual risk lower.

Controls reduce risk because of what they actually do, not because they appear in a control catalogue.

Risk appetite is supposed to matter

A surprisingly common failure is having a risk appetite statement that never affects a risk decision.

The organisation says it has “low tolerance for cybersecurity risk”.

The risk register contains twelve high risks.

Nothing happens.

That creates a governance contradiction.

Risk appetite only becomes useful when connected to decision thresholds.

For example:

Risks within tolerance may be managed by the relevant operational owner.

Risks approaching a defined threshold may require additional treatment or management review.

Risks exceeding the accepted tolerance may require formal escalation and an explicit decision.

The exact thresholds depend on the organisation.

A financial institution, healthcare provider and software company will not necessarily have the same tolerance for availability, confidentiality or regulatory exposure.

The important thing is that the criteria are defined before the organisation needs to make the difficult decision.

Otherwise risk appetite becomes a sentence in a policy rather than a constraint on management behaviour.

What good looks like

A defensible risk assessment system is usually simpler than the average corporate risk register.

It starts with a consistent methodology.

The organisation defines:

What constitutes an information security risk?

How are risks identified?

Which likelihood and impact criteria are used?

What makes a risk low, medium, high or unacceptable?

How are existing controls considered?

Who can accept residual risk?

When must a risk be escalated?

How frequently must risks be reassessed?

What triggers an assessment outside the normal review cycle?

Those triggers are particularly important.

A risk assessment should not necessarily wait for the annual review.

A major acquisition changes the organisation.

A new cloud platform changes the technology environment.

A critical supplier changes its architecture.

A significant security incident provides new information.

A new regulation changes the consequences of failure.

A major product launch changes the organisation’s threat exposure.

These events can invalidate assumptions on which an earlier risk assessment was based.

A living risk management process therefore responds to material change rather than simply following a calendar.

Build the register around decisions

One of the most useful practical changes an organisation can make is to redesign the risk register around decisions rather than descriptions.

For every material risk, leadership should be able to see:

Risk scenario: What could happen?

Business consequence: Why does it matter?

Current exposure: What is the organisation’s position today?

Existing controls: What already reduces the risk?

Residual exposure: What remains after those controls?

Risk owner: Who has authority over the decision?

Treatment decision: What are we going to do?

Resources: What does that decision require?

Target date: When should the treatment be complete?

Acceptance: If exposure remains, who authorised accepting it?

Review trigger: What would cause us to reassess it?

This changes the character of the register.

It becomes less like an inventory and more like a management queue.

That is much closer to what an effective ISMS needs.

Evidence should follow the decision

The quality of a risk assessment is also visible in its evidence.

An auditor should be able to trace a material risk through the management system:

Risk identified → assessment performed → risk evaluated against defined criteria → treatment or acceptance decision → owner assigned → action implemented → effectiveness reviewed.

The evidence does not need to be enormous.

A concise assessment with a clear decision can be stronger than a twenty-page risk report nobody reads.

For example, if leadership formally accepts a residual risk because remediation would require replacing a core platform within six months, the evidence should show the decision, its rationale, the accountable owner and the conditions under which the decision will be revisited.

That is defensible governance.

It also prevents the risk register from becoming a graveyard of permanently open items.

The spreadsheet is not the problem

It is tempting to blame spreadsheets.

Sometimes that is justified.

But replacing an Excel risk register with a GRC platform does not automatically solve the underlying problem.

A badly designed risk process implemented in MetricStream, ServiceNow or another GRC platform is still a badly designed risk process.

The technology can improve workflow, notifications, evidence collection and reporting.

It cannot decide what constitutes an acceptable risk for the business.

That requires governance.

In fact, organisations sometimes make the problem worse by implementing sophisticated GRC tooling before agreeing on their methodology.

The result is an expensive system that automates ambiguity.

The better sequence is the reverse:

Define the decision model → establish the methodology → clarify ownership → then automate the workflow.

Technology should make good governance easier to operate.

It should not be used to disguise the absence of governance.

A practical test for your risk register

Take your ten highest-rated information security risks.

For each one, ask five questions:

Can we clearly describe the scenario?

If not, the risk may be too vague to treat.

Can we explain why the current score is what it is?

If not, the methodology may be producing false precision.

Does the named owner have authority over the relevant decision?

If not, ownership is probably misassigned.

Has the risk rating actually changed a decision?

If not, the assessment may not be connected to governance.

Can we trace the risk to evidence of treatment or acceptance?

If not, the register may be recording risks without managing them.

This exercise often reveals more than another annual risk-register review.

Executive takeaway

The purpose of an information security risk assessment is not to create a perfect list of everything that might go wrong.

It is to give the organisation a repeatable way to understand uncertainty, compare exposure against defined criteria and make defensible decisions about what to do next.

That is why the quality of a risk register cannot be judged by its size, its colour coding or the sophistication of its scoring formula.

Judge it by what happens after a risk is recorded.

Does somebody with authority make a decision?

Does the decision result in action, acceptance or escalation?

Does the organisation know what evidence supports that decision?

And does the assessment change when the underlying environment changes?

If the answer is yes, the risk register is doing its job.

If the answer is no, you may not have a risk management system.

You may simply have a very well-maintained list of things everyone already knows are wrong.

The objective of risk assessment is not to produce more accurate numbers. It is to produce better decisions.

This gives the article a different personality from the Clause 5 piece. Clause 5 is fundamentally about who owns the decision. This one is about whether the assessment actually produces a decision at all, with the scoring illusion, false precision and GRC-tooling point giving it more practitioner depth.