Which IIA Topical Requirements are issued as of September 2026?

Four: Cybersecurity (issued February 5, 2025; effective February 5, 2026; 17 requirements), Third-Party Management (issued September 15, 2025; effective September 15, 2026; 17 requirements), Organizational Behavior (issued December 15, 2025; effective December 15, 2026; 15 requirements), and Organizational Resilience (issued April 30, 2026; effective April 30, 2027; 20 requirements). Anti-Corruption is a public consultation draft (16 draft requirements) that the IIA plans to issue in Q4 2026, and Talent Management is announced for consultation in January 2027.

When does a Topical Requirement apply to an engagement?

Each set states the same rule: it applies when the topic is the subject of an engagement in the internal audit plan, is identified while performing an engagement, or is the subject of a requested engagement that was not on the original plan. Conformance is mandatory for assurance services and recommended for advisory services.

Can we apply only part of a Topical Requirement?

Yes. The IIA's Application Guidance says not all parts must be applied if the identified risk pertains to only a subset of governance, risk management, and control elements, and coverage may be spread across several engagements and years if the documentation clearly shows how and when each part is addressed. Every excluded requirement still needs a documented, retained rationale.

What must be documented when a requirement does not apply?

The requirement documents say it directly: evidence that each requirement was assessed for applicability must be documented and retained, and if requirements are excluded, a rationale must be documented and retained. The newer sets add that a requirement superseded by regulatory or contractual requirements, or addressed through procedures performed in conformance with the Standards, also needs a documented rationale.

What will an external quality assessor actually look at?

IIA Quality Services says assessors start with the audit universe, risk assessment and plan, then sample engagements and review planning documentation (Standards 13.2 and 13.3), risk and control matrices, applicability matrices, audit programs, reliance memos, exclusion rationales, board communications on resources, and whether the internal quality program covers Topical Requirements. They are not looking for work or documentation beyond what the Standards already require.

Is 'applies in part' a decision?

We recommend treating it as a result, not a decision. Decide whether the set applies to the engagement, then decide each requirement: in scope, covered by other work (with a reference), or excluded (with a rationale). If any requirement is not in scope, the set applies in part. This keeps the record at the grain the IIA documents, one requirement at a time.

Does a structured applicability record replace professional judgment?

No. The IIA's Application Guidance says professional judgment is 'explicitly required by the Standards' and is exercised when deciding which topical risks are significant enough to cover, whether a set applies fully or in part, which requirements and criteria are relevant, and whether another provider's evidence meets a requirement. It also says judgment 'does not replace structure; it enables internal auditors to adapt structured requirements.' The record described here is where those judgments are written down so they are reasoned, evidence-based and defensible; it does not make them.

Does conforming to a Topical Requirement mean the organization's controls are effective?

No. Conformance describes the internal audit function's adherence to the requirement: every requirement was assessed for applicability and every exclusion documented. The organization's processes get assessment results (no exception, exception, not concluded). Keep the two words apart in reports so neither the board nor an assessor misreads one for the other.

What changed in the coverage-map workbook?

Version 2.0 is a guided rebuild: a Start Here sheet with steps, definitions and examples; a scorecard Dashboard with a chart; a Coverage Map ordered by workflow with dropdowns for applicability, disposition (in scope here, covered by other engagement, covered by external framework, reliance on other provider, excluded), rationale category, coverage rating and result, guidance notes on every header, and cells that turn red when a required rationale, reference or procedure is missing; a Worked Example sheet; per-row QAR Readiness checks; a Timeline grid; and all four issued sets with the Anti-Corruption draft on the Reference sheet. Formulas work in Excel and Google Sheets.

IIA Topical Requirements, Engagement by Engagement: Deciding Applicability, Documenting Exclusions, and Passing the QAR

In April we published a plan-level map of the IIA Topical Requirements and a workbook to run the first coverage pass. Since then the IIA has issued a fourth set, released a draft of a fifth, and Third-Party Management becomes effective on September 15, 2026. More importantly, the functions that ran the plan-level map have hit the next question: what does conformance look like inside a single engagement, and what exactly do we write down when a requirement does not apply?

This post answers that. It is based on the requirement documents, the User Guides, the IIA's Application Guidance (August 2025), and the Quality Services paper on how assessors will evaluate conformance (updated April 2026). Links are at the end.

What changed since April

Requirement set	Issued	Effective	Requirements (G / RM / C)
Cybersecurity	Feb 5, 2025	Feb 5, 2026	17 (4 / 6 / 7)
Third-Party Management	Sep 15, 2025	Sep 15, 2026	17 (4 / 4 / 9)
Organizational Behavior	Dec 15, 2025	Dec 15, 2026	15 (4 / 4 / 7)
Organizational Resilience	Apr 30, 2026	Apr 30, 2027	20 (6 / 4 / 10)
Anti-Corruption	Consultation draft, June 2026; the IIA has indicated issue in Q4 2026	12 months after issue	16 draft (4 / 3 / 9)
Talent Management	Announced; the IIA has indicated consultation in January 2027	—	—

Three things in that table matter for planning:

Organizational Resilience is real, and it is broad. It adopts the ISO 22316 definition and folds in business continuity, disaster recovery, incident command, critical-supplier inventories, critical-data classification, IT asset inventories, stress testing and lessons-learned. Twenty requirements is the largest set so far, and most of the control requirements will touch engagements you already run under other names.
The pipeline is corruption and talent, not privacy or AI. Early previews from advisory firms (Deloitte and PwC, linked below) listed privacy, IT governance and ESG as candidates. None of those exist or are on the IIA's published pipeline. The IIA has published non-mandatory guidance on privacy, fraud risk and AI governance instead.
Every set becomes effective 12 months after issue. That gives you a known date for each. The IIA has not said how an effective date applies to an engagement already under way. Our approach, and it is ours rather than the IIA's, is to treat a set as required when the engagement starts on or after the effective date, and to record decisions on sets that are issued but not yet effective without letting them gate anything.

The sentence that drives everything

Each requirement document carries the same paragraph. The part that matters for workpapers reads:

"Evidence that each requirement in the Topical Requirement was assessed for applicability must be documented and retained. Not all individual requirements may apply in every engagement; if requirements are excluded, a rationale must be documented and retained. Conformance with the Topical Requirement is mandatory and will be evaluated during quality assessments."

The two newest documents widen the second sentence:

"Not all individual requirements may apply to every engagement, and some may be fulfilled through other approaches. If a requirement is excluded or superseded by other regulatory or contractual requirements or addressed through implementation of procedures in conformance with the Global Internal Audit Standards, the rationale must be documented and retained."

Read those slowly. The unit of documentation is the requirement, not the set. Every requirement needs one of three things on file: evidence it was assessed, a reference to the other work that covers it, or a rationale for leaving it out. Nothing else is asked, and nothing less will do.

When a set applies at all

Every set gives the same three triggers. A Topical Requirement applies when the topic is:

the subject of an engagement in the internal audit plan;
identified while performing an engagement;
the subject of a requested engagement that was not on the original plan.

The second trigger is the one functions forget. Applicability is not a planning-only event. The Cybersecurity User Guide's own worked example is an accounts-payable audit where the walkthrough surfaces a web-based purchase-order portal: the auditors bring the relevant cybersecurity requirements into scope, might exclude the governance and risk-management requirements, and document the rationale either way.

Underneath all three triggers sits one test. The Application Guidance says a Topical Requirement applies "when the topic is identified during this risk assessment and the risk exceeds a significant risk level," with the threshold set by the organization's risk appetite. Applicability is therefore a professional-judgment call grounded in the engagement risk assessment (Standard 13.2), not a search for the word "vendor" in the scope statement. A screen of the charter can prompt the question; it cannot answer it.

Two more rules shape the decision:

Assurance versus advisory. Conformance is mandatory for assurance services and recommended for advisory services. On an advisory engagement you still record the decision; you are not gated by it.
Partial application is allowed. The Application Guidance says not all parts of a set must be applied if the identified risk pertains to only a subset of governance, risk management and control elements, and coverage "may be addressed across several engagements, potentially spread over multiple years," provided the documentation clearly shows how and when each part is addressed.

And one rule the IIA keeps repeating because functions keep missing it: Topical Requirements do not mandate that you audit a topic. They tell you what to assess once you do. A set whose topic does not reach a significant risk level in an engagement is a one-line decision, not a burden.

Where judgment sits

The Application Guidance opens with a section called "The Role of Professional Judgment," and it is worth taking literally, because a structured record is easy to mistake for a checklist. Judgment is exercised, in the IIA's words, when deciding "which Topical Requirement-related risks are significant enough to warrant coverage" (Standard 9.4), "whether the Topical Requirement should be applied fully or only in part" (Standard 13.3), "when evaluating and documenting applicability and exclusions, selecting evaluation criteria (Standard 13.4) and work program steps (Standard 13.6), and when deciding whether audit evidence from external assurance providers, such as regulatory audits, meets the requirements."

Three further points frame everything below:

The requirements are a floor, not a ceiling. They "provide a consistent minimum baseline," and "internal auditors must apply additional procedures when organizational risks, regulations, or context demand greater depth." An organization that rates cyber risk very high may need to assess more than the 17 listed requirements.
Judgment must be defensible. Decisions "must be reasoned and evidence-based, not arbitrary or intuitive," consistent with the function's methodology, and documented in planning records, workpapers or applicability matrices so that they are "transparent and defensible during quality assurance reviews or external assessments." That sentence is the reason every exclusion below carries a rationale.
"Conform or explain" has an owner. Where full conformance is not feasible, for example under resource constraints, the chief audit executive "should implement alternative actions that achieve the intent of the requirement and must document and communicate the rationale for the deviation," and must inform the board about resource shortfalls (Standard 8.2).

The guidance's own summary: "Professional judgment does not replace structure; it enables internal auditors to adapt structured requirements like Topical Requirements to complex realities." The method that follows is a structure for recording those judgments. It does not make them.

The engagement-level method

The plan-level workbook answers "where in the universe is each requirement covered?" The engagement-level record answers "for this engagement, what happened to each requirement?" Here is the model we recommend. It is deliberately small.

1. One decision per set, and it is binary

For each issued set that is effective on or before the engagement start date, the engagement lead records one of two things: applies or does not apply. The basis for either is the engagement risk assessment: does the topic reach a significant risk level in this engagement, given its objectives and the organization's risk appetite?

We recommend against making "applies in part" a decision. It is the result you get when a set applies and some requirements are not in scope. The moment "in part" becomes a top-level answer, the record stops saying which requirements were left out and why, which is the one thing the assessor needs.

"Does not apply" needs a category and one sentence a reviewer can verify against the engagement risk assessment and charter: the topic is outside the engagement's objectives and scope; the topic is present but its significance in this engagement is below the threshold (an example the User Guide itself gives); the topic is not relevant to the organization; a legal or regulatory constraint prevents assessment; the engagement is advisory and the set was not applied. If the planning screen shows that nothing in the risk assessment, objectives or scope reaches the topic, the sentence can be drafted from the charter's own words and confirmed in one click. The click is still the auditor's judgment, and the auditor is accountable for it.

2. Four dispositions per requirement

For a set that applies, every requirement gets exactly one disposition:

Disposition	Meaning	What must be on file
In scope	An engagement criterion. At least one procedure covers it.	The procedure(s), and later the result.
Covered by other work	Assessed in another engagement, tested under a stricter external framework (NIST CSF, ISO 27001, DORA, SOC 2), or relied on from another assurance provider under Standard 9.5.	The reference: engagement and period, framework and procedure, or provider and report. For reliance, also the evaluation Standard 9.5 requires: the provider's competence and objectivity and whether the work is sufficient for this requirement. It counts as coverage; the conclusion comes from the referenced work.
Excluded	Not assessed in this engagement, and not covered elsewhere.	A category and a sentence. The User Guide's own examples: the requirement is covered on a rotational basis elsewhere in the plan, or "the risk's significance in the engagement is low." It earns no coverage.
Not assessed	It was in scope but no conclusion was reached by the end of fieldwork.	The reason. This is a limitation and it is disclosed, never dropped. Where the reason is resources, the chief audit executive owns the alternative actions and the communication to the board.

The distinction between "covered by other work" and "excluded" is the one most workpapers blur. Reliance on a SOC 2 report is coverage with a documented basis; it is not an exclusion, and writing it up as one understates your work. But reliance is itself a judgment, not a filing: Standard 9.5 asks you to evaluate the other provider before you rely on them, so record that evaluation, not only the report's name. Conversely, "we assessed this last year" is only coverage if you can point at the engagement and it actually covered that requirement. When you reference another engagement, check what that engagement's own record says about the requirement. "Did not cover it" is a finding for your reviewer, not a footnote.

3. Rationale is category plus sentence plus attribution

Categories exist for roll-ups and for assessors scanning a matrix. The sentence is for your reviewer. The name and date are for the trail. A rationale without any of the three is what the Quality Services paper politely calls a gap in "conform or explain."

Resist the urge to generate rationale text with a language model. The guidance asks for decisions that are "reasoned and evidence-based, not arbitrary or intuitive," and identical paragraphs across engagements are what arbitrary looks like on paper. Draft the sentence from the engagement's actual risk assessment, objectives and scope areas, then let the auditor edit it and own it.

4. Review, lock, reopen

Applicability decisions for sets that apply get a second pair of eyes. The Standards require supervision of engagement work; our practice goes one step further and asks that the reviewer is not the person who made the decisions. Once approved, the decision and the dispositions lock. Mapping procedures to requirements does not lock; that is planning work that continues until fieldwork starts. If a topic emerges mid-engagement (trigger two), reopen with a reason, keep the approved version in history, and send it back for review.

5. Keep "conformance" for the function

This is our vocabulary rule, and it follows the IIA's usage: every conformance sentence in the requirement documents is about the internal audit function's adherence to the requirement, meaning every requirement assessed for applicability and every exclusion documented. The organization's processes do not "conform" to a Topical Requirement; the auditor concludes on them: no exception, exception, not concluded. A report that says "Cybersecurity: 9 conform, 0 gaps" invites a board member to read it as the organization conforming to the IIA, and an assessor to read it as the function's conformance. Separate the two on the page.

Mistakes we keep seeing

Assuming all 17 apply. One advisory firm calls this the most common error on cybersecurity, and the User Guide says plainly that not every requirement applies in every engagement. Partial application is explicitly allowed. Decide per requirement.
One central audit as the only coverage model. A single annual cybersecurity audit can cover governance and risk management, but the control requirements often live in application, infrastructure and vendor audits. Map them where they are actually tested and reference across engagements.
Rationale written after fieldwork. Assessors read the planning documentation under Standards 13.2 and 13.3. A rationale dated after the report is a rationale about a decision nobody made.
A checklist on every audit step. One external assessor put it plainly: "I don't need seven checkboxes for every one of the control elements on every single audit step." One matrix per engagement, one row per requirement, is the whole ask.
Fan-out from shared procedures. One vendor-management procedure may serve four governance requirements. If it finds an exception, do not stamp four gaps. Tie the exception to the requirement it actually breaches and confirm the rest.
Sets treated as gates before they are required. A set that is issued but not yet effective for this engagement is not yet required, and any set on an advisory engagement is recommended rather than mandatory. Record the decision; do not let it block planning.
Rationale that names the scope but not the risk. "Not in scope" is a description. "The topic does not reach a significant risk level in this engagement because…" is a judgment an assessor can test.

What the assessor reads

The Quality Services paper is the closest thing to an answer key. Assessors will:

start with the audit and risk universe, the risk assessment and the annual plan, looking for how topical risks were identified;
sample engagements, and in most cases not expand the sample because of Topical Requirements;
verify that planning documentation supports inclusion and exclusion decisions without reperforming the work;
review risk and control matrices, checklists, applicability matrices and audit programs;
check reliance memos under Standard 9.5, exclusion rationales, board communications about resources under Standard 8.2, and whether the internal quality program under Standard 12.1 covers Topical Requirements.

The paper's own summary: assessors "are not looking for additional work or documentation beyond what is already required in the Standards." If the engagement-level record above exists, the QAR conversation is short.

The applicability matrix

Each User Guide includes an optional documentation tool with three columns: requirement; executed coverage or rationale for exclusion; documentation reference. That is the artifact. Everything in this post is a way of filling it so it survives a reviewer and an assessor. We add three columns in practice: disposition, coverage basis (this engagement, other engagement, external framework, other assurance provider, excluded), and who decided and who approved.

Workbook v2.0

We rebuilt the coverage-map workbook around the method above:

a Start Here sheet with six steps and time estimates, a definitions table with a worked example for every applicability, disposition and result value, the rationale categories (including the IIA User Guide's own two examples), and a colour legend;
a Dashboard with one scorecard per issued set (decided, applicable, in scope, covered elsewhere, excluded, coverage and readiness percentages), headline tiles for requirements decided, QAR readiness, unmapped in-scope requirements, missing rationale and exceptions, and a stacked chart of where every requirement sits;
a Coverage Map ordered the way the work happens (reference, decide, cover, plan, conclude), with dropdowns for every judgment field, a guidance note on every column header, and cells that turn red when a required rationale, reference or procedure is missing;
a Worked Example sheet: a completed vendor cloud-hosting review showing every disposition with real rationale sentences, including a Standard 9.5 reliance note and a set-level "does not apply";
QAR Readiness checks per row (decision made, disposition set, rationale or reference present, procedure mapped) with a per-set summary;
a Timeline grid showing each set's issue-to-effective window, with rows for your own QAR, plan and board milestones;
all four issued sets (69 requirements) on the map and the Anti-Corruption draft on the Reference sheet with links to every IIA document.

Download the Topical Requirements Coverage Map v2.0 (.xlsx)

Requirement text in the workbook is condensed. The IIA documents remain the authority; the Reference sheet links to them. Formulas use only functions that work in both Excel and Google Sheets.

A sixty-minute routine per engagement

At scope confirmation (10 minutes). List every issued set that is effective on or before the engagement start date. For each, decide from the engagement risk assessment whether it applies. Write the one-sentence rationale for each "does not apply," naming the risk judgment, not just the scope.
For each set that applies (20 minutes). Walk the requirements by domain. Mark each in scope, covered by other work (with the reference and, for reliance, the 9.5 evaluation), or excluded (with the sentence). Ask whether the risk profile calls for anything beyond the listed requirements.
Map procedures (20 minutes). Every in-scope requirement gets at least one procedure. Where a requirement has none, either write the procedure or move it to excluded with a reason. Do not leave it hanging.
Review (10 minutes). A manager who did not make the decisions approves the sets that apply. "Does not apply" sets are approved with the planning sign-off.
At conclusion. Conclude on each in-scope requirement. Anything without a conclusion is a disclosed limitation, with its reason, in the report, and if the reason is resources it goes to the chief audit executive and the board.

This is the model behind the topical-requirements work in Audvera's engagement workflow, which is in design as of this post. Whether you use software or the workbook, the record is the same: one decision per set, one disposition per requirement, one verifiable sentence per exclusion, each a documented judgment, attributed and reviewed.

Sources

IIA Topical Requirements landing page: https://www.theiia.org/en/standards/2024-standards/topical-requirements/
Topical Requirements Application Guidance (August 2025): https://www.theiia.org/globalassets/site/standards/topical-requirements/topical_requirements_application_guidance_english.pdf
IIA Quality Services, Assessing Topical Requirements Conformance (updated April 2026): https://www.theiia.org/en/content/group-services/assessing-topical-requirements-conformance/
Organizational Resilience Topical Requirement (April 2026): https://www.theiia.org/globalassets/site/standards/tr/or/org_resilience_tr_en.pdf
Anti-Corruption Topical Requirement, public consultation draft (June 2026): https://www.theiia.org/globalassets/site/standards/tr/ac/anti-corruption_tr_en.pdf
Cybersecurity Topical Requirement User Guide (worked examples, optional documentation tool): https://www.theiia.org/globalassets/site/standards/topical-requirements/cybersecurity/cybersecurity_tr_user_guide.pdf
Internal Audit Collective, on what assessors expect (May 2026): https://www.internalauditcollective.com/newsletters/why-conforming-with-the-iias-topical-requirements-wont-be-as-hard-as-you-may-think-how-to-do-it
Rehmann, on common errors applying the Cybersecurity requirement (April 2026): https://www.rehmann.com/resource/iia-cybersecurity-topical-requirements-the-basics/
Early candidate-topic previews: Deloitte Switzerland https://www.deloitte.com/ch/en/Industries/financial-services/blogs/global-internal-audit-standards-are-you-ready-for-them.html and PwC https://www.pwc.com/gx/en/services/audit-assurance/internal-audit/new-global-internal-audit-standards.html