Internal Audit

Business Continuity Is Not Organizational Resilience

The IIA's new Topical Requirement becomes effective April 30, 2027. Business continuity and disaster recovery plans appear in one of its twenty requirements.

By Eric Kennedy · Originally published Thu Aug 27 2026 · Updated Thu Aug 27 2026 · 11 min read

One of Twenty

Most internal audit functions already audit business continuity. The engagement is well understood. You request the plan, check that a business impact analysis exists, confirm recovery time objectives are documented, verify a tabletop exercise happened, and report on gaps.

That engagement is not going to satisfy the Organizational Resilience Topical Requirement.

Count what the requirement actually asks for. There are six requirements under Governance, four under Risk Management, and ten under Control Processes. Twenty in total. Business continuity and disaster recovery plans are named in one of them, Control Processes E, which asks that the plans exist, define roles for assigned personnel and recovery teams, are tested periodically, and that testing results including improvement opportunities are reported to the board and senior management.

That is the requirement's continuity and recovery criterion, and it is one line item. It is also narrower than the engagement most audit functions actually run, which is worth noticing in both directions.

The IIA is explicit about the relationship. It notes that internal auditors commonly assess IT processes and controls around business continuity and disaster recovery, then states that organizational resilience includes both of those plans but requires strategic planning, enterprise risk management, effective leadership and culture, and organizationwide control processes.

By my reading, four of the twenty requirements fall inside what a traditional continuity and disaster recovery audit would already touch: the continuity and recovery plans themselves, data classification and recoverability, critical IT controls and monitoring, and the IT asset inventory. That mapping is my judgment rather than the IIA's, and a reasonable CAE could draw the line one requirement in either direction. The other sixteen are not close calls. They are about strategy, board oversight, named accountability, escalation thresholds, third-party concentration, budget, training, and what the organization learned last time.

What Actually Changed

Three mechanics matter more than the topic itself.

It is mandatory, and it is not a Standard. Topical Requirements are a component of the IPPF alongside the Global Internal Audit Standards and Global Guidance. The IIA states that conformance with Topical Requirements is mandatory for assurance services and recommended for advisory services. This is a different instrument from a Statement of Position, which sits outside the IPPF and carries no conformance obligation. The distinction is worth holding onto, because the two get discussed in the same breath and only one of them binds.

It applies whether or not you planned for it. The requirement is applicable when resilience is the subject of an engagement in the audit plan, when it is identified while performing an engagement, or when it is the subject of a requested engagement that was not on the original plan. That second condition is the one that catches people. A CAE can open a supply chain engagement, find resilience inside it, and be inside the requirement without having scoped for it.

Exclusions are allowed but must be documented. Not every individual requirement applies to every engagement, and some may be fulfilled through other approaches. If a requirement is excluded, superseded by regulatory or contractual obligations, or already addressed through procedures conforming to the Standards, the rationale must be documented and retained. Conformance is evaluated during quality assessments.

That last sentence is the enforcement mechanism. The requirement does not demand that every organization pass twenty tests. It demands that an audit function which scopes resilience either covers the twenty or writes down why it did not, and that the writing down survives external review.

The dates give you room. Issued April 30, 2026, effective April 30, 2027.

AT A GLANCE

Source: The Institute of Internal Auditors, Organizational Resilience Topical Requirement, April 2026.

Most of This Is Not an IT Audit

Read the Governance requirements and notice who they are actually about.

The requirement directs internal auditors to assess whether management has established a formal organizational strategy addressing resilience, adopted and overseen by the board, covering the operational, technological, and financial elements needed to continue operations, with resilience objectives aligned to the organization's overall approach to risk management. Auditors must assess whether updates on the achievement of those objectives are periodically communicated to the board, embedded into strategic oversight, long-term planning, succession planning, culture, and the resource and budgetary decisions that support critical business activities. And whether an incident command structure exists with decision-making hierarchies, communication and escalation protocols, and defined leadership roles.

None of that is a systems test. It is a governance and finance test, and in a mid-market company it lands on the CFO and the board rather than on IT.

The Risk Management criteria point the same direction. Auditors must assess whether resilience risks are periodically identified, assessed, and managed across the organization and mapped to strategic objectives. Whether accountability is clearly defined, with a designated individual or team monitoring and reporting on those risks, including the resources needed for mitigation. Whether a process exists to monitor resilience risk levels and quickly escalate anything reaching an unacceptable level as defined by the organization's risk tolerance. And whether management has implemented and periodically tests an incident response and recovery process covering detection, prioritization, containment, recovery, and post-incident analysis, with scenario analyses and periodic stress testing against a range of disruptive events.

If those sound like enterprise risk management requirements, that is because they are. The IIA says so in the definitional section: resilience requires enterprise risk management. A company without a functioning risk program does not have a resilience gap it can close with a better continuity plan. It has a resilience gap that runs through the risk program.

Even inside Control Processes, the majority are not IT. Auditors must assess whether a process exists to identify critical third-party providers and determine minimum inventory levels to sustain essential operations, with a current list of alternative suppliers. Whether the operational, human, technological, and financial resources needed during a disruption are budgeted and available, with those financial resources periodically analyzed and communicated to the board. And whether there is training including simulated disruptive scenarios, a process for modifying the working environment during a crisis, continuous monitoring of emerging threats, and a lessons-learned process that feeds back into future planning.

The budget requirement deserves particular attention. It asks whether the money to respond has been identified and made available, not whether a plan says what you would spend it on. That is a question a CFO can answer and a continuity coordinator usually cannot.

Where Mid-Market Companies Will Struggle

For a $200 million company, several of these criteria will represent a significant step up from current practice. Three predictable pressure points.

Nobody owns it. Risk Management B asks auditors to assess whether accountability is clearly defined, with a designated individual or team monitoring and reporting on resilience risks. In most mid-market companies, continuity sits with an operations manager, disaster recovery sits with IT, third-party risk sits with procurement, and resilience as a whole sits with nobody. The requirement does not create the gap. It makes the gap auditable.

There is no strategy to test. Governance A asks auditors to assess a formal resilience strategy adopted and overseen by the board. Many mid-market companies have plans without a strategy, which is a different thing. A plan says what you do when the plant floods. A strategy says which capabilities the company protects at what cost and who decided that.

Scenario analysis and stress testing are a genuine lift. Risk Management D covers scenario analyses and periodic stress testing against a range of disruptive events. One annual tabletop does not, on its own, demonstrate that management is doing this, and building the capability is real work rather than a documentation exercise.

Worth being fair about the other side. This is a minimum baseline for auditing the topic, not a maturity model, and the IIA is clear that the organization's risk profile may require auditors to consider additional aspects. A small company with simple operations and few critical dependencies will legitimately document exclusions for several requirements, and that is the mechanism working as designed rather than a failure to comply. The requirement asks for a defensible rationale, not for every company to look the same.

It is also fair to say that a lot of this is already good practice. A CAE who reads the twenty requirements and finds fifteen of them already covered under other engagement names is in decent shape and mostly has a documentation problem.

What to Do Before April 30, 2027

The effective date gives audit functions room to do this deliberately rather than in a scramble.

Map before you scope. Take the twenty requirements and mark each one covered, partially covered, or not covered by existing engagements. Continuity, disaster recovery, third-party risk, and IT general controls will absorb more than people expect. The point is to find what nothing touches.

Establish whether anyone owns it. If no individual or team is designated for resilience risk monitoring, that is a readiness gap against Risk Management B. The requirement is not effective until April 30, 2027, so this is a benchmark against a forthcoming criterion rather than a conformance failure today. It is still the observation most likely to change something, and nothing stops you from raising it now.

Check whether the board has ever seen a resilience objective. Governance B asks for periodic communication to the board on achievement of resilience objectives. In many mid-market companies the honest answer is that the board has seen a continuity plan summary and nothing else.

Decide where this sits relative to ERM. If your organization has an enterprise risk program, resilience risks should be inside it and mapped to strategic objectives, not maintained as a parallel list. If it does not, the resilience requirement will surface that faster than anything else on the audit plan.

Write the exclusion rationales as you go. The documentation obligation is not a year-end task. Deciding in the moment why a requirement does not apply, and recording it, is far easier than reconstructing the reasoning for a quality assessment two years later.

If you want the narrower question of how to audit the continuity plan itself, which is Control Processes E and one piece of this, that is covered separately in how to audit a business continuity plan.

The Harder Question

The requirement is addressed to internal auditors, but the interesting question it raises is not an audit question.

If resilience requires a board-adopted strategy, named accountability, defined escalation thresholds, scenario analysis, budgeted response resources, and integration with enterprise risk management, then a company that cannot demonstrate those things does not have an audit finding. It has an operating gap that an audit finding will describe.

Internal audit can report it. Somebody else has to fix it, and in a mid-market company that somebody is usually the CFO.

Where to Start

Print the twenty requirements. Go through them once, marking each covered, partial, or absent against what your audit plan already includes. That exercise takes about an hour and it will tell you whether you are looking at a scoping change or a program gap.

If the answer is a program gap, and particularly if several requirements point back to enterprise risk management that does not yet exist in a workable form, the ERM Program Diagnostic is a one-to-two-week, fixed-fee review built for mid-market organizations, and the fee is credited toward a larger engagement if you move forward.

Take the ERM Scorecard{.cta-primary} Explore the ERM Diagnostic{.cta-secondary}