ISO 27001 risk assessment is how you identify, analyse, and treat information security risks in a way auditors can follow — the standard does not mandate a single methodology. The risk register is the compass for your SoA, budget, and internal priorities.
Good assessment connects business reality to Annex A: not every control applies, but every relevant control should trace to a risk or explicit exclusion. SaaS and SMEs often focus on identity, chain, development process, and data residency.
What does this mean?
Risk assessment covers threat and vulnerability identification, impact and likelihood estimation, and treatment choice: mitigate, accept, transfer, or avoid. Define criteria before scoring — retroactive changes are hard to defend.
The register is living: assets, threats, current controls, residual risk, owner, review date. Auditors sample high-risk items and follow chains to tickets, configs, and acceptance decisions.
Qualitative matrices work for many SMEs if applied consistently. FAIR or CRQ is optional — explain your choice at stage 1.
Treatment links to SoA — each measure should reference a risk ID. Risks without treatment or acceptance are red flags.
Threat modelling in engineering can feed product risk identification — same language on impact and ownership.
Who is this for?
CISOs for roadmap and board reporting; product owners prioritising security in releases; compliance linking risks to contracts and DPIAs; finance seeing acceptance decisions with budget impact.
SMEs: sharp top-10 list with quarterly review beats hundreds of stale rows. Hypergrowth scale-ups revisit risk after new regions or integrations.
Internal auditors use the register to plan samples on high impact or recent changes.
What steps or requirements apply?
Define criteria with leadership: impact scales, likelihood, acceptance threshold, and who may accept residual risk.
Inventory assets and data flows from scope. Identify threats: unauthorised access, ransomware, vendor outage, insider, cloud misconfiguration.
Score, prioritise, treat. Document residual risk and owner. Link actions to tickets with deadlines.
Review at least annually and on significant change — new product, acquisition, major vendor switch.
Common mistakes
Generic template without your stack. Scores without criteria — everything ‘medium’. Risks named but not treated.
Incidents and near-misses not fed back. Privacy risks in a separate silo contradicting Annex A priorities.
Acceptance without recorded management decision. DevOps deployment risks ignored.
Practical action plan
Workshop scope + assets; scoring and top-15; treatment plans and SoA linkage; leadership review. Input from scope and context.
One register with version control — link Jira/Linear tickets to risk IDs. Internal audit dry-run on three high risks in 48 hours.
Post-certification: CVEs, vendor incidents, and pentest findings enter the register within defined SLAs. See SoA.
Relationship with ISO 27001, NIS2, GDPR or ISMS
Clause 6.1 bridges ISMS planning and certification. NIS2 emphasises chain risk — model vendors and SaaS as assets.
GDPR DPIAs feed processing risks. Evidence shows treatment works. One tagged register avoids duplicate work.
Risk appetite statement from leadership gives scoring context — without it, every team interprets ‘acceptable’ differently.
Business continuity risks belong in the same register — not a separate BCP document auditors cannot link to treatment.
Cloud misconfiguration scenarios (public bucket, open SG) should appear explicitly for SaaS on AWS/Azure/GCP.
Risk review meeting minutes with who attended — proves clause 6 participation beyond security silo.
Escalation path when residual risk exceeds appetite — named executive and timeline.
Link customer SLA penalties to impact scores — makes risk real for product and finance, not abstract.
Fourth-party risk via critical SaaS subprocessors — note concentration risk when one vendor hosts identity, mail, and docs.
AI feature risk row when product ships ML — training data leakage and model abuse are 2026 audit conversation topics.
Risk treatment budget field — finance sees cost to mitigate vs accept; avoids silent deferral.
Historical incident IDs cross-linked — shows learning loop, not static register.
Qualitative vs quantitative choice documented once — auditors ask why you chose your method at stage 1.
Fourth-party concentration when one hyperscaler hosts identity, compute, and backup — document single-points in register with treatment or acceptance.
Risk workshop attendance from product, ops, and finance — not security-only — satisfies clause 6 participation expectations in interviews.
Customer SLA financial penalties referenced in impact scoring — connects risk language to revenue and legal exposure leadership understands.
Post-incident review updates register within ten business days — auditors trace whether you learn or repeat the same gap yearly.
Risk workshop agenda: confirm scope assets, introduce scoring criteria, score top assets in session, assign owners and treatment deadlines before room leaves. Minutes with attendee names satisfy clause 6 participation better than circulated spreadsheets.
Treatment plans distinguish project work from run-state — ‘implement MFA’ needs ticket, budget line, and completion metric such as enrollment percentage by date. Auditors sample completion, not project charter existence.
Accepted risks carry expiry and trigger — ‘accept until Q4 while vendor migrates’ beats permanent acceptance without review. Management review must reconfirm before expiry or treatment auto-escalates.
Link risk register exports to management review pack automatically — leadership sees open high items with owners, not static PDF regenerated manually each quarter.
Risk register version printed in management review pack with change log — demonstrates living document, not pre-audit rewrite.
Threat intelligence feed linked to risk review agenda — new sector campaigns become register updates, not ad-hoc Slack alerts.
Chain dependencies deserve dedicated rows: identity provider, email, DNS, backup SaaS and payment gateway — compromise or outage hits multiple Annex A controls at once.
Post-pentest: every medium+ finding gets a risk ID or dated acceptance — auditors link testing to clauses 6.1 and 8.8; a PDF without register update fails surveillance.
Board slides should translate risk in business terms — pure CVSS jargon without customer impact or contractual penalty context weakens management review evidence.
Tabletop scenarios (ransomware, insider, cloud misconfig) feed realistic triggers — theoretical registers without scenarios feel hollow in stage 2 interviews.
Concentration risk when one engineer or one SaaS vendor holds critical knowledge — explicit register rows with exit plans satisfy chain and continuity auditors.
Enterprise questionnaire findings become treatment or acceptance — ad-hoc spreadsheets beside the register create surveillance inconsistency.
Risk register version in management review pack with change summary — board sees delta, not only static snapshot from last year.
Threat intelligence feed linked to risk review agenda — new CVE classes trigger reassessment of related assets within agreed SLA.
Accepted risks without expiry date fail surveillance — every acceptance needs review date and named approver at or above documented appetite threshold.
Link customer SLA penalties to impact scores — financial quantification optional but strengthens board conversations.
Review risk criteria when organisation doubles headcount or revenue — scales that worked at 20 FTE break at 80 without recalibration.
Document why qualitative scoring was chosen over quantitative — stage 1 expects methodology rationale, not only filled spreadsheet.
Seasonal risk review before peak trading or renewal periods — SaaS vendors often miss capacity and fraud spikes tied to commercial calendar.
Risk workshop attendees listed in register version history — proves cross-functional input beyond security-only scoring sessions.
Export risk register with hash or version ID before audit — proves which snapshot management reviewed.