Internal Audit Checklist for ISO 27001:2022
Understanding What You're Actually Auditing
Before diving into the checklist itself, let's address a fundamental misunderstanding I encounter constantly: internal audits aren't compliance checks against every single control. Clause 9.2 requires you to audit against "the organization's own requirements for its information security management system" and "the requirements of this document." This means your audit scope must cover:
- All clauses 4 through 10 of ISO 27001:2022
- The specific Annex A controls you selected in your Statement of Applicability
- Any additional requirements you've defined in policies, procedures, or contractual obligations
What you're not doing is auditing every conceivable security control that might exist. If you excluded Control 5.15 (Access control for networks) because you don't have network segmentation requirements, you don't audit against it. Sounds obvious, but I've watched internal auditors waste days checking controls that their own SoA marks as not applicable.
The other critical point: internal audits must verify both conformity and effectiveness. Finding that a procedure exists isn't enough. You need evidence it's being followed and achieving its intended outcome. This distinction separates genuinely useful audits from the checkbox exercises that certification auditors see through immediately.
Context and Scope Verification (Clauses 4.1-4.4)
Start your audit by verifying the foundation. Without solid context and scope, everything built on top is questionable. I've seen organizations spend months perfecting their risk assessments while their fundamental scope boundaries were fiction.
For Clause 4.1 (Understanding the organization and its context):
- Review the documented internal and external issues—when was this last updated?
- Has the organization undergone significant changes (new products, markets, acquisitions) not reflected in context documentation?
- Interview management: can they articulate key issues affecting information security without consulting documents?
- Check if identified issues actually influenced risk assessments and control decisions
For Clause 4.2 (Interested parties):
- Is the list of interested parties current and complete?
- Are requirements specific and actionable, not generic statements like "customers expect security"?
- Sample 2-3 interested parties: verify their requirements are actually addressed in the ISMS
- Check contractual obligations—are client security requirements captured and flowing into controls?
For Clause 4.3 (Scope):
- Is the scope boundary crystal clear? Could a stranger determine what's in and out?
- Are exclusions justified and not simply avoiding difficult areas?
- Walk the physical and logical boundaries—are they realistic and maintained?
- Review any scope changes since last audit and verify proper change management
I audited an organization last year that claimed their scope excluded "legacy systems." Digging deeper revealed those legacy systems processed customer data and connected to in-scope systems. The internal audit had never questioned this exclusion. The certification audit did.
Leadership and Planning Effectiveness (Clauses 5-6)
Leadership commitment is notoriously difficult to audit but absolutely essential. Most internal auditors shy away from challenging senior management. Don't. The standard requires demonstrable commitment, not just policy signatures.
For Clause 5.1 (Leadership and commitment):
- Interview top management: can they describe the information security policy and objectives without prompting?
- Review meeting minutes—does information security appear on leadership agendas?
- Check resource allocation decisions—has security been funded appropriately or constantly deprioritized?
- Look for evidence of leadership communicating security importance beyond formal announcements
For Clause 6.1 (Risk assessment and treatment):
- Test the risk methodology: apply it to a new scenario and see if results make sense
- Sample 5-10 identified risks: verify they're actually organizational risks, not generic IT concerns
- Check if risk appetite is defined beyond vague statements
- Verify risk treatment decisions are traceable to actual business impact analysis
The risk assessment is where I see the most elaborate documentation covering the least actual analysis. Organizations create 200-page risk registers that haven't influenced a single control decision. Test this by asking: "If this risk materialized tomorrow, what specific business impact would occur and how exactly does Control X.Y mitigate that?"
What the Auditor Looks For
Based on ISO/IEC TS 27008:2019 guidelines, your internal audit evidence should demonstrate:
- Clear traceability from identified risks to selected controls
- Documented rationale for risk treatment decisions, including accepted risks
- Evidence that risk assessments consider technical vulnerabilities, not just business risks
- Regular review and update of risk assessments reflecting organizational changes
Critical Annex A Control Areas
The 2022 revision restructured Annex A into four themes. Focus your audit effort on these high-impact areas that consistently trip up organizations:
Organizational Controls (Theme 1)
Control 5.1 (Information security policies): Don't just check if policies exist. Verify they're communicated, understood, and current. I've found policies last updated in 2019 that still reference the "new GDPR requirements."
Control 5.7 (Threat intelligence): This is new territory for many organizations. Check if they have any systematic approach to understanding relevant threats beyond reading occasional security news.
Control 5.23 (Information security in project management): Sample recent projects—were security requirements identified early and addressed throughout the lifecycle?
People Controls (Theme 2)
Control 6.4 (Disciplinary process): Verify there's an actual process, not just HR boilerplate. Has it ever been used for security violations?
Control 6.8 (Information security in remote working): With post-pandemic work patterns, this deserves deep attention. Don't accept generic remote work policies—verify security-specific requirements exist and are enforced.
Physical and Environmental Controls (Theme 3)
Control 7.4 (Physical security monitoring): If you claim to have monitoring, verify it's actually monitored. I've seen organizations with cameras that haven't been checked in months.
Technology Controls (Theme 4)
Control 8.9 (Configuration management): This is where technical assessment becomes crucial. Don't just verify procedures exist—sample systems and check if configurations match documented baselines.
Control 8.16 (Monitoring activities): Verify log monitoring isn't just log collection. Can the organization detect and respond to suspicious activities?
Pro tip: For cloud environments, cross-reference with ISO/IEC 27017:2015 guidance. Many organizations select cloud-related controls without understanding the shared responsibility model implications.
Performance Evaluation Deep Dive (Clauses 9.1-9.3)
This is where internal audits often become circular—auditing the audit process. Focus on substance:
For Clause 9.1 (Monitoring and measurement):
- Are security metrics actually meaningful or just easy to collect?
- Do measurement results trigger management action or just create reports?
- Sample 3-5 security incidents: were they properly classified, investigated, and learned from?
For Clause 9.3 (Management review):
- Review last three management review meetings—do minutes show actual decisions or just acknowledgments?
- Were improvement actions assigned owners and deadlines?
- Check if resource adequacy is genuinely assessed, not assumed
Common Implementation Pitfalls
After hundreds of internal audits, these patterns emerge repeatedly:
The "Policy Paradise" Problem: Organizations create beautiful policies that nobody follows. Your audit should verify implementation, not just documentation quality. Ask operational staff about procedures—do their descriptions match the documented processes?
The "Checkbox Control" Trap: Controls implemented to satisfy auditors rather than reduce risk. Control 8.21 (Data loss prevention) is often deployed without understanding what data needs protecting or how the technology actually prevents loss.
The "Scope Creep Avoidance": I mentioned the legacy system example earlier. Organizations often define narrow scopes to avoid difficult areas, then wonder why their ISMS doesn't improve overall security posture.
What the Auditor Looks For
When certification auditors review your internal audit program, they expect to see:
- Competent auditors: Evidence that internal auditors understand both the standard and your business context. Generic training certificates aren't enough.
- Risk-based audit programs: Higher-risk areas audited more frequently, not just annual rotation through all clauses.
- Substantive testing: Evidence of actual testing, not just interviews and document reviews.
- Management action: Audit findings result in corrective actions that are tracked to completion.
- Objective evidence: Specific, dated, attributed evidence supporting all findings.
Certification auditor perspective: I can spot ineffective internal audit programs immediately. If your internal audits only find minor documentation issues while certification audits uncover implementation gaps, your program needs fundamental revision.
Practical Implementation Tips
Based on ISO/IEC TS 27008:2019 assessment guidance and real-world experience:
Use sampling intelligently: Don't check 10% of everything. Use stratified sampling—check 100% of high-risk areas, sample medium-risk areas based on previous findings, and use automated tools where possible for low-risk bulk checks.
Combine audit techniques: Document review identifies what should happen, interviews reveal what people think happens, and observation/testing shows what actually happens. All three are necessary.
Focus on effectiveness: For Control 5.15 (Access control for networks), don't just verify that network access controls exist. Test whether unauthorized access is actually prevented.
Cross-reference related standards: If you handle personal data, ensure your audit considers ISO/IEC 27018:2019 requirements. For supplier relationships, factor in ISO/IEC 27036 guidance.
Remember: internal audits should be your early warning system, not your public relations exercise. Better to find problems internally than during certification or—worse—during an actual security incident.
Ready to strengthen your internal audit program? Join the discussion in our ISO 27001 Info Hub for peer insights and expert guidance, or schedule a consultation to review your current audit approach against certification auditor expectations.
Need personalized guidance? Reach our team at ix@isegrim-x.com.
