Topical Requirements are the newest mandatory element of The IIA’s International Professional Practices Framework, and the first one that tells internal auditors what to cover rather than how to behave. The Global Internal Audit Standards say how a function must be governed, managed and run; a Topical Requirement says that when the function gives assurance on a named subject, its work must assess a specified set of governance, risk management and control processes, and must document why any of them was left out. The first, on cybersecurity, took effect on 5 February 2026. The second, on third-party management, takes effect on 15 September 2026. Two more, on organizational behavior and organizational resilience, follow in December 2026 and April 2027, and the pipeline behind them is public.
This guide explains what a Topical Requirement is and where it sits in the framework, lists every requirement issued or announced with its dates and structure, walks through the anatomy of one (the three domains, the lettered requirements, the user guide and the applicability rules), sets out exactly when a requirement binds and what conformance has to look like on the file, shows how the requirements interact with the Standards a function already conforms to, answers the objections practitioners raise most, and ends with a worked example of a distributor’s audit function mapping its plan against the requirement calendar. Companion guides cover each requirement in depth: the Cybersecurity Topical Requirement workbook and the Third-Party Topical Requirement guide.
This guide was rewritten in September 2026 from a shorter version published in August 2026. Dates, requirement counts and applicability rules were checked against The IIA’s published Topical Requirement documents and pages in September 2026; requirement wording is paraphrased, and the practitioner guidance is ours.
In this guide
- What a Topical Requirement is, and where it sits in the 2024 IPPF
- Every Topical Requirement issued or announced: dates and structure
- Anatomy of a Topical Requirement: domains, lettered requirements, user guide
- When a requirement binds: the three triggers and the assurance line
- What conformance looks like on the file
- How Topical Requirements interact with the Standards you already follow
- The applicability and conformance record: a template
- Reading a requirement well: five habits
- Building the method once: an eight-step plan for any function
- The objections, and the straight answers
- Worked example: mapping a plan against the requirement calendar
- Related guides
What a Topical Requirement is, and where it sits in the 2024 IPPF
The 2024 International Professional Practices Framework has three parts. The Global Internal Audit Standards are mandatory and describe the function, its governance and its engagements; the Global Internal Audit Standards guide covers them. Topical Requirements are mandatory when they apply, and each one describes the minimum scope of an assurance engagement on a specific risk topic. Global Guidance is recommended. The Standards themselves anchor the second element: conformance with the Standards (Standard 4.1) extends to any Topical Requirement that applies, and each requirement states that internal auditors must apply it in conformance with the Standards.
The reason The IIA added the layer is consistency. Under the 2017 framework, two functions auditing the same subject could produce engagements of entirely different scope and both call the result assurance; a board comparing its cybersecurity audit to a peer’s had no way to know whether the same things had been examined. A Topical Requirement fixes the floor: it lists the governance, risk management and control processes that an assurance engagement on that topic must assess (or consciously and documentably exclude), so that the word assurance means something comparable across organisations, and so that external quality assessors have something to test. The IIA’s own framing is that conformance will improve the consistency, quality and reliability of internal audit services on the topic, and that it will be evaluated during quality assessments. That last clause is the one with teeth.
| IPPF element (2024) | Status | What it governs | Where to read it |
|---|---|---|---|
| Global Internal Audit Standards | Mandatory | Purpose, ethics, governance, management and performance of the function; effective 9 January 2025 | The Global Internal Audit Standards guide; the IPPF to GIAS mapping table for the crosswalk from the old numbering |
| Topical Requirements | Mandatory when applicable (assurance); recommended for advisory | Minimum assessment scope for assurance on a named topic; applicability assessed and documented per engagement | This guide; the per-requirement guides |
| Global Guidance | Recommended | Implementation and practice guidance, GTAGs and other material being reissued against the 2024 numbering | The IIA’s guidance library |
Every Topical Requirement issued or announced: dates and structure
The IIA issues each requirement about a year before it takes effect, with a user guide alongside, after a public comment period on a draft. The table is the calendar as it stands in September 2026; the two consultation-stage topics may change name or timing before issue, and this guide will be updated when they are published.
| Topical Requirement | Issued | Effective | Structure | Status in September 2026 |
|---|---|---|---|---|
| Cybersecurity | 5 February 2025 | 5 February 2026 | 17 requirements: Governance A to D, Risk Management A to F, Control Processes A to G; user guide with considerations and evidence examples | In force. Every cyber assurance engagement planned or requested after 5 February 2026 must apply it. |
| Third-Party | 15 September 2025 | 15 September 2026 | 17 requirements: Governance A to D, Risk Management A to D, Control Processes A to I; user guide | In force from 15 September 2026; applies to third-party, vendor, supplier and outsourcing assurance engagements from that date. |
| Organizational Behavior (culture) | 15 December 2025 | 15 December 2026 | Governance, risk management and control processes for organizational behavior and culture; user guide | Issued; functions planning culture engagements in 2027 should build to it now (see the corporate culture audit method). |
| Organizational Resilience | 30 April 2026 | 30 April 2027 | Governance, risk management and control processes for resilience; user guide | Issued; effective for resilience and continuity assurance from April 2027 (see the business continuity and resilience audit guide). |
| Talent Management | Consultation expected October 2026 | To be set at issue (typically twelve months after) | Draft not yet public | Announced in The IIA’s pipeline. |
| Anti-Corruption | Expected Q4 2026 | To be set at issue | Draft not yet public | Announced in The IIA’s pipeline. |
Two patterns are worth noticing. The topics are the ones boards ask about most and where the profession’s assurance has been least comparable: cyber, third parties, culture, resilience, people, corruption. And the structure is identical every time: three domains, lettered requirements, a user guide with considerations and evidence examples, and the same applicability rules. A function that builds its method for the first requirement has built it for all of them.
Anatomy of a Topical Requirement: domains, lettered requirements, user guide
Each requirement is a short document, six or seven pages, in a fixed shape. An introduction restates the purpose of Topical Requirements and the applicability rules. A definitions section fixes the topic’s terms (the third-party requirement, for instance, defines a third party as an external individual, group or entity with which the organisation establishes a business relationship to obtain products or services, formalised by contract or otherwise, and extends the term to the third party’s own suppliers where relevant). Then come the requirements themselves, grouped into three domains that mirror the way the Standards think about any subject: Governance (does the board and management set direction, roles, policies and reporting for the topic), Risk Management (are the topic’s risks identified, assessed, prioritised, responded to and escalated) and Control Processes (do the operational controls that manage the topic exist and work). Within each domain the requirements are lettered, and each is a single statement of what the organisation’s process should include, written in the present tense as a description of a well-run state.
The user guide is the longer companion document, and it is where the practical content lives: for each lettered requirement, considerations for what the assessment might cover, examples of evidence, and, in an appendix, an optional tool for recording the applicability assessment and the conclusions. The user guide is not itself mandatory; the requirement statements are. A function that reads only the requirement will know what to assess; a function that reads the user guide will know how the assessors expect it to be evidenced. The table shows the shape using the third-party requirement, which takes effect this month.
| Domain | Third-Party Topical Requirement (effective 15 September 2026), paraphrased | What an engagement has to examine |
|---|---|---|
| Governance (A to D) | A formal, periodically reviewed approach to deciding whether to contract with a third party; policies and procedures across the third-party life cycle, aligned to regulation and kept current; defined roles for who selects, directs, manages, communicates with and monitors third parties, with the competence to do so; stakeholder communication protocols with timely reporting on performance, risk and compliance of prioritised third parties | The make-or-buy decision framework, the TPRM policy, the RACI and the reporting to management and the board |
| Risk Management (A to D) | Standardised, comprehensive third-party risk processes with defined roles that address the key risk types; risks identified and assessed across the life cycle and used to rank and prioritise third parties, including downstream parties; risk responses commensurate with ranking, implemented and monitored; processes to manage and escalate issues arising from third parties with accountability for outcomes | The inherent and residual risk assessment, the tiering, the risk responses per tier, and issue escalation |
| Control Processes (A to I) | Due diligence with a documented business case; contracting and approval per policy with cross-functional collaboration; final contracts reviewed by all relevant stakeholders including legal and compliance, signed by authorised individuals and stored securely; an accurate, complete and current inventory of all third-party relationships; documented onboarding; ongoing monitoring of performance against contract and of the third party’s own risk; corrective-action and incident-escalation protocols; monitoring of expiration and renewal dates; a formal offboarding plan covering termination, data and access | The life-cycle controls from selection to exit, and the inventory that everything else depends on |
When a requirement binds: the three triggers and the assurance line
A Topical Requirement applies when its topic is the subject of an engagement in the internal audit plan, when the topic is identified while performing an engagement, or when the topic is the subject of a requested engagement that was not on the original plan. Those three triggers are written into every requirement, and the second one is the one functions underestimate: an operations audit that finds the process depends on an outsourced provider has identified the third-party topic, and the requirement’s applicability has to be assessed for that part of the work. Conformance is mandatory for assurance services and recommended for advisory services, which makes the classification of the engagement (see the Domain V guide on Standards 13.1 to 13.4) a decision with mandatory consequences.
The effective date is a start line, not a retrospective test. Engagements completed before the date are not measured against the requirement; engagements planned for after it are. The grey zone is the engagement in progress across the date, and the reading most functions are adopting is that an engagement whose planning is done after the effective date should conform, and one whose fieldwork is substantially complete before it need not, provided the file says so. The applicability decision, in either direction, is itself something the requirement says must be documented.
| Situation | Does the requirement apply? | What the file needs |
|---|---|---|
| Assurance engagement on the topic, planned after the effective date | Yes, in full | Applicability assessment for every lettered requirement; rationale for exclusions; evidence per requirement |
| Assurance engagement on part of the topic (one system, one vendor category, one region) | Yes, to the parts in scope; exclusions documented | The scope statement and the rationale for each excluded requirement, tied to the engagement objective |
| Advisory engagement on the topic | Recommended, not mandatory | A note of the decision; the requirement is a useful criteria set even when not binding |
| Topic surfaces inside another engagement | Yes, for the part of the work that gives assurance on the topic | Applicability assessment for the relevant requirements; a decision to scope the topic out with rationale, if that is what happens |
| Engagement in progress at the effective date | Depends on the stage; document the decision | A dated note of where the engagement stood and whether the requirement was applied |
| Co-sourced or outsourced engagement on the topic | Yes; the CAE remains responsible for conformance | The provider’s work mapped to the requirements; the CAE’s review |
| Organisation has no program for the topic at all | Yes; absence is the finding | Each requirement assessed and concluded as not established, which is a reportable result, not a reason to exclude |
What conformance looks like on the file
Conformance has three parts, and the requirement spells out two of them. First, evidence that each requirement was assessed for applicability must be documented and retained; the assessment is per lettered requirement, not per domain. Second, where requirements are excluded, a rationale must be documented and retained; “out of scope” is not a rationale, “the engagement objective is limited to the onboarding stage, so the offboarding requirement (Control Processes I) is excluded and will be covered in the FY28 engagement” is. Third, and implied by Standard 14.6 on engagement documentation, the work performed against each applicable requirement and the conclusion reached must be evidenced in the file to the same standard as any other test. The user guide’s appendix tool is one way to lay this out; the template later in this guide is another.
Conformance is tested at two levels. Engagement supervision and the internal quality assessment under Standards 12.3 and 12.1 should check each in-scope engagement for the applicability record and the evidence. The external quality assessment under Standard 8.4 will test the function’s method and a sample of engagements, and The IIA has said in each requirement that conformance will be evaluated during quality assessments. A function that has a written procedure for applying Topical Requirements, an applicability record on every in-scope file, and a conclusion per requirement in the report is conformant; a function that has read the requirement and audited the topic the way it always did is not, however good the audit.
How Topical Requirements interact with the Standards you already follow
The requirements do not sit beside the Standards; they plug into them at specific points, and a function that knows where can absorb each new requirement as a methodology update rather than as a project. The table maps the touchpoints.
| Standard | What the Topical Requirement adds | Methodology change |
|---|---|---|
| 9.3 Methodologies | A documented procedure for identifying applicable requirements, recording applicability and evidencing conformance | A section in the manual; a checklist in the planning template |
| 9.4 Internal Audit Plan | Engagements on the topic must be scoped and resourced to cover the requirements; the plan should flag them | A column in the plan: applicable Topical Requirement(s), and hours adjusted accordingly |
| 13.2 Engagement Risk Assessment and 13.3 Objectives and Scope | The three domains are a ready-made structure for the engagement risk assessment; exclusions must tie to the objective | Scope statements written against the lettered requirements |
| 13.4 Evaluation Criteria | The requirement statements are criteria; the user guide’s considerations refine them | Criteria column populated from the requirement, with the organisation’s own policy layered on top |
| 13.6 Work Program | Procedures mapped to each applicable requirement | A requirement reference on every work step |
| 14.6 Engagement Documentation | The applicability record and per-requirement evidence retained | The template below, filed with the planning memo |
| 15.1 Final Engagement Communication | A conclusion per domain, and ideally per requirement, so the reader sees coverage | A coverage table in the report; exclusions stated |
| 12.1 Internal Quality Assessment and 8.4 External Quality Assessment | Conformance with applicable requirements is a QAIP test and an EQA test | A question in the engagement QC checklist; a line in the annual self-assessment (see the QAIP self-assessment template) |
The applicability and conformance record: a template
One record per engagement, one row per lettered requirement, prepared at planning, updated at reporting and filed with the planning memo. It does the two things the requirement demands (applicability assessed, exclusions justified) and the one thing the Standards demand (evidence and conclusion per requirement). The four-value scale is the one used in the cybersecurity workbook so that results are comparable across topics and years.
Topical Requirement applicability and conformance record
Header: Engagement name and reference | Topical Requirement and version (issued date) | Engagement type (assurance / advisory) | Trigger (planned subject / identified during engagement / requested engagement) | Effective-date position (planned after effective date / in progress at effective date, with note) | Prepared by, date | Reviewed by, date.
Columns, one row per lettered requirement: Domain | Requirement letter and short name | Applicable? (Yes / No) | Rationale if excluded (tied to the engagement objective and scope) | Criteria used (requirement statement plus organisation policy reference) | Work program steps | Evidence references | Conclusion (Meets / Partially meets / Does not meet / Not established) | Finding reference | Reported in final communication? (Yes / No).
Footer: Count of requirements applicable, excluded, and by conclusion | Overall statement for the report’s coverage table | Sign-off that the record is complete and filed per Standard 14.6.
Reading a requirement well: five habits
The documents are short and easy to skim, which is how functions end up conforming with the headings and not the content. Five habits prevent that. Read each lettered requirement as a compound sentence and count its clauses: the third-party governance requirement on roles, for example, asks for defined roles for selecting, directing, managing, communicating with and monitoring third parties, for clarity on who must be informed, and for a process that ensures the people assigned have the competence to do the job, which is three things to assess, not one. Read the definitions before the requirements, because the scope of the topic (what counts as a third party, what counts as cybersecurity) decides what the engagement has to reach. Read the user guide’s evidence examples as a list of what assessors will expect to see, not as a list of what to request from management. Note the phrases that carry frequency or currency (“periodically reviewed”, “accurate, complete and current”, “throughout the life cycle”), because each one is a test of operation over time, not a test of existence. And read the requirement against the organisation’s own policy before fieldwork, so that the gaps between the two are known before the first interview; a policy that is silent on a requirement is a finding waiting to be written, and better written in the planning memo than discovered in the closing meeting.
One habit for chief audit executives specifically: brief the audit committee before the first engagement under a new requirement, not after. A one-page note that says which requirement applies, what the floor is, and what the coverage table in the next report will look like turns the requirement from an internal audit compliance matter into what The IIA intended it to be, a shared expectation about what assurance on the topic means.
Building the method once: an eight-step plan for any function
Because every requirement shares the same structure and the same applicability rules, the work of absorbing them is a one-time methodology build plus a small per-requirement update. The plan below has been run by functions of two people and of forty; the hours are for a mid-sized function doing it properly the first time, and the second requirement takes a fifth of the effort.
| Step | What to do | Artefact | Owner | Hours (first time) |
|---|---|---|---|---|
| 1. Register the calendar | List every issued and announced requirement with its effective date; assign someone to watch The IIA’s page quarterly | A calendar in the methodology manual | Audit manager | 2 |
| 2. Write the procedure | A methodology section under Standard 9.3: how applicability is decided at planning, how exclusions are justified, where the record is filed, how supervision checks it | Manual section; planning template change | CAE or manager | 8 |
| 3. Flag the plan | Add a Topical Requirement column to the audit plan; mark every engagement whose subject, or likely content, triggers one | Plan with the column populated | Manager | 3 |
| 4. Build the record | Adopt the applicability and conformance record above, or the user guide’s appendix tool, as a standard workpaper | Template in the audit management system | Manager | 4 |
| 5. Map criteria | For each in-force requirement, map the lettered statements to the organisation’s policies and to the external framework the function already uses | Criteria map per requirement | Engagement lead | 12 per requirement |
| 6. Update work programs | Add a requirement reference to each step in the standard work program for the topic; add steps for requirements the old program did not cover | Revised work program | Engagement lead | 8 per requirement |
| 7. Change the report | Add a coverage table to the report template: requirements assessed, excluded with reason, conclusions by domain | Report template | Manager | 3 |
| 8. Put it in the QAIP | Add the applicability record to the engagement QC checklist and a conformance line to the annual self-assessment | QC checklist; self-assessment | CAE | 3 |
The report’s coverage table deserves a word, because it is the part readers see. A one-line-per-domain summary (Governance: four requirements assessed, three meet, one partially meets; Risk Management: four assessed, one excluded because the engagement scope excluded downstream parties, two meet, one does not meet; Control Processes: nine assessed, and so on) tells the audit committee what the assurance covered in the vocabulary The IIA now uses, and it is the single most effective answer to the question the Audit Society summary taught boards to ask: what, exactly, did you test?
The objections, and the straight answers
“It turns every cyber audit into a seventeen-point compliance exercise.” It sets a floor for what an assurance engagement on the topic assesses; it does not set the depth, the sampling or the rating. A risk-based engagement that examines all seventeen at the depth each deserves, and excludes with reasons the ones the objective does not touch, is exactly what the requirement describes. The functions that experience it as a checklist are usually the ones whose previous cyber audits had no defined scope.
“Our engagement only covers one system, one vendor category, one region.” Then the requirement applies to that scope, and the requirements the scope does not reach are excluded with a rationale that says so. Partial scope is allowed; undocumented partial scope is the nonconformance.
“The organisation has no third-party program, so there is nothing to assess.” The absence is the assessment. Each requirement is assessed and concluded as not established, the report says so, and the recommendation is the program. Excluding the requirements because the processes do not exist is the one rationale that will not survive a quality assessment.
“We use a co-source provider for this topic.” The chief audit executive remains responsible for the function’s conformance, including with Topical Requirements, and the provider’s work has to be mapped to the requirements and reviewed. Write it into the statement of work; the co-sourcing vs outsourcing comparison covers the governance.
“Advisory engagements are exempt, so we will call it advisory.” Conformance is recommended rather than mandatory for advisory work, but the classification has to be real: an engagement that issues a rating or an assurance conclusion is assurance whatever the memo calls it, and Standards 13.1 to 13.4 require the nature of the engagement to be agreed and documented. Relabelling is the kind of thing an external assessor looks for first.
“We already use a framework (NIST, ISO, COSO) for this topic.” Keep it. The requirement is a scope floor, not a criteria set; the user guide expects the function to layer the organisation’s own policies and any external framework on top. The cybersecurity workbook maps the seventeen cyber requirements to NIST CSF 2.0 and ISO 27001 for exactly this reason.
“What happens if we do not conform?” Nothing immediate from The IIA; the consequence arrives through the quality programme. An internal assessment should flag it, an external assessment will, and a function that reports conformance with the Standards while ignoring an applicable requirement has a disclosure problem under Standards 8.3 and 12.1. For regulated organisations there is a second consequence: supervisors who ask whether internal audit conforms to the Standards now have a specific, testable question to ask about the topics they care about most.
Worked example: mapping a plan against the requirement calendar
MidState Beverage’s six-person internal audit function met the first requirement the hard way: its 540-hour cyber program audit ran from May to June 2026, after the cybersecurity requirement took effect, and the applicability assessment was done during planning against all seventeen requirements (the result, one operating, twelve gaps and four not established, is worked through in the Cybersecurity Topical Requirement workbook). The chief audit executive then did what this guide recommends for every function: took the FY27 and FY28 plans and mapped each engagement against the calendar, so that no engagement would again be planned without knowing which requirement it triggers.
| Engagement | Timing | Topical Requirement triggered | Decision recorded |
|---|---|---|---|
| Cyber program audit (540 hours) | FY27, fieldwork May to June 2026 | Cybersecurity (effective 5 February 2026) | Applied in full; applicability record on file; 17 of 17 assessed |
| ERP user access audit (550 hours plus co-source) | FY27 | Cybersecurity, partial: the identity and access requirements | Topic identified during the engagement; the access-related requirements assessed, the rest excluded with rationale (scope limited to ERP access) |
| Payroll provider reliance (SOC 1 review, two of four CUECs unoperated) | FY27, completed before 15 September 2026 | Third-Party (effective 15 September 2026) | Not applicable by date; recorded; FY28 third-party engagement to apply it in full |
| Third-party management audit (new, 400 hours) | FY28 | Third-Party | Added to the FY28 plan; scoped to all 17 requirements; the co-source contract for IT vendors mapped to Control Processes A to I |
| Organizational behavior assessment | FY28, after 15 December 2026 | Organizational Behavior (effective 15 December 2026) | Planned as assurance; will apply the requirement; criteria built from the user guide when issued |
| Resilience engagement | FY28 | Organizational Resilience (effective 30 April 2027) | Scheduled for the second half of FY28 so that it falls after the effective date and is done once, to the requirement |
| Fleet and DOT compliance assurance | FY28 | None issued for the topic | No requirement; standard methodology applies |
Three things came out of the mapping that would not have come out of reading the requirements alone. The plan gained a column and the planning memo template gained a section. The resilience engagement moved six months so that it would be performed once, to the requirement, rather than performed early and re-performed. And the third-party engagement, which had been a vague intention, became a scoped 400-hour engagement with the co-source provider’s statement of work written against the nine control-process requirements, because the mapping made the CAE read the requirement before the engagement rather than after.
Related guides
- IIA Cybersecurity Topical Requirement: conformance workbook
- Third-Party Topical Requirement: what applies from September 2026
- The Global Internal Audit Standards: the complete guide
- Old IPPF to new GIAS: the complete mapping table
- GIAS Domain V: performing engagements, standard by standard
- Building a QAIP from scratch: the complete playbook
- QAIP self-assessment template
- How to audit corporate culture: a Topical Requirement method
- How to audit business continuity and resilience
- DORA for internal auditors
- Co-sourcing vs outsourcing internal audit
- More guides on standards and frameworks
Leave a Reply