An ISO 27001 audit checklist helps you test whether your information security management system can be evidenced in an audit—not just whether policies exist. Use it to connect each requirement or control area to an audit question, current evidence, an owner, readiness status, and any corrective action.
ISO/IEC 27001:2022 specifies requirements for an information security management system and uses a risk-management approach, a checklist can support preparation, but it does not replace the standard, your audit scope, or your certification body’s plan. Use your licensed copy of the standard to validate the exact requirements you need to evidence. (ISO)
What is an ISO 27001 audit checklist?
An ISO 27001 audit checklist is a structured audit-preparation tool. Its purpose is to answer — or, more exactly, to help answer: “Can we show relevant, current, traceable evidence that our ISMS is designed, approved, operating, reviewed, and remediated where needed?”
For this article, use these distinctions:
| Checklist type | Main purpose | Audit-readiness limitation |
|---|---|---|
| Implementation checklist | Builds the ISMS | May show tasks completed, but not whether controls are operating |
| Requirements checklist | Maps ISO 27001 requirements | May identify what applies, but not where evidence lives |
| Gap analysis checklist | Identifies missing or immature areas | May show shortfalls, but not manage audit evidence |
| Audit checklist | Organises audit questions, evidence, owners, status, and actions | Best used with current evidence and follow-up tracking |
For certification, organisations assess their ISMS against Clauses 4–10, while Annex A is treated as part of risk-based control selection and applicability work. (BSI) ISO/IEC 27002:2022 provides implementation guidance for information-security controls; its 2022 edition contains 93 controls corresponding to the Annex A control set in ISO/IEC 27001:2022. (ISO/IEC JTC 1/SC 27)
How to use the checklist: documentation, operating evidence, and corrective actions
Assess each checklist item across three practical layers. A working model, not an ISO-prescribed maturity model.
| Readiness layer | What you are checking | Example question |
|---|---|---|
| Documented | The required policy, scope, process, risk record, SoA entry, review record, or plan exists and is approved where needed | “Can we show the current approved version?” |
| Operating | There are records showing the process or control has been performed during the audit period | “Can we show completed reviews, tickets, logs, reports, or approvals?” |
| Actioned | Gaps, findings, and nonconformities have owners, due dates, completion evidence, and follow-up review | “Can we show what was fixed and how completion was verified?” |
Use statuses that force an evidence-based conversation:
| Status | Use when |
|---|---|
| Not started | No documented approach or evidence exists yet |
| Planned | Work is assigned but evidence is not yet available |
| Documented | The process or control is defined, but operating evidence is limited or not yet sampled |
| Partially operating | Some evidence exists, but coverage, consistency, or ownership is incomplete |
| Operating | Evidence is current, traceable, reviewed, and aligned with the audit scope |
| Blocked | Progress depends on a decision, system access, owner input, or external dependency |
| Needs corrective action | A gap, finding, or nonconformity requires tracked remediation |
Do not set a status based on self-assessment alone. Link it to evidence location, date range, owner, and open action.
ISO 27001 audit-readiness checklist
The table below is a representative checklist, not a complete reproduction of ISO 27001 or Annex A. Adapt it to your licensed copy of the standard, your Statement of Applicability, your risk treatment decisions, and the audit scope.
| Requirement / control area | Audit question | Evidence to collect | Evidence location / source | Owner | Date range covered | Last review date | Readiness status | Open action | Corrective-action owner |
|---|---|---|---|---|---|---|---|---|---|
| ISMS scope and context | Can we show the current ISMS scope and explain boundaries, exclusions, interfaces, and relevant context? | Approved ISMS scope, context analysis, scope diagram, business/process inventory | GRC workspace / ISMS folder | GRC lead | Current period | YYYY-MM-DD | Documented | Confirm scope still matches systems and teams in audit scope | CISO |
| Interested parties and information security requirements | Can we show how relevant stakeholder and information security requirements are identified and reviewed? | Interested-party register, contractual/security requirement register, review notes | GRC register / contract repository | Compliance manager | Current period | YYYY-MM-DD | Partially operating | Update review evidence for new customer requirements | Compliance manager |
| Risk assessment methodology | Can we explain the risk assessment method and show it has been applied consistently? | Risk methodology, risk criteria, risk assessment records | Risk register | Risk owner | Audit period | YYYY-MM-DD | Operating | None | — |
| Risk register | Can we trace key information security risks to owners, treatment decisions, and review dates? | Risk register, review history, risk owner approvals | GRC platform / risk tracker | Risk owners | Audit period | YYYY-MM-DD | Partially operating | Add missing review notes for high-priority risks | Risk owner |
| Risk treatment plan | Can we show selected treatments, owners, due dates, and progress? | Risk treatment plan, project tickets, acceptance records, exception approvals | GRC platform / Jira / ticketing system | Security programme owner | Audit period | YYYY-MM-DD | Needs corrective action | Overdue treatment item requires updated plan | Security programme owner |
| Statement of Applicability | Can we show which Annex A controls are applicable, the rationale, and current implementation status? | Current SoA, approval record, links to risks and controls | GRC platform / ISMS folder | GRC lead | Current period | YYYY-MM-DD | Documented | Reconcile SoA status with latest control evidence | GRC lead |
| Information security objectives | Can we show measurable objectives, monitoring, and review evidence? | Objectives, metrics, management reporting, review minutes | GRC workspace / reporting dashboard | CISO / security leadership | Audit period | YYYY-MM-DD | Partially operating | Add evidence of latest objective review | CISO |
| Policies and approvals | Can we show current approved policies and that relevant users can access them? | Policy set, approval history, publication records, exception register | Document management system | Policy owner | Current period | YYYY-MM-DD | Operating | None | — |
| Roles, responsibilities, and competence | Can control owners explain their responsibilities and show competence or role evidence where applicable? | Role descriptions, responsibility matrix, training or qualification records, onboarding records | HRIS / GRC workspace | HR / security management | Audit period | YYYY-MM-DD | Partially operating | Confirm backup owners for key controls | Security operations manager |
| Awareness and training | Can we show assigned awareness activities and completion records for the sampled population? | Training assignments, completion reports, reminder records, exceptions | LMS / HRIS | Security awareness owner | Audit period | YYYY-MM-DD | Operating | None | — |
| Asset management | Can we show an inventory of relevant assets and ownership for systems in scope? | Asset inventory, ownership records, classification records, reconciliation reports | CMDB / asset tool | IT operations | Audit period | YYYY-MM-DD | Partially operating | Reconcile cloud assets not mapped to owners | IT operations lead |
| Access management | Can we show access provisioning, changes, removals, and periodic reviews for systems in scope? | Access requests, approval tickets, joiner/mover/leaver records, access review results | IAM / ticketing system | IAM owner | Audit period | YYYY-MM-DD | Needs corrective action | Complete missing evidence for privileged access review | IAM owner |
| Supplier oversight | Can we show how relevant suppliers are assessed, approved, monitored, and reviewed? | Supplier register, due diligence records, contracts/security terms, review records | Vendor management system / contract repository | Procurement / third-party risk owner | Audit period | YYYY-MM-DD | Partially operating | Update review evidence for critical supplier | Third-party risk owner |
| Vulnerability management | Can we show vulnerability identification, prioritisation, remediation, and exception handling? | Scan reports, remediation tickets, exception approvals, closure evidence | Vulnerability scanner / Jira | Security operations | Audit period | YYYY-MM-DD | Partially operating | Link closed tickets to scan findings | Security operations manager |
| Change management | Can we show that relevant changes were reviewed, approved, tested, and closed? | Change tickets, approvals, test results, deployment records, rollback notes where applicable | ITSM / CI/CD tooling | Engineering / IT change owner | Audit period | YYYY-MM-DD | Operating | None | — |
| Incident management | Can we show incident records, response actions, lessons learned, and closure evidence? | Incident tickets, investigation notes, communications, post-incident reviews | Incident management system | Security operations | Audit period | YYYY-MM-DD | Documented | Add evidence for post-incident follow-up actions | Incident response lead |
| Internal audit programme and results | Can we show internal-audit planning, scope, results, findings, and follow-up actions where applicable? | Internal audit plan, audit reports, finding register, follow-up evidence | GRC workspace | Internal audit / GRC | Audit period | YYYY-MM-DD | Partially operating | Confirm closure evidence for prior findings | GRC lead |
| Management review records | Can we show management-review inputs, decisions, actions, and follow-up where applicable to the ISMS? | Meeting agenda, minutes, management reports, action tracker | Board / management review folder | CISO / executive sponsor | Audit period | YYYY-MM-DD | Needs corrective action | Complete action-owner updates from latest review | Executive sponsor |
| Nonconformities and corrective actions | Can we trace findings or nonconformities to root cause, action, owner, due date, completion evidence, and verification? | Finding register, corrective-action plans, completion evidence, verification notes | GRC platform / action tracker | GRC lead | Audit period | YYYY-MM-DD | Partially operating | Add verification evidence for closed action | Corrective-action owner |
Use these rows as prompts. The exact sample, depth, and evidence expectations may vary by audit scope, certification body, selected controls, and the maturity of your ISMS.
Evidence register structure
If your checklist is separate from your evidence index, keep the register simple enough to maintain:
| Field | Purpose |
|---|---|
| Requirement / control reference | Links evidence to the relevant clause, ISMS process, SoA entry, or control area |
| Audit question | States what the auditor or internal reviewer is trying to verify |
| Evidence required | Defines the record, report, ticket, approval, or artefact to collect |
| Evidence location | Shows where the evidence is stored |
| Source system | Identifies the system of record, such as GRC, IAM, HRIS, LMS, ITSM, CMDB, or ticketing |
| Owner | Names the person accountable for the evidence |
| Date range | Shows the period covered by the evidence |
| Last review date | Shows when the evidence or control record was last checked |
| Readiness status | Uses the status model consistently |
| Open action | Captures the gap or next step |
| Corrective-action owner | Names the person accountable for remediation, if different from the evidence owner |
What to check before internal, Stage 1, Stage 2, and surveillance audits
Different audit moments need different evidence emphasis. Certification bodies commonly use a two-stage initial audit: Stage 1 is a readiness review that evaluates documents and key system elements; Stage 2 uses interviews, records, and observation of working practices to assess implementation. (SGS)
| Audit moment | Primary readiness focus | What to check |
|---|---|---|
| Internal audit | Whether the ISMS is ready to be challenged before external audit | Confirm audit scope, audit programme, auditor competence or independence where applicable, sampling approach, findings, and corrective-action tracking |
| Stage 1 | Documentation and system readiness | Confirm ISMS scope, risk assessment method, risk register, risk treatment plan, SoA, policies, required records, and readiness for Stage 2 |
| Stage 2 | Operating evidence | Prepare records across the audit period, control-owner interviews, traceability from risk to control to evidence, and consistency across tickets, approvals, reviews, reports, and system records |
| Surveillance audit | Continued operation and improvement after certification | Maintain current evidence, record changes since certification, track previous findings, and keep internal-audit, management-review, risk, and control evidence up to date |
After certification, regular surveillance visits form part of the certification process and are intended to assess continued operation and improvement. (SGS) Do not assume every surveillance audit will review the same sample or sample type; keep the evidence register current between audits.
How to judge whether audit evidence is good enough
Evidence is solid when it is relevant to the audit question, current for the sampled period, complete enough to explain the activity, traceable to an owner or system, and consistent with interviews and related records.
Use these checks before marking an item “Operating”:
- Relevance: Does the evidence answer the specific audit question?
- Recency: Does it cover the audit period or sampled period?
- Completeness: Does it show the full activity, not just a screenshot or final state?
- Approval or review trail: Can you show who approved, reviewed, or accepted the record?
- Traceability: Can you link the evidence to a risk, policy, SoA entry, ticket, system, or owner?
- Consistency: Do records in different systems tell the same story?
- Interview support: Can the control owner explain how the process works and where evidence is kept?
Examples of weak versus stronger evidence:
| Area | Weak evidence | Stronger evidence may include |
|---|---|---|
| Access reviews | A spreadsheet listing users with no reviewer, date, scope, or actions | Review export, system scope, reviewer approval, exceptions, removal tickets, closure evidence |
| Awareness training | A policy stating training is required | Assigned population, completion report, overdue follow-up, exception handling, review by training owner |
| Incidents | A list of incident titles | Incident tickets, severity, response timeline, actions taken, lessons learned, closure and follow-up evidence |
| Supplier review | A supplier list only | Supplier risk rating, due diligence records, contract/security terms, review date, open issues, owner decisions |
| Vulnerability management | A scan screenshot | Scan results, prioritisation, remediation tickets, exception approvals, retest or closure evidence |
| Change management | A deployment log only | Change request, approval, testing evidence, deployment record, rollback notes where applicable, closure status |
These examples do not guarantee acceptance by an auditor. They are practical prompts for checking whether evidence is likely to support the audit conversation.
How to handle findings, nonconformities, and corrective actions
The checklist should not stop at identifying gaps. It should create a traceable remediation path from finding to follow-up.
Track each finding or nonconformity with:
| Field | What to capture |
|---|---|
| Description | What was found and why it matters |
| Related requirement or control area | Clause, ISMS process, SoA item, or control area |
| Severity or priority | Internal rating, if your process uses one |
| Root cause | The underlying reason the gap occurred |
| Corrective action | The action intended to address the cause, not only the symptom |
| Owner | Person accountable for completion |
| Due date | Target completion date |
| Evidence of completion | Ticket, approval, record, report, updated process, or other completion evidence |
| Verification or follow-up review | Evidence that completion was checked |
| Status | Open, in progress, blocked, complete, verified, or similar internal status |
Include internal-audit results, management-review records, findings, and follow-up actions in the readiness checklist if they apply to your ISMS and audit scope.
Turning the checklist into continuous audit readiness
An ISO 27001 audit checklist is most useful when it becomes an operating workflow, not a document pulled together shortly before an audit. Keep evidence linked to owners, risks, controls, policies, review dates, and open actions throughout the year.
Teams can manage this manually in a spreadsheet or through a GRC workflow. If you use Ciphrix, treat this checklist as a readiness scan: map each item to evidence, owner, status, and action so preparation is basically a review of current operating records rather than a last-minute evidence search.
Start with the representative rows above, remove anything outside your scope, add the controls selected in your SoA, and review every “Documented,” “Partially operating,” and “Needs corrective action” item before your next audit milestone.