Every ISO/IEC 27001:2022 certification stands or falls on one document: the risk assessment. Auditors don't just check that you have a risk register — they check that your methodology is repeatable, your scoring is defensible, and your Statement of Applicability actually traces back to real, assessed risks. Get this wrong and you'll spend six months in remediation loops with your certification body.
Most teams treat the risk assessment as a compliance exercise: fill in a spreadsheet, assign some red/yellow/green scores, move on. That approach passes a first audit maybe half the time — and it produces a register that's useless for actually reducing risk. A good ISO 27001 risk assessment identifies where a compromised dependency, a misconfigured pipeline, or an unvetted vendor could actually hurt you, and ties every Annex A control decision back to that evidence.
This guide walks through how to conduct one end to end: scoping, asset identification, risk scoring, treatment, and the ongoing cadence auditors expect — including where a GRC platform like Secureframe helps and where it doesn't.
What is an ISO 27001 risk assessment, exactly?
An ISO 27001 risk assessment is the documented process, required by Clause 6.1.2 of ISO/IEC 27001:2022, of identifying information security risks to your organization, analyzing their likelihood and impact, and evaluating them against a defined acceptance criteria. It is not the same thing as the Statement of Applicability (SoA) — the SoA is the output that maps your 93 Annex A controls (organized into four themes: Organizational, People, Physical, Technological) to the risks you found. Auditors will ask to see the chain: asset → threat → vulnerability → risk score → control → justification. If any link is missing — say, you selected control A.8.28 (secure coding) but can't point to a risk it addresses — that's a nonconformity. ISO/IEC 27005:2022 provides the companion guidance most assessors expect you to reference for methodology, even though it isn't itself certifiable.
When do you need to conduct one?
You need a formal risk assessment before your Stage 1 audit, and then again at least annually or whenever a "significant change" occurs — a new production region, an acquisition, a new critical vendor, or a major architecture shift like moving build infrastructure to a new CI/CD provider. In practice, certification bodies such as BSI, DNV, and Schellman will flag a register that hasn't been touched in over 12 months as evidence the ISMS isn't operating, which is a Clause 9.3 (management review) and Clause 9.1 (monitoring) finding. Fast-growing SaaS companies typically re-run a full assessment every 6 months in year one, then settle into an annual cycle once the ISMS matures. If you ship code weekly and pull in new open-source packages continuously, waiting a full year to reassess third-party and supply chain risk is usually too slow — those risks change faster than your audit calendar.
How do you scope the assessment?
Scoping means defining the boundary of your ISMS — which systems, teams, data flows, and third parties are in scope — before you can assess anything, per Clause 4.3. A typical mid-market SaaS company (100–300 employees) scopes in: production infrastructure (AWS/GCP accounts), the CI/CD pipeline, source code repositories, customer data stores, and the top 20–30 vendors with access to production or customer data. It scopes out things like the marketing website if it holds no customer data and shares no infrastructure. Get this wrong in either direction and you pay for it: over-scope and you're assessing risk on systems the auditor doesn't even care about, wasting weeks; under-scope and the auditor will pull a sample — commonly 10–15% of your vendor list or asset inventory — find something you missed (an unassessed subprocessor, an unmanaged S3 bucket), and issue a scope-boundary nonconformity that stalls certification.
How do you identify and score risks?
You identify risks by building an asset inventory first, then mapping threats and vulnerabilities to each asset, and scoring likelihood × impact on a consistent scale — most commonly a 5×5 matrix producing scores from 1 to 25. Assets fall into a handful of categories: information assets (customer PII, source code, credentials), technology assets (production servers, build systems, SaaS tools), and people/process assets. For each, you ask: what could go wrong (threat), what makes that possible (vulnerability), and how bad and how likely is it. A concrete example: your asset is "CI/CD pipeline," the threat is "malicious code injection via a compromised build dependency," the vulnerability is "no SBOM or dependency provenance verification," likelihood is scored 4/5 given the frequency of npm/PyPI supply chain incidents in 2024–2025, and impact is scored 5/5 because it reaches production. That's a risk score of 20 — squarely in the "must treat" band on most 25-point matrices, typically anything above 12–15. Risks below your acceptance threshold (often 6–8) can be formally accepted and documented as such under Clause 6.1.3.
How do you choose treatment options and map them to Annex A?
You choose treatment by selecting one of four options — mitigate, transfer, avoid, or accept — for each risk above your threshold, then mapping the mitigation to specific Annex A controls in your SoA. For the supply chain example above, the treatment is "mitigate," and it maps to A.8.28 (secure coding), A.5.23 (information security for use of cloud services), and A.5.21 (managing information security in the ICT supply chain) — one of the controls organizations most frequently mark "not yet fully implemented" on first assessment, because verifying the security posture of every upstream dependency and vendor is operationally hard to do by hand. Each control needs an implementation owner, a target date, and evidence — a policy document alone doesn't satisfy an auditor; they want to see the control operating (e.g., an actual SBOM being generated on every build, not just a policy that says one should be).
How often should you repeat it and what does an auditor want to see?
You repeat the full risk assessment at least once every 12 months, with lightweight interim reviews triggered by significant changes, and auditors want to see version history proving the register is a living document, not a one-time artifact produced two weeks before the audit. During surveillance audits (conducted annually in years one and two of your three-year certification cycle), assessors commonly sample 3–5 risks from the register and ask you to walk through the current status of the associated controls, plus any incidents that occurred since the last review and whether they fed back into new or re-scored risks. A register with a single "last updated" timestamp from 11 months ago, no incident linkage, and no evidence of management review sign-off is one of the most common Stage 2 minor nonconformities cited by certification bodies.
How Safeguard Helps
GRC platforms like Secureframe are genuinely good at what they're built for: automating evidence collection for administrative and policy controls, running vendor security questionnaires, and keeping your SoA organized for the audit. Where that model runs out of depth is exactly the risk category auditors are pushing hardest on right now — A.5.21, A.5.23, and A.8.28, the software supply chain controls. A questionnaire response from a vendor telling you they "follow secure development practices" isn't evidence; it's a claim.
Safeguard generates the actual technical evidence those Annex A controls require, and feeds it directly into your risk register as data instead of self-attestation. That means continuously generated SBOMs across your build pipeline, dependency and transitive-dependency vulnerability scoring, build provenance and attestation (SLSA-aligned) so you can prove what actually shipped to production, and real-time monitoring of the open-source packages and third-party build tools in your supply chain — the exact "vulnerability" side of the threat/vulnerability pairing that risk scoring requires.
Concretely, when Safeguard detects a new critical CVE in a package you depend on, it doesn't just alert you — it gives you the asset, the exploitability data, and the affected build artifacts needed to re-score that risk on your existing 5×5 matrix within minutes, and to update your treatment plan with a documented trail an auditor can follow. Teams running Safeguard alongside a GRC platform like Secureframe get the best of both: policy and evidence-collection automation for the administrative controls, and real supply chain telemetry for the technical ones — so your risk assessment reflects what's actually running in production, not just what a spreadsheet says should be.