Internal Audit
How to Audit a Business Continuity Plan
Confirming a plan exists is not an audit. A useful one tests whether the recovery assumptions inside it would survive contact with a real disruption.
By Eric Kennedy · Originally published Sun Feb 15 2026 · Updated Thu Aug 27 2026 · 10 min read
TL;DR
A business continuity audit evaluates whether an organization could actually recover its critical operations within its stated objectives, not whether it has documented a plan to try. The useful engagement works through seven areas in order: governance, business impact analysis, recovery strategy, dependencies, controls, testing, and maintenance. For each, the auditor asks one question, names the evidence that would answer it, and knows the failure mode that shows up most often. The most common findings are not missing plans. They are recovery time objectives nobody has validated, dependencies nobody mapped, and tabletop exercises designed to succeed. Under the IIA's Organizational Resilience Topical Requirement, effective April 30, 2027, continuity and recovery plans are addressed in one of twenty criteria covering a much broader topic.
Stop Auditing for Existence
The weakest version of this engagement tests whether documents exist. Is there a plan. Is there a business impact analysis. Was a tabletop held in the last twelve months. Are contact lists current.
Every one of those can come back clean at a company that could not recover.
Existence testing is popular because it is fast, the evidence is unambiguous, and the report writes itself. It is also close to worthless in most cases, because in practice the consequential failure is rarely an absent document. It is a document containing assumptions nobody checked.
A useful business continuity audit asks a harder question. If the disruption in the plan happened next Tuesday, would the organization meet the recovery objectives it has committed to, using the resources it actually has, with the people who would actually be available?
That question cannot be answered from the plan alone. It gets answered by testing the assumptions the plan rests on.
Business Continuity Audit Checklist: 7 Areas to Test
Work through these seven areas in order. Sequence matters: testing recovery strategy before you have validated the business impact analysis means testing whether the company can hit targets that may themselves be wrong.
1. Governance. Who owns continuity, what authority do they have, and who approved the current plan?
2. Business impact analysis. Which processes are actually critical, how was that determined, and when?
3. Recovery strategy. What are the recovery time and recovery point objectives, and on what basis?
4. Dependencies. What does recovery rely on that the organization does not control?
5. Controls. What happens to the control environment when the process runs manually?
6. Testing. What has been tested, under what conditions, and what failed?
7. Maintenance. What triggers an update, and has the plan kept pace with the business?
Two of these deserve more attention than they usually get.
Dependencies is, in my experience, where mid-market continuity plans tend to be thinnest, because the dependency that matters is often not the one in the plan. Plans name the ERP vendor and the data center. They tend not to name the single person who knows the pricing logic, the bank relationship that funds a recovery, or the fact that the alternate supplier and the primary supplier both source from the same upstream plant. A dependency the organization does not control and has not confirmed is an assumption wearing a mitigation label.
Controls is the area auditors are best positioned to catch and, in my experience, the one most often left out of scope. Every manual workaround is a temporary control environment that nobody designed. When invoicing runs on a spreadsheet for three weeks, the approval limits, the segregation of duties, and the audit trail that existed inside the system do not automatically exist outside it. The plan will describe how the work gets done. It will usually be silent on who authorizes it and how anyone would later prove what happened. That silence is a finding, and it is one an internal auditor is uniquely qualified to raise.
The Audit Program
For each area: the question worth asking, the evidence that answers it, and the failure that shows up most often.
| Area | Audit question | Evidence | Common failure |
|---|---|---|---|
| Governance | Who has authority to declare a disruption and commit resources? | Approved policy, delegation of authority, board or committee minutes | Plan owned by a coordinator with no authority to spend |
| Business impact analysis | How was criticality determined, and by whom? | BIA methodology, process inventory, business owner sign-off, date of last refresh | BIA inherited from a prior year and never revalidated |
| Recovery strategy | On what basis were the RTOs and RPOs set? | Documented recovery capability, backup and failover architecture, capacity assumptions | RTOs set by aspiration and never tested against actual capability |
| Dependencies | What does recovery require that a third party controls? | Critical vendor inventory, contracts, alternate supplier list, single points of failure | Vendor recovery capability assumed, never contractually confirmed |
| Controls | Which controls fail when the process runs manually? | Manual workaround procedures, compensating controls, authorization limits | Workarounds documented for operations, silent on approvals and segregation |
| Testing | What was tested, and what failed? | Exercise scope, scenario, participants, results, remediation tracking | Exercises designed around a scenario the team already handles well |
| Maintenance | What triggers a plan update? | Change triggers, version history, evidence of updates after real change | Annual review cycle that misses acquisitions, system changes, and turnover |
The pattern across the failure column is the same. In each case the plan is present, populated, and internally consistent. What is missing is any evidence that a number in it was ever checked against reality.
Testing the Test
Tabletop exercises are where a continuity audit earns its keep, because the exercise is where assumptions either get tested or get confirmed for the wrong reasons.
Do not ask whether an exercise happened. Ask four things about the one that did.
Was the scenario plausible or comfortable? An exercise built around a scenario the team has managed before produces a smooth run and no information. The useful scenario is one where the primary recovery option is unavailable.
Did leadership actually decide anything? Many exercises walk through a plan without requiring a single decision under time pressure. If nobody had to choose between two bad options, the incident command structure was described rather than tested.
Were the backup processes used or discussed? There is a difference between agreeing that the manual process would be used and running a transaction through it.
What failed, and where did it go? An exercise that produces no failures at all is worth a second look, since it usually means the scenario was undemanding rather than that the organization is unusually well prepared. Trace whatever did surface to remediation items with owners and dates, and check whether last year's items were closed.
The question a CAE should be able to answer after this section is whether the organization has ever discovered something uncomfortable during an exercise. If it has not, the exercises are ceremony.
What Findings Actually Look Like
Distinguish two categories in the report, because they go to different people and carry different urgency.
A plan deficiency is a documentation or process gap. The plan is missing a section, the contact list is stale, the BIA has not been refreshed, roles are undefined. These are real and they are fixable by the continuity owner.
A resilience exposure is a case where the organization could not recover as committed, regardless of what the documents say. A recovery time objective that the infrastructure cannot support. A critical vendor with no alternative and no contractual recovery commitment. A manual workaround that would breach segregation of duties for as long as it ran.
That second category does not belong to the continuity coordinator. It belongs to whoever can fund infrastructure, renegotiate a contract, or accept the exposure formally. Reporting a resilience exposure as a plan deficiency is the most common way a good finding dies, because it gets routed to someone without the authority to resolve it.
The findings I see most often, offered as practitioner judgment rather than as survey data:
- Recovery time objectives that were never validated against actual recovery capability
- Critical dependencies on third parties whose own recovery capability was assumed
- Manual workarounds documented for operations but silent on approval and segregation controls
- IT recovery planning disconnected from business process recovery
- Exercises scoped to scenarios the organization already handles well
- Plans not updated after acquisitions, system migrations, or key personnel departures
The Broader Requirement
One thing worth knowing before scoping this engagement in 2027 or later.
The IIA's Organizational Resilience Topical Requirement, issued April 30, 2026 and effective April 30, 2027, is mandatory for assurance services. Business continuity and disaster recovery plans appear in exactly one of its twenty requirements. If you scope an engagement on organizational resilience, a continuity audit will not cover the topic, and the requirement asks for a documented rationale wherever an individual requirement is excluded.
That does not diminish this engagement. Auditing the continuity plan well is still worth doing, and Control Processes E asks precisely for it: plans that exist, define roles for personnel and recovery teams, are tested periodically, with results including improvement opportunities reported to the board and senior management.
It does mean a continuity audit and a resilience audit are different engagements with different scopes. It also means the criterion is narrower than the engagement described above, so a well-run continuity audit will generally exceed what Control Processes E asks about. The distinction, and what the other nineteen requirements ask for, is covered in business continuity is not organizational resilience.
Where to Start
Take the current plan and find every number in it. Recovery time objectives, recovery point objectives, staffing assumptions, capacity assumptions, vendor restoration commitments. For each one, ask what evidence exists that it is achievable.
Numbers with no supporting evidence are your engagement scope. In most first-time audits that list is longer than anyone expects, and it is more useful than a document completeness checklist.
One caution on tone. A first continuity audit run this way produces an uncomfortable report, and the people who wrote the plan are usually not the reason it will not work. Recovery objectives get set by committee, infrastructure gets funded years earlier under different assumptions, and vendor commitments get inherited through contracts nobody renegotiated. Findings written as though somebody was careless will be resisted. Findings written as exposures the organization has been carrying without deciding to carry them tend to get funded.
If the exercise surfaces exposures that run past continuity into how the organization identifies and owns risk generally, 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 Explore the ERM Diagnostic
Frequently Asked Questions
What is a business continuity audit?
A business continuity audit is an internal audit engagement that evaluates whether an organization could recover its critical operations within its stated recovery objectives following a disruption. It goes beyond confirming that a plan exists to test the assumptions the plan depends on: how criticality was determined, whether recovery time objectives match actual recovery capability, which dependencies sit with third parties, what happens to controls during manual workarounds, and what past exercises actually revealed.
What documents should internal audit request for a business continuity audit?
Request the business continuity plan, the business impact analysis and its methodology, disaster recovery plans, the critical vendor inventory with contracts and alternate supplier lists, documented recovery time and recovery point objectives, the incident and escalation matrix, crisis communications plan, testing and tabletop exercise records including results and remediation tracking, manual workaround procedures, and version history showing when and why the plan was last updated. The version history and the testing results are usually the most revealing.
How do you audit a business continuity plan test?
Examine the scenario, not just the fact that a test occurred. Ask whether the scenario removed the primary recovery option or was one the team already handles well, whether leadership had to make decisions under time pressure, whether backup processes were actually executed rather than discussed, and what failed. Then trace failures to remediation items with named owners and dates, and check whether items from the prior exercise were closed. An exercise that produced no failures is usually a sign of an easy scenario rather than a resilient organization.
What are the most common business continuity audit findings?
Recovery time objectives that were never validated against actual capability, critical third-party dependencies whose recovery capability was assumed rather than confirmed, manual workarounds documented for operations but silent on approvals and segregation of duties, IT recovery planning disconnected from business process recovery, exercises scoped to comfortable scenarios, and plans not updated after acquisitions, system migrations, or key personnel departures. In practice, a missing plan is rarely the problem. Unvalidated assumptions inside an existing plan usually are.
Does a business continuity audit satisfy the IIA Organizational Resilience Topical Requirement?
No. Business continuity and disaster recovery plans appear in one of the twenty requirements in the IIA's Organizational Resilience Topical Requirement, which was issued April 30, 2026 and becomes effective April 30, 2027. The other requirements cover a board-adopted resilience strategy, board reporting on resilience objectives, incident command structure, defined accountability for resilience risk, escalation thresholds, scenario analysis and stress testing, critical third-party identification, budgeted response resources, training, and post-incident learning. A continuity audit remains a legitimate engagement, but scoping an engagement on organizational resilience requires covering the broader set or documenting why individual requirements were excluded.