ISO 27005:2022 sharpens risk treatment decisions for security teams

At a glance

What this is: ISO/IEC 27005:2022 is a structured information security risk management standard that now emphasises five-step analysis, residual risk acceptance, and tighter alignment with ISO 27001 controls.

Why it matters: It matters because security, IAM, and GRC teams need a repeatable way to decide which risks to accept, which to treat, and how to evidence those decisions across identity, NHI, and broader control programmes.

👉 Read Secureframe's explanation of ISO 27005:2022 risk management updates

Context

ISO/IEC 27005 sits in the risk management layer of an information security programme. It does not replace ISO 27001, but it explains how teams can identify, analyse, evaluate, and treat risk in a way that supports a defensible ISMS.

For identity-heavy environments, that governance layer matters because service accounts, secrets, workload identities, and human access all create different risk paths. A risk method that links controls to specific scenarios is more useful than a generic checklist, especially when identity lifecycle and access scope change quickly.

Key questions

Q: How should teams apply ISO 27005 to identity and access risks?

A: Start by defining identity-specific risk scenarios such as privilege misuse, orphaned accounts, over-scoped service identities, and leaked secrets. Then analyse likelihood and impact, map each treatment to a named control, and record who accepts any remaining exposure. That approach makes identity risk measurable and auditable rather than anecdotal.

Q: When should organisations prioritise residual risk acceptance over more controls?

A: Use residual risk acceptance only after treatment options have been evaluated and when the remaining exposure is understood, limited, and explicitly owned. It is appropriate when further control adds little reduction or creates disproportionate cost or friction. The key is documented accountability, not silent tolerance of unresolved exposure.

Q: What do security teams get wrong about ISO 27005 risk assessments?

A: They often treat risk assessment as a one-time compliance task instead of a continuous decision process. ISO 27005 works best when teams revisit scenario assumptions, asset criticality, and control effectiveness after changes in access, architecture, or business context. Without that review cycle, the register quickly drifts from reality.

Q: How do security teams know whether their ISO 27001 controls are actually working?

A: They know by testing the controls before the external audit. Internal audits, evidence sampling, and control walkthroughs should show that access governance, risk treatment, and documentation all line up. If those checks fail, the issue is usually drift between policy and practice rather than a missing certificate.

Technical breakdown

How ISO 27005:2022 structures information security risk analysis

ISO 27005:2022 now frames risk management as five steps: context establishment, risk identification, risk analysis, risk evaluation, and risk treatment. That structure matters because it separates the decision to understand risk from the decision to act on it. The update also recognises semi-quantitative analysis, which sits between qualitative judgement and fully quantitative modelling. This helps teams combine measurable inputs such as likelihood with expert judgement on impact, which is often necessary in identity and NHI programmes where hard loss data is limited.

Practical implication: define one repeatable risk method across identity, NHI, and control owners so treatment decisions are comparable.

Event-based and asset-based approaches to risk identification

The 2022 update makes two risk identification paths explicit. An event-based approach starts with scenarios and threat events, then asks what could happen and how severe the outcome might be. An asset-based approach starts with a specific asset, system, or information set, then maps threats and vulnerabilities around it. In practice, the two approaches answer different governance questions. Event-based analysis is useful for board-level risk framing, while asset-based analysis is better for scoping controls around sensitive systems, privileged accounts, or machine identities that need precise ownership and containment.

Practical implication: use event-based analysis for programme risk and asset-based analysis for high-risk identities, secrets, and privileged systems.

Why residual risk acceptance now sits closer to the Statement of Applicability

ISO 27005:2022 places more weight on risk owners approving treatment plans and accepting residual risk after controls are selected. It also aligns treatment more tightly with ISO 27001 Annex A through the Statement of Applicability, which makes the link between a risk, the chosen control, and the justification visible. That change reduces ambiguity, but it also raises the standard for evidence. Teams can no longer rely on broad statements of intent when they need to show why a control was chosen, why a risk remains, and who signed off on the remaining exposure.

Practical implication: document risk ownership and control rationale at the same time, not after the audit asks for proof.

NHI Mgmt Group analysis

ISO 27005:2022 is most useful when teams treat risk management as an evidence chain, not a policy paragraph. The standard’s value is not that it adds more governance language. It is that it forces a documented path from scenario, to analysis, to treatment, to residual acceptance. For identity and NHI programmes, that discipline is essential because access risk is rarely static. The practitioner conclusion is clear: risk decisions need traceability, not just approval.

Residual risk acceptance is the governance moment where many security programmes lose credibility. ISO 27005:2022 tightens that moment by moving approval closer to the risk owner and the Statement of Applicability. That matters when privileged access, service accounts, or secrets remain in place after a mitigation attempt, because the remaining exposure has to be owned explicitly. The practitioner conclusion is clear: make residual risk a named decision, not an implied outcome.

Event-based and asset-based analysis should be used together, not treated as competing methods. Event-based thinking surfaces attack scenarios and business impact. Asset-based thinking exposes which identities, systems, and data sets carry that risk in practice. In identity-governed environments, that combination is especially useful for prioritising controls around privileged accounts, external integrations, and machine identities. The practitioner conclusion is clear: scenario analysis tells you where risk may emerge, asset analysis tells you where to place controls.

ISO 27005:2022 reinforces a broader governance shift toward control evidence, not control assumption. Linking treatment to the Statement of Applicability makes control selection auditable, but it also exposes weak justification where teams have inherited controls they cannot explain. That is relevant to IAM and PAM programmes as much as to broader GRC work. The practitioner conclusion is clear: if a control cannot be tied to a specific risk treatment decision, it is not yet governance-ready.

What this signals

Residual risk discipline is becoming a test of programme maturity. As identity estates expand across human and non-human access, teams need a way to show why a control was chosen and why a risk was accepted. ISO 27005:2022 gives that process a more defensible shape, but only if risk owners actually use it to govern decisions.

Conceptually, the important shift is from assessment as a document to assessment as a control-selection workflow. That has direct implications for IAM, PAM, and NHI teams because access decisions change faster than annual reviews. A programme that cannot revisit risk after architecture or privilege changes will fall behind the environment it is meant to govern.

For practitioners

• Define a single risk taxonomy Use one taxonomy for identity, NHI, cloud, and application risks so the same likelihood and impact language is applied across control owners and audit evidence. That makes residual risk decisions comparable and avoids duplicated registers.
• Separate scenario and asset analysis Run event-based analysis for top threat scenarios and asset-based analysis for privileged systems, secrets, and service accounts. This prevents high-level concern from obscuring the identities and assets that actually need treatment.
• Tie every treatment to a named control Map each accepted or mitigated risk to a specific control in the Statement of Applicability, then record why that control was chosen and who owns the residual exposure. That link is what auditors and risk committees will test.
• Review residual risk after major identity changes Reassess risk whenever privileged access, workload identity scope, or secret ownership changes. Those events can invalidate prior risk assumptions even when the technical stack has not changed.

Key takeaways

• ISO 27005:2022 is less about scoring risk and more about making treatment decisions traceable, owned, and repeatable.
• The update matters because it links scenario analysis, asset analysis, and residual acceptance into one governance chain.
• For identity-heavy environments, the standard is most useful when it is tied to named controls, explicit ownership, and continuous review.

Key terms

• Information Security Risk Management: The process of identifying, analysing, evaluating, and treating risks that could affect information assets, services, or business continuity. In ISO 27005, it is a repeatable governance method that helps teams decide what to accept, what to reduce, and what to document.
• Statement of Applicability: A Statement of Applicability lists the security controls an organisation has selected, excluded, or adapted for its ISMS. It matters because it forces explicit justification, which makes audit discussions easier and exposes weak control decisions that were previously implied or undocumented.
• Residual Risk: Residual risk is the risk that remains after controls are applied. In identity-heavy environments, it often reflects over-permissioning, stale accounts, and exceptions that were accepted but never truly removed, which means the real exposure can be higher than the documented policy baseline.
• Semi-Quantitative Analysis: A risk analysis method that combines numeric elements with expert judgement. It sits between purely qualitative scoring and full statistical modelling, which makes it useful when security teams need more consistency than opinions alone but lack enough data for precise quantification.

What's in the full article

Secureframe's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of the five ISO 27005:2022 process stages and how to apply them during assessments.
• Practical comparison of event-based and asset-based risk identification methods in live compliance programmes.
• Operational guidance on linking risk treatment to the Statement of Applicability and ISO 27001 Annex A controls.
• Implementation detail for Secureframe's automated risk register, control linking, and history tracking workflow.

👉 Secureframe's full post covers the updated process steps, risk treatment model, and automation details.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need stronger governance across access, secrets, and workload identity programmes.