- The planner works on the page. Production's three steps ("Catalog every critical dependency / Evaluate threats across your stack / Design a step-by-step recovery strategy") become a four-step wizard that returns a draft plan straight away. The toolkit download stays further down as this page's own offer.
- The calculator is fixed and shows its working. Production prints the "chance of zero incidents" as a fraction with a % sign (0.58% at one vendor, which should read 58%), and it hides a 42% per-vendor failure rate with no source. Here the formula and the assumption are on screen, and the visitor can change the assumption.
- The unsourced statistics are gone: "93% of companies file for bankruptcy after 10+ days of data loss", "98% of businesses lose over $100,000 per hour of downtime", "90% of smaller companies fail within a year if recovery takes more than 5 days", "77% of consumers end retailer relationships…", and "NIS2 and DORA fine up to €10 million or 2%" (a NIS2 floor, wrongly given for DORA). None is in the agreed list in MESSAGING §6, and together they read as fear lines.
Map what you depend on. Plan how it comes back.
Four steps: the software you rely on, the threats to plan for, how long you can be without it, and who brings it back. You'll get a draft recovery plan on this page.
Free, and no email needed for your plan. Start planning
- Trusted by 3,500+ teams
- ISO/IEC 27001:2022 certified
- 10+ years securing software
Four steps
Draft your recovery plan.
Answer for the business as a whole in steps 1 and 2, then for your most critical application in steps 3 and 4.
Your progress
- Catalogue
- Threats
- Target
- Recovery
- Your plan
What does your business run on?
Choose all that apply.
Which threats should the plan cover?
Choose all that apply.
How long can your most critical application be down?
Your recovery target. Pick the closest.
Who should bring it back?
For the same application.
Your draft recovery plan
Worked out from your answers, in your browser. Copy it into your own plan, or get the toolkit below.
1. List what you depend on
For each critical application: the owner, the vendor, where it runs, and what a recovery would need.
- Vendor software: record the version you run and the agreement that covers it.
- SaaS platforms: note where each one runs and which accounts keep it paid.
- Your own applications: record who could rebuild each one, and keep copies outside production.
- AI: list the models, prompts and pipelines each system depends on.
- Cloud hosting: record the accounts, regions and managed services, and who can access them.
- External APIs: list each service, and what your application does if one stops.
2. Plan for each threat
- Failure: agree release or recovery terms with each critical vendor now, while they're there to sign.
- Attack: keep a copy outside your own environment, and know which applications use a compromised component.
- Non-compliance: keep dated evidence that each critical application can come back, and test the exit plan.
- Broken: keep a known-good version and its data, so you can go back before the faulty change.
3. Set the recovery target
Hours. A rebuild takes time, even a fast one. If the business can only be without the application for hours, plan to keep the live service switched on while it's recovered.
A day or two. Write the target down, and make sure everything a recovery needs is deposited and current before you need it.
About a week. Write the target down, and test once that a recovery from the deposit fits inside it.
Not set yet. Ask the people who run the process: how long until customers notice, and how long until it costs real money? Write both down.
4. Decide who recovers it
5. Test the plan
Trusted by 3,500+ teams, from regulated enterprises to fast-growing software vendors
- The bug: at one vendor production shows "Chance of zero incidents 0.58%" next to "Risk of at least one failure 42.00%". It prints the probability (0.58) with a % sign; it should read 58%. Both results here are percentages.
- The formula: 1 − (1 − p)n, the chance that at least one of n vendors has a serious incident if each has chance p, independently. It's printed under the result with the visitor's own numbers.
- The assumption: production's numbers imply p = 42% per vendor, with no source and no time period. It's kept as the starting value so the page stays consistent with the flagged homepage stat (99% at ten vendors), labelled as an assumption on screen, flagged ⚑ here, and editable. Marketing: source it or replace it before launch. It also doesn't match the flagged "2 in 10 vendors fail within 3 years" (20% over three years). Production's homepage says 90% at five vendors, while this formula gives 93% (production's own planner page also says 93%).
- Removed: production's "Overall risk exposure: Moderate…" label, which turned an assumption into a verdict.
Vendor risk calculator
How small risks add up.
Each critical vendor brings its own chance of a serious incident. Across several vendors, the chance that at least one is affected grows quickly.
Chance of at least one vendor incident
Formula: 1 − (1 − 0.42)^5 = 0.934
Why plan ahead
What a plan changes on the day.
Three common situations, and what having the plan in place gives you.
A vendor goes out of business
The release terms were agreed in advance. When the conditions are met, the deposit is released to you under Escrow, or we run the recovery under Resilience. Which one fits?
A supply-chain attack
A library you rely on is compromised. The SBOM from each Pro rebuild lists the components it found, so you can see where it's used. Agentic Verification
A corrupted update
A faulty release damages your own system. Software Backup lets you restore the data and artefacts you deposited, from before the change. Software Backup
The planner toolkit
Turn the draft into a written plan.
Four templates to work through with your team, in the same order as the planner.
- Information assets list
- Internal and external data management systems
- A risk register you can adapt for your own assessments
- Risk mitigation methods
Sample evidence pack
See what your auditor would receive.
An anonymised set of outputs from a real Agentic Verification run, so you can judge the evidence before you talk to us.
- Recoverability Certificate
- Run report
- SBOM and Exit workbook excerpts
Questions
About the Disaster Recovery Planner.
What is a disaster recovery plan?
A written plan for getting critical systems back after a failure: what you depend on, which threats you plan for, how long you can be without each system, who recovers it, and how you know the recovery works.
How does the vendor risk calculator work?
It takes the number of critical vendors (n) and an assumed chance that any one of them has a serious incident (p), and works out 1 − (1 − p)n: the chance that at least one does. It assumes vendors fail independently, which shared providers can make untrue.
Where does the 42% come from?
It's an illustrative assumption, not a measured rate, and we don't cite a source for it. Replace it with your own estimate, for example from your incident history or vendor reviews.
What's in the toolkit?
Four templates: an information assets list, a list of internal and external data management systems, a risk register you can adapt for your own assessments, and risk mitigation methods.
Where does Codekeeper fit in the plan?
In parts 4 and 5. Escrow releases a vendor's deposit to you, Resilience puts the recovery with us, Continuity also keeps the live environment switched on, and Software Backup covers systems you run yourself. Agentic Verification and the Exit Exercise test the plan.
Will the plan make us compliant with ISO 27001 or SOC 2?
A plan is evidence for your file, not a certificate. Codekeeper's evidence supports your assessment; whether it meets a specific requirement is for you and your assessor to decide.
Have the plan before you need it.
Book a demo and we'll turn your draft plan into protections for the applications that matter most.