# ISO 27001 Risk Assessment

> Complete ISO 27001:2022 risk assessment workflow covering methodology definition, risk identification using a 12-category threat taxonomy, risk analysis with 5×5 matrix scoring, treatment planning with Annex A control mapping, and residual risk validation. Produces auditor-ready risk methodology, risk register, treatment plan, and acceptance forms per Clause 6.1.2 and 6.1.3.



Tags: ISO 27001, Risk Assessment, ISMS, GRC, Compliance, Information Security, Risk Management


## Example Prompts

- Build a risk assessment for our ISO 27001 certification
- Validate our risk register entries for completeness
- Map our identified risks to Annex A controls
- Create a risk treatment plan from our risk register
- Check our risk methodology against Clause 6.1.2 requirements

URL: https://rakenne.app/skills/iso27001-risk-assessment/index.md

Try this skill: https://rakenne.app/a/?skill=iso27001-risk-assessment



## Overview

Complete ISO 27001:2022 risk assessment workflow covering the full lifecycle from methodology definition through risk identification, analysis, treatment planning, and residual risk validation. Produces the four documents auditors expect to see: risk methodology, risk register, treatment plan, and risk acceptance forms.

The skill uses a structured 12-category threat taxonomy with 52 specific threats and 15 vulnerability categories to ensure systematic risk identification. A 5x5 risk matrix (Likelihood x Impact) scores risks from Low (1–4) through Critical (17–25), with automated validation that catches scoring errors, missing fields, duplicate entries, and treatment gaps.

For a step-by-step walkthrough of how this skill fits into the full ISMS flow, see the [**ISO 27001 ISMS workspace tutorial**](/learn/tutorials/iso27001-isms-workspace-guide/).

### What It Covers

- **Risk methodology** — defines scales, matrix, acceptance criteria, roles, and review frequency per Clause 6.1.2
- **Risk identification** — systematic coverage of 12 threat categories (unauthorized access, malware, social engineering, data breach, system failure, natural/environmental, supply chain, network attack, insider threat, physical, legal/regulatory, configuration/human error)
- **Risk analysis** — 5x5 scoring with automated calculation verification
- **Risk treatment** — Treat, Accept, Avoid, Transfer with Annex A control mapping
- **Residual risk** — validates treatment completeness and cross-references the treatment plan

## Example Conversation

> **You:** We need to build a risk assessment for our ISO 27001 certification. We're a SaaS company with about 50 employees, running on AWS.
>
> **Agent:** I'll guide you through the complete risk assessment process per Clause 6.1.2 and 6.1.3. Let's start by establishing context.
>
> First, I need to understand your ISMS scope:
> 1. What systems and processes are in scope?
> 2. What data do you handle? (customer PII, financial data, health data, etc.)
> 3. What regulatory obligations apply?
> 4. What's your risk appetite — how much risk is management willing to accept?
>
> **You:** Our SaaS platform processes customer data including PII and business data. We're subject to GDPR. Management wants to keep all risks at Medium or below — High risks must be treated.
>
> **Agent:** Good. Now let me help you define the risk methodology. I'll start from the template and customize it for your context. Here's the 5x5 risk matrix I recommend:
>
> | | Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 |
> |---|:---:|:---:|:---:|:---:|:---:|
> | **Likelihood 5** | Medium (5) | High (10) | High (15) | Critical (20) | Critical (25) |
> | **Likelihood 4** | Low (4) | Medium (8) | High (12) | High (16) | Critical (20) |
> | **Likelihood 3** | Low (3) | Medium (6) | Medium (9) | High (12) | High (15) |
> | **Likelihood 2** | Low (2) | Low (4) | Medium (6) | Medium (8) | High (10) |
> | **Likelihood 1** | Low (1) | Low (2) | Low (3) | Low (4) | Medium (5) |
>
> With your acceptance threshold: Low/Medium risks accepted by default, High must be treated, Critical requires immediate treatment with executive approval. Does this work for your organization?
>
> **You:** Yes, that looks right. Let's move to identifying risks.
>
> **Agent:** I'll use the threat taxonomy to systematically identify risks for your SaaS platform on AWS. Let me walk through each category that's relevant:
>
> **Unauthorized Access** — Your SaaS handles customer PII. Key risks:
> - R-001: Credential theft leading to unauthorized access to customer database (Likelihood 4, Impact 4 = High 16)
> - R-002: Privilege escalation via misconfigured AWS IAM (Likelihood 3, Impact 4 = High 12)
>
> **Social Engineering:**
> - R-003: Phishing attack compromising employee credentials (Likelihood 4, Impact 3 = High 12)
>
> **Data Breach:**
> - R-004: API vulnerability exposing customer PII (Likelihood 3, Impact 4 = High 12)
>
> **Supply Chain:**
> - R-005: AWS service outage disrupting platform availability (Likelihood 3, Impact 3 = Medium 9)
>
> Let me continue through the remaining categories. For each, I'll check if there are relevant threats given your SaaS/AWS/GDPR context...
>
> After identifying all risks, I'll run `risk_entry_validator` to verify every entry and `risk_deduplication_engine` to check for overlaps. Then we'll map each risk to Annex A controls using `risk_to_control_mapper`.
>
> **You:** Let's see the control mapping for R-001.
>
> **Agent:** Running `risk_to_control_mapper` for R-001 (credential theft → unauthorized access to customer database)...
>
> - **Threat category:** Unauthorized Access
> - **Vulnerability category:** Weak Authentication
> - **Recommended controls:** A.5.15, A.5.16, A.5.17, A.5.18, A.8.1, A.8.2, A.8.3, A.8.5
> - **Key actions:**
>   - A.5.17: Enable MFA for all accounts with access to customer data
>   - A.8.5: Implement secure authentication (no shared credentials, strong password policy)
>   - A.8.2: Restrict privileged access to database administrators only
>
> With these controls, estimated residual risk drops from High (16) to Medium (6). Shall I proceed with the treatment plan?

## Sample Output Excerpt

Below is a representative excerpt from a generated risk register showing several entries with their scoring and treatment decisions.

---

### Risk Register (excerpt)

| Risk ID | Asset / Process | Threat | Vulnerability | Consequence | L | I | Risk Level | Risk Owner | Treatment | Controls | Residual Risk |
|---------|----------------|--------|---------------|-------------|:-:|:-:|:----------:|------------|-----------|----------|:-------------:|
| R-001 | Customer database (PostgreSQL) | Credential theft | No MFA on database admin accounts | Exposure of customer PII; GDPR fine; reputational damage | 4 | 4 | High (16) | CTO | Treat | A.5.17, A.8.2, A.8.5 | Medium (6) |
| R-002 | AWS IAM | Privilege escalation | Overly permissive IAM policies | Unauthorized access to all AWS resources | 3 | 4 | High (12) | Head of Engineering | Treat | A.5.15, A.5.18, A.8.2 | Low (4) |
| R-003 | Email (Google Workspace) | Phishing | Insufficient security awareness training | Account compromise; data exfiltration; BEC fraud | 4 | 3 | High (12) | Head of Engineering | Treat | A.6.3, A.8.23 | Medium (6) |
| R-004 | SaaS API | API vulnerability | No API security testing in CI/CD | Customer PII exposure; GDPR breach notification | 3 | 4 | High (12) | CTO | Treat | A.8.29, A.8.8 | Medium (6) |
| R-005 | AWS infrastructure | Service provider outage | Single-region deployment | Platform unavailability; SLA breach; revenue loss | 3 | 3 | Medium (9) | CTO | Accept | — | Medium (9) |

### Risk Treatment Plan (excerpt)

| Risk ID | Risk Description | Treatment | Controls | Actions | Resources Required | Responsible | Target Date | Status | Expected Residual Risk |
|---------|-----------------|-----------|----------|---------|-------------------|-------------|-------------|--------|:----------------------:|
| R-001 | Credential theft → customer database | Treat | A.5.17, A.8.2, A.8.5 | 1. Enable MFA for all DB admin accounts. 2. Implement least-privilege access. 3. Deploy privileged access management. | MFA setup (2 days); PAM tool ($X/yr) | Head of Engineering | 2024-04-15 | Not started | Medium (6) |
| R-005 | AWS service outage | Accept | — | Justification: Single-region acceptable for current SLA (99.5%). Cost of multi-region ($X/mo) exceeds risk impact. Will reassess when SLA target increases to 99.9%. | N/A | CTO | N/A | Accepted | Medium (9) |

<!-- /excerpt -->

## Extension Tools

### `risk_methodology_validator`

Validates a risk methodology document against 11 Clause 6.1.2 requirements:

| Element | Clause | What It Checks |
|---------|--------|----------------|
| Purpose and scope | 6.1.2 | Document states its purpose |
| Likelihood scale | 6.1.2(a) | Defined 1–5 scale with levels |
| Impact scale | 6.1.2(a) | Defined 1–5 scale with CIA dimensions |
| Risk matrix | 6.1.2(d) | Visual matrix with level calculation |
| Acceptance criteria | 6.1.2(a) | Defined thresholds for risk acceptance |
| Assessment criteria | 6.1.2(a) | Triggers and frequency for performing assessments |
| Treatment options | 6.1.3(a) | Treat, Accept, Avoid, Transfer defined |
| Risk owner | 6.1.2(c) | Risk owner assignment process |
| Review frequency | 6.1.2(a) | Reassessment triggers and schedule |
| Roles | 6.1.2 | Roles and responsibilities defined |
| Consistency | 6.1.2(b) | Repeatability statement |

### `risk_entry_validator`

Validates each risk register entry for:
- Required fields (ID, asset, threat, vulnerability, consequence)
- Valid likelihood/impact scores (1–5)
- Correct risk level calculation (L × I)
- Risk owner assignment
- Treatment decision (Treat/Accept/Avoid/Transfer)
- Control mapping for treated risks
- Residual risk documentation (ERROR for treated risks, WARNING for others)
- High/Critical acceptance flagging

### `risk_deduplication_engine`

Detects near-duplicate risks using Jaccard similarity on tokenized threat + vulnerability + consequence text. Configurable threshold (default 0.6). Flags pairs above threshold and recommends merging or differentiating.

### `risk_to_control_mapper`

Maps each risk's threat and vulnerability to recommended Annex A controls using a 2D lookup:
- **12 threat categories** → associated controls
- **15 vulnerability categories** → associated controls
- Merges both sets and compares against currently selected controls
- Reports missing controls (consider adding) and extra controls (may be valid)
- Validates avoidance documentation for "Avoid" treatment decisions

### `residual_risk_validator`

Cross-checks the risk register against the treatment plan:
- Treated risks must have controls and lower residual risk
- Accepted risks should have residual = inherent (no treatment applied)
- High/Critical acceptance requires documented justification
- Critical residual risk flags as ERROR
- Optional treatment plan cross-reference using register-driven ID lookup

## Getting Started

Activate the *ISO 27001 Risk Assessment* skill. If you've completed the *Organization Profile* skill, load it — the agent uses your industry, tech stack, and regulations to identify relevant threats.

Have this information ready:
- Your ISMS scope (what systems, processes, and locations are in scope)
- Existing security controls already in place
- Management's risk appetite (what risk level is acceptable)
- Any previous risk assessments or security audits

The agent guides you through a 7-step workflow: context establishment, methodology definition, risk identification, analysis and evaluation, treatment planning, documentation, and SoA cross-reference. Each step includes automated validation to catch gaps before an auditor does.



---

Back to [Skill Library](https://rakenne.app/skills/index.md)