Checklist for scoping ISO 27005 risk analysis

An ISO 27005 risk analysis can become heavy very quickly if it starts too soon with tables, scenarios and scoring. The decisive point is often simpler: knowing exactly what is being analysed, why, under which assumptions and who validates the choices.

This checklist helps prepare a solid scope before entering detailed evaluation.

Key takeaway A useful risk analysis is not the one with the most rows. It is the one whose scope, scenarios, decisions and treatments can be reviewed without ambiguity.

1. Define the real scope

Start by stabilising the object of the analysis.

• Organisation, entity, process or client concerned.
• Applications, services, data or assets included.
• Assets excluded or handled in another analysis.
• Objective: audit, security programme, project decision, client review, insurance or compliance.
• Known constraints: deadlines, dependencies, documentation debt, access to stakeholders.

A vague scope almost always produces generic risks.

2. Identify assets without creating catch-all groups

Assets must remain useful for the analysis. If they are too broad, scenarios lose meaning.

• Distinguish business, technical, information and organisational assets where needed.
• Avoid overly global categories such as “IT system” or “infrastructure”.
• Keep a level of detail compatible with the expected decision.
• Check that each asset can be linked to at least one credible scenario.
• Document groupings when they are necessary.

The right level is not the most detailed one. It is the level that supports a decision.

3. Write usable scenarios

A risk scenario should be precise enough to guide evaluation and treatment.

• Describe an understandable event.
• Link the scenario to an asset or process.
• Avoid vague wording such as “cyberattack”.
• Separate causes, impacts and existing measures.
• Limit duplicates between similar scenarios.

If two readers interpret the scenario differently, it probably needs rewriting.

4. Clarify evaluation criteria

Before scoring risks, make sure the criteria are understandable.

• Likelihood levels are defined.
• Impact levels match the context.
• Scales are easy to explain.
• Priority or acceptance thresholds are known.
• Exceptions or arbitrations are recorded.

An evaluation is defensible when the team can explain why a score was chosen.

5. Connect existing measures to risk

Existing measures should not be added as a simple list.

• Each important measure is linked to one or more scenarios.
• Actual maturity is distinguished from intention.
• Available evidence is identified.
• Unverified measures are marked as such.
• Dependencies on third parties or other projects are explicit.

This avoids overestimating the real level of control.

6. Prepare treatment

A useful risk analysis should lead to decisions.

• Reduce, accept, transfer or avoid the risk.
• Define a readable action.
• Assign an owner.
• Give a deadline or priority.
• Identify expected evidence.
• Record decisions when an action is postponed.

Without tracked treatment, the analysis becomes a static document.

7. Plan for human validation

AI can help structure, detect inconsistencies or accelerate preparation. It does not replace business validation.

• Assumptions are reviewed by people who know the scope.
• Critical scenarios are validated with the right stakeholders.
• Decisions are owned by an accountable person.
• Deliverables remain readable outside the tool.
• Exports support review or committee work.

The tool’s role is to help keep the thread together, not to decide for the team.

Warning signs

Revisit the scope if these symptoms appear.

• Too many scenarios look alike.
• Assets are too generic.
• Scores are hard to justify.
• Treatment has no owner.
• The workbook is complete but nobody uses it.
• Important decisions are not recorded.

How Torus fits this logic

The Risk Analysis page presents the Torus approach: guided steps, autonomous Excel workbook, controlled MONARC compatibility and human validation. The goal is to structure a readable analysis, not to generate a black box.