What ISO 27001 expects when you manage information security risks

This article summarises common expectations under ISO/IEC 27001 for discussion and learning. It is not legal or certification advice; your notified body and applicable laws have the final word.

ISO/IEC 27001 is built around an Information Security Management System (ISMS). Risk is not a side chapter—it is how the organisation decides what to protect and which controls matter, then proves it keeps that story up to date.

Context and planning (Clause 4–6)

Before scoring spreadsheets, the standard expects you to understand context: interested parties, scope of the ISMS, and how information security objectives align with the business. Risk activities sit in that frame so you assess the right assets and obligations—not every theoretical threat on the internet.

Interested parties and the objectives register

Interested parties are people or organisations who influence or depend on your ISMS—customers with contractual security clauses, regulators, boards, staff, critical suppliers, and similar. Capturing their requirements is what makes scope and control choices defensible. An information security objectives register turns policy intent into measurable targets (owners, timelines, measures) so management review can show progress, not only intent. For a dedicated explanation with examples of what to record, see Interested parties & the objectives register.

Risk assessment (typically 6.1.2)

The organisation shall define and apply an information security risk assessment process that:

• Identifies risks to confidentiality, integrity, and availability.
• Identifies risk owners.
• Analyses and evaluates likelihood, consequences, and levels of risk in a consistent way.

Auditors look for repeatability: the same criteria year to year, evidence of decisions, and updates when scope or context changes.

Risk treatment and options (typically 6.1.3)

You select appropriate risk treatment options and controls—often mapped to Annex A (or your justified alternative)—and produce a Statement of Applicability that explains what applies and why. Residual risk and acceptance need to be legible to leadership, not buried in a forgotten tab. For SoA fundamentals and how to complete the table, see what is a SoA? and how to fill in an SoA.

Documented information

The ISMS must retain enough documented information to show the process was followed: risk register entries, assessment outputs, treatment plans, approvals, and changes over time. That is why teams pair registers with versioned policies and activity history in tooling—not just for convenience, but for audit traceability.

Operation, performance evaluation, and improvement

Risks are not “done” at certification. Monitoring, measurement, internal audit, and management review feed new information back into the register. When audits or incidents find gaps, non-conformities and corrective actions close the loop (see non-conformities explained).

Where controls fit

Annex A controls are the usual catalogue for treatment—but “control” in day-to-day language means any safeguard you rely on. See what controls are for a reader-friendly definition tied to the ISMS.

For how software can mirror these expectations, read how ISMSVision supports ISO 27001 risk requirements.