ISO 27001 internal audit checklist template (Clauses 4–10 + SoA + IRL tracker)

ISO 27001 internal audit checklist template (Clauses 4–10 + SoA + IRL tracker)

If you’re searching for an ISO 27001 internal audit checklist that’s actually usable during real fieldwork, this template gives you a structured way to plan the audit, assign owners, track requests, and keep evidence auditor-friendly.

This guide covers:

• A practical “before you start” internal audit preparation checklist
• A Statement of Applicability (SoA) checklist to keep Annex A in scope (and defensible)
• An ISO 27001 internal audit checklist by clause (4–10) with evidence examples
• An Information Request List (IRL) tracker you can copy/paste for audit week

GIF via GIPHY

Related guides:

• How to conduct an ISO 27001 internal audit (practical guide)
• How to write an ISO 27001 Statement of Applicability (SoA)
• ISO 27001 audit: how controls are tested (what auditors expect)
• How much does ISO 27001 certification cost in 2026?

---

Key takeaways

• Internal audits fail in the handoffs, not the standards. The biggest issues are unclear scope, missing owners, and scattered evidence—not “not knowing ISO.”
• Your SoA is the auditor’s map. If your SoA isn’t current (and aligned with your risk treatment plan), the audit becomes slower and more contentious.
• Clause-by-clause works best when it’s tied to evidence. Every checklist item should map to a system, owner, cadence, and exportable artifact.
• Use an IRL tracker during audit week. It prevents repeated requests, lost screenshots, and “who owns this?” churn.

---

How to use this ISO 27001 internal audit checklist template

Use this template in two passes:

• Pass 1 (readiness): confirm scope, owners, and what evidence exists today.
• Pass 2 (fieldwork simulation): run a dry-run IRL against real systems and exports, as if an auditor asked for it.

If you want a simple operational workflow:

• Copy the checklists into your internal tracker (or SecureSlate)
• Replace all bracketed placeholders (like [Name/Role])
• Attach links to evidence sources next to each checklist item
• Export a PDF for internal distribution (optional)

---

Before you start (internal audit preparation)

As you begin the internal audit process, this administrative prep helps ensure a smooth audit cycle.

Internal audit preparation checklist

• Identify the audit leader and confirm scope: locations, systems, teams, and exclusions
• Confirm audit type and timing: Stage 1 / Stage 2 / surveillance / recertification + target dates
• Request and confirm the Information Request List (IRL) (aka RFI) from your auditor (or draft an internal IRL for a dry run)
• Ensure your Statement of Applicability (SoA) exists and is current (see next section)
• Hold an audit kickoff with stakeholders (purpose, schedule, expectations)
• Put calendar holds in place for audit week + schedule prep sessions with owners
• Define roles and responsibilities (clause owners, SoA owner, control owners)
• Prepare a document map (where policies, procedures, logs, and evidence live)
• Decide your sampling approach (time period, systems, teams)

Owners and links (fill these in)

• Audit leader: [Name / Role]
• Target audit week: [Date range]
• Links:
  • [Audit plan]
  • [IRL / RFI]
  • [Audit schedule]

How SecureSlate can help

SecureSlate helps you keep internal audit prep from turning into “spreadsheet archaeology” by centralizing:

• Controls and clause ownership
• Evidence attachments with timestamps and audit trails
• Remediation tasks (with due dates and reminders)
• Exportable audit-ready views for auditors and internal reviewers

---

Statement of Applicability (SoA) checklist (Annex A reference)

The SoA lists Annex A controls (commonly A.5–A.8), indicates whether each control is applicable, and documents justification and implementation status. Auditors use the SoA to understand what’s in scope and why.

SoA checklist

• Maintain a current SoA covering all Annex A controls
• For each control, document:
  • applicability (yes/no)
  • justification
  • implementation status
  • owner (recommended)
• Ensure the SoA aligns with your risk assessment and treatment plan
• Make the SoA easy for the auditor to access (and keep the current version obvious)

Owners and links (fill these in)

• SoA owner: [Name / Role]
• Due by: [Date]
• Links:
  • [SoA doc]
  • [Risk register]
  • [Risk treatment plan]

How SecureSlate can help

Use SecureSlate to keep your SoA defensible by linking SoA entries to:

• Controls and owners
• Evidence artifacts (policies, exports, logs)
• Remediation tasks that explain “what changed” over time

---

ISO 27001 internal audit checklist by clause (4–10)

For each clause, you’re validating that the ISMS is established, implemented, maintained, and continually improved—and that evidence demonstrates effectiveness, not just the existence of a document.

Quick evidence map (useful for audit week)

Clause	What auditors typically test	Evidence examples	Typical owner
4: Context	Scope is defined and used consistently	Scope statement; interested parties register	ISMS owner
5: Leadership	Leadership commitment + responsibilities	InfoSec policy approval; RACI/charters	CISO / ISMS owner
6: Planning	Risk method, register, treatment, objectives	Risk register; treatment plan; KPIs	Risk owner
7: Support	Competence, awareness, documentation control	Training records; doc control SOP	HR / IT / Security
8: Operation	Operational controls run as designed	Meeting records; workflows; tickets	Ops / IT / Security
9: Performance	Monitoring, internal audit, management review	Audit plan; audit reports; review minutes	ISMS auditor / owner
10: Improvement	NCs/CAPAs tracked and validated	NC/CAPA tracker; RCA docs	ISMS auditor / owner

Clause 4: Context of the organization

This clause requires understanding internal/external issues, stakeholder expectations, and an explicitly defined ISMS scope.

Checklist:

• Document organizational context (business model, technology, regulatory drivers)
• Identify interested parties and relevant requirements
• Define and approve ISMS scope: locations, systems, processes, exclusions
• Maintain a scope statement used consistently across policies and artifacts

Evidence examples:

• ISMS scope statement
• Context and interested parties register
• Contracts and regulatory mappings

Owner: [ISMS Owner: Name/Role]
Due: [Date]
Links: [Scope doc]

Clause 5: Leadership

This clause requires leadership commitment, clear roles, and an Information Security Policy and measurable objectives.

Checklist:

• Information Security Policy and objectives approved and communicated
• Evidence of leadership commitment (resources, objectives, policy endorsement)
• Roles and responsibilities defined (RACI or charters)
• ISMS roles assigned (ISMS owner, risk owner, control owners)

Evidence examples:

• Signed policy
• Org chart and/or RACI
• Leadership communications
• Resource/budget approvals

Owner: [CISO/ISMS Owner: Name/Role]
Due: [Date]
Links: [IS Policy], [RACI]

Clause 6: Planning (risks, changes, and objectives)

This clause requires a repeatable risk process, a treatment plan aligned to controls, and measurable security objectives.

Checklist:

• Documented risk assessment method and criteria (likelihood/impact + scoring)
• Risk assessment performed on in-scope assets/processes (current cycle)
• Risk treatment plan with selected controls and owners (aligned to SoA)
• Security objectives with metrics/KPIs and monitoring cadence
• Planning for change and risks/opportunities is documented and communicated

Evidence examples:

• Risk methodology
• Risk register
• Treatment plan
• KRIs/KPIs and objective dashboards

Owner: [Risk Manager: Name/Role]
Due: [Date]
Links: [Risk register], [Treatment plan], [Objectives]

Clause 7: Support

This clause covers resources, competence, awareness, communications, and documented information controls.

Checklist:

• Resource planning for ISMS (people/tools/budget) documented
• Competence defined for key roles; training completed and recorded
• Security awareness program exists (and is repeatable)
• Communication plan covers internal + external security communications
• Documented information is controlled (review/approval/versioning/retention)

Evidence examples:

• Training records/LMS exports
• Awareness program artifacts
• Communication plan
• Document control SOP and version history

Owner: [HR/IT/ISMS: Name/Role]
Due: [Date]
Links: [Training plan], [Doc control SOP]

Clause 8: Operation

This clause expects operational planning and evidence that risk treatment actions are implemented and governed.

Checklist:

• Operational planning and control for ISMS processes is defined and followed
• Risk treatment actions are implemented; residual risk accepted by owners
• ISMS program meetings occur (scope/R&R/metrics/performance)
• Records are maintained for operating and governing the ISMS program

Evidence examples:

• ISMS meeting notes and action items
• Risk treatment execution records
• Operational workflow tickets (access, change, incident, vendor)

Owner: [Ops/IT/Security: Name/Role]
Due: [Date]
Links: [Vendor register], [IR playbooks], [BCP/DR]

Clause 9: Performance evaluation

This clause requires monitoring, internal audit, and management reviews to prove ongoing effectiveness.

Checklist:

• Monitoring and measurement plan defined for ISMS objectives/controls
• Internal audit program and schedule established (scope/criteria/methods)
• Internal audits conducted by competent, impartial personnel; reports issued
• Management review held with defined inputs (audit results, KPIs, incidents, risks)

Evidence examples:

• KPI dashboards
• Internal audit plan and report
• Management review minutes (agenda and attendees)

Owner: [ISMS Auditor/ISMS Owner: Name/Role]
Due: [Date]
Links: [Audit plan], [Audit report], [Mgmt review]

Clause 10: Improvement

This clause is about closing the loop: documenting nonconformities, corrective actions, and continual improvement.

Checklist:

• Nonconformities documented with root cause analysis
• CAPAs defined, owners assigned, and deadlines set
• Effectiveness checks performed and documented
• Opportunities for improvement captured and prioritized
• Continual improvement tracking exists (and is used)

Evidence examples:

• NC/CAPA tracker
• RCA artifacts
• Verification/validation notes
• Improvement backlog

Owner: [ISMS Auditor: Name/Role]
Due: [Date]
Links: [NC/CAPA log]

---

During the audit: what to expect (and how to keep evidence moving)

Here’s what to expect during the audit period:

• Opening meeting: confirm scope, criteria, schedule, and SMEs
• Requests and sampling: auditor may expand samples (users, tickets, vendors)
• Interviews and demos: SMEs explain processes and show systems/logs
• Real-time evidence delivery: provide documents/exports per IRL; keep a delivery log
• Daily touchpoints: align on open items and next-day interviews
• Closing meeting: walk through NCs/observations/opportunities and next steps

Tips:

• Answer what’s asked; show how the process actually works
• If unsure, follow up with evidence rather than speculate
• Keep a running list of follow-ups and owners

---

Post-audit remediation checklist (NCs + CAPAs)

Checklist:

• Log all NCs/observations with severity and clause mapping
• Perform RCA for each NC
• Define CAPAs with owners and due dates (update risks/SoA if needed)
• Verify effectiveness and close items (preserve evidence)
• Turn lessons learned into ISMS improvements and training updates

Owner: [ISMS: Name/Role]
Due: [Date]
Links: [NC/CAPA tracker]

---

Appendix A: Information Request List (IRL) tracker (copy/paste)

Copy/paste this into a table in your doc system.

• Request ID: [IRL-###]
• Clause / SoA ref: [e.g., 9.2 / A.5.15]
• Request description: [What auditor asked for]
• Owner: [Name/Role]
• Evidence source: [System/Doc link]
• Status: Not started / In progress / Delivered / Verified
• Notes: [Follow-ups]

---

Appendix B: Artifacts and links index (copy/paste)

This makes audit week faster because people stop asking “where is that doc again?”

• Policies & SOPs: [link]
• Risk register & methodology: [link]
• SoA: [link]
• Training & attestation exports: [link]
• Vendor register & assessments: [link]
• Incident logs & postmortems: [link]
• Audit plan, reports, and management review minutes: [link]

---

Run your internal audit workflow in SecureSlate

Internal audits get painful when evidence lives in ten tools and ownership lives in people’s heads.

SecureSlate helps you run a cleaner internal audit cycle by:

• Centralizing controls, owners, and evidence (so requests don’t bounce between teams)
• Keeping recurring activities on schedule (access reviews, policy reviews, training, vendor checks)
• Tracking NCs and CAPAs with due dates, status, and proof of remediation
• Making audit exports easier by keeping evidence tied to the right control and time period

Get started for free

---

Frequently asked questions

How often should you run an ISO 27001 internal audit?

It depends on your program maturity and audit cycle, but most teams run internal audits on a regular cadence and before certification, surveillance, or recertification audits. Align your schedule to risk and change frequency.

What’s the fastest way to prepare for internal audit fieldwork?

Lock scope, assign clause/control owners, and run a dry-run IRL against real evidence exports. If you can’t produce evidence quickly and consistently, audit week will be slower and more disruptive.

What evidence do auditors typically ask for first?

Typically: scope statement, SoA, risk register + treatment plan, policy approvals, training/awareness records, and proof of recurring activities (access reviews, incident management, vendor oversight).

---

Disclaimer (legal note)

This template is provided for informational purposes only and does not constitute legal, compliance, or audit advice. Customize it to your organization’s actual practices and consult qualified counsel and/or auditors as needed.