Preparing for an ISO 27001 audit: a practical ISO 27001 risk assessment guide

by SecureSlate Team in ISO 27001
4.8(214 reviews)

Photo: Unsplash

ISO 27001 risk assessment is the engine of a risk-based Information Security Management System (ISMS). It’s how you identify your highest-impact security risks, decide what to do about them, and produce evidence that holds up during certification audits.

In this guide, you’ll learn how the ISO 27001 risk assessment process works (including Clause 6 requirements) and how to execute it in six practical steps.

This guide covers:

  • What ISO 27001 expects from risk management (Clause 6.1.2 and 6.1.3)
  • When to run risk assessments (and common triggers)
  • A repeatable 6-step workflow you can run every year (and after major changes)
  • What to show an auditor: reports, approvals, and traceability to controls

Related guides:

When “risk-based” meets “we need this done by Friday”

GIF via GIPHY


Key takeaways

  • ISO 27001 requires a repeatable risk assessment process (Clause 6.1.2) that produces consistent, comparable results.
  • Risk treatment is just as important as risk identification (Clause 6.1.3): auditors expect to see decisions, selected controls, and approvals.
  • Your risk register must connect to evidence: assets → risks → scores → treatments → Annex A controls → Statement of Applicability (SoA).
  • Treat risk assessments as a continuous system: at minimum annually, and also after major change or incidents.
  • Centralized documentation speeds audits: the fastest ISO 27001 audits happen when your risk workflow, ownership, and evidence are in one place.

What is ISO 27001 risk management?

ISO 27001 takes a risk-based approach to building and maintaining an ISMS. In practice, ISO 27001 risk management has two connected components (Clause 6):

  • Risk assessment (Clause 6.1.2): identify, analyze, and prioritize information security risks using defined criteria
  • Risk treatment (Clause 6.1.3): decide what to do about those risks and implement the controls that support your decisions

What ISO 27001 expects from risk assessment (Clause 6.1.2)

Your risk assessment process should help you:

  • Establish and maintain risk criteria (how you define likelihood, impact, and acceptable risk)
  • Ensure assessments are repeatable and produce consistent, valid, comparable results
  • Identify and analyze information security risks (including internal, external, and third‑party risks)
  • Evaluate and prioritize risks based on your pre-defined criteria

What ISO 27001 expects from risk treatment (Clause 6.1.3)

After scoring and prioritizing risks, you should be able to show:

  • Selected risk treatment options aligned to your assessment results
  • The controls necessary to implement those options
  • A Statement of Applicability (SoA) that lists selected controls and justifies inclusion
  • Justifications for excluded Annex A controls (when applicable)
  • A documented risk treatment plan, with approval from relevant risk owners (and commonly leadership)

When should you conduct a risk assessment under ISO 27001?

Risk assessment is an ongoing activity, but it’s commonly triggered at specific points, such as:

  • Before implementing ISO 27001 (as part of certification readiness)
  • Before major strategic or technical changes (new product lines, major infrastructure shifts, acquisitions, new vendors)
  • After security incidents (to update assumptions and treatment plans)
  • At least annually (to keep your risk posture current and meet surveillance audit expectations)

If you want risk assessment to feel less like a once-a-year fire drill, design it as an owned workflow with clear inputs, outputs, and approvals.


How to conduct an ISO 27001 risk assessment (6 steps)

Here’s a practical six-step process you can run for initial certification and then repeat each year (or after major change).

1. Define your risk assessment methodology

Start by defining how you’ll measure and compare risks. There’s no single “correct” methodology, but your approach should be documented and usable across teams.

Your ISO 27001 risk assessment methodology typically includes:

  • How you’ll identify and document ISMS vulnerabilities and threats
  • Who owns each risk (risk owners and escalation paths)
  • How you’ll determine likelihood and impact
  • How you’ll rank risks (e.g., a 3–5 level scale, with numeric values)
  • Your criteria for deciding what gets treated now vs later (including acceptance thresholds)

Operational note: keep the methodology simple enough that it can be followed consistently, even when the team changes.

2. Identify and document risks and vulnerabilities

Next, identify the risks across your ISMS and capture them in a structured way. A common approach looks like this:

  1. Build an inventory of information assets (systems, services, data stores, endpoints, networks, key vendors)
  2. List likely threats and vulnerabilities tied to each asset
  3. Consolidate into a risk register (risk statement, scope, owner, likelihood, impact, controls, treatment)

Don’t stop at internal risks. ISO 27001 auditors often expect to see:

  • Third-party and supplier risks (especially when vendors process or host sensitive data)
  • External threats (phishing, credential stuffing, vulnerability exploitation, misconfiguration)
  • Environmental context where relevant (including climate-related risks if they plausibly affect availability or security in your operating context)

3. Analyze and prioritize risks

Once you have a risk register, score each risk using your likelihood and impact criteria. Many teams use a risk matrix to keep prioritization consistent.

Example 5-level likelihood scale:

  • Highly unlikely
  • Unlikely
  • Possible
  • Likely
  • Highly likely

To make prioritization consistent and auditable, assign numeric values to your scales (for example 1–5), then define thresholds that trigger treatment vs acceptance.

Here’s a simple scoring approach you can adapt:

Score element Example scale Notes
Likelihood 1–5 Based on exposure, historical incidents, control maturity, and threat activity
Impact 1–5 Based on confidentiality/integrity/availability impact, customer impact, legal/regulatory exposure
Risk score Likelihood × Impact Use thresholds (e.g., 15+ = treat, 8–14 = plan, 1–7 = accept/monitor)

4. Select and implement risk treatment options

For each priority risk, decide on a treatment approach and map it to controls.

Common treatment options include:

  • Reduce the risk (implement/strengthen controls)
  • Avoid the risk (stop the activity or change scope)
  • Transfer/share the risk (contracts, insurance, outsourced services—while retaining accountability)
  • Accept the risk (with documented justification and approval)

In ISO 27001 programs, treatment commonly involves selecting relevant Annex A controls and documenting how they reduce likelihood and/or impact.

Make the mapping explicit:

  • Risk → treatment option → controls → control implementation evidence → residual risk

This traceability is what makes your risk management “audit-ready,” not just “done.”

5. Produce audit-ready risk reports

Auditors typically want to see evidence of completed assessment and treatment planning, often through three artifacts:

  • Risk assessment report (methodology, scope, results, scoring)
  • Risk summary that explains prioritization decisions
  • Risk treatment plan (selected treatment options, controls, owners, timelines, approvals)

Also ensure management review (and approvals where required by your process) are documented. In practice, the most common audit friction is not the absence of a risk register—it’s missing approvals, unclear ownership, or weak linkage to controls and evidence.

6. Monitor and review your ISMS continuously

Risk management is not a one-time project. To maintain certification, you’ll typically reassess risks at least annually and update treatment plans as your environment changes.

A lightweight, repeatable monitoring rhythm can include:

  • Scheduled reassessments (quarterly check-in, annual full reassessment)
  • Trigger-based reviews (new vendors, major architecture changes, incidents)
  • Tracking residual risk and remediation progress over time

If you’re doing this in spreadsheets and scattered docs, audits will feel heavier than they need to. Centralized, real-time (or near real-time) documentation makes reassessment and evidence collection much easier.


Streamline ISO 27001 risk assessments with SecureSlate

If your team is preparing for ISO 27001 certification, the goal isn’t just “complete a risk assessment.” It’s to run a repeatable risk workflow that ties directly to ownership, remediation, controls, and evidence—so audits don’t turn into a scramble.

SecureSlate helps teams streamline ISO 27001 risk assessment and treatment by:

  • Centralizing your risk register with consistent scoring and ownership
  • Linking risks to controls and evidence so audit traceability is clear
  • Tracking remediation work with accountable owners and due dates
  • Keeping audit readiness continuous, so surveillance audits are simpler

Get started for free: Create your SecureSlate account


FAQs: ISO 27001 risk assessment

Is an ISO 27001 risk assessment mandatory?

Yes. ISO 27001 requires a defined, repeatable risk assessment process (Clause 6.1.2) and corresponding risk treatment planning (Clause 6.1.3).

How often should we do an ISO 27001 risk assessment?

At minimum, organizations commonly perform a full reassessment annually, plus additional reviews after major changes or incidents. Your audit cycle and internal governance may require more frequent updates.

What does an auditor want to see for risk assessment?

Typically: your documented methodology, a risk register with scoring and ownership, treatment decisions, a treatment plan, and traceability to controls and the Statement of Applicability—plus evidence of review/approval.

What’s the difference between risk assessment and risk treatment?

Risk assessment is identifying, analyzing, and prioritizing risks. Risk treatment is deciding what to do about them (reduce/avoid/transfer/accept) and implementing controls and plans accordingly.


Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to relevant laws and regulations, you should consult a licensed attorney.

Need compliance without the complexity?

SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.

No credit card required

Filed under: ISO 27001

Author: SecureSlate Team

Related blogs