Risk Assessment Services | Audit-Ready Evidence

ISO 27001 Risk Assessment Services

An ISO 27001 risk assessment is usually the first document your certification auditor opens, and often the one that decides how the rest of the audit goes. If your Stage 1 is on the calendar, the real question isn’t whether you need one. It’s whether the risk register, treatment plan, and Statement of Applicability you’re about to produce will actually survive scrutiny against clause 6.1.2 and the 2022 Annex A control set.

We build those three documents as a connected set: every risk in the register traces to a control in the SoA, every control has a treatment owner and a date, and every technical risk is backed by evidence rather than a guess. That’s the difference between documentation that moves you toward certification and documentation that comes back as a string of nonconformities.

What Your Auditor Checks at Stage 1 vs. Stage 2

Stage 1 is a documentation review. The auditor confirms your ISMS scope statement (clause 4.3) matches what you’re actually certifying, that your risk methodology defines consistent likelihood and impact criteria, that the risk register applies that methodology, and that your Statement of Applicability gives a justification for every one of the 93 Annex A 2022 controls, including the ones you’ve excluded. A vague exclusion (“not applicable”) without a documented rationale is one of the most common Stage 1 findings.

Stage 2 is where it gets harder. The auditor samples evidence that the controls in your SoA are actually operating, not just written down. For technical controls under clause A.8, vulnerability management (8.8), monitoring activities (8.16), security testing in development (8.29), that means they’ll ask: where’s the evidence this control is functioning? A risk register entry that says “external attacker exploits a web application vulnerability, likelihood: medium” needs something behind it. If the answer is “we haven’t tested that,” it’s a finding.

Our risk assessment is built with Stage 2 in mind from the start, not patched up after a Stage 1 pass.

Why a Vulnerability Scanner Doesn’t Satisfy Annex A 8.8

Annex A 8.8 requires that information about technical vulnerabilities be obtained in a timely manner, that the organization’s exposure to those vulnerabilities be evaluated, and that appropriate measures be taken. A lot of organizations run an automated scan, attach the PDF to their risk register, and treat 8.8 as closed. Increasingly, auditors don’t accept that, and for good reason.

A scanner flags what’s potentially exploitable based on version banners and known CVEs. It doesn’t chain findings together, doesn’t test business logic, and produces a list of CVSS scores that have nothing to do with your actual environment. The “exposure evaluated” requirement in 8.8 implies someone determined whether a vulnerability is actually reachable and exploitable in context, which is exactly what a scan output can’t tell you.

What You Get: The Audit-Ready Deliverable Set

Every deliverable is built to be handed directly to your auditor or your internal audit team, not reformatted first.

  • ISMS Scope Statement – context of the organization, internal/external issues, and interested parties (clause 4.3), aligned to your certification boundary
  • Asset Inventory – classified assets with named owners, ready for the SoA cross-reference
  • Risk Methodology – documented criteria, scoring scales, and risk acceptance thresholds
  • Risk Register – threats, vulnerabilities, existing controls, and risk ratings, with each entry mapped to an Annex A control
  • Risk Treatment Plan – selected controls, owners, target dates, and residual risk sign-off
  • Statement of Applicability (SoA) – full Annex A 2022 mapping with justification for every inclusion and exclusion
  • Executive Summary – written for leadership sign-off and for the auditor’s first read
  • Pre-Audit Readiness Review – a findings walkthrough conducted the way an assessor would run it

ISO 27001 Evidence Pack

This is what an auditor will physically see and ask about during your engagement:

  • ISMS scope statement mapped to your certification boundary, with named exclusions justified
  • Risk register (matrix format) with an Annex A 2022 cross-reference column for every entry
  • Statement of Applicability covering all 93 controls, inclusion/exclusion justified individually
  • Risk treatment plan with owner, target date, and residual risk acceptance recorded per item
  • Technical vulnerability assessment or penetration test report, mapped explicitly to controls A.8.8, A.8.16, and A.8.29
  • Internal audit checklist derived from the risk register, ready for your internal audit cycle
  • Management review input pack aligned to clause 9.3 reporting requirements
  • Pre-Stage-1 mock review notes documenting what was checked and resolved before the real audit

If your ISMS scope doesn’t currently include a recent technical assessment, we’ll flag that early. It’s the most common reason a risk register stalls during Stage 2.

1. Discovery and scoping

We confirm your ISMS boundary, business processes, and the systems and data in scope.

2. Asset and context mapping

Asset inventory, data classification, ownership, and data flows.

3. Threat and vulnerability identification

Workshops with your team plus a review of any existing technical evidence – scan results, prior pentest reports, architecture docs.

4. Risk evaluation

Likelihood and impact scoring against your defined methodology, with risk acceptance thresholds applied consistently.

5. Annex A control mapping

Selecting and justifying controls for the SoA, including documented rationale for exclusions.

6. Treatment planning

Owners, target dates, and budget for each treatment action, with residual risk explicitly recorded.

7. Pre-audit readiness review

A findings walkthrough run the way an assessor would conduct it, so nothing in the deliverable set surprises you during the real audit.

If Your Audit Is Six Weeks Out

  • Weeks 1-2: Scoping call, ISMS boundary confirmation, asset inventory, and kickoff of any technical assessment work in parallel.
  • Weeks 3-4: Risk register build, Annex A mapping, and technical assessment findings integrated as evidence for technical controls.
  • Week 5: SoA drafted with justifications for every control, treatment plan assigned to owners, executive summary written.
  • Week 6: Pre-audit readiness review, we walk through the deliverable set the way your auditor will, flag anything that needs tightening, and hand over the final pack.

This timeline assumes reasonable availability from your side for workshops and evidence requests. If you’re closer than six weeks out, tell us where things stand on the scoping call and we’ll tell you honestly what’s achievable in the time you have.

Frequently Asked Questions

Tell Us Where You Are in Your ISO 27001 Cycle

Whether you’re starting from a blank risk register or validating one you’ve already built, we’ll scope exactly what’s needed for your audit date and quote it as a fixed price.

Scroll to Top