The IIA’s Cybersecurity Topical Requirement has been mandatory since 5 February 2026 for any assurance engagement that covers cybersecurity, and most internal audit functions have now met it the hard way: a cyber audit that was scoped the way it always had been, and a quality reviewer asking where the seventeen requirements were assessed. This guide is the practical companion. It turns the three domains and seventeen requirements into a working checklist, with what to assess, the evidence that answers each requirement, and the gap most functions find, then adds the crosswalk to NIST CSF 2.0, a conformance documentation template, and a worked assessment at a mid-sized distributor. Requirement wording below follows the IIA’s published requirement and user guide; where this guide adds interpretation, it says so.
In this guide
- What the Topical Requirement is and when it binds
- How to use the workbook
- Domain 1: Governance (four requirements)
- Domain 2: Risk Management (six requirements)
- Domain 3: Control Processes (seven requirements)
- Crosswalk to NIST CSF 2.0 and the test catalogs
- Rating conformance and writing the conclusion
- The conformance documentation template
- Worked example: MidState Beverage’s seventeen-requirement assessment
- The gaps that recur
- Related guides
What the Topical Requirement is and when it binds
Topical Requirements are the mandatory layer the IIA added alongside the Global Internal Audit Standards: for named risk areas, they prescribe the minimum the internal audit function must assess when it provides assurance on that topic. The Cybersecurity Topical Requirement was the first, issued on 5 February 2025 with a twelve-month runway and effective on 5 February 2026. Three more have followed on the same pattern: Third-Party Management, effective 15 September 2026; Organizational Behavior, effective 15 December 2026; and Organizational Resilience, effective 30 April 2027, with Talent Management and Anti-Corruption in consultation. The Topical Requirements overview covers the family; this guide is about the cybersecurity one only.
The binding rule is short. When the function performs an assurance engagement on cybersecurity, it must apply the Topical Requirement in conformance with the Standards: each of the seventeen requirements is assessed, or documented as not applicable with a rationale. For advisory services the requirement is recommended, not mandatory. Where cybersecurity appears inside a broader engagement, the IIA asks the auditor to use professional judgment and a risk-based approach to decide applicability, and the defensible reading is that an engagement whose scope includes cybersecurity governance, risk management or control processes assesses the requirements that scope touches and records the rest as not applicable to that engagement: a warehouse operations audit that tests the handheld fleet’s access controls has touched the third domain, and an ERP user access review has touched its user-access element, even though neither is a cyber audit by name. The user guide’s considerations for implementation are illustrative, not mandatory, and the IIA says so explicitly: they describe what an assessment of each requirement might look at, and the auditor applies professional judgment to decide what is relevant. That is the sentence that makes the workbook approach legitimate: the requirement fixes what must be concluded on; the function chooses how.
Conformance has to be documented, and the user guide is specific about what the file must show: that each requirement was assessed for applicability, with a rationale for excluding any that were not assessed, and evidence retained in line with Standard 14.6 on engagement documentation. The user guide offers an optional documentation tool in its Appendix C; the template later in this guide serves the same purpose in a form that fits an ordinary workpaper set. The requirement’s structure is three domains and seventeen requirements: Governance with four, Risk Management with six, and Control Processes with seven. Each domain is a workbook section below.
How to use the workbook
Each requirement appears with four things: the requirement as the IIA states it, what to assess (the questions the auditor actually answers), example evidence (what a conforming organization can hand over), and the common gap (what a first assessment usually finds). The columns are designed to be copied into the work program. For a full cybersecurity program audit, all seventeen rows become work steps and the user guide’s considerations become the sub-steps the auditor selects from. For a narrower engagement, the auditor marks each row as in scope, out of scope with rationale, or covered by another engagement with a cross-reference, and the marked-up workbook is the applicability record the user guide asks for.
Two rules keep the workbook honest. The first is that a requirement is assessed against evidence of operation, not against the existence of a document: a cybersecurity strategy that exists is not a strategy that is periodically updated, and a policy that exists is not one that strengthens the control environment, which is the test the requirement’s own wording sets. The second is that the requirement is written at the level of the organization’s processes, so the assessment conclusion is about whether the process is established and working, and the detailed control testing that sits underneath, whether the patching SLA is met or the terminated users are disabled, is the evidence for that conclusion rather than the conclusion itself. The cybersecurity program audit guide carries the test-level detail and the NIST CSF 2.0 test matrix; this workbook is the layer above it.
Domain 1: Governance (four requirements)
Governance is where first assessments most often overstate conformance, because the artifacts exist. The test in every row is whether the artifact drives behavior: whether the strategy is the thing the budget follows, whether the policies are the thing the configuration matches, whether the named roles are filled by people who can do the job, and whether the stakeholders who are supposed to act on threats have acted on one.
| Ref | Requirement (IIA wording) | What to assess | Example evidence | Common gap |
|---|---|---|---|---|
| G-A | A formal cybersecurity strategy and objectives are established and periodically updated. | Is there a strategy approved at a level that can fund it; does it state measurable objectives; has it been refreshed on a defined cycle or after a material change; does the budget and project portfolio trace to it? | Approved strategy with version history; objectives with owners and metrics; board or committee minutes approving the refresh; budget lines mapped to strategic initiatives | A strategy document exists but was written once, for an insurer or a customer questionnaire, and the security roadmap the team actually works from is a different document nobody approved |
| G-B | Policies and procedures related to cybersecurity are established, periodically updated, and strengthen the control environment. | Policy set coverage against the organization’s risk profile; review dates within the stated cycle; evidence the policies are enforced in configuration and process, not just published; exception handling | Policy register with owners and review dates; sampled policies traced to enforcing controls (password policy to directory settings, acceptable use to endpoint controls); exception log with approvals | Policies reviewed by re-dating the cover page; requirements in policy (encryption, MFA, logging) that the environment does not meet and nobody has recorded as exceptions |
| G-C | Roles and responsibilities that support cybersecurity objectives are established, and a process exists to periodically assess the knowledge, skills, and abilities of those filling those roles. | Are accountable roles defined for governance, operations and response; are they filled; is there a competency framework or job profile; is there evidence of periodic assessment and development for those in the roles? | RACI or role charter; organization chart with vacancies; competency assessments, certifications, training records and succession or coverage plans for key roles | Roles are defined; the skills assessment does not exist, or the whole function’s cybersecurity capability sits in one person with no assessed backup |
| G-D | Relevant stakeholders are engaged to discuss and act on existing vulnerabilities and emerging threats in the cybersecurity environment. | Which forum brings security, IT, business, legal and risk together; how often; whether threat and vulnerability information reaches it; whether decisions are made and tracked to closure | Committee charter and attendance; agendas and minutes showing vulnerability and threat items; decision log with actions and closure dates; board reporting on cyber | The forum exists but is a status update; nothing in the minutes shows a decision, a dissent or a funded action |
Domain 2: Risk Management (six requirements)
The Risk Management domain asks whether cyber risk is managed as risk, with identification, analysis, treatment and monitoring, and whether that management reaches the whole organization rather than the IT department. Requirement F, on incident response and recovery, is the one most functions test in depth elsewhere; the incident response audit guide carries the full program and this row records the conclusion.
| Ref | Requirement (IIA wording) | What to assess | Example evidence | Common gap |
|---|---|---|---|---|
| R-A | The organization’s risk assessment and risk management processes include the identification, analysis, mitigation, and monitoring of cybersecurity threats. | Is there a cyber risk assessment with a defined method; does it connect threats to assets and controls; are treatments decided and tracked; is residual risk monitored and re-assessed on a cycle | Risk assessment methodology; current cyber risk register with inherent and residual ratings, owners and treatment plans; evidence of re-assessment after incidents or changes | A vulnerability scan report stands in for a risk assessment; the ERM register carries one line for cyber with no analysis beneath it |
| R-B | Cybersecurity risk management is conducted across the organization, which may include the following areas: information technology, enterprise risk management, human resources, legal, compliance, operations, supply chain, accounting, finance, and others. | Which functions participate in identifying and owning cyber risk; whether business-owned systems, operational technology, vendors and acquisitions are in the assessment’s population | Risk register entries owned outside IT; ERM integration; HR, legal, supply chain and finance involvement documented in the assessment and its forums | Cyber risk is assessed for the IT estate only; acquired units, plant systems, shadow SaaS and third parties are outside the population |
| R-C | Accountability and responsibility for cybersecurity risk management is established and an individual or team is identified to periodically monitor and report. | Who is accountable for cyber risk (distinct from who operates controls); what they monitor; what they report, to whom, how often | Charter or job description naming the accountable role; periodic risk reports to management and the board; KRIs with thresholds | The CISO or IT director both operates the controls and reports on the risk, with no second-line or independent challenge and no defined reporting cadence |
| R-D | A process is established to quickly escalate any cybersecurity risk that rises to an unacceptable level. | Is there a defined tolerance or threshold; who escalates, to whom, within what time; has the process ever been used, and what happened | Risk appetite or tolerance statements for cyber; escalation procedure with thresholds and timeframes; examples of escalations and the decisions taken | Escalation exists only for incidents, not for risks; a critical vulnerability aging past the SLA has no route to anyone who can decide to accept or fund it |
| R-E | A process is established to communicate cybersecurity risk awareness to management and employees, and for the periodic review by management. | Awareness program design and coverage (all populations, including contractors and front-line staff); completion and effectiveness measures; management review of results and adjustments made | Training curriculum and completion rates by population; phishing simulation results and trend; management review minutes; changes made in response | Completion is measured, effectiveness is not; whole populations (drivers, plant staff, contractors, executives) sit outside the program |
| R-F | The organization has implemented a cybersecurity incident response and recovery process that includes detection, containment, recovery, and post-incident analysis. | Plan currency; playbooks for the scenarios that matter; detection coverage; exercise history; recovery capability demonstrated; post-incident reviews producing change | Incident response plan with version history; playbooks; exercise reports; incident log with timelines; post-incident review reports and tracked actions; restore test records | A plan dated years ago, never exercised, with recovery assumed from backups that have not been restored end to end |
Domain 3: Control Processes (seven requirements)
The Control Processes domain is where the cyber audit’s test work lives, and where the workbook needs the most discipline, because each requirement is a process statement that sits above dozens of technical controls. The conclusion on each row is whether the process is established and operating; the technical testing that supports the conclusion is drawn from the catalog the function already uses, whether NIST CSF 2.0, ISO/IEC 27001:2022 or CIS Controls, and the crosswalk in the next section shows where each row lands.
| Ref | Requirement (IIA wording) | What to assess | Example evidence | Common gap |
|---|---|---|---|---|
| C-A | A process is established that ensures both internal controls and vendor-based controls are in place to protect the confidentiality, integrity, and availability. | How the organization decides which controls it needs (a control framework mapped to risk); how it knows the controls exist and operate, internally and at vendors; how vendor controls are evidenced (SOC 2 reports, assessments, contractual rights) | Control framework and mapping to risks; control monitoring or testing results; vendor inventory with tiering; SOC 2 reports reviewed with exceptions and complementary user entity controls tracked | Internal controls are tracked; vendor controls are assumed from a questionnaire nobody read, and the vendor inventory is incomplete (see the SOC 2 review guide) |
| C-B | A talent management process is established and periodically reviewed for cybersecurity operations that includes training opportunities. | Staffing model for security operations against workload; recruitment and retention; role-specific training and certification paths; review of the model when the environment changes | Staffing plan and vacancy history; training plans and completions for security staff; managed service contracts covering gaps; periodic review of the operating model | Security operations are a single individual or an unmanaged MSSP relationship; no training budget line; no review since the last reorganization |
| C-C | A process is established to continuously monitor and report emerging cybersecurity threats and vulnerabilities. | Threat intelligence sources and how they are actioned; vulnerability scanning coverage, cadence and SLA performance; reporting of aging vulnerabilities to someone who can act | Scanning coverage reconciled to the asset inventory; SLA metrics by severity with aging; threat advisories logged with actions; exception and risk acceptance records for unpatchable items | Scanning runs, the report is not read, and critical findings age for months with no risk acceptance (see the patch and vulnerability management guide) |
| C-D | Cybersecurity is included in the life cycle management of all IT assets, including hardware, software, and vendor services. | Asset inventory completeness (hardware, software, cloud, vendor services); security requirements at acquisition, deployment, change and disposal; end-of-support tracking | Inventory reconciled to independent sources (directory, EDR, DHCP, procurement); onboarding and decommissioning checklists with security steps; end-of-support register with plans | The inventory is a fraction of what the network sees; unsupported operating systems run production systems on extended updates with no exit plan |
| C-E | Processes are established to promote cybersecurity including configuration, end-user device administration, encryption, patching, user-access management, and monitoring. | Each named process in turn: hardening baselines and drift; device management enrollment and compliance; encryption at rest and in transit; patching SLAs; joiner-mover-leaver and privileged access; logging coverage and alert handling | Baseline standards and compliance scans; MDM enrollment vs device population; encryption status reports; patch compliance; access review records; log source inventory vs systems in scope; alert triage metrics | Each process exists for the core estate and stops at the edges: acquired units, handhelds, service accounts, application logs outside central monitoring (see the IAM audit guide and privileged access guide) |
| C-F | Network-related controls are established, such as network access controls and segmentation; the use and placement of firewalls. | Network architecture against the risk profile; segmentation between user, server, plant, guest and acquired networks; firewall rule governance and review; network access control for unmanaged devices; remote access security including MFA | Network diagrams reconciled to configuration; segmentation tests; firewall rule review records with owners and expiry; NAC policy and enforcement evidence; VPN and remote access configuration with MFA enforcement reports | Flat networks joined by site-to-site VPNs after acquisitions; depot or guest Wi-Fi on the corporate VLAN; firewall rules never reviewed; MFA enforced for users but not for vendor and service accounts |
| C-G | Endpoint communication security controls are established regarding services such as email, internet browsers, videoconferencing, messaging, social media, cloud, and file-sharing protocols. | Email security (authentication, filtering, phishing defenses); browser and web controls; approved collaboration and file-sharing services and blocking of unapproved ones; cloud access governance; data loss controls on outbound channels | Email security configuration and reports (SPF, DKIM, DMARC, filtering statistics); web filtering policy and logs; approved application list and cloud access security reports; DLP policies and incident reports | Email is well defended; personal cloud storage, messaging apps and browser extensions are uncontrolled and nobody has measured what leaves through them |
Crosswalk to NIST CSF 2.0 and the test catalogs
The Topical Requirement sets what must be concluded on; it does not supply the test catalog, and it was not written to. The user guide’s considerations point toward the same practices any mature catalog names, so the efficient approach is to keep testing against the framework the organization already uses and map the results upward. NIST CSF 2.0 (February 2024) is the natural anchor because its Govern function lines up with the requirement’s Governance and Risk Management domains almost row for row, and its Protect, Detect, Respond and Recover functions cover the Control Processes domain. The crosswalk below is this guide’s mapping, not an IIA publication; it is offered as a starting point to adapt. The cybersecurity program audit guide carries the full 22-category CSF test matrix that supplies the tests behind each row.
| Topical Requirement row | Primary CSF 2.0 categories | ISO/IEC 27001:2022 Annex A anchors | Typical test-level sources |
|---|---|---|---|
| G-A strategy and objectives | GV.OC Organizational Context; GV.RM Risk Management Strategy | Clauses 4-6 (context, leadership, planning) | Strategy, budget, board materials |
| G-B policies and procedures | GV.PO Policy | A.5.1 policies for information security; A.5.36 compliance with policies | Policy register, configuration evidence, exception log |
| G-C roles and skills | GV.RR Roles, Responsibilities, and Authorities | A.5.2 roles and responsibilities; A.6.3 awareness and training | RACI, competency assessments, training records |
| G-D stakeholder engagement | GV.OV Oversight; GV.RM | A.5.5 and A.5.6 contact with authorities and special interest groups | Committee minutes, decision logs |
| R-A to R-D risk process, breadth, accountability, escalation | GV.RM; ID.RA Risk Assessment; GV.RR; GV.OV | Clause 6.1 risk assessment and treatment; A.5.7 threat intelligence | Risk register, methodology, KRIs, escalation records |
| R-E awareness | PR.AT Awareness and Training | A.6.3 | Training and phishing data by population |
| R-F incident response and recovery | DE.AE, DE.CM; RS.MA, RS.AN, RS.CO, RS.MI; RC.RP, RC.CO | A.5.24 to A.5.28 incident management; A.5.29 and A.5.30 continuity and ICT readiness | IR plan, exercises, restore tests, incident log |
| C-A internal and vendor controls | GV.SC Supply Chain Risk Management; ID.IM Improvement | A.5.19 to A.5.23 supplier relationships and cloud services | Control framework, SOC 2 reviews, vendor inventory |
| C-B talent management | GV.RR; PR.AT | A.6.1 to A.6.8 people controls | Staffing model, training plans, MSSP contracts |
| C-C threat and vulnerability monitoring | ID.RA; DE.CM Continuous Monitoring | A.5.7 threat intelligence; A.8.8 management of technical vulnerabilities | Scan coverage, SLA aging, advisories |
| C-D asset life cycle | ID.AM Asset Management; PR.PS Platform Security | A.5.9 to A.5.11 assets; A.8.19 software installation | Inventory reconciliation, end-of-support register |
| C-E configuration, devices, encryption, patching, access, monitoring | PR.PS; PR.AA Identity Management, Authentication, and Access Control; PR.DS Data Security; DE.CM | A.8.9 configuration; A.8.1 endpoint devices; A.8.24 cryptography; A.8.8; A.5.15 to A.5.18 access; A.8.15 and A.8.16 logging and monitoring | Baselines, MDM, encryption reports, patch compliance, access reviews, log inventory |
| C-F network controls | PR.IR Technology Infrastructure Resilience; PR.AA | A.8.20 to A.8.22 networks, network services, segregation | Architecture, segmentation tests, firewall reviews, remote access MFA |
| C-G endpoint communication | PR.DS; PR.PS; DE.CM | A.5.14 information transfer; A.8.12 data leakage prevention; A.8.23 web filtering | Email security, web filtering, approved services, DLP |
Rating conformance and writing the conclusion
The Topical Requirement does not prescribe a rating scale, and the temptation is to reuse the engagement’s maturity rubric for the seventeen rows. Resist it. A maturity score answers a different question, how good the practice is, while the requirement asks a narrower one, whether the process the requirement names is established and operating. The scale that works has four values: established and operating, established with material gaps, not established, and not applicable to this engagement with a rationale. Each row gets one value, a one-sentence basis, and a cross-reference to the workpaper where the evidence sits. The maturity rating, if the engagement uses one, is reported separately and can be higher or lower than the conformance picture: an organization can have every process established and still be immature in how it runs them, and a very capable security team can operate without the governance processes the first domain requires.
Three drafting rules for the basis sentence. It names the evidence, not the opinion: “the strategy was approved in March 2026 and the FY27 budget traces to its four initiatives” rather than “strategy is adequate”. It records the gap in the requirement’s own terms, so a reviewer can see which clause failed: a policy set that exists but is not periodically updated fails the second clause of G-B, not the whole requirement. And it states what the auditor did not do, where a row was concluded on the basis of another engagement’s work under Standard 9.5 reliance, with the reference, so the file shows the assessment was made even where the testing was not repeated. The engagement conclusion then says, in one paragraph, how many rows fall in each value and which gaps drive the overall rating, and the final report carries the seventeen-row summary as an appendix, which is what audit committee members increasingly ask for by name now that the requirement is public.
The conformance documentation template
One record per engagement that touches cybersecurity, filed with the planning memo and completed at reporting. It satisfies the user guide’s expectation that each requirement is assessed for applicability with a rationale for exclusions, and it is the document a quality assessor will ask for first.
Cybersecurity Topical Requirement conformance record
1. Engagement. Engagement name and reference; type (assurance or advisory); period; lead auditor; date the record was opened and closed.
2. Applicability decision. Whether the engagement provides assurance on cybersecurity or on a scope that includes cybersecurity governance, risk management or control processes; the basis; for advisory engagements, whether the requirement was applied voluntarily and to what extent.
3. Scope of application. Which of the seventeen requirements are in scope for this engagement; for each excluded requirement, the rationale (outside the engagement’s objectives, covered by a named engagement with a cross-reference, or not applicable to the organization with the reason).
4. Criteria. The requirement text as the evaluation criteria under Standard 13.4; the framework used for test-level criteria (for example NIST CSF 2.0 or ISO/IEC 27001:2022) and the crosswalk applied.
5. Assessment table. For each in-scope requirement: reference; conclusion (established and operating / established with material gaps / not established / not applicable); basis sentence naming the evidence; workpaper reference; reliance on other work with the engagement reference and the Standard 9.5 evaluation; related finding references.
6. Overall conclusion. Count of requirements by conclusion; the gaps that drive the engagement rating; whether any gap was remediated during fieldwork and re-tested, with dates.
7. Reporting. Where the seventeen-row summary appears in the final communication; date reported to senior management and the board or audit committee.
8. Documentation and retention. Confirmation that evidence supporting each conclusion is retained per Standard 14.6 and the function’s retention policy; reviewer sign-off with date.
Worked example: MidState Beverage’s seventeen-requirement assessment
MidState Beverage is the illustrative distributor used across this site: three states, 12 depots, 300 routes, roughly $221 million of revenue, a 2013 ERP, two acquired distributors still on their own systems and a six-person internal audit function. Its first cybersecurity program audit ran from May to June 2026 after the audit committee chair asked for one; the program audit guide tells that engagement’s full story, with its 540-hour budget, its eight-domain maturity rubric and its eleven findings. What follows is the Topical Requirement layer of the same engagement: how the seventeen rows were concluded on, from the same evidence.
Applicability was not in doubt. The engagement was assurance, cybersecurity was its subject, and the requirement had been effective for three months, so all seventeen rows applied and none were excluded. The CAE recorded one reliance decision: the ERP user access engagement running in parallel supplied the termination testing (40 sampled FY26 terminations from a population of 312, 12 with active ERP accounts), evaluated under Standard 9.5 and cross-referenced rather than repeated. The conclusions used the four-value scale, and the basis sentences below are condensed from the conformance record.
| Ref | Conclusion | Basis (condensed) |
|---|---|---|
| G-A | Established with material gaps | A security roadmap existed, written by the IT director for the January 2026 insurance renewal; not approved above the CFO, no objectives with measures, never refreshed |
| G-B | Established with material gaps | Policy set dated 2021 to 2022; the remote access policy required MFA on all remote access, and the VPN did not enforce it for four vendor and 27 service accounts; no exception record |
| G-C | Established with material gaps | Roles defined in job descriptions; the IT director is the only person in a security role, no skills assessment exists and no backup is named |
| G-D | Not established | No forum brings IT, operations, finance and legal together on threats; the audit itself was the first time the committee discussed a specific vulnerability |
| R-A | Not established | No cyber risk assessment; the ERM register carried no cybersecurity entry; the vulnerability scan report was the closest artifact |
| R-B | Not established | Risk identification confined to the IT department; the two acquired distributors, the handheld fleet and the drivers were outside any assessment |
| R-C | Established with material gaps | The IT director both operates the controls and reports on them, monthly to the CFO, with no independent challenge and no defined risk reporting |
| R-D | Not established | 212 open critical vulnerabilities with a median age of 71 days against a 30-day SLA, and no route by which an aging critical item reaches anyone who can accept or fund the risk |
| R-E | Established with material gaps | Training completion 71%; phishing simulation to 610 office users produced 84 clicks; the 300 drivers were outside the program entirely; no management review of results |
| R-F | Established with material gaps | Incident plan dated 2022, never exercised, no playbooks; the last full ERP restore was 26 months old at the start of fieldwork; the 20 June restore succeeded in 31 hours against a 24-hour objective |
| C-A | Established with material gaps | Internal controls tracked informally; the managed detection provider’s SLA was evidenced (22 of 25 sampled critical alerts within 15 minutes); no vendor inventory, and the ERP vendor’s credential was shared by four of its engineers until replaced in June |
| C-B | Established with material gaps | Security operations rest on the managed provider plus one internal role; no training plan or budget line for security skills; no review of the model since the acquisitions |
| C-C | Established with material gaps | Scanning runs and reports are produced; 23 of the 38 criticals older than 180 days sat on the ERP application server on an operating system out of support since 2023, with no risk acceptance |
| C-D | Established with material gaps | Configuration database of 712 devices against 803 directory objects, 732 EDR agents and 1,118 DHCP addresses left 289 devices with no owner; extended updates for the ERP server lapse in October 2026 with no plan |
| C-E | Established with material gaps | EDR on 92 servers and 640 endpoints; 194 of 380 handhelds enrolled in device management; 1,912 local ERP accounts including 214 terminated; 19 domain administrator accounts for 11 staff, six shared; ERP and handheld logs outside central monitoring |
| C-F | Established with material gaps | Acquired distributors (140 endpoints, no EDR) joined by site-to-site VPN without segmentation; depot Wi-Fi on the corporate VLAN; VPN MFA gaps closed by 12 June and re-tested |
| C-G | Established and operating | Email MFA enforced for 98% of accounts with filtering and managed detection over mail; web filtering and approved collaboration services in place; the remaining exposure sits in awareness (R-E), not in the channel controls |
The tally was one requirement established and operating, twelve established with material gaps, and four not established, all four in the governance and risk domains. That distribution is the useful output, because it tells the committee something the eleven findings do not: MidState’s technical controls were partial but present, and its governance and risk management of cyber were absent, which is why a competent IT team had spent years patching around an unsupported server that nobody with budget authority had been asked to decide about. The two-page appendix with the seventeen rows went to the committee on 12 August 2026 alongside the findings, and the CAE’s cover note made the connection explicit: the four not-established rows were the root cause of most of the six High findings, and the remediation plan was sequenced accordingly, with the risk assessment, the forum and the escalation route before the technical items.
Two decisions in the record are worth copying. The June remediation of the VPN MFA gap and the restore test were re-tested during fieldwork and reflected in the basis sentences, but the conclusions were kept at the values the evidence supported at the end of fieldwork rather than upgraded on the strength of promised work: G-B stayed at material gaps because the policy exception process still did not exist, even though the specific MFA gap had closed. And R-F was concluded as established with material gaps rather than not established, because the detection and containment elements operated through the managed provider even though recovery and post-incident analysis did not; the basis sentence names which of the four named elements failed, which is what a reviewer needs to agree or disagree with the call.
The gaps that recur
Across first assessments the same six gaps appear, and each maps to a requirement. The organization has no cyber risk assessment distinct from its vulnerability scan (R-A). Cyber risk is managed for the IT estate and not for the organization’s acquired, operational, mobile and third-party edges (R-B and C-D). Nobody is accountable for reporting cyber risk who is independent of operating the controls (R-C). Aging vulnerabilities and unsupported systems have no escalation route to a risk decision (R-D and C-C). Awareness is measured by completion and excludes whole populations (R-E). And the incident plan exists but has not been exercised, with recovery never demonstrated end to end (R-F). The pattern is that Control Processes rows are usually “established with material gaps” while Governance and Risk Management rows are more often “not established”, and reporting the pattern, not just the findings, is what the requirement adds to a cyber audit that would otherwise have been done the same way.
Three mistakes in applying the requirement itself. Treating the user guide’s considerations as a mandatory checklist, which produces a 200-step program and a conclusion nobody can find; the considerations are illustrative and the auditor selects. Rating the seventeen rows on the maturity scale, which conflates capability with conformance. And documenting applicability only for the rows that were assessed, leaving no rationale for the rows that were not, which is the specific omission a quality assessment will write up. The GIAS Domain V guide covers the engagement documentation standard the record has to satisfy, and the IT audit plan guide shows where the Topical Requirement’s coverage obligations sit in the annual plan.
Related guides
- Auditing cybersecurity programs: the complete program audit
- The IIA Topical Requirements: what they are and when they bind
- The Third-Party Topical Requirement
- How to audit incident response
- How to audit patch and vulnerability management
- How to audit backup and recovery
- How to audit Active Directory and Entra ID
- How to audit identity and access management
- IT general controls: the complete primer
- How to build the IT audit plan
- The Global Internal Audit Standards hub
Leave a Reply