A cybersecurity program audit exists to answer the one question audit committees actually ask: if we were hit tomorrow, would the controls hold, and would we know in time? Most first-time cyber audits never answer it. They inventory policies, restate the security team’s own dashboard, attach a penetration test that someone else scoped, and close with a “generally adequate” conclusion nobody can defend once an incident is in the newspaper. Since 5 February 2026 the stakes include a professional one: the IIA Cybersecurity Topical Requirement makes 17 specific assessments mandatory in any assurance engagement where cybersecurity is the subject, and it expects a written rationale for anything you leave out. An engagement that stops at policy review now fails the committee and the Standards at the same time.
This guide gives you the working parts of a program-level engagement: a 22-row NIST CSF 2.0 test matrix with an objective, tests and evidence for every category; a 17-requirement conformance tracker for the Topical Requirement; a 1–5 maturity rubric across eight domains with scoring rules and caps; a 90-day plan with hours; a common findings table with root causes and ratings; and a one-page audit committee outline. It was rewritten in September 2026 to reflect the Global Internal Audit Standards, the Topical Requirement now in force, NIST CSF 2.0 and ISO/IEC 27001:2022. It assumes the ground covered in the ITGC primer for non-IT auditors and the identity and access management audit; those are inputs here, not the subject.
In this guide
- What a cybersecurity program audit is, and what it is not
- What the IIA Cybersecurity Topical Requirement obliges you to cover
- NIST CSF 2.0, ISO/IEC 27001:2022 and CIS Controls v8.1 as test catalogs
- Scoping the engagement and the 90-day plan
- The NIST CSF 2.0 test matrix: 22 categories, objectives, tests and evidence
- Rating maturity: a 1–5 rubric across eight domains
- Worked example: MidState Beverage’s first cybersecurity program audit
- Common findings, root causes and typical ratings
- Reporting to the audit committee
- Where cybersecurity audits go wrong, and how to adapt the program
What a cybersecurity program audit is, and what it is not
A program audit tests the organization’s system for managing cyber risk from end to end, and five questions define it. Does leadership know what it is protecting, what it will tolerate and who is accountable? Does the security function identify and prioritize threats on a cycle that keeps up with them? Do the controls that treat the prioritized risks operate, on the assets that matter, all of the time? Would monitoring catch a failure, and how fast? Could the business recover within the time it has said it can survive? Each question maps to a CSF 2.0 function (Govern, Identify, Protect, Detect, Respond, Recover), and each is answered with tests, not interviews.
It is not a penetration test, which asks whether one attacker path exists on one date against targets IT chose. It is not a SOC 2 examination, which reports on a provider’s controls against criteria the provider selected, inside a boundary the provider drew. It is not an ISO/IEC 27001 certification audit, which tests conformity of a management system and treats Annex A as a menu chosen through the Statement of Applicability. It is not the cyber insurance application either, although that document lists controls management has attested to an insurer, every one of which you can test. All of these are evidence, and the matrix section explains how far to rely on each under Standard 9.5. None is an opinion on the program.
Under the IIA Three Lines Model (2020), the security function is a first-line owner of controls even when it also oversees IT in a second-line style, which is normal where one manager writes the policy and runs the tooling. That is an observation about roles, not a reason to accept the function’s self-assessment as evidence; the CISO’s maturity self-score is a management representation, and you corroborate it or you do not report it. The Global Internal Audit Standards require evaluation criteria (Standard 13.4) to be identified during planning and, where management has adopted no framework, selected by internal audit and discussed with management; “adequate” has no meaning without a named framework. Engagement mechanics are in the site’s guide to Domain V, performing internal audit services.
What the IIA Cybersecurity Topical Requirement obliges you to cover
The IIA issued the Cybersecurity Topical Requirement on 5 February 2025 with a one-year runway; it became effective on 5 February 2026 and is mandatory under the International Professional Practices Framework alongside the Global Internal Audit Standards. It applies when cybersecurity is the subject of a planned engagement, when elements of cybersecurity are identified while performing another engagement, and when a request that includes cybersecurity arrives outside the plan. Conformance is mandatory for assurance services and recommended for advisory services. It does not tell you to audit cybersecurity every year; it tells you that once cybersecurity is in scope, each of its 17 requirements must be assessed for applicability and evidence retained, “including a rationale explaining the exclusion of any requirements.” The site’s overview of the IIA Topical Requirements covers the family.
The second trigger is the one that catches functions out. An accounts payable audit that finds supplier bank-account changes accepted by email has surfaced a business email compromise exposure, and the auditor in charge must document whether the scope now includes cybersecurity elements and which of the 17 requirements bear on them. Usually two or three apply and the rest are excluded because the engagement is not a cybersecurity engagement, which is a legitimate rationale if it is written down. The User Guide adds two things: Appendix B maps every requirement to NIST CSF 2.0 subcategories, NIST SP 800-53 controls and COBIT 2019 objectives, and Appendix C supplies a tracking template with three entries per requirement (description, executed or rationale for exclusion, documentation reference). The table restates the 17 requirements in the User Guide’s lettering.
| Ref | Internal audit must assess whether | Evidence that demonstrates conformance | Matrix coverage |
|---|---|---|---|
| Governance A | A formal strategy exists and the board reviews objectives, resources and budget (“generally quarterly” per the User Guide) | Strategy with revision history; four quarters of board packs; budget versus plan | GV.OC, GV.RM, GV.OV |
| Governance B | Policies and procedures are established and updated at least annually | Policy register with review dates; framework adopted; acknowledgment statistics | GV.PO |
| Governance C | Roles are clear and personnel knowledge, skills and abilities are periodically assessed | RACI; security lead’s reporting line; skills matrix | GV.RR |
| Governance D | Senior management, operations, risk, HR, legal, compliance and vendors are engaged on emerging threats | Steering committee minutes; threat briefings; vendor correspondence | GV.OC, GV.RR, GV.SC |
| Risk management A | A risk process identifies, analyzes, mitigates and monitors threats to strategic objectives | Current cyber risk assessment; treatment plans with owners and dates | ID.RA, GV.RM |
| Risk management B | Risk management spans IT, enterprise risk, HR, legal, compliance, operations, supply chain and finance | Risk inputs from each function; cyber entries in the enterprise register | GV.RM, GV.OC |
| Risk management C | A designated individual or team monitors and reports on cyber risk | Role charter; monthly or quarterly risk updates | GV.RR |
| Risk management D | Unacceptable risks are escalated per organizational guidelines and regulation | Defined risk levels and thresholds; escalation log | GV.RM, GV.OV |
| Risk management E | Awareness is communicated and management reviews issues, gaps and deficiencies with timely remediation | Annual training completion by population; phishing simulations; deficiency tracker | PR.AT, ID.IM |
| Risk management F | Incident response covers detection, containment, recovery and post-incident analysis, tested at least annually | Current plan; tabletop report with tracked actions; post-incident reviews | RS.MA, RS.AN, RS.CO, RS.MI, RC.RP, RC.CO |
| Control processes A | Internal and vendor-based controls protect confidentiality, integrity and availability, and are periodically evaluated | Control testing results; SOC report reviews before contracting and through the term; remediation of deficiencies | GV.SC, ID.IM, DE.CM |
| Control processes B | Talent management includes technical competency training for security staff | Training plans; certifications; continuing education records | GV.RR, PR.AT |
| Control processes C | Emerging threats and vulnerabilities are monitored continuously, including threats from technology such as AI | Threat intelligence sources; vulnerability SLAs with aging; AI-use risk assessment | ID.RA, DE.CM, ID.IM |
| Control processes D | Cybersecurity is built into the IT asset life cycle, the SDLC and DevSecOps | Lifecycle procedures; secure configuration at issuance; disposal certificates; SDLC gates where code is written | ID.AM, PR.PS |
| Control processes E | Configuration, device administration, encryption, patching, access management and monitoring strengthen security | Baseline scans; MDM enrollment; encryption status; patch compliance; MFA exports | PR.PS, PR.DS, PR.AA, DE.CM |
| Control processes F | Network controls include segmentation, firewalls, limits on connections, VPN or zero trust access, IoT controls and IDS/IPS | Firewall rule reviews; segmentation design with connectivity tests; remote access configuration | PR.IR, PR.AA, DE.CM |
| Control processes G | Email, browsers, video conferencing, messaging, social media, cloud and file sharing are secured | Email security configuration; web filtering; blocked file types; MFA on collaboration tenants | PR.PS, PR.DS, PR.AA |
How to evidence conformance without inventing a bureaucracy
Complete the Appendix C tracker during planning, attach it to the planning memo, and update it at reporting so the documentation references point at final workpapers. The rationale for any exclusion has to be risk-based: “the organization does not do this” is a rationale; “we ran out of hours” is a scope limitation that Standard 15.1 obliges you to disclose. An external quality assessment under Standard 8.4 will ask for the tracker on every cyber engagement performed after 5 February 2026; the site’s QAIP and external quality assessment guide explains what else assessors pull. Two model entries show the difference.
Acceptable rationale (Control processes D, DevSecOps element). The organization develops no software and commissions no custom code; the SDLC and DevSecOps elements of Control processes D are not applicable. The asset life cycle elements of D were assessed under work steps 4.3 to 4.6 (workpapers C-410 to C-460).
Unacceptable rationale (Risk management F). Incident response was not reviewed because the security team plans a tabletop next quarter. This is a scope limitation, not an exclusion: the requirement applies, the plan and prior exercise records must be assessed now, and the limitation must be stated in the report with the follow-up date.
NIST CSF 2.0, ISO/IEC 27001:2022 and CIS Controls v8.1 as test catalogs
NIST CSF 2.0, published 26 February 2024, has six functions, 22 categories and 106 subcategories. The Govern function is new, and supply chain risk management moved into it as GV.SC. The subcategories are written as outcomes (“Identities and credentials for authorized users, services, and hardware are managed by the organization”), which makes CSF the right spine for audit objectives and the wrong place to look for a test. The Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe the rigor of risk governance practices, and NIST says they are not a maturity model, so do not present a Tier as one. Organizational Profiles (Current and Target) are CSF’s own gap tool; test the profile before you borrow its conclusions.
ISO/IEC 27001:2022 restructured Annex A into 93 controls across four themes: 37 organizational, 8 people, 14 physical and 34 technological. Eleven controls were new in 2022, and several sit where mid-sized programs are thin: threat intelligence (5.7), cloud services (5.23), ICT readiness for business continuity (5.30), configuration management (8.9), monitoring activities (8.16) and web filtering (8.23). The transition from the 2013 edition closed on 31 October 2025, so any certificate shown to you in 2026 should reference the 2022 edition. Annex A states what good looks like per control; the Statement of Applicability tells you what management chose to exclude, and every SoA exclusion is a scoping decision to challenge.
CIS Controls v8.1 (June 2024) keeps the 18 Controls and 153 Safeguards of v8, adds a Governance security function and realigns to CSF 2.0 without changing the Implementation Groups. IG1, the 56 safeguards CIS calls essential cyber hygiene, is the floor for any organization. CIS supplies the specific, testable safeguard: dormant accounts disabled after 45 days (5.3), MFA for remote network access (6.4) and administrative access (6.5), operating system patching at least monthly (7.3), an isolated instance of recovery data (11.4), recovery testing (11.5) and an inventory of service providers (15.1). The crosswalk lines the three catalogs and the Topical Requirement up against the eight domains this guide scores.
| Rubric domain | CSF 2.0 categories | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | Topical Requirement refs |
|---|---|---|---|---|
| 1. Governance and oversight | GV.OC, GV.RR, GV.PO, GV.OV | 5.1, 5.2, 5.4, 5.35, 5.36 | Governance function tags (v8.1); no standalone Control | Governance A to D |
| 2. Risk management and awareness | GV.RM, ID.RA, ID.IM, PR.AT | 5.7, 5.27, 6.3, 6.8 | 14, 18 | Risk management A to E; Control processes C |
| 3. Asset, vulnerability and patch management | ID.AM, ID.RA-01, PR.PS-01, PR.PS-02 | 5.9, 5.12, 8.8, 8.9, 8.19 | 1, 2, 4, 7 | Control processes C, D, E |
| 4. Identity and access management | PR.AA | 5.15 to 5.18, 8.2, 8.3, 8.5 | 5, 6 | Control processes E |
| 5. Network, endpoint and data protection | PR.IR, PR.PS, PR.DS | 8.1, 8.7, 8.12, 8.20 to 8.24 | 3, 9, 10, 12, 16 | Control processes E, F, G |
| 6. Detection and monitoring | DE.CM, DE.AE | 8.15, 8.16 | 8, 13 | Control processes C, E |
| 7. Incident response, backup and recovery | RS.MA, RS.AN, RS.CO, RS.MI, RC.RP, RC.CO, PR.DS-11 | 5.24 to 5.26, 5.29, 5.30, 8.13, 8.14 | 11, 17 | Risk management F |
| 8. Third-party and supply chain | GV.SC | 5.19 to 5.23 | 15 | Control processes A; Third-Party Topical Requirement from 15 September 2026 |
Pick the criteria in planning and write them into the planning memo. If management has adopted a framework, test against it, because a finding written against a standard management never agreed to is the one most likely to be argued down; if management has adopted nothing, use CSF 2.0 for objectives and CIS IG1 or IG2 for safeguards, and record the absence as a Governance B observation. The crosswalk also tells you what to reuse: a recent privileged access audit covers much of domain 4.
Scoping the engagement and the 90-day plan
Scope from assets and attack paths, not from the IT organization chart. Start with tier-1 systems: what stops revenue within a day, what holds regulated data and what moves money. Then list the paths an attacker uses to reach them: identity, remote access and vendor accounts, internet-facing services, unpatched edge devices, and the backups every ransomware crew targets first. The engagement risk assessment (Standard 13.2) records this reasoning, and the planning memo turns it into objectives and scope under Standard 13.3. The decisions that most often go wrong are in the next table.
| Scope decision | Include when | Exclude only when (and document why) | The trap |
|---|---|---|---|
| Acquired or non-integrated entities | They connect to your network or share identities or data with tier-1 systems | Fully isolated, verified by you rather than asserted | Management equates “not on the ERP” with “not on the network” |
| Warehouse, field and IoT devices | They touch tier-1 data or sit on the corporate network | They live on an isolated segment with no route to corporate, verified | EDR coverage of 98% means 98% of laptops; handhelds and printers are outside the denominator |
| Cloud tenants and SaaS | Any tier-1 process or regulated data runs there | Never; at minimum the identity and security configuration of each tenant | Relying on the provider’s SOC 2 for settings that are the customer’s responsibility |
| Third parties with access | Any standing or remote access, or hosting of tier-1 data | They hold nothing and connect to nothing | The vendor list comes from accounts payable, not from the firewall and identity provider |
| Penetration testing | Management already has one; you review scope, method and remediation | You never perform it inside a program audit | Letting the test’s target list define your scope |
| SOX ITGC overlap | In-scope financial systems share infrastructure and identities with everything else | Never; coordinate under Standard 9.5 | Testing the same access controls twice with different conclusions (see SOX ITGC scoping) |
Resourcing follows scope. A mid-sized organization with one data center, a handful of cloud tenants and 50 to 100 servers takes 450 to 650 hours at program level, and 100 to 150 of those hours should be a specialist’s, because firewall rule analysis, cloud tenant configuration and segmentation testing are where a generalist gets it wrong without knowing (Standards 3.1 and 13.5 make competency an engagement-level obligation). The site’s guide to internal audit co-sourcing covers how to buy those hours without buying the vendor’s opinion. The plan below is built for 540 hours over 90 days.
| Phase | Days | What happens | Hours | Deliverables |
|---|---|---|---|---|
| 0. Planning | 1 to 10 | Engagement risk assessment; tier-1 and attack-path scoping; criteria selection; Topical Requirement applicability tracker; risk and control matrix; data requests issued day 1 | 70 | Planning memo; Appendix C tracker; RCM; request list with due dates |
| 1. Governance and risk management | 11 to 30 | Four quarters of board packs; strategy, policies, roles and skills; risk register and escalation; awareness data | 80 | Governance and risk workpapers; first interim observations memo |
| 2. Identity, assets, vulnerabilities, platform, network | 21 to 55 | Configuration exports; inventory reconciliation; termination and access samples; scan and patch aging; MFA and privileged access; firewall and segmentation testing (co-sourced) | 200 | Identify and Protect rows concluded; exception logs; second interim memo |
| 3. Detection, response, recovery, third parties | 40 to 65 | Log coverage against the tier-1 list; alert triage sample; incident plan and playbooks; tabletop observed; restore observed; vendor access inventory and SOC report review | 100 | Tabletop observation memo; restore evidence with timings; third-party workpapers |
| 4. Evaluation and reporting | 66 to 90 | Findings rated by root cause; maturity rubric scored; management responses and dates; draft, closing meeting, final; committee one-page | 90 | Final report; maturity scorecard; one-page committee summary; issue log entries |
Two scheduling points decide whether the plan holds. Issue the data request on day 1 with every export named exactly, from the asset inventory and directory objects to scan exports with first-seen dates, firewall rules, backup logs, the monitoring provider’s log source list and four quarters of board material. Then book the two observation events in week 2: a tabletop exercise and a timed restore of a tier-1 system. Both need calendars from people outside audit, and both produce evidence no document can substitute for; if management declines either, the refusal is reported as a scope limitation.
The NIST CSF 2.0 test matrix: 22 categories, objectives, tests and evidence
The matrix is the work program. The evidence column is the standard: system-generated exports with query parameters, run date and row count recorded, because a console screenshot is a picture of one moment and a vendor dashboard is information produced by the entity until you have checked how it was produced. The site’s guides on IPE testing, sample sizes of 25, 40 and 60 and design versus operating effectiveness apply without modification; test design first in every row. The matrix loads into the free RCM Workbench as the starting risk and control matrix.
| CSF 2.0 category | Audit objective | Tests | Evidence to retain |
|---|---|---|---|
| GV.OC Organizational Context | The program rests on mission, legal obligations and critical dependencies | Trace strategy objectives to business objectives; confirm business owners agreed the tier-1 list and the obligations register | Strategy; obligations register; signed tier-1 list |
| GV.RM Risk Management Strategy | Cyber risk appetite is stated and integrated with enterprise risk management | Compare cyber entries in the enterprise register with the security team’s list; trace one high risk to treatment | Register extracts; appetite statement; treatment history |
| GV.RR Roles, Responsibilities and Authorities | An accountable executive, defined roles, resourcing and skills assessment exist | Inspect RACI and the security lead’s reporting line; compare budget and headcount to plan; inspect the last skills assessment | RACI; budget versus plan; skills matrix |
| GV.PO Policy | Policies are established, communicated, enforced and reviewed annually | Inventory policies with review dates; sample 25 employees for acknowledgment; compare coverage with the framework | Policy register; acknowledgment report; gap list |
| GV.OV Oversight | The board reviews outcomes and adjusts strategy and resources | Read four quarters of board packs for KPIs, remediation status and decisions; confirm accepted risks reach the board | Packs and minutes; KPI history; acceptance records |
| GV.SC Cybersecurity Supply Chain Risk Management | Suppliers with access or data are identified, assessed, contracted and monitored | Build the vendor list from firewall, VPN and identity data; sample 25 vendors for due diligence, contract clauses and SOC 2 review with user entity control mapping; test that vendor access is named and time-bound | Access-derived inventory; due diligence files; SOC reports with CUEC mapping |
| ID.AM Asset Management | Hardware, software, data and services are inventoried with owners | Reconcile the inventory to directory objects, EDR agents, 30 days of DHCP leases and procurement; disposition every unmatched device | Reconciliation workpaper; unmatched list with dispositions |
| ID.RA Risk Assessment | Vulnerabilities and threats are identified, prioritized and responded to | Compare scan coverage with the inventory; age open criticals against SLA; review penetration test scope and remediation | Scan exports with first-seen dates; aging analysis; pen test tracker |
| ID.IM Improvement | Lessons from exercises, assessments and incidents become tracked improvements | Inspect post-incident reviews for the last three incidents; test that tabletop and audit actions closed on time | Post-incident reviews; action trackers |
| PR.AA Identity Management, Authentication and Access Control | Identities are managed through their life cycle; authentication is strong; access follows least privilege | Sample 40 terminations against directory and tier-1 removal dates; export MFA configuration with every exception; inventory privileged and service accounts; inspect the last review of each tier-1 application | HR list matched to identity logs; MFA exports; privileged inventory; review sign-offs (see the user access review guide) |
| PR.AT Awareness and Training | All personnel, and privileged roles in particular, are trained | Compute completion by population including field staff and contractors; trend phishing click and report rates | Learning system reports; simulation results by campaign |
| PR.DS Data Security | Data is protected at rest and in transit; backups are created, protected and tested | Export disk encryption compliance; compare backup coverage with the tier-1 list; confirm an immutable copy; observe a timed restore | Encryption report; backup logs; restore record with timings |
| PR.PS Platform Security | Platforms are hardened, patched and maintained through a controlled life cycle | Obtain benchmark compliance scans; measure patch compliance by tier; list end-of-support systems; sample 25 changes for approval | Benchmark results; patch reports; end-of-support list; change tickets |
| PR.IR Technology Infrastructure Resilience | Networks resist unauthorized access; capacity and resilience are managed | Compare the network diagram with the firewall rule base; test segmentation with connectivity checks between field, vendor, acquired, corporate and server zones | Rule base with review evidence; VLAN design; connectivity results |
| DE.CM Continuous Monitoring | Assets, networks, personnel activity and providers are monitored | Compare monitored log sources with the tier-1 list; check retention; sample 25 critical alerts for triage within SLA; reconcile EDR coverage to the inventory | Log source inventory; retention report; alert sample with timestamps |
| DE.AE Adverse Event Analysis | Events are analyzed and incidents declared against defined criteria | Inspect declaration criteria; trace 10 escalated events from alert to decision | Criteria document; tickets with decision timestamps |
| RS.MA Incident Management | The response plan is current and executed with defined roles and escalation | Review the plan and playbooks for ransomware, business email compromise and data theft; observe a tabletop; sample three incidents for adherence | Plan; playbooks; exercise report; incident records |
| RS.AN Incident Analysis | Incidents are investigated to root cause with evidence preserved | Confirm a forensic retainer and preservation procedure; inspect analysis for sampled incidents | Retainer contract; incident analysis reports |
| RS.CO Incident Response Reporting and Communication | Stakeholders are notified as obligations require | Inspect the notification matrix (regulators, customers, insurer, board); confirm a materiality assessment procedure where disclosure rules apply | Notification matrix; materiality procedure; verified contact list |
| RS.MI Incident Mitigation | Incidents are contained and eradicated | Have the team demonstrate host isolation, account disablement and indicator blocking; measure time to contain in sampled incidents | Demonstration record; containment timings |
| RC.RP Incident Recovery Plan Execution | Recovery runs in sequence, integrity is verified, return to normal is decided on criteria | Inspect the tier-1 recovery sequence; compare the observed restore time with the stated RTO; test backup integrity checks | DR plan; restore report with RTO and RPO; integrity logs |
| RC.CO Incident Recovery Communication | Recovery progress is communicated to stakeholders | Inspect templates and cadence; trace communications from the last exercise or incident | Templates; communication logs |
Reliance on other assurance, under Standard 9.5, is a decision you document. For a SOC 2 Type 2 report, read the system boundary, the period, the exceptions and the complementary user entity controls, then test the user entity controls yourself, because “the customer is responsible for configuring MFA” is where most cloud incidents live. For a penetration test, evaluate the tester’s method, the target list against your tier-1 list, and the remediation tracker. For an ISO certificate, obtain the certified scope, the Statement of Applicability and the last surveillance audit findings. None of these replaces your own reconciliation of inventory, coverage and access, which is why domains 3, 4 and 6 are rarely candidates for reliance.
Rating maturity: a 1–5 rubric across eight domains
Findings tell the committee what is broken; a maturity profile tells it how far the program is from where the board wants it and whether the distance is closing. Level 1 is initial: activity depends on individuals and leaves no evidence trail. Level 2 is developing: documented in part, operating inconsistently, gaps known. Level 3 is defined: documented, operating consistently on every tier-1 asset, evidenced, measured at least annually. Level 4 is managed: measured against thresholds, exceptions tracked, independently tested, complete across the estate including field and acquired assets. Level 5 is optimized: metrics drive investment, controls are automated, validation is continuous.
| Domain | Level 1 Initial | Level 2 Developing | Level 3 Defined | Level 4 Managed | Level 5 Optimized |
|---|---|---|---|---|---|
| 1. Governance and oversight | No strategy; security is an IT cost line; the board hears about cyber after incidents | Strategy drafted; some policies older than two years; annual board slide without metrics | Approved strategy; policies reviewed annually; accountable executive named; quarterly board reporting with agreed KPIs | KPI thresholds trigger decisions; budget tied to risk treatment; skills gaps funded | Board challenges targets against peers and threat changes; strategy revised on evidence |
| 2. Risk management and awareness | Risks live in the security team’s heads; training ad hoc | Risk list outside the enterprise register; annual training for office staff only | Cyber risks in the enterprise register with owners; escalation thresholds defined; all populations trained annually; phishing simulations run | Assessment refreshed on threat and business change; simulations drive targeted training | Quantified risk informs investment; threat intelligence changes controls within days |
| 3. Asset, vulnerability and patch management | Inventory from procurement only; scans irregular; patching when convenient | Inventory unreconciled; monthly scans on servers only; SLAs missed | Inventory reconciled to discovery quarterly; all tier-1 assets scanned; criticals closed within SLA; end-of-support systems have funded plans | Unknown devices quarantined; metrics trended; compensating controls tested for exceptions | Exploitability-based prioritization; near-zero unknown assets sustained |
| 4. Identity and access management | Shared accounts common; deprovisioning late; no MFA on remote access | MFA on email and VPN with exceptions; deprovisioning within days; reviews irregular | MFA on all remote, cloud and administrative access with no standing exceptions; deprovisioning within one business day; quarterly reviews of tier-1 applications; separate admin accounts | Privileged access vaulted and session-logged; access certified against roles; exceptions expire automatically | Continuous access analytics; just-in-time privilege |
| 5. Network, endpoint and data protection | Flat network; unmanaged devices; no encryption standard | Perimeter firewall reviewed occasionally; laptops encrypted; field and IoT devices unmanaged | Zones enforced between corporate, server, field, vendor and acquired networks; rule base reviewed semi-annually; all endpoints managed and encrypted; email and web filtering enforced | Segmentation tested annually; DLP on regulated data; non-conforming devices blocked | Zero trust access for users and vendors; automated policy enforcement |
| 6. Detection and monitoring | Logs kept locally if at all; nobody watches them | Central logging for some sources; alerts reviewed in business hours; retention under 90 days | All tier-1 systems and identity sources forwarded; 24×7 triage with SLA; 12-month retention; EDR on every managed endpoint | Coverage mapped to attacker techniques; ingestion health alerted; triage SLA reported | Detections tested through purple-team exercises; automated response |
| 7. Incident response, backup and recovery | Plan absent or stale; never exercised; no immutable backup copy or restore test | Plan current; one exercise in 24 months; immutable copy exists; restore tested but RTO not demonstrated | Annual tabletop with actions closed; playbooks for ransomware, business email compromise and data theft; quarterly timed restores meeting RTO and RPO | Exercises include executives and third parties; post-incident reviews change controls; recovery sequence tested end to end | Recovery automated and rehearsed; integrated with business continuity |
| 8. Third-party and supply chain | No inventory of vendor access; contracts silent on security | Vendor list from AP; some SOC reports on file, unread | Access-derived inventory, tiered; due diligence before contracting; security clauses; SOC reports reviewed annually with user entity controls mapped; vendor access named and time-bound | Continuous monitoring of critical vendors; exit plans for tier-1 providers; fourth parties identified | Vendor risk quantified in procurement decisions |
The rubric only works with scoring rules that stop it drifting toward whatever management believes. Seven matter.
- Score on evidence, never on interview. A descriptor is met when a workpaper shows it operating; a descriptor management describes but cannot evidence is not met.
- Levels are cumulative. A domain earns a level only when every descriptor at that level and every lower level is met; quarterly restores with no playbooks is Level 2 in domain 7, not “Level 3 with a gap.”
- Coverage counts. Coverage below 95% of tier-1 assets caps a domain at 2; anything below 100% caps it at 3.
- Hard caps apply regardless of descriptors. No MFA on remote or administrative access caps domain 4 at 2; a tier-1 system outside central logging caps domain 6 at 2; no immutable backup copy, or no successful tier-1 restore within 12 months, caps domain 7 at 1; no access-derived vendor inventory caps domain 8 at 1; no cyber entry in the enterprise risk register caps domain 1 at 2.
- Report the profile, not an average. Give eight scores, the median and the minimum; the program level is the lower of the median and the minimum plus one, so one Level 1 domain holds a program at Level 2.
- The target belongs to management and the board. If none exists, that is a Governance A finding; compare against Level 3 as the interim target and say so.
- Score the same way next time. Any change to descriptors or caps is disclosed on the scorecard, otherwise year-on-year movement is noise.
Keep the maturity profile separate from the engagement rating. The rating answers Standard 14.5’s demand for an engagement conclusion and is driven by findings and the exposure they create today; maturity is the trajectory. A program can be Level 2 and rated Needs Improvement because its worst gaps are funded and closing, or Level 3 and rated Unsatisfactory because one unmitigated High finding exposes a tier-1 system right now. The committee gets both, with one sentence explaining why they differ.
Worked example: MidState Beverage’s first cybersecurity program audit
MidState Beverage distributes across three states from 12 depots and 300 delivery routes, on roughly $221 million of revenue, with a 2013 ERP route-accounting module, depot spreadsheets, two recently acquired distributors still on their own systems and a six-person internal audit function. In March 2026 a peer distributor lost its route accounting to ransomware for nine days, and in April the audit committee chair asked the CAE for a cybersecurity program audit. The request was not in the FY27 plan, which made it the third applicability trigger of the Topical Requirement, and it was assurance, so all 17 requirements applied. The CAE amended the plan under Standard 9.4, deferring the fleet and DOT advisory, and kept the planned ERP user access engagement running in parallel so the cyber audit could rely on its termination testing under Standard 9.5. The budget was 540 hours: 300 for the senior IT auditor in charge, 120 for a staff auditor and 120 co-sourced for firewall, segmentation and cloud tenant work. Fieldwork ran from 4 May to 26 June, the report was issued 24 July, and the committee met on 12 August 2026.
The environment was typical for a company of its size. Eleven IT staff reported to an IT director who reported to the CFO; security was a manager and one analyst. A managed detection and response provider had run 24×7 monitoring since FY25, with EDR on 92 servers and 640 laptops and desktops. The 380 ruggedized handhelds drivers use to settle routes sat under mobile device management, with 194 enrolled. The ERP application server ran an operating system out of mainstream support since 2023, on paid extended updates that lapse in October 2026. Backups ran nightly to an on-premises appliance replicating to a cloud vault. The two acquired distributors, 140 endpoints between them and none with EDR, were joined to MidState by site-to-site VPN with no segmentation, and depot Wi-Fi shared the corporate VLAN. Four vendors held VPN accounts.
The tests produced numbers the committee could hold onto. The inventory reconciliation compared the configuration database (712 devices) with directory computer objects (803), EDR agents (732) and 30 days of DHCP leases (1,118 unique addresses), and left 289 devices with no owner in any system: handhelds, label printers, telematics gateways and the acquired distributors’ PCs. Scanning showed 212 open critical vulnerabilities with a median age of 71 days against a 30-day SLA; 23 of the 38 older than 180 days sat on the ERP application server, where they could not be patched. MFA was enforced on cloud email for 98% of accounts but not on the VPN for four vendor accounts and 27 service accounts, and the ERP vendor’s credential was shared by four of its engineers. The ERP held 1,912 local accounts, 214 belonging to terminated employees; of 40 sampled FY26 terminations from a population of 312, 12 still had active ERP accounts. Nineteen domain administrator accounts served 11 IT staff, six of them shared. Backup immutability was off, the last full ERP restore test was 26 months old, and the 24-hour recovery time objective had never been demonstrated. The MDR provider ingested EDR, firewall and directory logs but not ERP application or handheld sync logs, retained 90 days, and triaged 22 of 25 sampled critical alerts within its 15-minute SLA; the slowest exception, 190 minutes, was a weekend vendor login from a new country closed as benign. The incident plan was dated 2022 and had never been exercised, there were no playbooks, and the cyber insurance application renewed in January 2026 for a $5 million limit attested MFA on all remote access. Training completion stood at 71%, a phishing simulation to 610 office users produced 84 clicks (13.8%), and the 300 drivers were outside the awareness program entirely.
Two things changed during fieldwork, and both went in the report. Management enforced MFA on every VPN account by 12 June and replaced the shared vendor credential with named, time-bound accounts; the audit retested both. Management also enabled immutability on the cloud vault and ran a full ERP restore on 20 June with the auditor observing. The restore succeeded in 31 hours against a 24-hour objective, which lifted the cap on domain 7 and created a new finding: the recovery time objective was not achievable with the current architecture. The DevSecOps element of Control processes D was excluded with a documented rationale, because MidState develops no software. Scored on the rubric, with caps for the missing risk register entry (domain 1), the 289 unknown devices (domain 3), the ERP logs outside central monitoring (domain 6) and the absent vendor inventory (domain 8), the profile came out 2, 2, 2, 2, 2, 2, 1, 1. Domain 7 stayed at 1 after the June fixes because the plan was stale and had never been exercised, so the Level 2 descriptors were not all met.
With a median of 2 and a minimum of 1, the program level was 2, Developing. The report carried 11 findings, six High, four Medium and one Low, and an overall rating of Needs Improvement rather than Unsatisfactory, under a stated rule: Unsatisfactory applies when a High finding leaves a tier-1 system exposed with no compensating control and no funded plan, and the two conditions that most exposed MidState had been fixed and retested before issuance. The ERP server plan is the part worth copying. Migration was funded at $410,000 for completion in March 2027, five months after the extended updates lapse, so management accepted the interim risk in writing under Standard 11.5 with compensating controls the audit will test at follow-up: the server isolated in its own segment, application allow-listing enforced, and its logs forwarded to the MDR provider by 30 September 2026. Segmentation was scheduled for the end of the second quarter of FY27, an ERP access cleanup by 31 October 2026, and an executive tabletop on 17 September 2026, after which domain 7 would be re-scored. Each action went into the issue log with an owner and a date, and the follow-up engagement was written into the FY27 plan under Standard 15.2.
Common findings, root causes and typical ratings
Write one finding per root cause, not one per vulnerability. A report that lists 212 critical vulnerabilities as 212 findings, or as one finding called “vulnerabilities exist,” has abandoned the discipline in the five Cs of audit findings: the finding is that vulnerability management has no asset ownership and no enforced SLA, the condition is the 212 and the 71-day median, and the effect is the exposure of named tier-1 systems. Rate on exposure today, using the scale in the site’s guide to finding severity ratings, and let the maturity profile carry the longer view.
| Finding | Root cause you usually find | Remediation that works | Typical rating |
|---|---|---|---|
| MFA not enforced on all remote and administrative access | Exceptions for vendors or legacy protocols with no owner and no expiry | Conditional access with no exception path; named, time-bound vendor access; quarterly exception review | High; Critical if administrative access is internet-reachable |
| Incomplete asset inventory; unknown devices on the network | Inventory built from procurement rather than discovery; field, IoT and acquired assets never onboarded | Monthly reconciliation of discovery data to inventory, EDR and DHCP; quarantine for unknown devices | High |
| Critical vulnerabilities open beyond SLA; end-of-support systems in production | Scanning without asset ownership; SLA never enforced; migration unfunded because no business owner understands the exposure | Owner per asset; monthly SLA reporting; funded migration with isolation and allow-listing in the interim; risk acceptance under Standard 11.5 | High |
| Backups without an immutable or offline copy; restore untested | Backup product configured for convenience; restore tests treated as optional | Immutable or air-gapped copy; quarterly timed restore of each tier-1 system, observed annually by someone outside IT | High; Critical when combined with a flat network |
| Flat network between field, vendor, acquired and corporate zones | Growth by acquisition; Wi-Fi and devices added without a segmentation design | Zone design; firewall policy between zones; connectivity tests after every change and annually | High |
| Terminated users retain access; no access review of tier-1 applications | HR-to-IT feed is manual; application-local accounts sit outside the identity system | Automated deprovisioning from the HR system; quarterly reviews of every tier-1 application with removal evidence | High |
| Excessive or shared privileged accounts | Administrators use one account for everything; shared credentials for convenience or vendors | Separate admin accounts; vaulting with session logging; monthly privileged review; named vendor accounts | High |
| Logging gaps on tier-1 systems; short retention | Log sources onboarded opportunistically; retention priced by volume rather than need | Log source inventory tied to the tier-1 list; 12-month retention for security logs; ingestion health alerts | Medium |
| Incident plan stale or untested; no playbooks | Plan written for a certificate or an insurer and then shelved | Annual tabletop with a board observer; ransomware, business email compromise and data theft playbooks; post-incident review template | Medium; High where insurance attestations or disclosure duties depend on it |
| Third-party access unmanaged; no cyber strategy, KPIs or board cadence | Vendor list lives in AP and security is not part of contracting; security run as an IT cost line with no accountable executive | Access-derived vendor inventory with SOC 2 review and contract clauses; executive-approved strategy; quarterly board pack with KPIs; cyber entries in the enterprise risk register | Medium |
Two rating disciplines keep the table honest. A control fixed during fieldwork is still reported, with the condition as found, the date fixed and the retest performed. And a rating does not rise because the topic is fashionable or fall because the fix is expensive: an unsupported server is High whether or not the migration is in the budget. Where the overlap with financial reporting controls is real, the ITGC deficiency is also evaluated under the control deficiency evaluation rules for SOX purposes, a separate judgment from the cyber rating.
Reporting to the audit committee
The committee needs six things on one page: the rating and the program level, the three conditions that would matter most in an incident, the maturity profile against target, a conformance statement for the Topical Requirement, what was not covered and why, and what management has accepted rather than fixed. Everything else lives in the full report, structured as in the site’s internal audit report template. Standard 15.1 requires the final communication to carry objectives, scope, conclusions, findings and limitations, and Standard 11.3 makes the CAE responsible for results reaching the board in a form it can use. The first quote block is the one-pager; the second gives model language for the two paragraphs committees read most closely.
Title and one-line conclusion. Cybersecurity program audit, FY27. Rating: Needs Improvement. Program maturity: Level 2 of 5 (Developing) against a management target of Level 3 by the end of FY28.
Basis. Scope (tier-1 systems, all sites including acquired entities, cloud tenants, third parties with access); criteria (NIST CSF 2.0 for objectives, CIS Controls v8.1 IG2 for safeguards); 540 hours including 120 co-sourced; reliance placed on the ERP user access engagement and two SOC 2 reports after user entity control mapping.
What would matter in an incident. Three conditions, each with the exposure in business terms, the rating, the owner and the date: (1) the ERP application server cannot be patched and its vendor support lapses in October; (2) a flat network lets an intrusion at a depot or an acquired site reach the ERP; (3) the 24-hour recovery objective was missed by seven hours in the observed restore.
What is working. 24×7 managed detection with 88% SLA adherence on sampled critical alerts; full-disk encryption on every laptop; MFA on email for 98% of accounts and on all remote access since 12 June.
Maturity profile. Eight domain scores with caps noted, the median, the minimum, the two domains at Level 1, the actions that move each and the re-scoring date.
Topical Requirement conformance. All 17 requirements were assessed for applicability; 16 were executed in full and one element was excluded with a documented rationale (no software development). The tracker is available to the committee on request.
Limitations and accepted risks. What was not tested and why; the risk management has accepted in writing (the unsupported ERP server until March 2027) with its compensating controls and follow-up date.
Next steps. Follow-up engagement in the plan; tabletop date; re-scoring date; the KPIs the committee will see quarterly from management.
Model conclusion paragraph. Based on the procedures performed, the cybersecurity program is rated Needs Improvement. Governance, detection and identity controls are established but incomplete in coverage, and three conditions expose route accounting to disruption that management could not recover from within its stated objective. Two of the six High-rated conditions were remediated and retested before this report was issued. Program maturity is Level 2 of 5 against a Level 3 target. This audit provides reasonable, not absolute, assurance, and it does not conclude that a breach will not occur.
Model accepted-risk paragraph. Management has accepted, in writing dated 18 July 2026, the risk that the ERP application server will operate without vendor security updates from October 2026 until migration completes in March 2027. Internal audit considers the compensating controls (segment isolation, application allow-listing, log forwarding to the monitoring provider) adequate to reduce the exposure to a level the board may reasonably accept, and will test them in November 2026. In accordance with Standard 11.5, the committee is asked to note this acceptance.
Quarterly reporting after the audit belongs to management, but the audit should leave behind the metrics the committee will watch and test the first two quarters of them; the site’s table of key risk indicators lists alternatives.
| Metric | Definition | Threshold worth escalating | Source you test |
|---|---|---|---|
| Critical vulnerability median age | Days from first detection to remediation on tier-1 assets | Above 30 days | Scanner export with first-seen dates |
| MFA coverage | Share of remote, administrative and cloud accounts with MFA enforced | Anything below 100% | Identity provider and VPN exports |
| EDR and logging coverage | Share of inventoried assets with an EDR agent and forwarding logs | Below 98%, or any tier-1 gap | EDR console and log source list reconciled to inventory |
| Deprovisioning timeliness | Share of terminations with all access disabled within one business day | Below 98% | HR termination list matched to identity logs |
| Restore test age | Days since the last successful timed restore of each tier-1 system | Above 90 days, or RTO missed | Restore records with timings |
| Alert triage within SLA | Share of critical alerts triaged within contracted minutes | Below 95% | Monitoring provider ticket export |
Disclosure obligations belong in the reporting conversation because the committee will ask. For SEC registrants, the 2023 rules require Form 8-K Item 1.05 within four business days of determining an incident is material, and Regulation S-K Item 106 disclosure in the annual report. As of September 2026 we found no rescission of those rules, but petitions to withdraw or narrow them have been pending since 2025, so confirm the position with counsel before the report states it. The audit question is narrower than the legal one: does a materiality assessment procedure exist, who runs it, and has it been exercised in a tabletop. EU financial entities have been subject to DORA since 17 January 2025, and NIS2 reporting deadlines are measured in hours; the same question applies.
Where cybersecurity audits go wrong, and how to adapt the program
The failures below recur in functions of every size, and most come from treating the security team’s outputs as evidence rather than claims, or scoping around what is convenient to test rather than what an attacker would use.
| Failure | What it looks like | Why it matters | Fix |
|---|---|---|---|
| Auditing the binder | Every test reads “inspected policy”; no export, sample or observation in the file | Design without operation; the committee gets assurance that documents exist | Every matrix row needs an export or an observed event before it is concluded |
| Letting a penetration test stand in for the audit | The report summarizes the tester’s findings and remediation status | The test covered one date and the hosts IT chose; governance, recovery and third parties are untouched | Treat the test as one evidence source for ID.RA and DE.CM; scope from tier-1 assets and attack paths |
| Accepting dashboards as evidence | Coverage and patch percentages quoted from the security tool without reconciliation | The tool measures against its own population; unknown devices are outside the denominator | Reconcile every coverage metric to an independently built inventory; treat tool output as IPE |
| Relying on a SOC 2 opinion page | “Vendor has a clean SOC 2” recorded as the GV.SC conclusion | Exceptions, boundary and user entity controls unread; the customer’s own duties untested | Read the full report, map and test user entity controls, note the period and bridge letter |
| Scoping out the awkward assets | Acquired entities, handhelds, IoT and warehouse systems excluded as “not corporate IT” | Those are the flat-network entry points; a clean opinion on 70% of the estate misleads | Exclusions require verified isolation, not assertion |
| Scoring maturity from interviews, then averaging it | Management’s self-assessment adopted with minor adjustments; “overall maturity 2.6” as the headline | Scores drift upward every year, and the average hides the Level 1 domain that decides whether the company recovers | Evidence only, cumulative levels, caps, and a profile reported with median and minimum |
| Technical findings without business effect | “SMBv1 enabled on 14 servers” as a finding title | The committee cannot rate it and management cannot prioritize it | Name the tier-1 system exposed and the consequence; put the technical detail in the condition |
| Skipping the applicability tracker | Topical Requirement mentioned in the planning memo; no assessment of the 17 requirements retained | Nonconformance with a mandatory element of the IPPF, visible to any external assessor | Complete Appendix C in planning, update at reporting, file with the report |
Adapting the program
In a small company with no security team, replace the eight-domain rubric with CIS IG1 as the criteria and run the engagement in 150 to 200 hours: inventory reconciliation, MFA everywhere, patching, backups with a restore, EDR, and a one-page incident plan tested over a lunch. The Topical Requirement still applies in full; most of its governance requirements will be met by one accountable manager and a quarterly conversation with the owner, provided it is evidenced, and the site’s guide to establishing an internal audit function in a small company covers how that conversation gets minuted.
In a cloud-first organization the perimeter is identity and configuration. Domains 4 and 5 expand to cover tenant security settings, conditional access, workload identities and storage exposure, and the shared responsibility matrix for each provider becomes a scoping document you test line by line. The cloud risk guide gives the tenant-level tests.
Where field or operational technology is material, as with MidState’s handhelds, telematics and warehouse systems, domain 5 gains a segmentation requirement between operational and corporate networks, domain 3 gains a separate inventory for devices that cannot run an agent, and recovery has to consider physical operations and safety. Regulated sectors add criteria rather than change the method: NYDFS Part 500, DORA, PCI DSS for card acceptance, HIPAA for health data. Where artificial intelligence is deployed, Control processes C obliges you to consider AI-related threats; the AI and algorithm audit guide covers the model-side controls. The Third-Party Topical Requirement (effective 15 September 2026) and the Organizational Resilience Topical Requirement (effective 30 April 2027) overlap with domains 8 and 7; plan the next cycle so one engagement can evidence all three. The Topics hub and the Risk Library list the sibling guides for each overlap.
Related guides
- The IIA Topical Requirements — the full family, effective dates and how conformance is evidenced across engagements.
- The Third-Party Topical Requirement — what changes for domain 8 from 15 September 2026.
- Identity and access management audit — the full work program behind the PR.AA row.
- Privileged access audit — admin account inventories, vaulting and session logging tests.
- User access review — testing the quarterly reviews that keep terminated users out of tier-1 applications.
- SOX ITGC scoping — coordinating cyber testing with the ICFR program so access controls are tested once.
- ITGC audit primer for non-IT auditors — the foundations this guide assumes.
- Cloud risk audit guide — tenant-level tests for cloud-first adaptations.
- Audit work program — turning the test matrix into a work program with steps, owners and sign-offs.
- Tools — the free RCM Workbench and mySampler for building the matrix and drawing samples.
Leave a Reply