Internal audit preparation should not be a scramble to make the ISMS look better than it is. A useful internal audit tests whether the management system is operating, whether the evidence supports the story, and whether the organization is ready for certification or surveillance.
The checklist below is the prep list I would use before an ISO 27001 internal audit. It is practical on purpose. These are the items that prevent wasted audit time, avoid avoidable findings, and help your team answer questions with evidence instead of memory.
1. Update your Statement of Applicability
Your Statement of Applicability should reflect your actual control environment, not last year's intent. Review each Annex A control for applicability, implementation status, justification, and linkage to your risk treatment decisions.
Before the audit, check for:
- Controls marked applicable but still "not started"
- Controls marked not applicable without a clear justification
- Controls whose status no longer matches actual implementation
- Risk treatment decisions that are not reflected in the SoA, or vice versa
The SoA is one of the first places an auditor will look because it is the bridge between your risk assessment, your treatment plan, and your Annex A control implementation.
2. Close previous corrective actions on time
If prior internal audits, external audits, risk reviews, or management reviews produced corrective actions, review every open item before the audit. Close what is complete and update anything that is delayed.
Do not show up with expired deadlines and no explanation. A missed target date is not automatically a major problem, but an unmanaged missed target date tells the auditor that corrective action tracking may not be operating.
For each corrective action, be ready to show:
- The original finding or issue
- Root cause analysis
- Planned action, owner, and target date
- Evidence that the action was implemented
- Verification that the action was effective
3. Collect control evidence before fieldwork
Do not wait for the opening meeting to start gathering evidence. Pull the proof that shows controls are implemented and operating over the audit period.
Common evidence includes:
- Access review records and access logs
- Incident reports and incident postmortems
- Risk assessments and risk treatment updates
- Security awareness and role-specific training records
- Vendor reviews and supplier risk assessments
- Vulnerability management reports and remediation tickets
- Backup, business continuity, and disaster recovery test results
If you use Vanta, Drata, Sprinto, or another GRC platform, make sure stale tasks are resolved and that evidence links point to current, auditor-accessible records.
4. Review policies and procedures against reality
Policies that look clean but no longer match how work gets done create easy findings. Review the core ISMS documents and confirm they are current, approved, versioned, and aligned with actual practice.
Start with:
- Information Security Policy
- Risk Management Policy or procedure
- Incident Response Plan and procedures
- Access Control Policy
- Supplier or third-party risk management procedure
- Business continuity and backup procedures
The question is not just "does the document exist?" It is "can the team show that this is the process they actually follow?"
5. Prepare interview participants
Internal audits depend on interviews. Brief key personnel before the audit so they know when they will be involved, what topics are likely to come up, and what evidence they may need to reference.
This is not coaching people to give scripted answers. It is making sure the right people are available and understand the purpose of the audit. A good briefing covers:
- The audit schedule and interview windows
- Which controls or clauses each person may be asked about
- What systems, tickets, dashboards, or records they may need open
- How to answer honestly when something is incomplete or in progress
6. Confirm ISMS documentation is controlled
Beyond policies and procedures, your key ISMS documents should be controlled, versioned, approved, and accessible. If the auditor asks for the current ISMS scope, risk treatment plan, or previous audit report, your team should know where the authoritative version lives.
Review document control for:
- ISMS scope and boundaries
- Risk assessment methodology
- Risk register and risk treatment plan
- Statement of Applicability
- Internal audit reports
- Corrective action records
- Management review minutes
If multiple versions are floating around in Slack, Google Drive, Notion, Confluence, and your GRC platform, clean that up before fieldwork.
7. Review risk treatment plans
Risk treatment plans should be current, tied to documented risk assessments, and tracked against the deadlines you set. If treatment work is overdue, document the reason and the revised plan.
The most common issue is drift: the risk register says one thing, the treatment plan says another, and the SoA says a control is implemented even though the treatment action is still open. Align those records before the audit.
For each treatment, confirm:
- The treatment option is clear: mitigate, transfer, avoid, or accept
- The action has an owner and target date
- The current status is accurate
- Accepted residual risks have the right approval
8. Check management review minutes
Management review minutes should show that leadership reviewed ISMS performance, not just that a meeting happened. Confirm the minutes are complete and cover the required inputs and outputs for your review cadence.
Useful evidence includes discussion of:
- Status of actions from previous management reviews
- Changes in internal and external issues
- Security objectives and performance against them
- Audit results and corrective action status
- Incident trends, vulnerabilities, and monitoring results
- Resource needs and improvement opportunities
If management review has not happened yet and you plan to complete it before the external audit, make that timing explicit. Do not let the plan live only in someone's head.
9. Prepare training records
Be ready to show both general awareness training and role-specific training where applicable. Training evidence should include completion records, dates, assigned populations, and any follow-up for overdue personnel.
Dashboards are fine if they are complete and exportable. Screenshots can be useful, but the stronger evidence is a report that shows who was in scope, who completed the training, when they completed it, and who is overdue.
Common examples:
- Security awareness training for all personnel
- Secure development training for engineering
- Incident response tabletop participation
- Privacy or data handling training for customer-facing teams
- Administrator training for privileged users
10. Document monitoring and measurement results
Clause 9.1 expects you to monitor, measure, analyze, and evaluate ISMS performance. Before the audit, collect the results you use to understand whether the ISMS is working.
Examples include:
- Incident metrics and trend analysis
- Security objective progress
- Vulnerability remediation SLA performance
- Access review completion rates
- Training completion rates
- Supplier review status
- Backup and recovery test results
The point is not to produce vanity metrics. The point is to show that the organization has defined what it monitors and uses the results to improve the ISMS.
11. Remind stakeholders again
Even if you already announced the audit, remind the involved departments and personnel shortly before fieldwork. ISO 27001 may be your priority this week; other teams have product releases, customer calls, support tickets, and budget meetings.
A useful reminder includes:
- The audit dates and expected availability windows
- Who is being interviewed
- Which systems or records may be requested
- How findings will be communicated
- Who owns follow-up after the audit
Good stakeholder preparation reduces scheduling churn and improves the quality of the evidence you get during fieldwork.
The real goal: fewer surprises
Checklists are useful because they help teams avoid basic mistakes: expired corrective action deadlines, stale SoAs, missing training reports, unmanaged evidence, and interviewees who did not know they were involved.
But internal audit readiness is not just box-ticking. The better habit is regular ISMS maintenance: keep risks current, close actions on time, review evidence as controls operate, and use monitoring results to improve the system before the auditor asks.
If you do that, the internal audit becomes what it should be: an independent check that your ISMS is solid enough for the next stage.