ISO 27001 Risk Management: How to Conduct a Risk Assessment
ISO 27001 risk management is the operational engine of every compliant ISMS — the process that transforms the abstract requirements of the standard into specific, justified, organizationally relevant security decisions. Every control selected in the Statement of Applicability, every policy documented in the ISMS, every security investment the organization makes in the name of ISO 27001 conformance should be traceable back to a specific risk identified in the risk assessment.
According to ISMS.online, risk assessment deficiencies are among the most common reasons for major nonconformity findings in first-time ISO 27001 certification audits. The ISO/IEC 27001:2022 standard is explicit that risk management must be systematic, documented, and consistently applied. For how risk management connects to the ISMS as a whole, see ISO 27001 ISMS. For how risk assessment output connects to the Annex A control framework, see ISO 27001 Statement of Applicability.
Tl; DR:
Concern: ISO 27001 risk management is the element of the standard that organizations most frequently get wrong — producing risk assessments that are either too generic to be meaningful, disconnected from the Annex A control framework, or conducted once and never updated as the organization’s threat environment evolves.
Overview: ISO 27001 risk management is the systematic process through which organizations identify information security risks, assess their likelihood and impact, select and implement treatment controls from Annex A, and continuously monitor and improve the risk posture of the ISMS. It is the process from which every control decision flows.
Solution: Organizations that build a documented, consistently applied ISO 27001 risk management framework — with a clear methodology, a complete risk register linked to the SoA, and a risk treatment plan with assigned ownership — produce an ISMS whose control selection is defensible, auditable, and genuinely aligned with the organization’s specific threat environment. CertPro CPA LLC guides organizations through every stage of ISO 27001 risk management.
What ISO 27001 Risk Management Requires
ISO/IEC 27001:2022 specifies risk management requirements across two mandatory clauses:
- Clause 6.1.2 — Information Security Risk Assessment: Requires a documented risk assessment process; systematic identification and analysis of information security risks; evaluation of risks against acceptance criteria; and retention of documented information as evidence of the risk assessment results
- Clause 6.1.3 — Information Security Risk Treatment: Requires selecting appropriate treatment options for risks above the acceptance threshold; determining the necessary controls; comparing determined controls with Annex A; producing a Statement of Applicability; formulating a risk treatment plan; and obtaining risk owner approval of the treatment plan and acceptance of residual risks
Critically, ISO 27001 does not prescribe a specific risk assessment methodology — it requires that the organization defines and uses a documented methodology consistently. The methodology can be quantitative, qualitative, or hybrid — as long as it is documented before the assessment is conducted, applied consistently across all identified risks, and produces results that are repeatable and comparable.
Stage 1 — Establish the Risk Assessment Methodology
The risk assessment methodology must be documented before the first risk assessment is conducted. The methodology document must specify:
- Risk identification approach: How information assets, threats, and vulnerabilities will be identified — asset-based, scenario-based, or threat-intelligence-based
- Risk analysis criteria: How likelihood and impact will be measured — the specific scales used, what each scale point means, and how scores are calculated
- Risk evaluation criteria: What risk score threshold defines acceptable versus unacceptable risk — the risk acceptance threshold that determines which risks require treatment
- Risk owner assignment: How risk ownership will be assigned — who is responsible for accepting residual risk at the treatment plan level
- Risk review frequency: When the risk assessment will be reviewed and updated — at minimum annually and upon significant changes
Organizations building their risk methodology for the first time benefit from reviewing risk and control self-assessment frameworks that provide a disciplined starting point for methodology design.
Stage 2 — Identify Information Assets
ISO 27001 defines information assets broadly to include:
- Information assets: Databases, files, contracts, documentation, research data, system documentation, operational procedures, plans
- Software assets: Application software, system software, development tools, SaaS platforms and APIs
- Physical assets: Computing equipment, networking equipment, removable media, storage media
- Services: Cloud services, utilities, communications services, general IT services
- People: Personnel and contractors with access to information systems
- Intangible assets: Reputation, organizational image, customer trust
For guidance on building a comprehensive, structured asset inventory that supports systematic risk identification, see how to build an asset inventory for ISO 27001.
Stage 3 — Identify and Analyze Information Security Risks
For each information asset, identify the specific risks — combining the asset with threats that could affect it and vulnerabilities that those threats could exploit. Use threat intelligence sources including sector-specific ISACs, ENISA threat landscape reports, NCSC advisories, and vendor security bulletins. See continuous security monitoring for how ongoing threat intelligence feeds into dynamic risk assessment.
For each identified risk, assess likelihood and impact using the documented scales, and calculate a risk score — typically Likelihood × Impact — producing a score that can be compared against the acceptance threshold.
ISO 27001 Risk Register — Complete Structure
| Field | Description | Example |
|---|---|---|
| Risk ID | Unique identifier | RISK-007 |
| Asset | Specific asset at risk | Production database — customer PII |
| Threat | Specific threat | Ransomware deployment by external actor |
| Vulnerability | Exploited weakness | Critical patches not applied within SLA |
| Likelihood | 1–5 score with justification | 4 — High (active exploitation campaigns in sector) |
| Impact | 1–5 score with justification | 5 — Very High (regulatory notification, data loss, revenue impact) |
| Risk score | Likelihood × Impact | 20 |
| Treatment decision | Treat / Accept / Avoid / Transfer | Treat |
| Selected controls | Annex A references | 8.8 (Vulnerability Mgmt), 8.13 (Backup), 5.29 (Business Continuity) |
| Residual risk score | Post-treatment expected score | 8 — Medium (below threshold) |
| Risk owner | Individual accepting residual risk | CTO |
ISO 27001 Risk Management Examples
Scenario 1 — Ransomware Attack on Production Database
Asset: Production database — customer PII | Likelihood: 4 | Impact: 5 | Score: 20 (above threshold of 15). Treatment: Implement controls 8.8 (Vulnerability Management), 8.13 (Backup), 8.15 (Logging), 5.29 (Business Continuity). Residual risk: 8.
Scenario 2 — Insider Data Exfiltration
Asset: Customer CRM data | Likelihood: 3 | Impact: 4 | Score: 12 (below threshold — accepted with controls). Treatment: Accept with compensating controls: 5.18 (Access Rights — automated deprovisioning), 6.5 (Responsibilities After Termination), 8.12 (Data Leakage Prevention). Residual risk: 6.
Scenario 3 — Cloud Misconfiguration Exposing S3 Bucket
Asset: AWS S3 bucket containing internal documentation | Likelihood: 3 | Impact: 3 | Score: 9 (below threshold). Treatment: Accept with controls: 8.9 (Configuration Management — AWS Config rules), 8.16 (Monitoring Activities — CloudTrail alerts). Residual risk: 4.
ISO 27001 Third-Party Risk Management
ISO 27001 third-party risk management requires systematic identification and treatment of risks introduced by external suppliers, cloud service providers, and technology partners through Annex A controls 5.19–5.22 and the new 2022 controls 5.21 (ICT Supply Chain Security) and 5.23 (Cloud Services Security).
Key activities include: identifying all third parties with access to in-scope information assets, assessing the specific risks each relationship introduces, including security requirements in supplier agreements (control 5.20), and monitoring supplier security performance annually (control 5.22). For practical guidance, see vendor relationship management and preparing for third-party audits.
Maintaining the ISO 27001 Risk Assessment
The risk assessment must be reviewed at planned intervals and whenever significant changes occur including: new systems or services added to scope, significant changes to the threat landscape, information security incidents, changes to regulatory obligations, and changes to the third-party supply chain.
Organizations that integrate automated evidence collection and continuous security monitoring tools into their ISMS maintain continuous threat visibility that feeds directly into dynamic risk register updates. For organisations building ISO 27001 risk management within a broader GRC framework, integrating the risk register into the GRC platform’s continuous monitoring enables real-time risk posture tracking.
Ready to Get ISO 27001 Certified?
CertPro CPA LLC is a licensed CPA firm delivering ISO 27001 certification audits. Work with credentialed auditors who understand your business environment.
FAQ
What is ISO 27001 risk management?
ISO 27001 risk management is the systematic process through which organizations identify information security risks, assess their likelihood and impact, select and implement treatment controls from Annex A, and continuously monitor and update the risk posture of the ISMS. It is the operational foundation of every compliant ISO 27001 ISMS — the process from which every Annex A control selection decision flows.
What must an ISO 27001 risk assessment include?
A compliant ISO 27001 risk assessment must include: a documented risk assessment methodology (produced before the assessment is conducted), identification of information assets within scope, identification of threats and vulnerabilities for each asset, likelihood and impact assessment using a documented scale, a risk score for each identified risk, risk evaluation against the documented acceptance threshold, and formal documentation of all findings in a risk register.
What is an ISO 27001 risk register?
An ISO 27001 risk register is the document that records all identified information security risks. For each risk, it should include the asset at risk, the threat, the vulnerability, the risk statement, likelihood and impact scores, the overall risk score, the treatment decision, the selected Annex A controls, the control owner, the implementation status, the residual risk score, the risk owner, and the last review date.
What is the ISO 27001 risk treatment plan?
The ISO 27001 risk treatment plan documents how each identified risk above the acceptance threshold will be addressed — specifying the treatment option, the Annex A controls selected to implement the treatment, the control owner, the implementation timeline, and the expected residual risk level after controls are implemented. It must be formally approved by risk owners.
What is ISO 27001 third-party risk management?
ISO 27001 third-party risk management is the process of identifying, assessing, and treating information security risks introduced by external suppliers, cloud service providers, and technology partners. It is addressed by Annex A controls 5.19–5.22, plus the new 2022 controls 5.21 (ICT supply chain security) and 5.23 (cloud services security).
How often should the ISO 27001 risk assessment be updated?
The ISO 27001 risk assessment must be reviewed at planned intervals — typically annually as a minimum — and whenever significant changes occur to the organization’s ISMS scope, threat environment, regulatory obligations, or third-party supply chain. Organizations that treat the risk assessment as a living document maintained continuously achieve more credible risk postures than those that refresh it only before audit cycles.
