ISO 27001 · 13 min read · Updated 2026-07-06

ISO 27001 checklist: scope, risk and evidence

A practical ISO 27001 checklist covering scope, assets, risk assessment, SoA decisions, policies, evidence and audit preparation.

Direct answer: what an ISO 27001 checklist should include

An ISO 27001 checklist gives a SaaS team a clear way to show that its information security management system has a defined scope, named owners, risk-based decisions and supporting evidence. Start with the ISMS boundary: products, systems, teams, suppliers, customer commitments and legal requirements that are actually in scope.

For a small team, the useful checklist covers scope, asset inventory, risk assessment, risk treatment, Statement of Applicability, policies, procedures, evidence, internal audit and management review. Each item needs an owner, evidence location, review frequency and status, so the programme can be inspected without rebuilding the story from scattered files.

General information only; this is not legal advice. Certification decisions and audit acceptability remain with your auditor or certification body.

Who this checklist is for

This checklist is for founders, operations leads and first security hires at SaaS companies preparing ISO 27001 work without a large GRC team.

  • You need to prepare for a customer security review or future certification.
  • Evidence is spread across tickets, folders, screenshots and policy drafts.
  • You need named owners and review dates before an auditor or consultant gets involved.

ISO 27001 scope checklist

  • Define the products, services and locations covered by the ISMS.
  • List core systems such as cloud hosting, identity, source control, support, billing and analytics.
  • Record excluded systems and why they are outside the boundary.
  • Map important customer commitments and contractual security obligations.
  • Assign an accountable owner for scope changes.

Asset inventory checklist

  • List information assets, systems, repositories, production services and high-risk datasets.
  • Record the business owner, technical owner and data classification.
  • Connect assets to vendors and access groups where possible.
  • Review critical assets at least quarterly or when systems change.

Risk assessment checklist

The risk assessment needs to show what could go wrong, who owns the risk, how likelihood and impact were scored, and which evidence supports the decision.

  • Define risk criteria before scoring.
  • Use scenarios rather than one-word risks.
  • Assign a risk owner for every material risk.
  • Link risks to affected assets, suppliers or business processes.
  • Record review dates and changed assumptions.

Risk treatment checklist

  • Choose reduce, accept, transfer or avoid for each risk.
  • Link treatment to controls, policy changes or remediation tasks.
  • Record due dates and accountable owners.
  • Keep accepted risks visible for management review.
  • Record residual risk after treatment.

Statement of Applicability checklist

  • Record whether each control applies.
  • Write a clear justification for inclusion or exclusion.
  • Link applicable controls to policies, procedures, evidence and risk treatment decisions.
  • Track implementation status and owner review.
  • Review the SoA after material scope or risk changes.

Policy and procedure checklist

  • Maintain approved policies for access, incident response, supplier security, asset management, acceptable use and change management.
  • Keep version history, approval owner and next review date.
  • Avoid policies that promise controls the team does not operate.
  • Link procedures to evidence records and responsible teams.

Evidence checklist

ISO 27001 checklist table
AreaWhat to checkEvidence to keepOwnerReview frequencyStatus
ScopeISMS boundary is current and approvedScope statement, system list, exclusionsSecurity leadQuarterlyNot started
AssetsCritical systems and data stores are listedAsset register, owner list, data classificationOperationsQuarterlyNot started
RiskRisk scenarios have owners and scoresRisk register, scoring criteria, review notesRisk ownerQuarterlyNot started
TreatmentOpen treatments have due datesRemediation tasks, accepted risk notesControl ownerMonthlyNot started
SoAControl decisions are justifiedStatement of Applicability, evidence linksISMS ownerQuarterlyNot started
PoliciesPolicies are approved and currentPolicy documents, approval historyPolicy ownerAnnuallyNot started
AccessPrivileged users are reviewedAdmin export, review note, removalsIT ownerQuarterlyNot started
SuppliersCritical vendors are reviewedVendor review, DPA, SOC report or security overviewVendor ownerAnnuallyNot started
AuditInternal audit findings are trackedAudit plan, findings, corrective actionsISMS ownerAnnuallyNot started

Internal audit and management review checklist

  • Agree the audit scope and evidence sample before review week.
  • Prepare current scope, SoA, risk register and policy list.
  • Review open findings, exceptions and overdue treatment work.
  • Record management review decisions, resources, incidents and improvement actions.

Common mistakes

  • Starting from Annex A controls before confirming the ISMS scope.
  • Using copied policies that do not match how the company works.
  • Treating screenshots as evidence without owner review or date context.
  • Hiding accepted risks or open treatment work.
  • Letting the SoA drift away from the risk register.

Where Trustega fits

In Trustega, scope, controls, risks, policies, vendors and evidence live in connected records. The aim is not to replace an auditor; it is to keep the work inspectable, owner-reviewed and current.

Common questions

Is this guide legal or certification advice?

No. This guide is for general information and is not legal advice. Use qualified legal, privacy or audit advisers for formal interpretation and assurance decisions.

Can a small SaaS team use this without a GRC team?

Yes. The workflows are designed for lean teams, but each record still needs a named owner, a review date and evidence that matches the actual scope.