ISO 27001 Internal Audit Checklist (2026)

If you're preparing for an ISO 27001 certification audit, the internal audit is your dress rehearsal. It's required by Clause 9.2 of the standard and should be conducted at least annually — ideally 4-6 weeks before the external auditor arrives.

After conducting over 100 internal audits, I've distilled the process into a structured checklist that covers the full audit lifecycle.

Step 1: Scope and Context

Before reviewing any controls, establish what you're auditing.

• Identify the ISMS scope — What systems, processes, locations, and people are covered?
• Gather the Statement of Applicability (SoA) — Which of the 93 Annex A controls apply to your organization?
• Review previous audit findings — Are corrective actions from the last audit closed?
• Check data freshness — If you use a compliance platform like Vanta, verify the data is less than 7 days old

The scope drives everything. If it's wrong, the entire audit is unreliable.

Step 2: ISMS Clause Assessment (Clauses 4-10)

This is where most startups fail. They focus on technical controls and neglect the management system itself.

Walk through each clause:

• Clause 5 (Leadership) — Is there a signed security policy? Who owns the ISMS? Is there evidence of management review?
• Clause 6 (Planning) — Is the risk assessment current (less than 12 months old)? Does it reference the SoA?
• Clause 7 (Support) — Is there a competence matrix? Are training records current?
• Clause 8 (Operation) — Is the risk treatment plan being executed?
• Clause 9 (Performance) — Are there security metrics? Has an internal audit been conducted? Is there a management review record?
• Clause 10 (Improvement) — Are nonconformities tracked? Are corrective actions implemented?

The auditor looks for a connected chain: risk assessment to SoA to risk treatment plan to evidence of implementation to monitoring to management review to improvement. Any break in that chain is a nonconformity.

Step 3: Annex A Control Assessment

Work through controls by domain, starting with the highest-risk items.

Prioritize by tier

Not all 93 controls carry equal weight. I classify them into three tiers:

Tier	Approach
Critical (~30 controls)	Full assessment: documented policy, evidence of implementation, evidence of monitoring
Relevant (~30 controls)	Standard check: evidence of implementation plus spot-checks
Checkbox (~33 controls)	Verify a policy exists or cloud provider SOC 2 covers it

Top 10 controls that fail most often

#	Control	Common Failure
1	A.5.15 Access Control	No periodic access reviews
2	A.8.8 Vulnerability Management	No vulnerability scanning program
3	A.5.24 Incident Response	Plan exists but was never tested
4	A.8.5 Authentication	MFA not enforced everywhere
5	A.5.30 Business Continuity	No DR failover test conducted
6	A.8.15 Logging	Audit logs not centralized
7	A.8.9 Configuration Management	No baseline configuration documented
8	A.6.1 Screening	Background checks incomplete
9	A.8.32 Change Management	No formal change approval process
10	A.5.9 Asset Inventory	Incomplete or outdated asset register

If you only have time to check ten things, check these.

Step 4: Evidence Collection

For each finding, collect supporting evidence. The hierarchy from best to worst:

1. API exports (JSON/CSV with timestamps) — preferred because they're reproducible and tamper-evident
2. System-generated reports — SOC 2 reports from vendors, SIEM exports
3. Configuration exports — Terraform state, policy JSON
4. Screenshots with system clock — visual proof, but harder to validate
5. Manual attestation — signed statements, last resort only

Name evidence files consistently: {control_id}_{evidence_type}_{date}.{ext} — for example, A.5.15_user-access-list_2026-02-28.json.

Step 5: Generate Findings

For each nonconformity, document:

• Control — Which control failed (e.g., A.5.15)
• Severity — Major nonconformity, minor nonconformity, or observation
• Description — What was found
• Evidence — What evidence supports the finding
• Root cause — Why the control failed
• Corrective action — Specific steps to fix it
• Due date and owner — Who will fix it and by when

Severity definitions

• Major nonconformity — Control is missing or completely ineffective. This is a certification failure risk.
• Minor nonconformity — Control exists but has gaps in implementation or evidence. Must be addressed before the next surveillance audit.
• Observation — An improvement opportunity. Not required, but recommended.

Step 6: Audit Report

The final deliverable is a structured report containing:

1. Executive summary — Overall ISMS maturity assessment and key findings
2. Scope — What was audited, what was excluded, and why
3. Methodology — Controls assessed, evidence reviewed, people interviewed
4. Findings — Grouped by domain with severity ratings and corrective actions
5. Positive observations — What's working well (balanced audits note these)
6. Conclusion — Readiness assessment for the external audit

Common Mistakes to Avoid

• Don't audit your own work — Clause 9.2 requires auditor independence
• Don't accept policies at face value — "Show me" beats "tell me" every time
• Don't skip ISMS clauses for Annex A — Most first-time failures are in Clauses 4-10
• Don't screenshot without a system clock — Auditors reject undated evidence
• Don't treat checkbox controls as zero-effort — Even N/A controls need SoA justification

Next Steps

If this is your first internal audit, treat it as a learning exercise. Document everything, even if the findings are uncomfortable. A thorough internal audit with honest findings is far more valuable than a clean report that falls apart during certification.

Need help? We offer ISO 27001 internal audits for $300 flat rate — including a written findings report with corrective action recommendations.