Evidence lands on the task that asked for it
Each evidence request is a task with a named control owner and a due date. The owner uploads the leaver list or patch report onto that task, and the auditor sees what is overdue without chasing email.
IT Security Audit Checklist Template
A security audit that repeats last year’s findings has usually failed in the same place. The actions were agreed and assigned, and nobody went back to check that the fix worked.
This free IT security audit checklist is for internal auditors, IT and security managers, and MSPs auditing for clients. It audits the whole information security programme, from governance and risk through access, patching, monitoring, suppliers and recovery, then carries every finding through a risk rating, a signed management response and a retest. Each phase has an owner, each evidence request has a due date, and the scope, responses and final report all need a named approval.
An Internal Security Audit Is Not a Certification Audit, or a Scan
An IT security audit tests whether the security programme you describe is the one you actually run. The policy says leavers lose access on their last day, so the auditor samples twenty leavers and checks. The output is a set of findings, each with a risk rating, an owner and an agreed fix, at a level an audit committee can act on.
It is hard to skip. ISO/IEC 27001:2022 requires internal audits at planned intervals (clause 9.2). Since 5 February 2026, internal audit functions following the IIA’s Global Internal Audit Standards apply its Cybersecurity Topical Requirement when assessing cyber governance, risk management and controls. In the EU, NIS2 makes management bodies accountable for overseeing cybersecurity risk measures. And customer security questionnaires ask when the programme was last independently reviewed.
A vulnerability scan or penetration test tells you what is exposed today. The audit asks whether the process that should have found and fixed it is working. The scan report is evidence, not a substitute.
Internal IT security audit
Run by internal audit or an independent IT reviewer
Tests against: your own policies and risk appetite.
Cadence: annual, or a rolling plan by domain.
Output: rated findings, signed responses and a remediation plan.
Audience: management, the CISO and the audit or risk committee.
Certification or attestation audit
Run by a certification body, CPA firm or assessor
Tests against: a fixed standard such as ISO 27001, SOC 2 or PCI DSS.
Cadence: set by the scheme and the certification cycle.
Output: a certificate, an attestation report or a report on compliance.
Audience: customers, partners and regulators.
This template is the first kind. If an external audit is coming, run it early enough to fix what it finds.
What the IT Security Audit Checklist Covers
Seven phases take the audit from scope to closed findings. Framework-mapping tasks appear only for certification-mapped audits, and the escalation phase only when a high-risk finding is raised.
Phase 1
Phase 1: Scope, Plan & Approve the Audit
Owned by the audit lead. The last task is an approval: the CISO or IT director signs off the scope before any evidence is requested.
- Set the audit objective, scope and period — entities, systems, cloud tenants and dates
- Choose the audit criteria — your own policies first, then any framework you have committed to
- Pull forward open findings from the last audit — anything not closed is retested
- Rank the domains by risk with IT and security leads — test hardest where failure hurts most
- Agree the timetable, audit team and independence — nobody audits a control they run
- CISO or IT director approves the audit scope — before any evidence is requested
Phase 2
Phase 2: Request Evidence & Walk Through the Controls
Assigned to the audit lead, with each evidence item owned by the control owner who has to supply it.
- Send the evidence request list with owners and due dates — grouped by domain
- Collect the policy set, risk register and asset inventory — most later tests depend on them
- Obtain the Statement of Applicability or SOC 2 system description — certification-mapped audits only
- Walk through each domain with its control owner — how it really works, not how the policy says it works
- Pull populations and agree sample sizes — joiners, leavers, changes, patches and incidents
- Log evidence gaps and chase them before testing starts — a missing item can be a finding
Phase 3
Phase 3: Test Governance, Risk & People Controls
- Test governance and policy — policies approved, owned and reviewed; security reported to leadership
- Test the risk assessment — current, complete, and every high risk has an owner and a treatment
- Test the asset inventory — trace devices, cloud accounts and SaaS apps found in use back to it
- Test third-party security — critical suppliers assessed, contracted and reviewed
- Test security awareness training — completion, joiners trained on time, phishing follow-up
Phase 4
Phase 4: Test Access, Endpoints & Infrastructure
- Test joiner, mover and leaver access — leavers disabled within the policy deadline
- Test privileged access and MFA — admin accounts justified, separate and protected by MFA
- Test patching and vulnerability management — critical fixes on time, exceptions approved
- Test endpoint protection and secure configuration — anti-malware, disk encryption, hardening baseline
- Review network and cloud security at summary level — a network audit goes deeper
- Test data protection and encryption — classification applied, sensitive data encrypted
Phase 5
Phase 5: Test Detection, Response & Recovery
- Test logging and monitoring — coverage, retention and alert triage
- Trace a sample of security incidents end to end — from detection to lessons learned, including notification decisions
- Confirm the incident response plan was exercised — a tabletop or live test in the period
- Test backup and restore — one copy offline or immutable, and a restore actually tested
- Check business continuity and disaster recovery testing — recovery targets met or explained
Phase 6
Phase 6: Findings, Report & Sign-Off
Finding owners approve their responses; the head of internal audit and the CISO approve the report.
- Rate each finding high, medium or low — using the risk register’s scale
- Map each finding to the affected framework control — certification-mapped audits only
- Agree each finding and action with its management owner — the fix, the owner and a target date
- Management owners sign off their responses — returned if the action misses the cause
- Issue the draft report and hold the closing meeting — record corrections and disputed ratings
- Head of internal audit and CISO sign off the final report — then send it to the audit or risk committee
- Schedule follow-up testing for every agreed action — a retest date, not just a due date
Phase 7 — High-Risk Findings Only
Phase 7: Escalate & Track High-Risk Remediation
Conditional: its tasks appear only when Phase 6 records a high-risk finding.
- Escalate high-risk findings to the audit or risk committee — record who was told and what they decided
- Record interim risk acceptance or compensating controls — signed by the risk owner
- Review remediation progress every month — slipped dates go back to the committee
- Retest each high-risk fix before closing it — proof it works, not a closed ticket
- Report closure to the committee and feed lessons into next year’s audit plan
The Audit-Domain Matrix
Each domain maps to four common frameworks: NIST CSF 2.0 categories (six functions, including the new Govern), ISO/IEC 27001:2022 Annex A controls (93 in four themes; Amendment 1:2024 added climate change to the context clauses), CIS Controls v8.1 (18 controls) and the SOC 2 Trust Services Criteria (2017, points of focus revised 2022). Treat the mappings as a guide to where to look, not an official crosswalk.
| Domain | What the auditor tests | Typical evidence | Framework references |
|---|---|---|---|
| Governance & policy | Policies approved, owned and reviewed; security reported to leadership | Policy register, approval minutes, board or committee papers | CSF GV.PO, GV.OV · ISO 5.1 · CIS: no single control · SOC 2 CC1, CC5.3 |
| Risk assessment | Assessment current and complete; treatment decisions recorded | Risk register, methodology, treatment plan | CSF ID.RA, GV.RM · ISO clause 6.1.2 · SOC 2 CC3.2 |
| Asset inventory | Hardware, software, cloud and SaaS in use are all recorded | Inventory export, discovery scan, reconciliation sample | CSF ID.AM · ISO 5.9 · CIS 1, 2 · SOC 2 CC6.1 |
| Identity & access | Joiners, movers and leavers handled on time; privileged access and MFA | HR leaver list vs directory, access review sign-offs, admin list | CSF PR.AA · ISO 5.15–5.18, 8.2, 8.5 · CIS 5, 6 · SOC 2 CC6.1–CC6.3 |
| Endpoints, patching & vulnerabilities | Patch timeliness, scan coverage, anti-malware and hardening | Patch compliance report, scan results, exception register | CSF PR.PS, ID.RA · ISO 8.7, 8.8, 8.9 · CIS 4, 7, 10 · SOC 2 CC6.8, CC7.1 |
| Network & cloud (summary) | Boundary controls reviewed; cloud configuration monitored | Firewall review record, cloud posture report | CSF PR.IR · ISO 8.20, 5.23 · CIS 12, 13 · SOC 2 CC6.6 |
| Data protection | Classification applied; encryption at rest and in transit | Classification policy, encryption settings, DLP reports | CSF PR.DS · ISO 5.12, 8.24 · CIS 3 · SOC 2 CC6.7, C1.1 |
| Backup & restore | Backups complete, protected and restorable | Backup job logs, restore test record | CSF PR.DS · ISO 8.13 · CIS 11 · SOC 2 A1.2, A1.3 |
| Logging & monitoring | Coverage of key systems, retention, alert triage | Log source list, SIEM rules, alert tickets | CSF DE.CM, DE.AE · ISO 8.15, 8.16 · CIS 8, 13 · SOC 2 CC7.2 |
| Incident response | Plan current and tested; incidents handled and reported on time | IR plan, exercise report, incident records | CSF RS.MA, RS.CO · ISO 5.24–5.28 · CIS 17 · SOC 2 CC7.3–CC7.5 |
| Third-party security | Suppliers risk-assessed, contracted and reviewed | Supplier register, assessments, SOC reports received | CSF GV.SC · ISO 5.19–5.22 · CIS 15 · SOC 2 CC9.2 |
| Awareness & training | Completion, timeliness for joiners, phishing follow-up | Training records, phishing campaign results | CSF PR.AT · ISO 6.3 · CIS 14 · SOC 2 CC1.4, CC2.2 |
| Business continuity & DR | Plans current, tested, recovery targets met | BIA, DR test report, lessons-learned actions | CSF RC.RP, PR.IR · ISO 5.29, 5.30 · SOC 2 CC9.1, A1.3 |
Regional schemes add checkpoints. In the UK, Cyber Essentials (Requirements for IT Infrastructure v3.3, the Danzell question set, from April 2026) requires MFA on cloud services wherever it is available and critical or high-risk updates within 14 days of release, so audit a certified organisation against both. In the EU, NIS2 requires risk-management measures covering suppliers, incident handling and continuity, and staged incident reporting: an early warning within 24 hours, a notification within 72 hours and a final report within a month. The Commission proposed targeted NIS2 amendments in January 2026, so check your national law. In the US, obligations come from sector regulators, contracts and the frameworks above rather than one cross-sector audit rule.
Why Run Your IT Security Audit in CheckFlow?
Approvals that hold up later
Scope, each management response and the final report go to named approvers who approve or return them. Every decision is timestamped, and the finished audit exports with its evidence for the committee or an external auditor.
Findings get retested, not forgotten
Conditional logic adds the escalation phase only when a high-risk finding is raised, and every action carries a retest date. A recurring schedule starts next year’s audit on its own.
CheckFlow is not a GRC suite, a vulnerability scanner or a SIEM, and it does not replace them. It runs the audit workflow around them: requests, testing, findings, approvals and follow-up. CheckFlow’s compliance checklist software shows that across a full compliance calendar. If the audit is preparation for an attestation, see CheckFlow for SOC 2 compliance and our SOC 2 compliance checklist guide.
The ISO 27001 Compliance Checklist builds the ISMS this audit tests, and the SOC Report Review Checklist handles supplier SOC reports collected as third-party evidence. For controls that run all year, see recurring compliance checklists for IT teams.
Frequently Asked Questions
What is an IT security audit?
It is an evidence-based review of whether an organisation’s information security controls are well designed and working in practice. The auditor agrees a scope, requests evidence, tests samples across domains such as access, patching, monitoring and suppliers, and reports rated findings. Management agrees an action and date for each finding, and the auditor retests the fix. Unlike a certification audit, it tests against your own policies and risk appetite, not only a published standard.
What should an IT security audit checklist include?
It should cover the audit lifecycle as well as the controls. The lifecycle: scope and approval, evidence requests, walkthroughs, testing, rated findings, management responses, a signed report and follow-up. The controls: governance, risk assessment, asset inventory, identity and access, patching and vulnerabilities, endpoints, network and cloud, data protection, backup, logging, incident response, third parties, training and business continuity.
How often should you do an IT security audit?
Most organisations audit the whole programme once a year, or cover the highest-risk domains yearly and the rest over a two- or three-year cycle. ISO 27001 requires internal audits at planned intervals but leaves the frequency to your audit programme. Audit sooner after a major change such as a cloud migration or serious incident.
Which framework should an IT security audit use?
Start with your own policies, then use the framework your organisation has committed to. ISO 27001 suits organisations certified or working towards it. NIST CSF 2.0 works well for board reporting because its six functions are easy to explain. The CIS Controls are the most prescriptive and suit smaller IT teams wanting a clear baseline. SOC 2 matters when customers expect an attestation report. The matrix above maps each domain to all four.
Who should carry out an internal IT security audit?
Someone independent of the controls being tested. In larger organisations that is internal audit, often with an IT audit specialist. In smaller ones it might be a peer from another team or an outside consultant. An MSP should not audit controls it operates for the same client. Whoever runs it, people other than the auditor should approve the scope, the management responses and the final report.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.