How to Run a Risk Assessment with AI
Clause 6.1.2 of ISO 27001 demands a repeatable risk assessment, and PCI DSS v4 added targeted risk analyses for flexible requirements. Most first attempts stall at the blank risk register.
AI removes the blank page: it proposes risks from your context, drafts the scoring, and keeps the register alive between annual reviews. Humans own the ratings and acceptance.
Step by step
- 1
Fix the methodology first
Decide scales (1 to 5 likelihood and impact), risk appetite, and acceptance criteria, and write them down. AI can draft this methodology document; management must approve it. Consistency is what auditors test.
- 2
Generate a candidate risk list with AI
Describe your stack, data, vendors, and history; ask AI for candidate risks per asset group with threat and vulnerability stated separately. Expect 60 to 80 percent useful; the rest you cut.
- 3
Score in a workshop, not alone
Likelihood and impact ratings need the people who run the systems. AI pre-fills suggested scores with reasoning; the workshop confirms or corrects them in a fraction of the usual time.
- 4
Map treatments to controls
For each risk above appetite, AI proposes treatment options and maps them to ISO Annex A controls or PCI requirements, which feeds your Statement of Applicability directly.
- 5
Get explicit acceptance
Risk owners sign off residual risk. This is a human signature, never an AI output. Record who accepted what and when.
- 6
Re-run on triggers, not just annually
New vendor, new system, incident, or major change triggers a delta assessment. AI makes the delta cheap: feed it the change, get the new and changed risks.
Where AI helps
- Risk identification: AI proposes candidate risks from your stack and history.
- Pre-scoring: AI suggests likelihood and impact with reasoning for the workshop to confirm.
- Treatment mapping: AI maps treatments to Annex A controls and PCI requirements.
- Delta assessments: AI turns any change description into the new and changed risks.
Tips
- ›Separate threat from vulnerability in every risk statement; mushy risks get mushy scores.
- ›A register over 100 rows for a small company means you are listing scenarios, not risks. Merge.
Skills and templates
Copy-paste these into your AI assistant (as a custom skill, project instruction, or system prompt) or your repo. Replace the [bracketed] placeholders with your details.
Risk assessor skill
Runs the identify, pre-score, and treatment-mapping passes against your context. Workshop confirms, owners accept.
risk-assessor.SKILL.md--- name: risk-assessor description: Proposes candidate information security risks, pre-scores them, and maps treatments to ISO 27001 / PCI DSS controls. Humans confirm scores and accept residual risk. --- You are the risk assessment assistant for [Company]: [size], [industry], stack: [stack], data held: [data types], key vendors: [vendors]. Methodology: likelihood 1-5, impact 1-5, score = L x I, appetite: treat anything above [10]. Mode 1, IDENTIFY. Propose candidate risks grouped by asset. Each: Risk ID, asset, threat, vulnerability, existing controls if obvious. Mode 2, SCORE. For each risk, suggest L and I with one sentence of reasoning each. Mark all scores [WORKSHOP TO CONFIRM]. Mode 3, TREAT. For each risk above appetite: treatment option (treat, tolerate, transfer, terminate), the specific ISO Annex A controls or PCI DSS requirements that implement it, and the residual score you would expect. Mode 4, DELTA. Given a change description, output only new risks and changed scores. Rules: - Threat and vulnerability always stated separately. - Never output an acceptance decision; that belongs to the risk owner. - Cap the register: merge scenario variants of the same underlying risk.
Targeted risk analysis template (PCI 12.3.1)
The per-requirement analysis PCI DSS v4 asks for when you set your own frequencies.
targeted-risk-analysis.md# Targeted risk analysis, PCI DSS requirement [x.y.z] - Requirement: [e.g. 5.3.2.1, frequency of periodic malware scans] - Asset(s) protected: [what this activity protects] - Threat(s): [what could go wrong if done less often] - Factors affecting likelihood: [environment, exposure, history] - Factors affecting impact: [data, volume, blast radius] - Chosen frequency: [e.g. weekly] - Justification: [why this frequency keeps risk acceptable] - Approved by: [name, role] Date: [date] - Next review (max 12 months): [date]
Run this with Drata
Automated, continuous compliance with deep integrations.
FAQ
- Does ISO 27001 mandate a specific risk methodology?
- No. It requires a defined, consistent, repeatable process with criteria. A simple 5x5 likelihood and impact matrix is fine if you apply it consistently.
- What is a PCI DSS targeted risk analysis?
- PCI DSS v4 lets entities set the frequency of certain activities based on a documented, annually reviewed risk analysis per requirement 12.3.1. AI drafts these well from a template.