ISO 27001 Risk Assessment

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 Treatment Plan (excerpt)

Extension Tools

risk_methodology_validator

Validates a risk methodology document against 11 Clause 6.1.2 requirements:

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.