ISO 27001 for IT managers 3: risks, treatment and the Statement of Applicability

Write a risk someone can make a decision about

Use the scope, information map and obligations from part 2. A useful risk describes a plausible event, the weakness or circumstance that enables it and the consequence for information or the business. “Cyber attack” is too broad to assign sensible treatment; “MFA” is a control, not a risk.

For fictional Merefield: an attacker compromises a staff account that can download customer working files, causing unauthorised disclosure and disruption to delivery. Identify the information owner, current access paths and existing controls before rating it. A vulnerability scan can inform that discussion, but it cannot decide the customer or operational impact by itself.

Build scenarios across confidentiality, integrity and availability. Include mistakes, supplier failures and process gaps as well as deliberate attacks. A legitimate employee changing bank details without verification can be as relevant to a small business as a sophisticated intrusion scenario.

Define the rating method before scoring

Choose a repeatable method with understandable likelihood and impact criteria, risk acceptance rules and named owners. ISO 27001 does not require this tutorial's matrix or a particular commercial tool. The purpose of a method is to make decisions comparable and reviewable.

As an illustrative starting point, use likelihood bands from 1 to 3 with written descriptions based on exposure and evidence, and impact bands from 1 to 3 based on agreed business consequences. Multiplying them produces a prioritisation score from 1 to 9, not a probability or a cash-loss estimate. Define how each score is treated before using the results to justify decisions.

Two risks with the same product can still need different treatment. A low-likelihood event with severe contractual consequences deserves discussion even if a matrix puts it beside a frequent minor inconvenience. Record the rationale, uncertainty and obligations, not only the colour of a cell.

Separate current risk from hoped-for improvement

Record current controls and their evidence, then assess the risk as it stands. A future MFA deployment cannot lower today's rating. After implementation and verification, reassess the residual risk and obtain the risk owner's decision. Keep both the original assessment and the later review so the change is explainable.

Possible responses include reducing risk with controls, avoiding the activity, sharing aspects through arrangements such as insurance, or accepting residual risk within approved criteria. Sharing financial exposure does not remove operational responsibility. A contract or legal obligation may constrain what the organisation can accept.

The example intentionally does not claim a universal score. Your owner must judge consequences and acceptance using your method. IT supplies options and evidence; it should not accept a business risk merely because a technical ticket is due to close.

Make treatment executable

A treatment plan needs an action owner, target date, resource decision, dependency and completion evidence. “Implement access control” is too broad. “Review the delivery workspace's external members with its owner, remove unauthorised access and test a revoked account” is work a team can complete and check.

Link the action to a change or project record. If the deadline slips, keep the current risk visible and obtain a decision about the exposure. Do not mark the treatment implemented because a licence was purchased. Procurement, deployment and effectiveness are different milestones.

Build the Statement of Applicability from the decisions

The Statement of Applicability, or SoA, records the controls needed, why they are included, whether they are implemented, and justified exclusions from Annex A. The 2022 Annex A reference set contains 93 controls. Compare your necessary controls with Annex A to check for omissions. Necessary custom controls also belong in the SoA. ISO's public auditing-practice note explains this relationship; consult the licensed current standard for the normative requirements.

Do not start by marking every reference control “yes” to look safe, or “not applicable” because a supplier performs it. Explain how the organisation ensures an outsourced control works. The management-system requirements in clauses 4–10 cannot be discarded through SoA exclusions.

A practical working register can include control reference, reason, related risks/obligations, owner, implementation status and evidence pointer. Those extra tracking columns are our suggestion. Use the correct references from your licensed edition rather than copying a 2013 control table from the internet. Avoid reproducing the entire standard in publicly shared templates.

Exercise: follow one complete chain

Select the account-compromise scenario. Trace its business consequence to the treatment decision, implementation record, verification result, residual-risk acceptance and SoA entry. Ask a colleague to follow the links without your narration. Broken links reveal missing decisions or evidence.

Then choose a proposed exclusion and challenge it against the scope and obligations. If the justification is merely “cloud provider handles this”, identify the assurance and responsibility arrangement that makes the control effective. You finish this part with a repeatable method and a working decision chain, not a spreadsheet of unsupported green cells.

Check your understanding