ISO 27001 Audit Checklist: Controls, Evidence, and Common Readiness Gaps

Overview

This article gives you a practical ISO 27001 readiness checklist focused on three things: controls, evidence, and likely weaknesses. It is not a substitute for a formal audit plan or legal advice, but it can help you become audit ready compliance-wise by showing where auditors usually look first and where internal teams often discover avoidable gaps.

At a high level, ISO 27001 readiness depends on more than having security policies in a shared folder. Auditors generally want to see that your information security management system is defined, approved, communicated, operated, reviewed, and improved over time. That means your evidence should tell a consistent story:

• You defined scope clearly.
• You identified risks and selected controls deliberately.
• You assigned ownership.
• You operate the controls in practice.
• You review exceptions, incidents, and changes.
• You can show records, not just intentions.

For many teams, the most useful framing is this: every major control area needs both design evidence and operating evidence. Design evidence shows the control exists on paper. Operating evidence shows people actually use it.

Use the checklist below as a working information security audit checklist. Mark each line item as one of the following:

• Ready: control exists and evidence is current.
• Partial: control exists but evidence is weak, stale, or inconsistent.
• Missing: control is not defined, not implemented, or not in scope.

If you are comparing frameworks, our SOC 2 vs ISO 27001 guide for SaaS teams can help clarify how readiness work overlaps and where it differs.

Checklist by scenario

This section breaks the ISO 27001 audit checklist into practical scenarios so you can review the areas most likely to matter in your environment.

1. ISMS foundation and governance

Start here. If your management system is weak, strong technical controls will not fully compensate during a readiness review.

• Scope defined: Your ISMS scope identifies covered systems, teams, locations, services, and exclusions. Make sure exclusions are explicit and defensible.
• Information security policy approved: There is a current top-level policy, approved by management, with version control.
• Objectives and responsibilities documented: Security goals, owners, and review cadence are clear.
• Risk assessment methodology defined: You can explain how risks are identified, rated, accepted, and treated.
• Statement of Applicability maintained: Included controls are justified, excluded controls are explained, and the document matches actual practice.
• Internal audit and management review planned: These are common evidence points and often underprepared.

Evidence to collect: ISMS scope statement, policy documents, org chart, role assignments, risk methodology, risk register template, Statement of Applicability, management review records, internal audit plan, corrective action log.

Typical gap: The scope says one thing, but your tooling, cloud accounts, or business units suggest a wider reality.

2. Asset inventory and data handling

Auditors often test whether you know what you are protecting. An incomplete inventory creates downstream problems across access control, vulnerability management, and incident response.

• Asset inventory exists: Hardware, endpoints, servers, repositories, cloud services, production systems, and critical SaaS tools are tracked.
• Information classification defined: Data categories and handling expectations are documented.
• Ownership assigned: Key assets and systems have owners responsible for review and risk decisions.
• Retention and disposal practices described: Teams know how data is retained and securely removed when no longer needed.

Evidence to collect: Asset register, CMDB extracts if available, data classification policy, system ownership records, retention schedule, disposal procedures, screenshots from endpoint or cloud inventory tools.

Typical gap: Teams track infrastructure assets but ignore business-critical SaaS platforms where sensitive data is stored and processed.

3. Access control and identity management

This is one of the highest-yield sections in any ISO 27001 readiness checklist because it is visible, testable, and closely tied to real risk.

• User access provisioning is documented: Joiner, mover, and leaver workflows are defined.
• Least privilege is applied: Access is role-based or otherwise constrained by business need.
• Privileged access is controlled: Admin rights are limited, logged, and reviewed.
• Multi-factor authentication is enforced where appropriate: Especially for remote access, admin access, and cloud control planes.
• Periodic access reviews occur: Reviews are scheduled and completed, not merely planned.
• Shared accounts are minimized and governed: If they exist, ownership and usage controls are documented.

Evidence to collect: Access control policy, IAM screenshots, sample access requests and approvals, MFA settings, privileged role list, access review records, termination checklist evidence, SSO configuration summary.

Typical gap: A good policy exists, but no one retained evidence of completed access reviews or timely deprovisioning.

4. Secure configuration, change management, and vulnerability handling

Auditors usually want to see that production changes are controlled and that known weaknesses are identified and addressed in a repeatable way.

• Baseline configurations are defined: For endpoints, servers, cloud workloads, and critical applications where relevant.
• Change management process exists: Changes are reviewed, tested, approved, and traceable.
• Vulnerability scanning or equivalent review is in place: Coverage, frequency, and ownership are clear.
• Patching expectations are defined: Severity-based timelines or risk-based treatment is documented.
• Exceptions are tracked: Deferred remediation has owner approval and review dates.

Evidence to collect: Change tickets, release approvals, pull request reviews, infrastructure-as-code controls, scan reports, remediation tickets, patch compliance reports, exception register, hardening standards.

Typical gap: Vulnerability scans are run, but no one can show remediation workflow or accepted risk decisions for unresolved findings.

5. Logging, monitoring, and incident response

Readiness here is not about claiming perfect detection. It is about showing that important events are captured, reviewed, and escalated using a documented process.

• Logging requirements are defined: Critical systems, authentication events, admin actions, and security-relevant changes are included.
• Monitoring responsibilities are assigned: Teams know who reviews alerts and when.
• Incident response plan exists: Severity, escalation, communications, containment, recovery, and lessons learned are addressed.
• Tabletop exercises or tests are performed: Even simple walkthroughs are useful if they are documented.
• Incident records are retained: Evidence of triage, response, and follow-up exists.

Evidence to collect: Logging standards, SIEM or alerting screenshots, on-call procedures, incident response policy, sample incident tickets, post-incident reviews, tabletop notes, escalation matrix.

Typical gap: Teams rely on ad hoc Slack coordination during incidents and have no durable record of decisions or corrective actions.

6. Supplier and third-party risk management

ISO 27001 controls often expose weaknesses in how vendors are assessed, approved, and monitored. This is especially important for SaaS-heavy environments.

• Vendor inventory is maintained: Critical processors, subprocessors, infrastructure providers, and security-relevant vendors are known.
• Risk-based reviews are performed: Not every vendor needs the same depth, but critical vendors should have structured review.
• Contracts address security and data handling: Terms align with the service provided and the risk involved.
• Ongoing review is defined: Renewals, changes in service scope, or security incidents trigger reassessment.

Evidence to collect: Vendor register, vendor risk assessment template, security questionnaires, contract review notes, DPAs where relevant, due diligence records, renewal workflow.

Typical gap: Procurement has the contracts, security has the concerns, privacy has the DPAs, and no unified vendor record exists.

For adjacent privacy work, see our cross-border data transfer checklist and website privacy policy checklist.

7. Business continuity, backup, and recovery

Auditors often ask whether critical operations can continue or recover within expected timeframes. Documentation without testing is a common weakness.

• Backup strategy is documented: Scope, frequency, retention, encryption, and restoration responsibility are defined.
• Recovery expectations are understood: Critical services have documented recovery priorities.
• Restores are tested: At least enough to show backups are usable.
• Continuity arrangements are practical: Key personnel, dependencies, and fallback processes are identified.

Evidence to collect: Backup policy, backup job reports, restore test records, business continuity plan, disaster recovery notes, dependency lists.

Typical gap: Backups exist, but no recent restore test can prove they support recovery objectives.

8. Security awareness, HR controls, and acceptable use

People controls matter because auditors look for consistency between policy, onboarding, and day-to-day behavior.

• Background or pre-employment checks are handled as appropriate: Based on role and legal context.
• Confidentiality and acceptable use terms exist: Staff obligations are documented.
• Security awareness training is delivered: It should be periodic and relevant to role.
• Disciplinary and reporting paths are defined: Employees know how to report concerns.

Evidence to collect: Employee handbook sections, onboarding checklist, policy acknowledgments, training completion records, awareness materials, reporting channel documentation.

Typical gap: Training was assigned once, but completion records are incomplete and new hires are not consistently captured.

What to double-check

Before any audit window opens, review the following points carefully. These issues often turn a mostly ready environment into a scramble.

• Document versions match reality: Retired workflows, legacy tools, and renamed teams create credibility problems quickly.
• Evidence is recent: A policy from last year may be acceptable; an access review from last year usually is not.
• Approvals are visible: If a process requires approval, keep proof of who approved what and when.
• Exceptions are explicit: Auditors are usually more comfortable with documented exceptions than hidden inconsistency.
• Sampling works in both directions: Be prepared to move from policy to ticket evidence and from a ticket back to the policy that governs it.
• Control ownership is not ambiguous: Each control area should have a person or function accountable for producing evidence.
• Cloud and SaaS systems are included: Many ISO 27001 evidence requirements break down when teams focus only on laptops and servers.
• Internal audit and management review are not postponed: These are often left late and become obvious gaps.

If you already collect evidence for multiple frameworks, our SOC 2 evidence collection guide can help you standardize how you store and review supporting records.

Common mistakes

The most common ISO 27001 readiness mistakes are not exotic security failures. They are basic control management problems that make a functioning team look less mature than it really is.

• Treating the audit as a one-time project: ISO 27001 works better when evidence is collected as part of normal operations.
• Confusing policy coverage with control effectiveness: A detailed security policy template is useful, but auditors still need operating evidence.
• Using generic templates without tailoring: If your documents mention tools, teams, or review cycles that do not exist, they create more risk than value.
• Ignoring boundary systems: Staging environments, developer tools, browser extensions, and support platforms may sit outside formal inventories but still create risk.
• Under-documenting risk acceptance: Not every issue must be fixed immediately, but risk treatment decisions should be recorded and owned.
• Splitting evidence across too many systems: If HR, IT, engineering, and legal all store records differently, retrieval becomes slow and inconsistent.
• Forgetting privacy-adjacent systems: Tracking tools, analytics platforms, and marketing vendors can affect scope, supplier review, and data handling expectations.

For teams dealing with tracking technology, related reading includes our Google Analytics GDPR compliance guide and cookie banner requirements by region. These are not ISO 27001 checklists, but they often expose governance and vendor-management patterns that matter for readiness work.

When to revisit

The best ISO 27001 audit checklist is one you revisit before change forces you to. Make this review part of your operating rhythm, not just a pre-audit ritual.

Revisit this checklist when any of the following happens:

• You enter annual planning or budgeting cycles.
• You adopt new infrastructure, identity, endpoint, or ticketing tools.
• You launch a new product, environment, or customer-facing service.
• You onboard a critical vendor or move data to a new processor.
• You restructure teams or change control owners.
• You experience a security incident or major near miss.
• You prepare for certification, surveillance, recertification, or a customer security review.

For a practical next step, turn this article into a working readiness board:

1. Create one row per control area.
2. Assign an owner for each row.
3. Add columns for policy, procedure, operating evidence, last review date, known gaps, and next action.
4. Mark any item without recent evidence as partial, even if the control exists.
5. Schedule a recurring quarterly review so evidence does not go stale.

If your team is still deciding whether ISO 27001 is the right path relative to customer-driven frameworks, revisit SOC 2 vs ISO 27001 before you overbuild documentation in the wrong direction.

A strong ISO 27001 readiness checklist is not just a compliance artifact. It becomes a durable map of how your organization manages security in practice. That is why it is worth revisiting whenever your workflows, tools, or risk profile change.