A business-continuity auditor rarely asks whether you have a DR plan. They ask a more specific question: “Show me the evidence that satisfies ISO 22301 clause 8.5, and SOC 2 availability criterion A1.3.” If your resilience program lives in a folder of Word docs and a calendar reminder, answering that means a scramble — finding the plan, the test results, the dates, and then arguing that they map to the clause.
Talarity runs the resilience program as structured data — Business Impact Analyses, recovery plans, continuity tests, DR exercises — and then crystallizes it into a DR Test Attestation that does the framework accounting for you: every report auto-cites the exact ISO 22301, SOC 2, ISO 27001, and NIST CSF clauses the evidence answers to. The auditor’s question stops being a scramble.
Who’s involved
- Compliance lead — owns the framework mapping and hands the evidence to the auditor.
- BC/DR / resilience owner — runs the BIAs, plans, and tests.
- Auditor — wants the clause, the evidence, and the date — in one artifact.
What’s on the page
Open Business Continuity & DR (under Governance).
- The program dashboard — counts of BIAs, recovery plans, and tests; BIAs by criticality; plans by latest test outcome; and a dependency map.
- The workspace tabs — BIAs, Recovery Plans, Continuity Tests, DR Exercises, Emergency Contacts, Crisis Comms, and Program.
- Readiness + the DR Test Attestation — a pre-audit readiness score and the signed test-evidence capstone, with ISO 22301 / DORA / NIST SP 800-34 citations applied for you.
Step 1 — Your BC/DR program
Open Business Continuity & DR under Governance. The dashboard is the program at a glance — here 11 BIAs, 5 recovery plans, 7 tests — with BIAs by criticality, plans by latest test outcome, and dependency mapping. The subtitle says it plainly: this program aligns with ISO 22301 / DORA / NIST SP 800-34 expectations.
Step 2 — Recovery plans with real recovery objectives
Each recovery plan carries the things an auditor checks: the scenario, the target RTO and RPO, the status, the latest test outcome, and when the next test is due. This is the operational substance behind ISO 22301 clause 8.4 (business continuity procedures) — not a narrative, a structured plan with measurable objectives.
Step 3 — Continuity tests: the “exercising and testing” evidence
ISO 22301 clause 8.5 is literally titled Exercising and testing, and SOC 2 A1.3 is recovery plan testing. The Continuity Tests tab is where that evidence lives — each test with its type (tabletop, simulation, parallel), the plan it exercises, the outcome (passed / partial / failed), and the actual RTO achieved against target.
Step 4 — Program coverage, not just plans
Auditors care about coverage — are your critical assets actually exercised? The Program tab scores the portfolio against a scope policy: here 100% fresh coverage, 6 of 6 in-scope assets tested, with a per-criticality breakdown and vendor-DR coverage. That’s the answer to “is your DR program operating across the estate, on cadence?”
Step 5 — The DR Test Attestation
When you need to hand an auditor something, generate a DR Test Attestation from a recovery plan. It assembles — without any narrative writing — the plan and its recovery objectives, a test summary (RTO/RPO achieved vs. target, Met or not), the full continuity-test history, and the dependencies. One immutable, dated PDF per plan.
Step 6 — The framework citations, done for you
Here is the whole point. The attestation closes with a Compliance Citations table that maps the evidence to the exact clauses an auditor cites:
- SOC 2 A1.2 — environmental protections, backup, and recovery infrastructure
- SOC 2 A1.3 — recovery plan testing
- ISO 22301 clause 8.5 — exercising and testing
- ISO 22301 clause 8.6 — evaluation of business continuity documentation and capabilities
- ISO 27001 A.5.29 / A.5.30 — information security during disruption / ICT readiness for business continuity
- NIST CSF 2.0 RC.RP — recovery plan execution
This is the difference between having resilience and proving it. The auditor names a clause; you hand them an artifact that already names it back, with the test date and the recovery time attached.
Step 7 — Know your readiness before the audit
Before you attest, the BC/DR Readiness view (under Extended Risk) scores your maturity across seven domains — DR testing, BIA, runbooks, backups, alternate processing, cloud DR, and third-party coordination — with RTO/RPO and recovery-validation dimensions. It tells you where the evidence is thin before the auditor finds out.
How the page works
The screens are a tour of one underlying idea: the program is structured data, and the attestation reads from it rather than from a document you write. The mechanics worth knowing:
- The attestation assembles, it doesn’t author. Generating it pulls the plan’s recovery objectives, the latest test summary (actual RTO/RPO vs. target → Met / not), the full continuity-test history, and the dependency map straight from the records — there’s no narrative field for you to fill, which is why two people generating the same plan’s attestation get the same artifact.
- A readiness gate stands in front of it. The plan must have a recorded test outcome before the attestation will generate — so you can’t produce evidence for a plan that was never exercised. (Approval is a recommended step the gate checks too, but a missing approval shows as a warning rather than a hard stop.) Untested, the gate stops you with the reason.
- The Compliance Citations are derived, not typed. The clause table (SOC 2 A1.2/A1.3, ISO 22301 8.5/8.6, ISO 27001 A.5.29/A.5.30, NIST CSF RC.RP) is mapped from the kind of evidence the report contains — a tested, dependency-mapped recovery plan satisfies those clauses, so the report names them. You’re not maintaining a spreadsheet of which artifact answers which clause.
- Program coverage is computed against a scope policy. The Program tab’s “fresh coverage” % isn’t a tally you keep — it’s in-scope assets with a current test (one inside your cadence window, whatever its outcome) ÷ in-scope assets, recomputed against your cadence, so it decays on its own exactly like vendor DR coverage does.
- The output is immutable and dated. Each attestation is one PDF, fixed at generation time and filed in the Evidence Repository — the version the auditor reads is the version that existed when you ran it, not a live document that can drift afterward.
What you walk away with
- A resilience program as structured data — BIAs, plans, tests, and coverage, not a folder of docs.
- Evidence mapped to the clause — every DR Test Attestation auto-cites ISO 22301, SOC 2, ISO 27001, and NIST CSF.
- An auditor answer in one artifact — the plan, the test, the recovery time, the date, and the framework citation, signed.
Open Governance → Business Continuity & DR, pick your most critical recovery plan, and generate its attestation. The next time an auditor asks for your ISO 22301 8.5 evidence, you’ll already have it — with the clause printed on it.