In This Guide
Risk Assessment Overview
Risk assessment is the heart of ISO 27001. It drives your control selection, resource allocation, and continuous improvement activities. Done well, it provides genuine security value; done poorly, it becomes a paperwork exercise that auditors see through.
ISO 27001 requires you to:
- Define and document a risk assessment methodology (Clause 6.1.2)
- Identify information security risks (Clause 6.1.2 b)
- Analyze and evaluate those risks (Clause 6.1.2 c, d)
- Select risk treatment options (Clause 6.1.3)
- Determine necessary controls (Clause 6.1.3 b)
- Produce a Statement of Applicability (Clause 6.1.3 d)
The standard doesn't prescribe a specific methodology - asset-based, scenario-based, or threat-led approaches are all valid. Choose what works for your organization and apply it consistently.
Designing Your Risk Assessment Methodology
Before assessing risks, document your methodology. This procedure should define:
Risk Criteria
Define scales for likelihood and impact that your team can apply consistently.
Likelihood Scale (Example)
| Rating | Description | Frequency |
|---|---|---|
| 1 - Rare | Highly unlikely to occur | Less than once in 5 years |
| 2 - Unlikely | Could occur but not expected | Once in 2-5 years |
| 3 - Possible | Might occur occasionally | Once per year |
| 4 - Likely | Will probably occur | Multiple times per year |
| 5 - Almost Certain | Expected to occur | Monthly or more frequent |
Impact Scale (Example)
| Rating | Description | Business Impact |
|---|---|---|
| 1 - Negligible | Minimal impact, easily absorbed | < $10,000, no reputation impact |
| 2 - Minor | Some impact, manageable | $10,000-50,000, limited reputation impact |
| 3 - Moderate | Significant impact requiring response | $50,000-250,000, noticeable reputation damage |
| 4 - Major | Serious impact on operations | $250,000-1M, significant reputation damage |
| 5 - Severe | Critical impact, threatens business | > $1M, regulatory action, severe reputation damage |
Risk Acceptance Criteria
Define which risk levels require treatment vs. acceptance:
- Low (1-6): Accept with monitoring—no treatment required
- Medium (7-14): Treat to reduce risk level within 6 months
- High (15-19): Priority treatment within 3 months
- Critical (20-25): Immediate action required, consider stopping activity
Step 1: Asset Identification
Start by identifying information assets within your ISMS scope. An information asset is anything that has value to the organization.
Asset Categories
- Information: Databases, files, documents, records, intellectual property
- Software: Applications, operating systems, development tools
- Hardware: Servers, workstations, network equipment, mobile devices
- Services: Cloud services, communication services, utilities
- People: Staff, contractors with critical knowledge
- Premises: Buildings, data centers, offices
Asset Register Template
For each asset, document:
- Asset ID: Unique identifier
- Asset Name: Descriptive name
- Category: Information, Software, Hardware, etc.
- Owner: Person accountable for the asset
- Location: Physical or logical location
- Classification: Confidentiality level (Public, Internal, Confidential, Restricted)
- Value: Importance to business operations
Practical Tips
- Don't list every individual laptop—group similar assets
- Focus on assets that store, process, or transmit important information
- Include cloud services and SaaS applications
- Assign owners who can make decisions about the asset
Step 2: Threat & Vulnerability Identification
For each asset (or asset group), identify potential threats and vulnerabilities.
Common Threat Categories
- Malicious Attacks: Malware, ransomware, phishing, social engineering, insider threats
- Technical Failures: Hardware failure, software bugs, capacity issues
- Human Errors: Misconfiguration, accidental deletion, misdirected emails
- Physical Threats: Fire, flood, theft, vandalism, power failure
- Third-Party Issues: Supplier failure, service outages, supply chain attacks
Common Vulnerabilities
- Technical: Unpatched software, weak passwords, missing encryption, open ports
- Organizational: Lack of procedures, no segregation of duties, insufficient training
- Physical: Inadequate access controls, no environmental protection
- Human: Susceptibility to phishing, lack of awareness, password sharing
Risk Scenario Format
Combine asset, threat, and vulnerability into risk scenarios:
"[Threat] exploits [Vulnerability] in [Asset] leading to [Impact on CIA]"
Examples:
- Ransomware exploits unpatched server vulnerabilities in Customer Database leading to loss of availability
- Phishing attack exploits lack of MFA on Email System leading to loss of confidentiality
- Disgruntled employee exploits excessive access privileges on Financial Systems leading to loss of integrity
Step 3: Risk Analysis
For each risk scenario, assess likelihood and impact to determine risk level.
Likelihood Assessment
Consider:
- Historical incident data (internal and industry)
- Threat intelligence and trends
- Existing control effectiveness
- Attractiveness to attackers (data value, visibility)
Impact Assessment
Consider impact across dimensions:
- Financial: Direct costs, fines, lost revenue
- Operational: Service disruption, recovery effort
- Reputational: Customer trust, brand damage
- Legal/Regulatory: Compliance violations, legal action
- Strategic: Competitive disadvantage, missed opportunities
Calculate Risk Level
Risk Level = Likelihood × Impact
Using 5×5 scales: Risk ranges from 1 (minimum) to 25 (maximum)
Step 4: Risk Evaluation
Compare analyzed risks against your acceptance criteria to prioritize treatment.
Risk Heat Map
Plot risks on a heat map to visualize the risk landscape:
- Green (1-6): Low risk - monitor
- Yellow (7-14): Medium risk - planned treatment
- Orange (15-19): High risk - priority treatment
- Red (20-25): Critical risk - immediate action
Risk Register
Document each risk in a risk register including:
- Risk ID
- Risk description (scenario)
- Asset(s) affected
- Threat and vulnerability
- Likelihood rating
- Impact rating
- Risk level (inherent)
- Existing controls
- Risk level (residual)
- Risk owner
- Treatment decision
Step 5: Risk Treatment
For each risk requiring treatment, select from four options:
Treatment Options
- Modify (Treat): Implement controls to reduce likelihood or impact
- Avoid: Stop the activity that creates the risk
- Transfer: Share risk through insurance, contracts, or outsourcing
- Accept: Accept the risk with documented justification
Control Selection
When modifying risk, select controls from:
- ISO 27001:2022 Annex A (93 reference controls)
- Other frameworks (NIST, CIS Controls)
- Industry-specific requirements
- Custom controls based on your environment
Risk Treatment Plan
Document planned treatments including:
- Risk being addressed
- Treatment option selected
- Control(s) to implement
- Responsible person
- Target completion date
- Resources required
- Expected residual risk level
Building the Statement of Applicability (SoA)
The Statement of Applicability is a required document that lists all Annex A controls and your implementation decisions.
SoA Purpose
The SoA serves multiple purposes:
- Documents which controls are applicable to your ISMS
- Provides justification for exclusions
- Shows linkage between risks and controls
- Serves as a summary of your control environment
- Key audit evidence for certification
SoA Content Requirements
For each of the 93 Annex A controls, document:
- Control reference number (e.g., 5.1, 8.16)
- Control title
- Applicable: Yes or No
- Justification for inclusion or exclusion
- Implementation status (Implemented, Partial, Planned, Not Implemented)
- How the control is implemented (brief description) - Optional
- Related risks from risk assessment - Optional
- Related policies/procedures - Optional
Justifying Exclusions
You may exclude controls only if they are genuinely not applicable. Valid exclusion reasons:
- Technology not used: "8.28 Secure coding - Not applicable; organization does not develop software"
- Activity not performed: "5.22 Information security in project management - Not applicable; no formal projects within scope"
- Environment-specific: "7.8 Equipment siting - Not applicable; organization uses only cloud infrastructure with no physical IT equipment"
Invalid exclusion reasons:
- "Too expensive to implement" (cost is not a valid exclusion)
- "Not a priority right now" (must treat if risk exists)
- "No incidents so far" (doesn't mean risk doesn't exist)
SoA Template Structure
| Control Ref | Control Title | Applicable | Justification | Status |
|---|---|---|---|---|
| 5.1 | Policies for information security | Yes | Required to establish management direction | Implemented |
| 5.7 | Threat intelligence | Yes | Addresses evolving cyber threats to customer data | Partial |
| 7.4 | Physical security monitoring | No | No physical premises; 100% remote with cloud infrastructure | N/A |
| 8.28 | Secure coding | Yes | Organization develops customer-facing applications | Implemented |
Common Mistakes to Avoid
Risk Assessment Mistakes
- Too generic: "Data breach" is not a risk; specify the scenario
- Over-complicated: 500-line risk registers that no one maintains
- Copy-paste: Using another organization's risk assessment without customization
- IT-only focus: Ignoring physical, people, and process risks
- One-time exercise: Risk assessment must be repeated and updated
SoA Mistakes
- Weak justifications: "Not applicable" without explaining why
- Incorrect exclusions: Excluding controls that should apply
- Missing linkage: No connection between risks and controls
- Outdated: SoA not updated when controls change
- Implementation mismatch: Saying "Implemented" when control is partial
Auditors can spot copy-paste risk assessments and weak SoA justifications instantly. Invest time in making these documents genuine, organization-specific, and defensible. They are the foundation of your ISMS.