ISO 27001 risk assessment and SoA: keep every decision connected

Risk assessment identifies, analyses, and evaluates information security risk under an approved method. It creates the basis for a decision; it does not select treatment or grant authority to accept risk. Treatment turns an evaluated scenario into an authorized response. The Statement of Applicability then records the controls found necessary, why they are included, their current implementation status, and why an Annex A control is excluded when it has been determined not to be necessary.

Begin with an approved scope or with explicit conditions on the parts still unresolved. Bring the service and interface map, applicable-requirement records, current asset and supplier information, incident and vulnerability records, and people who understand normal operation. If the boundary or population cannot be established, the apparent precision of a score will not make the decision sound.

Keep the governing records distinct. The risk record holds the scenario and assessment. The treatment plan holds the intended outcome and delivery actions. The SoA holds the necessary-control decision and Annex A comparison. Policies, systems, operating records, and evidence sources show implementation and operation; the SoA should point to them rather than trying to contain them.

Performing an annual assessment is an activity, not a purpose. State what the assessment must support and how far its conclusion can travel.

• The decision to be made and the authority that will make it.
• The approved ISMS scope and material interface involved.
• The assessment population, exclusions, time horizon, and method version.
• Participants and the knowledge or authority each contributes.
• Current sources, known limitations, and significant disagreement.
• The point at which missing or conflicting information stops or qualifies the decision.
• The escalation and reassessment route for a result that remains conditional.

A five-level scale or matrix can be a useful starting point, but it is not an ISO requirement. Replace template prompts with organizational decisions and test representative cases before approval.

An asset inventory contributes to coverage but should not silently define the entire assessment. Test the population against sources that expose different omissions.

Labels such as cyber attack, data breach, or supplier risk hide too much. A scenario needs enough structure to support consequence, likelihood, ownership, and treatment decisions.

• The information, service, decision, or dependency affected.
• The source of risk and the relevant event or operating condition.
• The weakness, exposure, or dependency that allows the event to matter.
• The consequence for confidentiality, integrity, availability, or another applicable information security outcome.
• The affected parties, operational extent, period, and circumstances.
• The current controls assumed in the assessment and the evidence for that assumed state.
• Material uncertainty, source references, and any conditions on the conclusion.

Use each source for the proposition it can support. Architecture can establish a dependency, a contract can establish an obligation, incidents show past events, vulnerability information describes a technical condition at a stated time, and operating records show what a process did for a population and period. A broad provider assurance statement should be tied to the service, responsibility, scope, and period it actually covers.

Assess consequence using the approved dimensions and the complete scenario. Preserve the reasoning and source, especially when several effects are material. Apply the method's aggregation rule rather than averaging serious consequences informally.

Give likelihood one declared meaning, such as frequency in a period or probability under stated conditions. Consider the complete path from source and condition to consequence. Frequent scanning does not by itself establish the likelihood of material compromise, and one control record does not establish operation across the full population.

When assessors disagree, identify whether they are using different time horizons, control assumptions, populations, or scale definitions. Resolve the assumption or preserve the materially different views for the decision owner. Voting or averaging should not conceal ambiguity in the method or source base.

1. Confirm the decision, scope, population, method version, participants, and authorities.
2. Review each scenario and its sources before displaying a proposed rating.
3. Examine current controls and the evidence supporting their assumed operation.
4. Assess consequence and likelihood separately under the approved anchors.
5. Record source limitations, uncertainty, dissent, and missing facts.
6. Apply the calculation and evaluation criteria, including any overriding condition.
7. Assign the risk owner, required escalation, and next decision or reassessment trigger.
8. Leave a materially unsupported result open; attendance at the workshop is not approval.

Begin with the result sought for the scenario. A purchase, policy revision, configuration task, or training session may contribute, but none of those tasks states the intended risk change by itself.

Determine controls from the intended treatment outcome and other applicable requirements. Let the need determine the form: organizational, people, physical, technological, contractual, or combined. Define the purpose, boundary, owner, operating criteria, expected record, failure response, and evaluation route for each control.

Use Annex A as a completeness comparison after the organization has determined what it needs. If that comparison exposes a missing or weak control, return to the treatment reasoning. Annex A does not prevent the organization from selecting controls from another appropriate source or designing a control for a need without a convenient one-to-one reference.

ISO/IEC 27002:2022 provides guidance for the 93-control Annex A reference set, organized into organizational, people, physical, and technological themes. Those themes and attributes help navigation and analysis; they do not decide applicability for the organization.

• The controlled identifier and title or reference for the control.
• Whether the control is necessary for the organization.
• The inclusion basis, linked to evaluated risks or other applicable requirements.
• Current implementation status at a stated date, kept separate from applicability.
• The control owner and any shared or provider-operated responsibility.
• The policies, standards, procedures, systems, or other sources implementing the control.
• The destination for operating evidence and later evaluation.
• For an Annex A control determined not to be necessary, a supportable exclusion justification.
• Open actions or conditions, together with approval and review history.

After treatment actions meet their completion conditions, return to the original scenario, scope, population, and approved method. Establish the present control state from evidence and perform the analysis again. Do not reduce the earlier rating by an estimated control percentage.

Where controls have not run long enough under normal conditions, label the result as forecast or target state. State the uncertainty, dependencies, and conditions for continued operation. Residual-risk acceptance is a separate decision: the authorized owner needs the current scenario, delivered treatment, evidence limits, remaining exposure, and an expiry or reassessment trigger.

Late actions, expired exceptions, scope changes, supplier changes, obligations, incidents, audit findings, and failed effectiveness reviews can all reopen the chain. Preserve the earlier decision and what was known at the time; add the new source rather than overwriting history.