Structuring ISO 27005 risk analysis without creating an unusable process

Many risk analyses fail for a very simple reason: they become too heavy before they become useful.

An ambitious workshop is launched, too many columns and scoring rules are introduced, and a few weeks later the organisation is left with a support file that is difficult to read, difficult to maintain and not very helpful for decision-making.

That is exactly what should be avoided. A risk analysis is not valuable because it looks sophisticated. It is valuable because it makes context readable, surfaces credible scenarios, supports decisions and leads to actions people can actually follow.

An ISO 27005-style approach can be extremely useful, provided it stays pragmatic. The objective is not to produce a theoretical object. The objective is to produce an analysis that is serious, reviewable, human-validated and still workable in the real world, including in environments where an Excel workbook remains the most practical format for discussion.

Key takeaway ISO 27005 is most useful when it keeps the reasoning chain clear: context, assets, scenarios, evaluation, treatment and validation. The method must remain readable for the people who actually arbitrate risk.

What ISO 27005 usefully brings to the table

ISO 27005 is helpful first because it gives structure to the thought process. It reminds teams that credible risk analysis does not begin with a score. It begins with context, scope, assets, scenarios, evaluation criteria and treatment options.

That matters because it forces risk discussion back into operational reality. Instead of talking about “cyber risk” in the abstract, the organisation has to discuss risk in relation to real assets, real activities, dependencies and business impact.

This structure helps avoid two opposite failures:

• a risk analysis that stays vague and generic;
• a risk analysis that becomes so detailed that nobody can review or update it properly.

The point of an ISO 27005-readable approach is not to add complexity. It is to maintain a coherent frame.

Start with context and scope

The first question is not “what are our risks?” but “what exactly are we analysing?”

A credible analysis should define the organisational scope, the relevant activities or processes, the initial assumptions and the criteria that will later be used for severity or prioritisation.

This step is often rushed even though it determines everything that follows. If the scope is unclear, assets will be described badly, scenarios will become generic, and treatment decisions will lose relevance.

For an SMB or a mid-market organisation, the right level is not necessarily encyclopaedic. The frame should mainly help teams understand what supports the business, what deserves protection and where significant impact could materialise.

Build a readable asset inventory before discussing scenarios

Another classic mistake is moving too quickly into threats and controls before stabilising the inventory.

If assets are badly identified, duplicated, grouped arbitrarily or described in a way that nobody recognises, the rest of the analysis will be weaker. The goal is not to produce the longest list possible. It is to build an inventory that is readable, sufficiently complete and usable.

In a pragmatic approach, it is often better to work with coherent groups rather than with excessive granularity. Well-named groups that make sense to a security lead or decision-maker are often more useful than technical fragmentation that complicates review without improving treatment.

A simple test helps: can an informed third party quickly understand what each asset or asset group represents, and why it matters within the scope under analysis?

Write credible scenarios, not generic threat labels

Once context and assets are stable enough, the analysis can move to scenarios.

The most common trap is using labels that are too broad: “cyberattack”, “human error”, “outage”, “data leak”. Such categories may point in the right direction, but they are not specific enough to support prioritisation or treatment.

A strong scenario should make a plausible chain clear:

• which asset or asset group is concerned;
• what event or weakness creates the exposure;
• what business, operational, financial or compliance impact may follow;
• why that scenario deserves to be retained.

The level of detail should remain reasonable. This is not about writing a short novel for each scenario. It is about making the analysis concrete enough to support qualification and treatment.

Evaluate without over-engineering

The evaluation phase is often where risk analysis becomes unusable. Too many scales, too many secondary criteria and too many hidden weightings, and the team ends up debating the model more than the risk.

A healthier approach is to keep an evaluation model that is clear, explainable and repeatable. Depending on the organisation, that may rely on likelihood, impact or a combination of both, but the criteria should remain readable in plain operational language.

What matters is not the illusion of mathematical precision. What matters is enabling:

• consistent qualification across scenarios;
• a discussion that responsible stakeholders can understand;
• defensible prioritisation;
• periodic updates without reopening the entire method each time.

If no one feels able to revisit a rating without starting the whole exercise again, the model is already too heavy.

Common drift	Useful approach
Add criteria until review stalls	Keep the evaluation model explainable
Produce an isolated score	Connect the score to scenario and treatment
Freeze everything in the method	Plan periodic review and updates

Move from risk to treatment

A useful risk analysis does not stop at scoring. It prepares decisions.

Each retained scenario should lead to a treatment logic: reduction, transfer, controlled acceptance, documentation reinforcement, follow-up action or later review depending on context and available means.

What matters is that this choice is explicit. Too many analyses end as a snapshot of risk without a clear link to a work programme. The document may look complete, but it does not help the organisation decide or follow through.

A workable support file should therefore show, for each important topic, the priority level, the treatment choice, the owner, the target timing or review rhythm and the current status.

Why a readable workbook still matters

In many environments, Excel remains the document that is most easily reviewed, shared and discussed. That is not a weakness in itself. It is often an advantage when the workbook is clear.

A readable workbook helps teams:

• review assets and scenarios with business stakeholders;
• challenge the consistency of evaluations;
• prepare human validation;
• hand over or export a format that remains understandable outside the tool;
• retain a durable working record.

The point is not to oppose method and readability. The point is to make sure the method produces an artefact that humans can actually use.

MONARC compatibility is useful, but only if meaning stays intact

Compatibility with MONARC can be valuable when an organisation or consultant wants to preserve structure or familiar vocabulary.

But one rule matters: compatibility should not strip the analysis of operational meaning. The workbook, asset groups, scenarios and treatments must first make sense to the people who will act on them.

In practical terms, it is better to start from a readable, human-reviewed analysis and then produce compatible outputs where relevant, rather than starting from an output format and trying to recover meaning afterwards.

Pitfalls worth watching closely

Three pitfalls deserve particular attention:

• catch-all asset groups that hide very different realities;
• uncontrolled scenario growth without clear hierarchy;
• a risk analysis prepared quickly but never really owned by the people who know the environment.

The catch-all inventory shortcut is especially tempting when the work gets dense. It makes data entry easier, but it weakens the risk reading sharply.

Conclusion

An ISO 27005-readable risk analysis does not need to become a process no one can live with. It needs to keep the thread: context, assets, scenarios, evaluation, treatment and human validation.

The Torus Risk Analysis page shows how guided steps, readable workbooks and human validation can connect in practice.