Compliance365 — Cyber, Privacy & AI Compliance Compliance365

ISO 27001 information security readiness checklist (free)

Use this free ISO 27001 readiness checklist to quickly assess how mature your Information Security Management System (ISMS) is. Score governance, risk management, Annex A controls, security operations and continual improvement to see how ready you are for ISO 27001 certification or surveillance audit.

Objective

Gauge ISO 27001 ISMS maturity and how ready your organisation is for internal review or external certification audit.

Scoring

Yes / Partial / No. Progress and readiness update automatically across each domain.

Output

Download a branded PDF with domain breakdown, top gaps, Trust Score bands and next-step guidance.

ISO 27001 ISO 27701 ISO 42001 Essential Eight SOC 2 DISP / ISM / IRAP

Governance & ISMS

Scope, context, leadership, policy and roles.

0/0 answered
Be clear on what is in-scope for security governance and audit, and what is explicitly out-of-scope (with reasons).
Show examples
  • A one-page scope statement listing sites, cloud environments, core systems, and customer-facing services in scope.
  • A diagram showing boundaries (e.g., “Production AWS + corporate M365 in scope; personal devices out of scope”).
  • Documented exclusions with justification and compensating controls (if needed).
Show you understand who you must protect, what matters to the business, and the key obligations you must meet.
Show examples
  • Interested parties list (customers, regulators, insurers, partners) and their security expectations.
  • Register of legal/regulatory/contractual requirements (e.g., privacy, health, SOC 2 clauses, customer security addendums).
  • Security objectives aligned to business risks (e.g., protecting patient data, maintaining uptime, passing customer audits).
Auditors want proof leadership owns security outcomes, not just IT. Make accountability obvious.
Show examples
  • ISMS governance chart: Sponsor, ISMS owner, risk owners, control owners.
  • Leadership-approved policy statement and meeting minutes showing security is reviewed.
  • Evidence of resourcing decisions (budget, roles, priorities) tied to security risks.
Policies should be current, approved, accessible, and actually used by staff—supported by procedures where needed.
Show examples
  • InfoSec policy with version control, approval date, and next review date.
  • Supporting policies: access control, incident response, change management, supplier security, acceptable use.
  • Proof of communication (intranet link, staff acknowledgement, onboarding/training content).

Risk & Statement of Applicability

Risk assessment, risk register, Annex A controls and SoA.

0/0 answered
Define how you score risk and how decisions are made, so risk ratings are repeatable and defensible.
Show examples
  • Risk matrix with likelihood/impact definitions and scoring guidance.
  • Documented risk acceptance thresholds and who can approve exceptions.
  • Example of two different teams assessing risks using the same method and producing comparable outcomes.
Your risk register should show ownership, action, and momentum—not just a list of problems.
Show examples
  • Risk register entries with: description, assets affected, owner, treatment plan, due date, status.
  • Regular review cadence (monthly/quarterly) with updates and decisions recorded.
  • Linked evidence: tickets, remediation plans, change records, or accepted risk sign-offs.
Control selection should be traceable: risks and obligations drive what you implement.
Show examples
  • Mapping from key risks to specific Annex A controls.
  • List of customer/contract requirements mapped to controls (e.g., logging, MFA, encryption, supplier controls).
  • Evidence of review when scope or services change (new system, new region, new vendor).
The SoA is your audit “index”: it explains what applies, why, how it’s implemented, and where evidence lives.
Show examples
  • SoA with each control marked applicable/not applicable and a clear justification.
  • Implementation status (Implemented/Partial/Planned) and named control owner.
  • Direct links to evidence locations (SharePoint folder, ticket, report, configuration screenshot).

Operations & Controls

Assets, access, suppliers and secure change/development.

0/0 answered
You should know what you have, who owns it, and what needs protection—especially customer-facing and sensitive assets.
Show examples
  • Asset inventory covering applications, infrastructure, data stores, endpoints, and key SaaS tools.
  • Data classification or “crown jewels” list (critical systems/data) with owners.
  • Lifecycle controls: onboarding new assets, retirement, and periodic review.
Access should be granted based on role, removed quickly when no longer needed, and privileged access tightly controlled.
Show examples
  • Documented joiner/mover/leaver process with timelines and approvals.
  • Role-based access groups and periodic access reviews for sensitive systems.
  • Privileged access controls (admin accounts separated, MFA, just-in-time access, logging).
Prove you assess and manage third-party risk through due diligence, contracts, and ongoing oversight.
Show examples
  • Vendor risk assessment process (tiering by criticality and data access).
  • Contract clauses: security obligations, breach notification, audit rights, sub-processor controls.
  • Annual review of critical suppliers (SOC reports, ISO certs, questionnaires, performance and incident history).
Changes should be controlled so you don’t introduce security or availability issues into production.
Show examples
  • Change management workflow: risk assessment, approvals, test evidence, rollback plan.
  • Secure SDLC practices (code review, security testing, dependency scanning) appropriate to your environment.
  • Records of production changes with outcomes and post-implementation review for major changes.

Security Operations & Resilience

Logging, backups/DR, vulnerability management and incidents.

0/0 answered
Logs should help you detect and investigate events quickly—especially for identity, endpoints, cloud, and critical apps.
Show examples
  • Centralised logging for identity (SSO), endpoints, cloud audit logs, and key applications.
  • Alert rules for suspicious activity (impossible travel, admin role changes, excessive failed logins).
  • Documented log retention and access controls; evidence of alert review and triage.
Backups and recovery are only “real” when tested. RTO/RPO should match business expectations and contracts.
Show examples
  • Defined RTO (restore time) and RPO (restore point) per critical system.
  • Backup schedule, coverage (what is backed up), and monitoring/alerts for failures.
  • Evidence of restore tests and DR/BCP exercises with outcomes and improvements.
Show a repeatable process for finding vulnerabilities, prioritising them, fixing them, and proving closure.
Show examples
  • Regular scanning (infrastructure + apps) with documented frequency and scope.
  • Patch SLAs (e.g., critical within X days) and exception process for delayed remediation.
  • Remediation tracking (tickets) and evidence that high/critical issues are resolved or risk-accepted.
Your plan should be practical, tested, and integrated with comms, legal/privacy, and customer obligations.
Show examples
  • Incident response runbook with roles, severity levels, escalation paths, and contact list.
  • Tabletop exercise outcomes and lessons learned action plan.
  • Post-incident review template showing improvements made after incidents or near-misses.

Monitoring, Audit & Improvement

Metrics, internal audit, management review and improvements.

0/0 answered
Choose a small set of meaningful metrics that demonstrate control effectiveness and risk reduction over time.
Show examples
  • Monthly security dashboard: incidents by severity, patch SLA compliance, phishing training completion, audit actions overdue.
  • Targets and thresholds (e.g., “Critical vulnerabilities fixed within 14 days”).
  • Trend reporting to leadership with decisions/actions taken.
Internal audits verify the ISMS is working and give you time to fix issues before external audits.
Show examples
  • Annual internal audit plan covering ISO clauses and key Annex A areas.
  • Audit reports with findings, root cause, corrective actions, owners, and due dates.
  • Evidence that corrective actions are verified closed (not just marked “done”).
Management review is where leaders steer the ISMS—confirming priorities, resourcing, and decisions.
Show examples
  • Management review agenda/minutes covering required inputs (risks, audit results, incidents, metrics).
  • Recorded decisions: resourcing, policy changes, risk acceptance, major improvements.
  • Action register from management review with owners and follow-up.
Track improvements in one place so nothing gets lost and you can demonstrate ongoing maturity.
Show examples
  • Corrective action register linking to incidents, audits, vulnerabilities, or customer findings.
  • Root cause analysis notes and prevention actions (not just short-term fixes).
  • Evidence of recurring review and closure verification (before/after state).
0%
Not started

Answer the questions to see your readiness.

📞 Microsoft Teams