Risk management · Supports ISO 27001 clause 6

ISO 27005

ISO/IEC 27005 is the information security risk-management standard. It doesn't add controls — it gives you the process for identifying, analysing, evaluating and treating risk, which is exactly what ISO 27001 clauses 6.1.2 and 6.1.3 demand. Risk is the engine that decides which Annex A controls you select and justify in your Statement of Applicability.

Risk assessment Risk treatment CIA triad SoA ISO 27001 clause 6

→What ISO 27005 is for

ISO 27001 says you must run a risk-assessment and risk-treatment process — but the requirements standard deliberately doesn't prescribe how. ISO 27005 fills that gap. It supports clause 6 of the ISMS:

6.1.2 — establish a repeatable, iterative risk-assessment process covering identification, analysis and evaluation.
6.1.3 — treat the risks: select controls (from Annex A and beyond) and record the decisions in the SoA and risk-treatment plan.

Everything is framed around the CIA triad — confidentiality, integrity and availability. A risk is, in practice, a threat exploiting a vulnerability to harm one of those three for an asset that matters.

→The risk-management process

The standard describes a continuous cycle. It runs once to stand the ISMS up, then iterates as the organisation, threats and assets change.

Context establishmentSet scope, criteria and the risk appetite. What are we protecting, and what level of risk is acceptable? Tie this to the interested-party requirements from ISO 27001 clause 4.
Risk identificationFind the assets, threats, existing controls, vulnerabilities and consequences. You can't treat what you haven't named.
Risk analysisEstimate likelihood and impact for each risk to derive a risk level — qualitative (low/medium/high) or quantitative.
Risk evaluationCompare each risk level against your criteria and prioritise: which risks must be treated, and in what order.
Risk treatmentChoose a response for each risk and select the controls that implement it.
Acceptance, communication & monitoringManagement formally accepts residual risk; the results are communicated, then monitored and reviewed so the picture stays current.

→Risk assessment in practice

Assessment is the identify + analyse + evaluate trio. A workable level is the product of how likely something is and how badly it would hurt:

Risk level ≈ Likelihood × Impact, assessed per asset against confidentiality, integrity and availability. The output is a prioritised list, not a single number.

Step	Question you answer
Asset identification	What do we hold, where does it live, who owns it, how valuable is it?
Threat & vulnerability	What could go wrong, and what weakness would let it?
Existing controls	What already reduces this risk today?
Consequence	If it happened, what's the impact on C, I or A — and on the business?
Likelihood	How plausible is it, given threats and current controls?
Evaluation	Does the resulting level exceed our acceptance criteria?

→The four treatment options

For every risk that fails evaluation, you pick one (or a mix) of these responses, then choose controls accordingly:

Modify / reduce Apply controls to lower likelihood or impact — the most common route, drawing on Annex A.

Retain / accept Consciously accept the risk because it sits within appetite. Must be a documented management decision.

Avoid Stop the activity that creates the risk altogether.

Share / transfer Move part of the impact elsewhere — e.g. insurance or a supplier contract. Note the limits of transfer below.

Transfer isn't a silver bullet. After the 2017 NotPetya outbreak, a major food manufacturer's claim for roughly $100m was initially refused under a "hostile or warlike act" exclusion — a reminder that the contract wording, not the premium, decides whether a transferred risk is actually covered.

→Worked example — NAS vs Cloud

A small, concrete assessment many SMBs face: where should our data live? Run it through the CIA lens.

	On-prem NAS	Cloud
Confidentiality	You control physical access, but patching, hardening and key management are on you.	Provider hardening and encryption-at-rest, but you must trust and verify the processor (and have a data processing agreement).
Integrity	Local control of versioning and change; vulnerable if backups are poor.	Managed redundancy and versioning, dependent on configuration and access control.
Availability	Single site — power, hardware, theft, fire and water are real single points of failure.	High availability by design, but you depend on connectivity and on the provider staying up.

Mitigations either way: encryption, a tested backup strategy (think 3-2-1), monitored access for critical/GDPR data, and clarity on where the data physically sits. Then assign a risk level to each option and decide — that decision, and its rationale, is the deliverable.

→From risk to SoA, and the BIA cousin

Statement of Applicability

Treatment output flows straight into the SoA: it lists which Annex A controls you've adopted, which you haven't, and why in each case. This is the document that connects "we assessed this risk" to "therefore we run this control," and it's central to certification.

Business Impact Analysis

For availability-driven risk, the BIA is the close relative. It captures how severely the business judges it would be hit if, say, IT support failed for given processes — which in turn reveals which processes are valued most. The BIA broadly corresponds to the consequence-analysis part of a normal risk-analysis process, and it feeds the Business Continuity Plan under Annex A.17 / ISO 22301.

Missing governance has a cost. Without a risk process you can't justify spend, you can't pass an audit, and you discover your single points of failure during the incident instead of before it.

→Related

ISO 27005 is the risk engine behind ISO 27001 clause 6, and it decides which ISO 27002 / Annex A controls you select. On the privacy side, risk to personal data ties into GDPR and ISO 27701.