You can have a flawless recovery plan for your own systems and still be one vendor outage away from a multi-day disaster. Your business doesn’t run on your infrastructure alone — it runs on Cirrus Cloud, on Keyhold Identity for every login, on a payment processor for every dollar. If one of them can’t recover from a regional failure on a timeline you can survive, your continuity plan is fiction.
Most teams assess vendors thoroughly — for security. They send the annual questionnaire, collect the SOC 2, score the risk. But “do you have an information security program?” is a very different question from “prove you can recover from a disaster in four hours,” and almost nobody tracks the second one. ISO 22301 §8.4 expects your continuity capability to account for your supply chain; DORA makes it explicit for financial entities — you must ensure your critical ICT third-party providers can meet your recovery objectives, and evidence it. The Vendor DR Coverage page is where Talarity tracks exactly that.
Who’s involved
- Vendor manager — owns the vendor relationship; sees which of their vendors are DR-tested and which are overdue.
- DR program owner — sets which vendor tiers are in DR scope and the cadence (in the DR program scope policy).
- Auditor / regulator — confirms critical vendors have verified recovery posture, not just a security attestation.
What’s on the page
Open Vendor DR Coverage (/app/dr-vendor-coverage). It’s a deliberately small page — one question, answered three ways. The header subtitle restates the job: “when each was last DR-tested, the outcome, whether it is current against the program cadence, and the risks DR testing surfaced.”
Three KPI cards across the top give you the program-level read before you look at a single vendor:
- In-scope vendors — how many vendors your DR program has pulled into DR scope. This is not every vendor in your register — only the tiers your program owner put in scope (more on that below). Here: 7.
- Current (fresh) — how many of those have a recovery test that still counts as current against your program’s cadence. Here: 3.
- Coverage — Current ÷ In-scope, as a percentage: 43%. This is the single number you take to a board or a regulator.
The vendor table (titled “Vendor coverage (3 / 7 in-scope vendors current)”) has one row per in-scope vendor and six columns:
- Vendor — the vendor’s name, linking through to its third-party-risk profile.
- Tier — the criticality the vendor carries in your register (Critical, High, …). This is why it’s in DR scope, and it’s how you triage: a red row on a Critical vendor is a different problem from a red row on a Low one.
- Last DR Test — the date the vendor last submitted a recovery test, or — if they never have.
- Outcome — the result of that test: Passed, Partial (recovered, but missed its RTO), Failed, or Never tested.
- Status — ✓ current (tested within cadence) or Overdue (never tested, or past the cadence window). This is computed, not set by hand — see “How the page works.”
- DR Risks — the count of tracked risks this vendor’s DR tests have opened. A bad-enough test auto-creates a risk linked back to the vendor; 0 means none surfaced.
Step 1 — Read your posture at a glance
The KPIs frame it instantly: 7 in-scope vendors, 3 current, 43% coverage — fewer than half of your in-scope third parties have actually proven they can come back. Then the table tells the story per vendor:
- Cirrus Cloud (Critical) and Keyhold Identity (High) were DR-tested and Passed, so they’re current.
- Shieldnet Edge (High) came back Partial — it recovered, but missed its RTO. Still current, but the kind of row you read twice.
- Adyen, Beacon Observability, Frostware Data, and Meridian Data Services — including two Critical dependencies (a payment processor and a data service) — have never been DR-tested. They’re Overdue, and they’re exactly the blind spot that turns a vendor’s bad day into your incident.
A green security score and a red DR-coverage row can sit on the same vendor. The first says “they protect their data well.” The second says “we have no idea if they can come back.” A vendor program that only tracks the first is half a program.
How the page works
A few mechanics are worth knowing, because they explain why the numbers are what they are — and why they move on their own:
- Scope is set by the DR program, not on this page. A vendor shows up here because its tier is in your program’s scope policy. Change which tiers are in scope and rows appear or disappear — and the coverage math re-bases to the new denominator. You curate what counts in the program; this page just reports it.
- Status decays by itself. ✓ current is not a stamp someone applies — it’s Last DR Test measured against your cadence, recomputed every time the page loads. A vendor that passed twelve months ago silently flips to Overdue the day it crosses the cadence window, with nobody touching the row. The page always shows today’s truth, not the day-you-tested truth.
- Coverage is Current ÷ In-scope. Adding a vendor to scope lowers coverage until that vendor is tested — which is correct: a new critical dependency you haven’t verified genuinely is a new gap, and the number should say so.
- A bad test opens a risk, not just a number. When a vendor submits a Failed (or partial-enough) result, Talarity opens a tracked risk linked to that vendor; the DR Risks count is your at-a-glance tally of those. A non-zero number there means the recovery gap is already on your risk register, not just in your memory.
Step 2 — How a vendor moves from “never tested” to “current”
A vendor gets tested the same way an asset does — through a DR exercise — but because the vendor isn’t your employee, the loop runs over a secure external link:
- Scope the vendor into a DR exercise. From the exercise’s scope step, add the vendor (or its tier) to the run.
- Talarity sends their DR contact a one-time secure link — no account, no login, no invitation to manage.
- The vendor records the outcome — Passed / Partial / Failed — plus the actual recovery time and any issues, and submits it.
- The row here updates the moment they submit: Last DR Test, Outcome, and Status recompute against your cadence; if the result was bad enough, a risk opens and the DR Risks count ticks up.
That’s the whole point of measuring it on this page: the coverage percentage isn’t a checkbox — it’s the running tally of how much of your third-party recovery risk you’ve actually verified versus assumed.
How to close an overdue row
The page is a worklist, read top-down by tier:
- Start with the Critical, Overdue rows. Those are the third parties your business can’t run without and has never confirmed can recover — here, Adyen and Meridian Data Services.
- Scope each into a DR exercise (Step 2 above). One exercise can carry several vendors, so you don’t need a run per vendor.
- Send the link and wait for the submission. Until the vendor submits, the row stays Overdue — the number doesn’t move on intentions, only on evidence.
- Watch the row turn green and the coverage KPI climb. When the last Critical vendor reports a passing test in cadence, your coverage number is one you can hand to a DORA or ISO 22301 auditor without a caveat.
What you walk away with
- One number for third-party recovery risk — what fraction of your in-scope vendors have verified, in-cadence DR — instead of a folder of security questionnaires that never asked the recovery question.
- The overdue vendors named — Critical dependencies that have never proven they can recover, surfaced as the gap to close, not buried.
- A page that ages honestly — Status and Coverage recompute against your cadence on every load, so “we’re covered” can’t quietly become false without the number telling you.
- Evidence, not assumption — each “current” row traces back to an actual recovery test a vendor submitted, with an outcome and a date — the answer DORA and ISO 22301 auditors are looking for.
Open Vendor DR Coverage and read the coverage number, then look at which Critical vendors show “never tested.” Those are the third parties your business can’t run without and has never confirmed can recover. Scoping them into one DR exercise is how you turn that red row green — and how you find out the answer before the disaster does.