The Organizational Resilience Topical Requirement is the fourth mandatory Topical Requirement issued under the IIA’s International Professional Practices Framework, and the broadest. Issued on 30 April 2026 and effective 30 April 2027, it sets a minimum baseline of twenty requirements that internal auditors must assess whenever organizational resilience is the subject of an assurance engagement: six on governance, four on risk management and ten on control processes. It defines resilience using ISO 22316’s phrase, the ability of an organization to absorb and adapt in a changing environment, and it deliberately reaches past business continuity and disaster recovery into strategy, culture, competencies, stakeholders, finance and the working environment. A function that has only ever audited the IT disaster recovery plan will find that it covers roughly a quarter of what the requirement asks for.
This workbook follows the format of the site’s cybersecurity, third-party and organizational behavior workbooks. For each of the twenty requirements it gives what to assess, the evidence that demonstrates conformance, the gap that recurs and the test steps. It then provides a crosswalk to the frameworks most organizations already use (ISO 22301 and 22316, NIST CSF 2.0, the Basel Committee’s resilience principles, DORA, the UK operational resilience regime), explains how the four Topical Requirements overlap, sets out sampling and evidence approaches, exclusion rationales that survive a quality assessment, a four-value conformance rating, a record template, a readiness plan to April 2027, and a worked example of a manufacturer’s first assessment. The Topical Requirements explained guide covers the mechanism common to all of them.
In this guide
- What the requirement says, and when it binds
- What “organizational resilience” covers, and what it changes
- How to use the workbook
- Governance: six requirements, with test steps
- Risk management: four requirements, with test steps
- Control processes: ten requirements, with test steps
- Crosswalk to ISO, NIST, Basel, DORA and the UK regime
- How the four Topical Requirements overlap
- Sampling and evidence when the subject is resilience
- Exclusion rationales that survive a quality assessment
- Rating conformance and writing the conclusion
- The conformance record: a template
- Readiness plan: now to 30 April 2027
- Worked example: Brightwater Foods’ first twenty-requirement assessment
- Questions about the requirement
- Related guides
What the requirement says, and when it binds
Topical Requirements are mandatory elements of the IPPF that must be used in conjunction with the Global Internal Audit Standards. Each one sets a minimum baseline for auditing a specified risk area; conformance is mandatory for assurance services and recommended for advisory services, and conformance is evaluated during quality assessments. The applicability test is the same for all four requirements issued so far: the requirement binds when the topic is the subject of an engagement in the plan, is identified while performing an engagement, or is the subject of a requested engagement that was not on the plan. Not every individual requirement applies to every engagement; where one is excluded, superseded by regulatory or contractual requirements, or addressed through other procedures in conformance with the Standards, the rationale must be documented and retained.
| Element | Organizational Resilience Topical Requirement |
|---|---|
| Issued | 30 April 2026 (document dated April 2026) |
| Effective | 30 April 2027 |
| Structure | Governance (A to F), Risk Management (A to D), Control Processes (A to J): 20 requirements |
| Definition used | ISO 22316:2017: the ability of an organization to absorb and adapt in a changing environment |
| Mandatory for | Assurance engagements where resilience is the subject; recommended for advisory |
| Triggers | Plan subject; identified during an engagement; requested engagement off-plan |
| Companion | A user guide with implementation tips |
| Siblings | Cybersecurity (effective 5 February 2026), Third-Party (15 September 2026), Organizational Behavior (15 December 2026) |
The second trigger is the one functions underestimate. An engagement on IT change management that finds the disaster recovery plan untested has “identified” resilience during the engagement, and the requirement then applies to the extent the auditor pursues the matter. The practical response, as with the other requirements, is to decide at planning whether resilience is in scope, and if it is not, to write the scoping memo so that an incidental observation can be handed to a resilience engagement rather than expanding the current one.
What “organizational resilience” covers, and what it changes
The requirement’s introduction is explicit that resilience is an umbrella term covering risks that may significantly disrupt the organization’s ability to deliver its core products and services, maintain stakeholder trust or fulfill its strategic objectives, whether from sudden-onset events (natural disasters, cyberattacks, geopolitical conflict), prolonged pressures (resource scarcity, public health crises) or shifts in the external context (technological disruption, regulatory change, reputational erosion), and including gradual, slow-building pressures that are routinely overlooked. It names the factors that raise inherent risk: highly complex operations, globalized supply chains, centralized infrastructure or data, limited workforce availability, volatile markets, strong dependence on critical third parties or geographic locations, and operation in high-reliability sectors or under intense regulatory scrutiny. Business continuity and disaster recovery plans are included but are described as only part of resilience, which also requires strategic planning, enterprise risk management, leadership and culture, and organization-wide control processes.
For an audit function this changes three things. The engagement is no longer an IT audit; it needs auditors who can read a strategy, a budget and a succession plan. The auditee is no longer the IT director; it is the executive team, with the board’s oversight in scope under the governance requirements. And the criteria broaden: the business continuity and resilience guide and the backup and recovery program remain the tools for the continuity and recovery requirements, but the strategy, competency, stakeholder, financial and working-environment requirements need criteria the function may never have used, which the crosswalk section supplies.
How to use the workbook
Each requirement below is stated in a close paraphrase (the requirement’s letter and domain are the IIA’s; the wording is condensed, and the engagement file should cite the IIA document itself), followed by what to assess, the evidence that demonstrates it, the gap that recurs and the test steps. Use the tables as the engagement’s work program skeleton: copy them into the program, add the organization-specific populations and samples, and record the result of each requirement in the conformance record at the end. Where a requirement is excluded, write the exclusion rationale into the record rather than leaving the row blank.
Governance: six requirements, with test steps
Internal auditors must assess the following aspects of the governance of organizational resilience.
| Req. | What it requires (condensed) | What to assess and the evidence | Common gap | Test steps |
|---|---|---|---|---|
| G-A | A formal strategy addressing resilience, established by management, adopted and overseen by the board, covering the operational, technological and financial elements needed to manage change and continue operations; resilience objectives aligned with the overall approach to risk management | A strategy document or a resilience section of the corporate strategy; board approval minuted; objectives that map to the risk framework | A business continuity policy is presented as the strategy; the board has never seen a resilience strategy; finance is absent from it | Obtain the strategy; confirm board adoption and oversight in minutes; map objectives to the risk appetite and framework; confirm the three elements are each addressed |
| G-B | Updates on achievement of resilience objectives periodically communicated to the board, embedding resilience in strategic oversight, long-term planning, succession planning and culture, including resource and budget decisions for critical activities | Board papers reporting progress against the objectives; evidence resilience appears in planning, succession and budget documents | Updates are incident reports, not progress against objectives; succession planning never mentions critical resilience roles | Inspect a year of board papers; trace objectives to updates; inspect the long-term plan, succession plan and budget for resilience content |
| G-C | Policies and procedures for critical operational, technological and financial processes established and periodically reviewed, tested and updated | A policy register with owners, review dates and test evidence for the processes identified as critical | Policies reviewed on paper, never tested; financial continuity procedures (liquidity under disruption) absent | Reconcile critical processes (from RM-A) to policies; sample ten for review date, test evidence, update after test |
| G-D | An incident command structure established and used, with decision-making hierarchies, communication and escalation protocols, and leadership and operational roles and responsibilities | A documented command structure; evidence it was used in real incidents or exercises; named alternates | The structure exists on paper and the last real incident was run by whoever was available | Inspect the structure; trace two incidents or exercises to the decisions made and by whom; confirm escalation protocols were followed |
| G-E | A process to periodically validate the competencies required for resilience success and reassess the competencies of individuals in critical resilience roles | A competency framework for resilience roles; assessment records; training or replacement actions | No one has defined what competencies the incident commander needs; alternates have never been assessed | Obtain the role list and competency definitions; sample critical roles for assessment within the cycle; confirm actions on gaps |
| G-F | A process to identify, prioritize and engage all relevant internal and external stakeholders in setting up information and reporting structures for resilience (senior management, operations, risk, IT, supply chain, facilities, HR, finance, legal, assurance providers including internal audit, compliance, public relations, critical vendors, customers, regulators, others) | A stakeholder map with prioritization; evidence of engagement (committee membership, communications plans, regulator notification protocols, vendor contacts) | Customers, regulators and critical vendors missing from the map; internal audit never consulted | Inspect the stakeholder map against the requirement’s list; test engagement evidence for five external stakeholders |
Risk management: four requirements, with test steps
Internal auditors must assess the following aspects of the risk management of organizational resilience. The RCSA guide and the risk register guide cover the mechanics the first three requirements depend on.
| Req. | What it requires (condensed) | What to assess and the evidence | Common gap | Test steps |
|---|---|---|---|---|
| RM-A | Resilience risks periodically identified, assessed and managed across the organization; mapped to strategic objectives; the process includes evaluating key processes | A resilience risk assessment or a resilience lens in the ERM register; mapping to objectives; a key process inventory with criticality ratings | Risks assessed by IT for systems only; no inventory of critical business processes; no mapping to objectives | Obtain the assessment; confirm enterprise coverage; test mapping to objectives; reconcile the key process inventory to the organization’s actual operations |
| RM-B | Accountability and responsibility clearly defined; a designated individual or team monitors and reports on resilience risk management, including resources for mitigation and identification of emerging threats | A named owner or team; reporting evidence; emerging-threat reports | Resilience owned by nobody between the CIO (systems) and the COO (operations) | Identify the owner; inspect reporting cadence and content for the year; confirm emerging threats are reported |
| RM-C | A process to monitor resilience risk levels (emerging or previously identified) and quickly escalate those reaching an unacceptable level per the risk guidelines, tolerance or legal and regulatory requirements; impacts considered | Tolerances or impact tolerances defined; monitoring indicators; escalation records | No tolerance defined, so nothing can be “unacceptable”; escalation depends on judgment | Inspect tolerances; test monitoring indicators against them; trace breaches to escalation |
| RM-D | Management has implemented and periodically tests a process to respond to and recover from crises, disruptions and emergencies, covering detection, prioritization, containment, recovery and post-incident analysis; includes scenario analyses and periodic stress testing against a range of disruptive events | The incident response and recovery process; test records; scenario and stress test documentation across a range of event types | Tests cover IT outage only; no scenarios for supply, people, facilities or financial disruption | Inspect the process for the five stages; inspect test records for the cycle; confirm scenarios span event types; re-perform one scenario’s assumptions (incident response program) |
Control processes: ten requirements, with test steps
Internal auditors must assess the following aspects of the control processes related to organizational resilience. Several map directly to existing site programs, noted in the table.
| Req. | What it requires (condensed) | What to assess and the evidence | Common gap | Test steps |
|---|---|---|---|---|
| CP-A | A process to identify critical third-party providers (suppliers and vendors) and determine the minimum inventory levels required to sustain essential operations; an up-to-date list of alternative suppliers | Critical supplier list; minimum inventory levels by critical input; alternative supplier list with currency | Critical suppliers listed; minimum inventory never calculated; alternatives listed but never qualified (third-party resilience) | Reconcile the critical supplier list to spend and dependency data; test minimum inventory calculations for five inputs; test alternative supplier currency |
| CP-B | Data critical for operations identified and classified: where it resides, who requires access, how it is accessed, whether it is backed up and recoverable during an emergency | Data classification register for critical data with location, access and recoverability attributes | Classification covers confidentiality but not criticality to operations; recoverability untested (data privacy program covers classification mechanics) | Inspect the register; sample ten critical data sets for the four attributes; trace recoverability to restore tests |
| CP-C | Critical IT controls and continuous monitoring to mitigate information security risks including cyber, protecting sensitive data during crises; includes real-time threat intelligence and restriction of access to authorized users | Security controls that operate during a crisis (not only in normal state); threat intelligence feeds; access restriction procedures for crisis mode | Controls assumed to work during a crisis without evidence; access widened during incidents and never reverted (cyber workbook) | Inspect crisis-mode procedures; test threat intelligence consumption; sample incidents for access changes and reversal |
| CP-D | Critical IT assets inventoried: hardware, software and services required during crises | An asset inventory flagged for crisis-critical items, reconciled to the critical process inventory | Inventory exists; “critical” flag absent or unreconciled to processes | Reconcile the inventory to RM-A’s process list; sample twenty assets for accuracy |
| CP-E | Business continuity and disaster recovery plans established with defined roles for personnel and recovery teams; tested periodically (for example, tabletop exercises); results including improvement opportunities reported to the board and senior management | BCP and DRP with role assignments; test records; board reporting of results | Plans tested, results never reach the board; improvement actions untracked (backup and recovery; cyber resilience) | Inspect plans for roles; inspect test records and the restore test itself; trace results to board papers and actions to the issue log |
| CP-F | A process to modify the working environment during crises, disruptions and emergencies | Remote work, alternate site, shift and safety procedures; evidence of use | Assumed from the pandemic experience; never documented or re-tested | Inspect the procedures; confirm they were exercised within the cycle |
| CP-G | A process to continuously monitor and report emerging threats and vulnerabilities affecting resilience, used to identify, prioritize and implement improvements, including whistleblowing or risk-intelligence systems | Horizon scanning or threat monitoring reports; whistleblowing channel; improvements traceable to the process | Monitoring is cyber-only; whistleblowing exists but is not connected to resilience | Inspect monitoring outputs for the year across threat types; trace two improvements to the process |
| CP-H | A process to educate and train personnel on resilience policies, procedures and actions, including exercises simulating disruptive scenarios | Training records; simulation exercise records with participation | Annual e-learning on fire safety presented as resilience training; no simulations beyond IT | Reconcile training completion for critical roles; inspect simulation records for scope and participation |
| CP-I | A process to ensure operational, human, technological and financial resources are budgeted and available during crises; financial resources for resilience periodically analyzed and communicated to the board | Contingency budgets; committed credit lines or reserves; board communication of the financial analysis | No financial analysis of what a disruption would cost or how it would be funded; the board has never been told | Inspect the resource plan across the four resource types; inspect the financial analysis and its board communication; test availability of one resource type |
| CP-J | A process for post-incident review of crises, disruptions and emergencies through a lessons-learned process, with lessons integrated into future planning | Post-incident review records; lessons log; evidence of integration into plans | Reviews done for major incidents only; lessons recorded, plans unchanged | Sample incidents from the year for review records; trace lessons to plan changes |
Crosswalk to ISO, NIST, Basel, DORA and the UK regime
Most organizations already work to a resilience framework, and the engagement should use it as criteria wherever it is more specific than the requirement. The crosswalk shows where each framework carries the requirement’s content; the DORA guide and the NIST CSF 2.0 method cover two of them in depth.
| Requirement group | ISO 22301:2019 (BCMS) and ISO 22316:2017 | NIST CSF 2.0 (2024) | Basel Principles for Operational Resilience (March 2021) | DORA (applies from 17 January 2025) | UK operational resilience (PRA SS1/21, FCA PS21/3) |
|---|---|---|---|---|---|
| Governance (G-A to G-F) | 22301 clauses 5 (leadership) and 7 (support, competence); 22316 principles on leadership and culture | Govern function (GV.OC, GV.RM, GV.RR) | Principle 1 (governance) | Art. 5 (management body responsibility) | Board approval of important business services and impact tolerances; self-assessment |
| Risk management (RM-A to RM-D) | 22301 clauses 6 (planning) and 8.2 (business impact analysis and risk assessment) | Identify (ID.RA, ID.IM); Govern (GV.SC) | Principles 2 (operational risk management), 4 (mapping interconnections), 6 (incident management) | Arts. 6 to 8 (ICT risk framework, identification), 17 to 19 (incident management) | Mapping of important business services; scenario testing; remaining within impact tolerances by 31 March 2025 |
| Control processes (CP-A to CP-J) | 22301 clause 8.3 to 8.6 (strategies, plans, exercising, evaluation); clause 10 (improvement) | Protect, Detect, Respond, Recover (PR.DS, DE.CM, RS.MA, RC.RP, RC.CO) | Principles 3 (business continuity planning and testing), 5 (third-party dependency management), 7 (ICT including cyber security) | Arts. 11 to 12 (response and recovery, backup), 24 to 27 (resilience testing), 28 to 30 (third-party risk) | Third-party dependencies; testing; lessons learned; communications |
Two framework specifics are worth importing even where they do not apply by regulation. The UK regime’s “impact tolerance”, the maximum tolerable disruption to an important business service expressed in time and other measures, gives RM-C the measurable tolerance it otherwise lacks. And the Basel principles’ mapping of interconnections and interdependencies gives RM-A and CP-D the dependency-mapping discipline that turns a process inventory into something testable.
How the four Topical Requirements overlap
Resilience touches the other three requirements, and an engagement can trigger more than one. The table shows where, and how to handle it without assessing the same control four times.
| Resilience requirement | Overlaps with | Handling |
|---|---|---|
| CP-A (critical suppliers, inventory, alternatives) | Third-Party: inventory (Control Processes D), ongoing monitoring (F), offboarding (I) | Assess once under whichever requirement is the engagement’s subject; cross-reference the record. The third-party program covers both |
| CP-B, CP-C, CP-D (data, security controls, IT assets) | Cybersecurity: governance of assets, protection, detection, response | Where a cyber assessment under the cyber requirement exists within the cycle, rely on it with the reliance assessment Standard 9.5 requires, and test only the crisis-mode aspects |
| G-E, CP-H (competencies, training, culture) | Organizational Behavior: competencies, training, culture of accountability | Behavior findings on culture feed G-B’s “embedded in culture”; keep the ratings separate |
| RM-D, CP-E (response, recovery, testing) | Cybersecurity: incident response and recovery | Cyber incident response is one scenario type; resilience requires a range (supply, people, facilities, finance, regulatory) |
| G-F (stakeholders incl. regulators) | Third-Party (regulators, customers); Cyber (notification obligations) | One stakeholder map serves all; test it once |
Sampling and evidence when the subject is resilience
Resilience evidence comes in three kinds and the engagement needs all three. Design evidence is documents: strategy, plans, registers, procedures. Operation evidence is records of use: incident logs, exercise reports, escalation emails, board papers, training records. Performance evidence is the result of a test: a restore that completed in 31 hours against a 24-hour target, a tabletop in which the alternate incident commander could not be reached, a supplier switch that took fourteen months. The gap that fails most engagements is stopping at design evidence; a plan is not resilience. Where the organization has run tests, re-perform or observe at least one (the restore test is the usual choice); where it has not, that is the finding. Sampling follows the standard sizes for records (incidents, training completions, policy reviews) and judgmental selection, documented under the judgmental sampling rules, for critical processes, suppliers and data sets.
Exclusion rationales that survive a quality assessment
| Situation | Rationale that works | Rationale that does not |
|---|---|---|
| CP-A at a services firm with no physical inventory | “Minimum inventory levels do not apply; the critical-supplier and alternative-supplier elements were assessed” | “Not applicable” with no split of the requirement |
| CP-C where a cyber assessment under the Cybersecurity Topical Requirement was completed within twelve months | “Addressed through the cyber engagement [ref]; reliance assessed under Standard 9.5; crisis-mode access procedures tested here” | “Covered by cyber” with no reliance assessment |
| G-A in a subsidiary whose strategy is set by the parent | “Parent strategy [ref] adopted by the subsidiary board on [date]; local objectives assessed” | “Group handles strategy” |
| RM-C at a UK-regulated firm with impact tolerances | “Superseded by the PRA and FCA operational resilience requirements; tolerances and breach escalation tested against those rules” | Ignoring the requirement because the regulator’s rules exist |
| CP-I financial resources at a public body with statutory funding | “Financial availability governed by [statute]; the analysis and board communication elements were assessed” | “Public sector, not applicable” |
Rating conformance and writing the conclusion
The requirement does not prescribe a rating scale. The four-value scale used across the site’s workbooks works for this one: Operating (the requirement’s process exists, is used and has evidence of performance), Gap (the process exists but a material element is missing or untested), Not established (no process), and Excluded (with the documented rationale). The engagement rating under the function’s standard rule follows from the findings, not from a count of gaps; a single Not established on CP-E (untested continuity and recovery plans) is a High finding that drives the rating on its own, while five Gaps on documentation elements may together support Needs Improvement. The conclusion should state the requirement, the number of requirements assessed, the results by domain, and the engagement rating, in the form the report anatomy describes. The requirement’s own word for the standard is a “minimum baseline”; the conclusion should say whether the organization meets it.
The conformance record: a template
Organizational Resilience Topical Requirement — conformance record. Engagement [name, ref]; period [dates]; trigger [plan subject / identified during engagement / requested]. Requirement version [April 2026]. Criteria used alongside the requirement [frameworks, policies]. Governance: G-A [Operating / Gap / Not established / Excluded; evidence refs; finding ref]; G-B […]; G-C […]; G-D […]; G-E […]; G-F […]. Risk management: RM-A […]; RM-B […]; RM-C […]; RM-D […]. Control processes: CP-A […]; CP-B […]; CP-C […]; CP-D […]; CP-E […]; CP-F […]; CP-G […]; CP-H […]; CP-I […]; CP-J […]. Exclusions and rationales: [requirement, rationale, approver]. Reliance on other engagements: [requirement, engagement ref, Standard 9.5 assessment]. Summary: Operating [n], Gap [n], Not established [n], Excluded [n] of 20. Engagement rating: [per the function’s rule]. Conclusion on the minimum baseline: [met / not met, with the requirements that determine it]. Prepared [name, date]; reviewed [name, date]; retained in [file ref] for quality assessment.
Readiness plan: now to 30 April 2027
| When | Action | Owner |
|---|---|---|
| Now | Add the requirement to the methodology manual’s Topical Requirement appendix; brief the team; identify which planned engagements will trigger it before and after the effective date | CAE, audit manager |
| Q4 2026 | Run a gap assessment against the twenty requirements as an advisory engagement (conformance recommended, not mandatory, for advisory work), so management sees the baseline before it binds | Engagement lead |
| Q4 2026 to Q1 2027 | Build criteria: adopt or map the organization’s framework (ISO 22301, NIST CSF 2.0, the UK regime) to the requirements; obtain the user guide; agree the rating scale | Audit manager |
| Q1 2027 | Scope the first assurance engagement for after 30 April 2027; set the record template; decide reliance on the cyber and third-party assessments | CAE |
| From 30 April 2027 | Apply the requirement to every triggered assurance engagement; retain conformance records for the next external quality assessment | All engagement leads |
Worked example: Brightwater Foods’ first twenty-requirement assessment
Brightwater Foods is a $180 million food manufacturer with three plants and about 600 staff, used in examples across this site; its first chief audit executive had already commissioned a cyber resilience review (no immutable backup copy, an ERP restore of 41 hours against a 24-hour target, nine days to full recovery against a five-day tolerance) and a third-party resilience review (five continuity-critical suppliers, including a sole closure-component supplier with three weeks of stock and an eight-week qualification lead time). In the second half of FY28 the audit committee asked for an organization-wide resilience assessment, scheduled deliberately ahead of the requirement’s effective date so the function could run it as an advisory engagement first, with the assurance engagement to follow in FY29. The function used the twenty requirements as the program, relied on the two prior reviews for CP-A and CP-C through CP-E after documenting the reliance assessment, and spent 260 hours on the remaining requirements.
The governance results were the surprise. The company had a business continuity policy and no resilience strategy (G-A Not established); the board received incident reports but no progress against resilience objectives, because there were none (G-B Not established); the incident command structure existed and had been used in a plant refrigeration failure, with the decisions traceable (G-D Operating); nobody had defined the competencies of the incident commander or assessed the alternates (G-E Not established); and the stakeholder map omitted the company’s largest retail customers and its food safety regulator (G-F Gap). In risk management, the key process inventory existed for IT only (RM-A Gap), the owner was the IT director for systems and nobody for operations (RM-B Gap), no tolerance had been set for anything except the IT recovery time objective (RM-C Gap), and scenario testing covered cyber and nothing else (RM-D Gap). Control processes were stronger where the prior reviews had already driven action: the immutable backup was in place and tested, which moved CP-E to Operating, and the second closure-component supplier had been qualified, which moved CP-A to Operating. The remaining control gaps were the working-environment procedures (CP-F, never documented), training (CP-H, fire safety e-learning only), and financial resources (CP-I, no analysis of what a two-week plant outage would cost or how it would be funded).
| Domain | Operating | Gap | Not established | Excluded | Findings |
|---|---|---|---|---|---|
| Governance (6) | 1 (G-D) | 2 (G-C, G-F) | 3 (G-A, G-B, G-E) | 0 | F1 High: no resilience strategy or board objectives; F2 Medium: competencies; F3 Low: stakeholder map |
| Risk management (4) | 0 | 4 (RM-A to RM-D) | 0 | 0 | F4 High: critical process inventory and tolerances limited to IT; F5 Medium: scenario range |
| Control processes (10) | 5 (CP-A, CP-B, CP-D, CP-E, CP-J) | 4 (CP-C, CP-F, CP-H, CP-I) | 1 (CP-G) | 0 | F6 Medium: financial resources never analyzed; F7 Medium: training and working environment; F8 Low: threat monitoring cyber-only |
| Total (20) | 6 | 10 | 4 | 0 | 2 High, 4 Medium, 2 Low; advisory report, no engagement rating |
The advisory report went to the executive team and the audit committee in month three. The chief executive’s reaction was to assign resilience to the chief operating officer as the designated owner (RM-B), commission a resilience strategy for board adoption at the next annual planning cycle (G-A, G-B), and ask finance to model the cost of a two-week outage at each plant (CP-I); the figure, about $1.1 million for the largest plant, became the first resilience tolerance the board had ever discussed. The function scheduled the assurance engagement for the second quarter after 30 April 2027, with the expectation that the four Not established requirements would have moved to Gap or Operating and that the engagement would be rated on the result.
Questions about the requirement
When does the Organizational Resilience Topical Requirement take effect?
It was issued on 30 April 2026 and becomes effective on 30 April 2027. Assurance engagements on organizational resilience that begin after that date must conform; applying it earlier, as an advisory baseline, is recommended.
How many requirements does it contain?
Twenty: six under governance (A to F), four under risk management (A to D) and ten under control processes (A to J). The cyber and third-party requirements each have seventeen; organizational behavior has fifteen.
Does a business continuity audit trigger it?
Yes, if the engagement’s subject is resilience or continuity. A narrowly scoped IT disaster recovery test can be scoped to exclude the broader requirements with a documented rationale, but an engagement titled “business continuity” will be expected to address the requirement, and most of its twenty elements reach beyond IT.
Can we rely on our cyber or third-party assessments?
For the overlapping requirements, yes, provided the reliance is assessed and documented under Standard 9.5 and the resilience-specific aspects (crisis-mode controls, minimum inventory, alternative suppliers) are tested in the resilience engagement.
What if the organization has no resilience strategy at all?
That is a Not established result on G-A and usually G-B, and a High finding. The requirement is a minimum baseline; the absence of a board-adopted strategy means the baseline is not met, whatever the quality of the continuity plans beneath it.
Does it apply to small organizations?
It applies to any assurance engagement on the topic, in any organization. Proportionality is handled through the exclusion mechanism and the depth of testing, not by exemption; a 200-person company still needs an owner, a process inventory, tested plans and a lessons-learned process, at a scale that fits it.
Where can we get the requirement itself?
From the IIA’s standards pages, with its user guide. This workbook paraphrases the requirements; the engagement file should cite the IIA’s document and version.
Related guides
- IIA Topical Requirements explained — the mechanism, the dates and what is mandatory.
- The Cybersecurity Topical Requirement: a conformance workbook — the sibling for CP-B to CP-D.
- The Third-Party Topical Requirement — the sibling for CP-A.
- The Organizational Behavior Topical Requirement — the sibling for G-E and CP-H.
- How to audit business continuity and resilience — the continuity engagement in depth.
- How to audit backups and recovery — the restore test behind CP-E.
- Auditing cyber resilience — recovery capability under attack.
- Third-party resilience — continuity when a supplier fails.
- How to audit incident response — RM-D’s five stages.
- DORA for internal auditors — the EU regime in the crosswalk.
- Assessing cybersecurity with NIST CSF 2.0 — the Govern, Respond and Recover functions.
- Internal audit and disaster recovery — before, during and after a crisis.
- Five business continuity concepts — the vocabulary.
- How to run an RCSA — the assessment mechanics behind RM-A.
- Risk appetite statements — setting the tolerances RM-C needs.
- Third-party risk management end to end — the program behind CP-A.
- How to audit operational risk management — the framework audit, test by test.
- Risk taxonomy — building the categories everything else uses.
- Operational Resilience Explained: Services and Tolerances — important business services, impact tolerances, scenario testing and the regimes compared
- How to Audit Business Continuity: End-to-End Work Program — a test-by-test program for governance, BIA, plans, exercises and vendors
- How to Run a Business Impact Analysis: RTOs, RPOs, Method — how to run a BIA that produces RTOs, RPOs and dependencies management will defend
Leave a Reply