ISO/IEC 27001 risk assessment and treatment, step by step

What clauses 6.1.2, 6.1.3, 8.2 and 8.3 require

• 6.1.2 Information security risk assessment. Establish and maintain risk criteria; ensure repeated assessments produce consistent, valid and comparable results; identify risks associated with the loss of confidentiality, integrity and availability of information within the ISMS scope, and their owners; analyse potential consequences, realistic likelihood and the level of risk; compare the results with the criteria and prioritise risks for treatment.
• 6.1.3 Information security risk treatment. Select treatment options in the light of the assessment; determine all controls needed to implement them; compare those controls with Annex A to verify that no necessary control has been omitted; produce the Statement of Applicability; formulate a risk treatment plan; and obtain the risk owners' approval of the plan and acceptance of the residual risks.
• 8.2 and 8.3. Perform risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the 6.1.2 a) criteria, and implement the treatment plan.

Documented information is required about both processes and of their results. ISO/IEC 27005:2022 offers guidance on meeting these clauses; it is not certifiable, and the auditor works to ISO/IEC 27001.

Choosing a method and setting the criteria

ISO/IEC 27005:2022 describes two routes into risk identification. The asset-based route starts from information and the systems, people and suppliers holding it, and asks which threats could exploit which vulnerabilities: thorough and easy to audit, but it grows fast. The event-based route starts from risk sources and scenarios, such as ransomware in production or a departing engineer taking customer data: quicker and closer to management's decisions, but it can miss the technical weakness that makes a scenario likely. Many organisations combine the two, adding asset-level detail where the most sensitive information sits.

Clause 6.1.2 a) then needs two sets of criteria, written before anyone scores a risk: acceptance criteria, stating which levels may be retained and by whom, and criteria for performing assessments, stating who assesses, how often, on which scales and what counts as significant change. Four- or five-point qualitative scales are usual; define every point with something testable, such as frequency, customers affected, hours of outage or contractual exposure.

The eight steps, with outputs and evidence

Each step leaves an output, and each output leaves evidence.

Worked example: a SaaS company's customer database

An illustrative case, not a client's: a business software provider on a public cloud service, whose production database holds customer accounts and the personal data its customers' users upload. It multiplies five-point likelihood and consequence scores. Levels 1 to 6 may be retained by the risk owner; 8 to 12 are treated unless the owner records a justification for retaining them; 15 and above are treated unless top management decides to retain them. The standard sets none of these thresholds.

Avoidance, forcing every database change through the deployment pipeline, was rejected because incident response needs an emergency route. The Annex A comparison then caught what the discussion missed: nobody reviewed who held database access, so a quarterly review under A.5.18 joined the plan. That is the purpose of 6.1.3 c).

What auditors test

The certification body's Stage 1 readiness review examines your risk method, criteria, Statement of Applicability and treatment plan. At Stage 2 and at surveillance audits, auditors sample the register and trace risks into the business.

• Comparability. Two similar risks rated differently, and a request to show how the scale definitions produced each rating.
• Ownership. Whether owners know their risks, can fund treatment, and approved the plan and accepted residual risk as a decision, not a signature gathered for the audit.
• Treatment that happened. Completed actions seen in operation: authentication enforced in the identity provider, the export alert firing, an access review with the revocations it produced.
• Re-assessment on change. Each significant change of the year, such as a new product, cloud region or critical supplier, and the assessment that considered it, ideally while it was still proposed.

Five defects that turn into findings

• Undefined scales. "Medium" means one thing to finance and another to engineering, so results cannot be compared.
• Gaps and controls recorded as risks. "No MFA" is a vulnerability and "firewall" a control; a risk says what could happen to which information, and why it matters.
• A register too large to maintain. Thousands of rows rated once and never revisited. Group similar assets and go deep only where the level justifies it.
• One owner for everything. When the ISMS lead owns every risk, nobody with a budget has approved the plan or accepted what remains.
• A yearly snapshot. One assessment a year, although the platform moved to a new cloud service in between, and residual levels never re-rated after treatment.

Keeping the risk register in Effivity

Spreadsheet registers fork into versions, and nobody can show what changed between reviews. In a Sterling engagement the register is kept in Effivity, the ISO and GRC software used in 50+ countries, included with the engagement at no additional cost. Assets, risks, the Statement of Applicability, controls, actions, incidents and audits share one workspace, and each risk carries its owner and review date.

ISO/IEC 27001 risk assessment: questions buyers ask