Every ISO 27001 audit starts in the same place: a risk assessment that can withstand an auditor's scrutiny. Yet most organizations treat it as a compliance checkbox rather than the analytical backbone the standard requires it to be. Get the methodology wrong — inconsistent scoring, missing asset context, a risk register that hasn't been touched since certification — and it becomes the single most common reason Stage 2 audits stall or Statements of Applicability get kicked back for rework.
Platforms like Vanta have made the paperwork side of ISO 27001 faster: templated policies, automated evidence collection, pre-built risk registers. But a risk assessment is only as good as the data feeding it, and generic GRC tooling has limited visibility into the software supply chain — the dependencies, build pipelines, and third-party code that increasingly drive real security risk. This post breaks down what ISO 27001:2022 actually requires for risk assessment, where automation platforms fall short, and how Safeguard closes the gap between compliance paperwork and technical risk reality.
What Is the ISO 27001 Risk Assessment Methodology, Exactly?
It's a documented, repeatable process for identifying information security risks, analyzing their likelihood and impact, and deciding how to treat them — defined under Clauses 6.1.2 and 8.2 of ISO/IEC 27001:2022. The standard doesn't mandate a specific scoring model (no required 1-5 scale, no mandatory heat map), but it does require that your methodology produce "consistent, valid, and comparable results" every time it's applied. In practice this means three fixed stages: risk identification (what assets exist and what could go wrong), risk analysis (how likely and how damaging), and risk evaluation (does this exceed our defined risk acceptance criteria, set in Clause 6.1.2(a)). Auditors will ask to see this methodology as a standalone document, distinct from the risk register itself, and they will check whether it was actually followed — not just written down. A common Stage 2 finding is a methodology document describing a 5x5 impact/likelihood matrix while the actual risk register uses ad hoc High/Medium/Low labels with no traceable calculation.
Which Risk Assessment Approach Does ISO 27001:2022 Require?
The 2022 revision requires an asset-based, control-mapped approach tied to the 93 controls in the restructured Annex A — down from 114 controls across 14 domains in the 2013 version, now organized into four themes: Organizational (37), People (8), Physical (14), and Technological (34) controls. This restructuring matters for methodology because your risk assessment needs to map identified risks to specific Annex A controls (or justified exclusions) in your Statement of Applicability. Many organizations that certified under ISO 27001:2013 and transitioned before the October 31, 2025 deadline had to redo this mapping entirely, since the control numbering and groupings changed substantially — for example, the old A.6.2.1 "Mobile device policy" now sits under the merged A.8.1 technological controls alongside device management. If your risk assessment methodology still references 2013-era control IDs, that's an immediate audit flag.
How Do You Calculate Risk Under ISO 27001, and What Do Auditors Expect?
Risk is calculated as a function of likelihood and consequence applied to a specific asset, threat, and vulnerability combination — most commonly Risk = Likelihood × Impact, scored on a defined scale (3x3, 5x5, or a qualitative equivalent). What auditors actually expect is traceability: for every entry in your risk register, they want to see the asset it applies to, the threat/vulnerability pairing, the scoring rationale, the calculated risk level, and the decision (accept, mitigate, transfer, avoid) tied back to your risk acceptance criteria. A frequent gap: organizations score "third-party software risk" as a single line item rather than assessing it per-dependency or per-vendor, which collapses dozens of distinct risks (a critical CVE in an unpatched library versus a low-severity misconfiguration in an internal tool) into one number that means nothing to an assessor. ISO 27001 Clause 8.2 requires you to perform this risk assessment "at planned intervals or when significant changes are proposed" — most certified organizations run it annually at minimum, with interim updates after major infrastructure or vendor changes.
Why Do Compliance Automation Platforms Fall Short on Risk Assessment?
Because they automate evidence collection and policy generation, not the risk analysis itself, which still depends on data most GRC platforms don't natively see. Vanta, Drata, and similar tools excel at pulling configuration evidence from your cloud provider, HR system, and MDM, and they'll generate a starter risk register with common risk scenarios pre-populated. But ISO 27001's technological controls — A.8.25 (secure development lifecycle), A.8.28 (secure coding), A.5.23 (cloud service security) — require risk data about your actual codebase, dependency tree, and build pipeline that a connector-based GRC tool typically can't produce on its own. The result is a risk register with a generic "vulnerability management" entry scored Medium, instead of a risk assessment grounded in the fact that your production build depends on 340 third-party packages, 12 of which have known critical CVEs, three of which are unmaintained. Auditors increasingly probe this gap directly, asking how software supply chain risks were identified and scored — a question templated risk registers aren't built to answer with specificity.
What Does a Risk Treatment Plan Look Like in Practice?
It's a document mapping each unacceptable risk from your register to a specific treatment option, control, owner, and target date — required under Clause 6.1.3 as the direct output of the risk assessment. For a supply chain risk example: if your assessment identifies that a payment-processing service depends on a package with a known critical vulnerability (say, a CVSS 9.1 remote code execution flaw), the treatment plan should specify the chosen option (mitigate via patching, or avoid via replacement), the responsible engineer, the Annex A control invoked (A.8.28, Secure Coding), and a remediation deadline — commonly 15-30 days for critical findings under most internal SLAs. Auditors will sample these entries during Stage 2 and ask for closure evidence: a Jira ticket alone rarely satisfies them; they want to see the vulnerability status before and after remediation. Organizations that fail this check most often have a treatment plan that exists as a spreadsheet column reading "Fixed" with no linked evidence of when or how.
How Often Should You Reassess Risk, and What Triggers a Reassessment?
Formally, ISO 27001 requires reassessment at defined planned intervals — nearly all certified organizations set this at 12 months to align with the annual surveillance audit cycle — but it also requires reassessment triggered by significant change, and this is the clause most organizations under-implement. A significant change includes a new production dependency, a new cloud region, an acquisition, or a newly disclosed critical vulnerability affecting something in your environment (think: a Log4Shell-scale event). If your methodology doesn't define what counts as "significant" for your environment, an auditor can reasonably conclude your risk assessment process is reactive rather than systematic. A practical benchmark: organizations with mature ISO 27001 programs typically re-score affected risks within 5 business days of a critical CVE disclosure impacting production software, rather than waiting for the next annual cycle.
How Safeguard Helps
Safeguard is built specifically to feed the technical half of your ISO 27001 risk assessment that GRC automation platforms like Vanta can't generate on their own. Where Vanta gives you the register template and the audit-evidence workflow, Safeguard gives you the underlying risk data for your software supply chain: continuous SBOM generation, dependency-level vulnerability scoring mapped to CVSS and exploitability context, and build-pipeline visibility that maps directly to Annex A technological controls (A.8.25, A.8.28, A.5.23, A.8.9). Instead of a single generic "third-party software" line in your risk register, Safeguard produces per-dependency, per-repository risk data you can import directly into your risk assessment methodology — with likelihood and impact grounded in actual exploitability and exposure, not estimation.
Safeguard also automates the "significant change" trigger that most organizations handle manually: when a new critical CVE lands in a dependency you use, Safeguard flags the affected assets immediately, so your risk register reassessment happens within days, not at the next annual cycle. That evidence trail — timestamped detection, remediation status, and closure — is exactly what auditors sample during Stage 2 reviews of your risk treatment plan.
For teams already running Vanta or another GRC platform for policy and evidence management, Safeguard is designed to sit alongside it rather than replace it: Safeguard handles the software supply chain risk data your GRC tool can't natively see, and that data flows into the same risk register and Statement of Applicability your auditor is going to review. The result is a risk assessment methodology that holds up not because the paperwork looks right, but because the numbers behind it are real.