Internal Audit for Cybersecurity: Planning Cyber Audits

Most internal audit functions now audit cybersecurity every year, yet many still deliver cyber audits that test a handful of IT controls and miss the governance and risk decisions that actually drive exposure. Since February 2026 the Institute of Internal Auditors (IIA) has made that harder to defend: its Cybersecurity Topical Requirement sets a mandatory baseline for any assurance engagement that covers cyber risk. This guide explains how to plan cyber coverage in the risk-based audit plan, scope and run individual engagements, apply the Topical Requirement without turning it into a checklist exercise, rate and follow up findings, and report to the audit committee. It is written for chief audit executives, IT audit leads and CISOs who want to understand what a good cyber audit looks like from both sides of the table.

Key takeaways

The Cybersecurity Topical Requirement is mandatory for assurance work. It was issued on 5 February 2025 and became effective on 5 February 2026, and it applies whenever cybersecurity is in the audit plan, emerges during an engagement or is requested outside the plan.
Seventeen requirements in three areas (governance, risk management and control processes) define the minimum the function must assess, and every exclusion needs a documented rationale.
Coverage can be spread across engagements. A multi-year plan that rotates cyber audits is acceptable, provided the plan references the Topical Requirement and coverage eventually addresses every relevant requirement.
Audit outcomes, not control existence. The strongest cyber audits test whether controls operate on the assets that matter, including service accounts, API keys and vendor access, rather than whether a policy exists.
Follow-up is where assurance is won or lost. Standard 15.2 requires internal audit to confirm that agreed actions are implemented; closing findings on management assertion alone is a common and costly failure.

The standards that shape a cyber audit

Internal audit of cybersecurity sits on three layers: the professional standards that govern how internal audit works, the IIA Topical Requirement that sets the cyber baseline, and the control frameworks the organisation itself has adopted, which provide audit criteria.

Source	What it governs	Practical use in a cyber audit
IIA Global Internal Audit Standards (2024 edition)	How internal audit is governed, managed and performed: five domains, 15 principles	Audit plan (Standard 9.4), engagement planning (13.1 to 13.6), findings (14.3), conclusions (14.5), communication (15.1), follow-up (15.2)
IIA Cybersecurity Topical Requirement	Minimum cyber governance, risk management and control process areas to assess	Scoping baseline and applicability matrix for each cyber engagement
IIA Topical Requirements Application Guidance	When topical requirements become mandatory, exclusions, "conform or explain"	Linking the audit plan to risk thresholds and documenting exclusions
NIST Cybersecurity Framework 2.0	Cybersecurity outcomes, including the GOVERN function	Evaluation criteria for governance and programme maturity
NIST SP 800-53 Rev. 5	Control catalogue	Detailed control criteria, such as CA-2 Control Assessments and CA-5 Plan of Action and Milestones
ISO/IEC 27001:2022	Information security management system requirements	Clause 9.2 internal audit of the ISMS, Annex A controls as criteria

The Global Internal Audit Standards were published on 9 January 2024 and took effect on 9 January 2025. The five domains are Purpose of Internal Auditing, Ethics and Professionalism, Governing the Internal Audit Function, Managing the Internal Audit Function and Performing Internal Audit Services. The Topical Requirement does not replace them: the IIA states it must be used together with the Standards. Where the organisation runs an ISO 27001 management system, the ISMS internal audit required by clause 9.2 is a separate obligation that internal audit may or may not perform. See the ISO 27001 Certification Guide.

What the Cybersecurity Topical Requirement asks

The requirement is short, but each line carries an expectation that auditors must test. The table paraphrases the IIA text; read the full PDF before building a work programme.

Area	Ref	Requirement (paraphrased)	Typical evidence
Governance	A	Formal cyber strategy and objectives, periodically updated, with board review of progress, resources and budget	Strategy document, board or committee minutes, CISO reports
Governance	B	Policies and procedures established and periodically updated	Policy register, review dates, approval records
Governance	C	Roles and responsibilities defined; skills of people in those roles periodically assessed	RACI, job descriptions, skills assessments
Governance	D	Stakeholders across the business engaged on vulnerabilities and emerging threats	Steering committee minutes, threat briefings
Risk management	A	Risk assessment covering identification, analysis, mitigation and monitoring of cyber threats against strategic objectives	Cyber risk register, assessment method
Risk management	B	Cyber risk management spans the organisation, not only IT	ERM integration, cross-functional inputs
Risk management	C	Named accountability for monitoring and reporting cyber risk	Risk owner assignments, periodic reports
Risk management	D	Escalation when risk reaches unacceptable levels, considering financial and non-financial impact	Escalation thresholds, risk acceptance records
Risk management	E	Awareness communicated; management reviews gaps and control failures with timely remediation	Training records, issue tracker
Risk management	F	Incident response and recovery covering detection, containment, recovery and post-incident analysis, periodically tested	IR plan, exercise reports, lessons learned
Control processes	A	Internal and vendor-based controls protect confidentiality, integrity and availability and are periodically evaluated	Control testing, SOC reports for vendors
Control processes	B	Talent management and training for cyber technical competence	Training plans, certification pathways
Control processes	C	Emerging threats and vulnerabilities monitored; improvements prioritised and implemented	Threat intelligence process, vulnerability metrics
Control processes	D	Cybersecurity built into asset life cycle: selection, use, maintenance, decommissioning of hardware, software and vendor services	Asset inventory, disposal records
Control processes	E	Configuration, end-user device administration, encryption, patching, user access management, availability monitoring, and security in software development	Baselines, patch reports, access reviews, SDLC gates
Control processes	F	Network controls: access, segmentation, firewalls, limited external connections, VPN or ZTNA, IoT controls, IDS/IPS	Network diagrams, firewall rule reviews
Control processes	G	Endpoint communication security: email, browsers, videoconferencing, messaging, social media, cloud and file sharing	Email security settings, browser and file-sharing policies

When it applies: the IIA lists three triggers: cybersecurity is the subject of a planned engagement, it is identified while performing another engagement, or it is the subject of an engagement request not in the original plan. Conformance is mandatory for assurance services and recommended for advisory services.
Exclusions: each requirement must be assessed for applicability, and the reason for any exclusion documented and retained. The application guidance suggests an applicability matrix held in planning records or workpapers, and ties exclusion judgements to Standards 13.3, 13.4 and 13.6.
Conform or explain: where full conformance is not feasible, the application guidance expects the chief audit executive to take alternative actions that meet the intent and to communicate the rationale; resource shortfalls are reported to the board under Standard 8.2.
Quality assessment: conformance is evaluated in internal and external quality assessments, so the applicability matrix is evidence in its own right.

Building cyber into the risk-based audit plan

Standard 9.4 requires a risk-based internal audit plan. The application guidance says significant topical risks should appear in the plan, either as a standalone cyber audit or spread across several engagements, and that the plan should reference the applicable Topical Requirement.

Build the cyber audit universe. List auditable units that carry cyber risk: the security programme itself, identity and privileged access, cloud platforms, critical applications, OT, third-party connections, data protection, incident response and resilience. Include non-human identities (service accounts, workload identities, API keys and tokens), which are often absent from the universe because no single team owns them.
Rate each unit. Use the organisation's risk taxonomy and appetite, not a separate audit scale. Inputs: the cyber risk register, recent incidents, penetration test and vulnerability results, regulatory change, and major technology change such as a cloud migration.
Map units to the 17 requirements. Decide which engagements will cover which requirements over a two- or three-year cycle. Governance A to D usually fit a programme-level audit; control processes E to G fit technical audits.
Coordinate with other assurance providers. Use an assurance map to see what the second line, external auditors, ISO certification bodies and penetration testers already cover, then decide where to rely and where to test independently. See the Three Lines Model for Cyber Risk Guide.
Check resources and skills. If the function lacks technical depth, co-source or outsource, but the IIA user guide is clear that the chief audit executive remains responsible for conformance.
Get the plan approved. Present the cyber coverage, rotation logic and any resource limitation to the audit committee.

Typical cyber engagement types

Engagement	Main Topical Requirement areas	Frequency in a mature plan
Cybersecurity governance and strategy review	Governance A to D, Risk management A to D	Every 2 to 3 years, or after a CISO or strategy change
Identity and privileged access (human and non-human)	Control processes A, E	Annually for high-risk organisations
Incident response and recovery readiness	Risk management F	Every 1 to 2 years
Vulnerability and patch management	Control processes C, E	Every 1 to 2 years, or continuous monitoring
Cloud security posture	Control processes A, D, E, F	Annually where cloud hosts critical services
Third-party and vendor security	Control processes A, D; Risk management B	Every 2 years
Cyber in pre-implementation or project audits	Control processes D, E	Per major project

These frequencies are a starting point, not an IIA rule; set them from your own risk ratings. See the SOX ITGC Guide for how cyber audits interact with financial reporting controls, and avoid testing the same access controls twice.

Planning and delivering a cyber engagement

Engagement risk assessment (Standard 13.2): walk through the area with the control owners, read prior findings and incident records, and identify which Topical Requirement items are in scope.
Objectives and scope (13.3): write objectives as assurance questions, for example "Are privileged credentials for production cloud accounts limited, monitored and rotated in line with policy?". State what is out of scope and why.
Evaluation criteria (13.4): use the organisation's own policies and the frameworks it has adopted, such as NIST CSF 2.0 outcomes, NIST SP 800-53 controls or ISO/IEC 27001 Annex A. Criteria must be agreed before fieldwork.
Work programme (13.6): for each control, define the test type (inquiry, inspection, observation, re-performance or data analytics), population, sample size and evidence required.
Fieldwork: extract data directly where possible, for example the full list of privileged role assignments from the identity provider or cloud platform, rather than accepting screenshots chosen by the auditee.
Findings (14.3) and conclusions (14.5): document condition, criteria, cause and effect for each finding, then form an overall engagement conclusion.
Communicate (15.1) and follow up (15.2): agree action plans with owners and dates, then verify implementation with evidence.

Testing approaches that work for cyber

Full-population analytics: compare HR leavers with active accounts, or service account inventories with authentication logs, rather than sampling 25 accounts.
Re-performance: re-run a firewall rule review or an access review on a sample and compare the result with management's.
Configuration inspection: read the live setting (conditional access policy, MFA enforcement, logging configuration) rather than the design document.
Exercise observation: attend an incident response tabletop and assess decisions against the plan.
Reliance on specialist testing: use penetration test results as evidence, after assessing the tester's scope, independence and competence. See the Penetration Testing Guide.

Where identity fits

Identity is where a large share of cyber audit findings live, and the Topical Requirement names user access management explicitly under control processes E. Two areas are commonly under-tested:

Non-human identities: service accounts, workload identities, OAuth applications, API keys and tokens frequently outnumber human accounts, are excluded from joiner-mover-leaver processes and have no owner. Ask for the inventory, test ownership and rotation, and compare credentials with last-used data. The Cloudflare Thanksgiving breach shows what happens when a few service tokens and accounts are left unrotated because they were wrongly believed to be unused.
Access reviews: test whether reviewers had enough information to decide, whether revocations were executed, and whether privileged and non-human accounts were in scope. See the Access Reviews Guide.

Rating, reporting and follow-up

The Standards define how findings are evaluated and communicated but leave rating scales to each function. A scale that mirrors the enterprise risk scale lets the board compare cyber findings with other risks.

Rating	Typical meaning	Expected remediation window (example)
Critical	Control failure that exposes critical systems or data now, or breaches risk appetite	Immediate containment; plan within days
High	Significant weakness in a key control or governance process	Within 3 months
Medium	Control operates inconsistently or lacks evidence	Within 6 months
Low	Improvement opportunity, limited exposure	Within 12 months or management discretion

Write for the audit committee: lead with the business consequence, for example "production databases can be reached with a shared credential known to former contractors", not with the control ID.
Report themes: aggregate findings across engagements to show systemic causes such as ownership gaps or tooling debt. See the Board Cyber Risk Reporting Guide.
Risk acceptance: where management decides not to remediate, Standard 11.5 covers communicating the acceptance of risks; the chief audit executive escalates to the board if the accepted risk exceeds appetite. See the Security Exceptions and Risk Acceptance Guide.
Validate closure: under Standard 15.2, re-test critical and high findings before closing them; accept evidence such as configuration exports or system reports, not emails saying the work is done.

Measuring the cyber audit programme

Topical Requirement coverage: percentage of the 17 requirements assessed in the current cycle, with exclusions documented.
Plan coverage of high-risk cyber units: share of units rated high that were audited within their planned frequency.
Overdue actions: number and age of critical and high cyber findings past their agreed date.
Repeat findings: percentage of findings that recur after closure, a direct measure of follow-up quality.
Validated closure rate: share of closed critical and high findings with re-test evidence.
Time to report: days from end of fieldwork to final report; stale cyber findings lose their value quickly.

Framework mapping

Audit activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022
Independent assessment of controls	ID.IM-01 Improvements from evaluations	CA-2 Control Assessments; CA-2(1) Independent Assessors	Clause 9.2 Internal audit; A.5.35 Independent review of information security
Oversight of strategy and performance	GV.OV-01, GV.OV-02, GV.OV-03	PM-9 Risk Management Strategy	Clause 9.3 Management review
Roles and accountability	GV.RR-01, GV.RR-02, GV.RR-03	PM-2 Information Security Program Leadership Role	Clause 5.3 Roles, responsibilities and authorities
Remediation tracking	ID.IM-01, ID.IM-02	CA-5 Plan of Action and Milestones	Clause 10.2 Nonconformity and corrective action
Ongoing monitoring that audit can rely on	GV.OV-03	CA-7 Continuous Monitoring; PM-31 Continuous Monitoring Strategy	Clause 9.1 Monitoring, measurement, analysis and evaluation
Supplier assurance	GV.SC-07	SR-6 Supplier Assessments and Reviews	A.5.22 Monitoring, review and change management of supplier services

The IIA user guide for the Topical Requirement maps each requirement to NIST CSF 2.0, NIST SP 800-53 and COBIT 2019, which helps reconcile existing audit programmes. See the NIST CSF 2.0 Guide.

Common failure patterns

Testing design, not operation: the audit confirms a privileged access policy exists but never extracts the actual list of administrators, so standing access and orphaned service accounts go unreported.
Closing findings on assertion: remediation is accepted from an email. The Capital One breach led the US OCC to impose an $80 million penalty in August 2020, citing both a failure to establish effective risk assessment before moving significant IT operations to the public cloud and a failure to correct deficiencies in a timely manner.
Checklist conformance: treating the 17 Topical Requirement items as the whole audit. The IIA describes them as a minimum baseline, and very high cyber risk may need more.
Undocumented exclusions: requirements silently skipped, which fails quality assessment and hides coverage gaps from the board.
Duplicated assurance: internal audit, the second line and external auditors all test the same access review while cloud and third-party access are untested.
Auditing the old estate: the audit universe lists data centres and on-premises applications but not SaaS, cloud accounts or AI agents now holding production access.

Practitioner checklist

Read the IIA Cybersecurity Topical Requirement, its user guide and the application guidance, and update the audit methodology.
Build a cyber audit universe that includes cloud, SaaS, OT, third parties and non-human identities.
Create an applicability matrix for the 17 requirements and record coverage or exclusion rationale for each.
Reference the Topical Requirement in the risk-based audit plan and show multi-year coverage to the audit committee.
Build an assurance map with the second line and external providers before deciding where to rely.
Agree evaluation criteria (policies, NIST CSF 2.0, SP 800-53 or ISO/IEC 27001) before fieldwork.
Prefer full-population data extraction and live configuration inspection over screenshots and samples.
Rate findings on the enterprise risk scale and report themes, not just lists.
Re-test every critical and high finding before closure and track repeat findings.
Report skill or resource gaps to the board and co-source where needed.

Internal Audit for Cybersecurity Guide: Planning and Delivering Cyber Audits