The request letter arrives with forty items and a due date three weeks out. Item 17 asks for "evidence of remediation of issues identified in business continuity testing during the review period." You have last year's failover test report, and it lists six issues. Your tracker shows two closed, three open past their due dates, and one that nobody can explain. The test went fine. The finding will be about what happened afterward.
That is the shape of most business continuity findings. Programs rarely get written up because a plan is missing. They get written up because the evidence shows a gap between what the program says it does and what it actually did. A review is uncomfortable, but it is one of the few times anyone outside the continuity team reads the program end to end, and a well-handled one often secures the budget and attention that a year of memos did not.
Three kinds of scrutiny
"Audit" gets used loosely. The three main types differ in who is asking, what yardstick they use, and what happens when they find something.
| Internal audit | Regulatory examination | ISO 22301 certification audit | |
|---|---|---|---|
| Who | Your internal audit function (third line) | Examiners from a supervisory agency | An accredited certification body |
| Yardstick | Internal policy, regulatory expectations, audit methodology | Agency guidance, such as the FFIEC BCM booklet for US financial institutions | The requirements of ISO 22301 |
| Frequency | Risk-based audit plan, often every one to three years | Exam cycle; BCM may be a targeted review or part of a wider IT exam | Two-stage initial audit, annual surveillance, recertification every three years |
| Output | Report with ratings and management action plans | Report of examination; findings may become Matters Requiring Attention (MRAs) or, if serious, enforcement | Major and minor nonconformities, observations |
| Consequence | Visibility to the board's audit committee | Supervisory pressure, ratings impact, possible enforcement | Certificate withheld or suspended until major nonconformities close |
External auditors add a fourth angle. Financial-statement auditors test IT general controls, and service organizations commission SOC 2 reports that can include availability criteria. Those reviews touch continuity but seldom go deep.
The practical difference is motive. Internal audit wants management to fix things before regulators see them. An examiner is judging whether the board and management are in control. A certification auditor checks conformity to the standard and has no interest in anything the standard does not require.
What examiners look for
For US financial institutions, the reference point is the FFIEC's Business Continuity Management booklet, issued in November 2019 to replace the older Business Continuity Planning booklet. The change of title was deliberate. The 2019 booklet moved the emphasis from recovering after an event toward resilience: an enterprise-wide management process, owned by the board and senior management, covering people, processes, technology, facilities, and third parties. The shift is often summarized as "from recovery to resilience," and the UK and EU rules that followed went further in the same direction (see the plain-English guide to operational resilience rules).
These themes run through the booklet and most request lists:
| Theme | What they ask for | What good evidence looks like |
|---|---|---|
| Governance | Board-approved policy, committee minutes, defined roles | Minutes that record questions asked and decisions made, not "presentation received" |
| BIA and risk assessment | Current BIA, risk assessment, interdependency analysis | Dated BIA signed off by business owners, with changes since the last cycle explained |
| Strategies and resilience | Recovery strategies, alternate sites, backup and replication | Strategies that meet BIA targets, with capacity demonstrated |
| Plans | Enterprise and business-line plans | Owners, versions, and evidence of recent review |
| Training | Training plan and completion records | Role-based training, not only annual awareness clicks |
| Exercises and tests | Test program, plans, results, after-action reports | Scope that escalates over time; issues tracked to closure |
| Third parties | Critical vendor inventory, due diligence, vendor test results | Reviews scaled to criticality; tests run with key providers |
| Maintenance and improvement | Change triggers, update logs | Plans updated after reorganizations, system changes, and incidents |
| Board reporting | Periodic reports to the board | Reports that state residual risk and open issues plainly |
Cyber resilience cuts across several rows. Expect questions about how the program would handle destructive malware or the loss of a critical service provider, not only the loss of a building.
Building the evidence pack
Treat the evidence pack as a product. A well-organized pack shortens fieldwork, reduces follow-up requests, and signals a program that is under control.
- Mirror the request list. Number folders to match request items exactly. If one document answers several items, cross-reference it instead of copying it.
- Write an index. For each item: what the document is, its date, its owner, and which requirement it addresses, in one line.
- Show design and operation. A policy shows design. Minutes, test results, and closed tickets show operation. Reviewers want both.
- Date and version everything. An undated document invites the question of whether it is current.
- Do not pad. Volume reads as an attempt to bury the answer. Provide what was asked, plus what is needed to make it intelligible.
- Disclose known gaps. If something is open, say so and include the remediation plan with dates. A self-identified issue with a credible plan lands very differently from one the examiner discovers.
- Check consistency. RTOs in the BIA, the plans, the DR runbooks, and the vendor contracts should agree. Mismatches are among the easiest findings to write.
If your plan structure is hard to map to a reviewer's framework, the annotated business continuity plan outline includes a clause-by-clause mapping to ISO 22301 and NFPA 1660.
Interviews
Expect interviews with the program owner, a sample of business-line coordinators, IT disaster recovery leads, vendor management, and sometimes the executive or committee chair who oversees the program. A few rules keep them productive.
- Answer the question asked, then stop. Long answers wander into territory nobody asked about.
- "I don't know, but I'll find out" is a good answer, provided someone logs the follow-up and it arrives on time.
- Never guess at a number. Say where it comes from, or go and get it.
- Coordinators should be able to walk through their own plan and their part in the last exercise. If they cannot, that tells the examiner more than any document.
- Prepare people, but do not script them. Rehearsed answers that contradict the documents are worse than plain ones.
Handling findings
Most reviews end with a draft report or an exit meeting. Use the factual-accuracy review to correct errors of fact, not to argue about severity you simply dislike. Then write a response that will survive follow-up.
- Fix the cause, not the instance. If a test issue went unremediated, the finding is about issue management, not that one issue. A response that closes the single item and changes nothing else will be back next cycle.
- Owners, milestones, dates. Name a person, break the work into milestones, and pick dates you can meet. Missing a self-imposed date on an MRA becomes a second problem.
- Define done. State what evidence will show the issue is closed, so audit or the examiner can validate it.
- Expect sustainability testing. Supervisors typically want to see that a fix has operated over time before closing an MRA, not merely that it was implemented.
- Report progress upward. Senior management and the board should see remediation status regularly. Examiners will check that they did.
Common findings and fixes
| Finding | Usual root cause | Fix |
|---|---|---|
| BIA out of date | No refresh trigger; owner left | Annual cycle plus change triggers; named owners |
| RTOs inconsistent across documents | BIA, DR, and contracts maintained separately | One system of record; reconcile every cycle |
| Test issues not remediated | No tracking discipline | Issue log with owners, dates, and escalation |
| Tests too narrow or scripted | Fear of a visible failure | Escalating test program; some unannounced elements |
| Third-party resilience not assessed | Vendor management and BC disconnected | Criticality tiering; continuity questions in due diligence |
| Superficial board reporting | Reports list activity, not risk | Report residual risk, open issues, and trends |
| No cyber scenarios | Plans built around facility loss | Add destructive-malware and provider-outage scenarios |
| Generic training | Single annual module for everyone | Role-specific training for plan owners and recovery teams |
A 90-day preparation timeline
Days 90 to 61: take stock.
- Confirm scope and the likely focus. Reread the prior report and every open finding.
- Self-assess against the relevant framework: the FFIEC booklet's examination procedures, ISO 22301, or internal policy.
- Reconcile RTOs and RPOs across the BIA, plans, DR documentation, and vendor contracts.
Days 60 to 31: close and document.
- Close what can genuinely be closed, and write credible plans for the rest.
- Refresh stale plans and contact lists, and capture management sign-off.
- Build the evidence pack skeleton and index.
Days 30 to 1: rehearse.
- Brief interviewees on scope and logistics, with one practice walkthrough per key person.
- Check the pack for dates, versions, and consistency.
- Tell senior management about known weaknesses so nobody is surprised in the exit meeting.
During fieldwork.
- One coordinator logs every request, response, and due date.
- Hold a short daily check-in with the lead reviewer to catch misunderstandings early.
Afterward.
- Factual-accuracy review, management response, remediation plan, and a calendar of progress reports to senior management.
Reviewers also look at whether the people running the program are competent, and some firms use professional credentials as part of that evidence. The comparison of business continuity certifications sets out the options.
Frequently asked questions
What is the difference between a BCM audit and a regulatory examination?
An audit is usually performed by your own internal audit function, or an outside firm acting for it, against policy and expectations, and it reports to the audit committee. A regulatory examination is performed by supervisors with authority over the institution, and its findings can carry supervisory consequences. Both look at similar evidence, but exam findings are harder to negotiate and slower to close.
What is an MRA?
A Matter Requiring Attention is a supervisory finding that US banking regulators expect the board and management to correct within a set time. It is not an enforcement action, but unresolved or repeated MRAs can escalate. Closing one usually requires evidence that the fix has worked over time, not just that it was put in place.
Do we need ISO 22301 certification to pass a regulatory exam?
No. US banking regulators do not require certification, and a certificate does not substitute for meeting supervisory expectations. Some firms certify because clients ask for it, and the discipline of a management system can make exams smoother, but the examiner still assesses the program on its own terms.
How far back will an examiner look?
Usually across the period since the last examination, with particular attention to anything raised last time. Expect requests for test results, BIA updates, board reporting, and remediation evidence from that whole window. Keep records organized by date so the period is easy to produce.