Tested recovery
We rebuild your critical software from its deposit and confirm it runs, so recovery is proven, not presumed.
Your recovery plan describes how your systems recover. A.5.30 now expects proof it works. Codekeeper rebuilds the software you depend on, confirms it recovers within your target times, and packages it into an ISO 27001 Evidence Pack for your auditor.
It isn’t a one-time exercise, either. Every system change makes last year’s test stale, so readiness has to be retested to stay valid.
However well your DR plan reads, the certificate stays unsigned until you can prove recovery works.
We rebuild your critical software from its deposit and confirm it runs, so recovery is proven, not presumed.
You get a dated, signed record that recovery was demonstrated, and when.
The pack ties each piece of evidence to the clause it satisfies, leaving nothing for the auditor to infer.
Your recovery is timed against the targets your business impact analysis (BIA) set, so “within agreed timeframes” stops being a guess.
We rerun the test on a set schedule, so readiness stays current between surveillance audits instead of going stale after one pass.
Software vendors hand clients a single pack that settles their A.5.30 evidence, instead of working through a questionnaire round.
Explain in one or two concise sentences how your solution transforms users' challenges into positive outcomes. Focus on the end benefits that matter most to your target audience. Keep it clear and compelling.
The ones whose failure would halt your business are where A.5.30 expects you to prove readiness.
An automated rebuild plus expert review runs from a vault kept separate from production, so your evidence stays current.
The certificate, the recovery test report, and the A.5.30 mapping arrive ready to drop into your audit file.
Set up in a day. From there, the pack stays current on its own.
Book a demoJordan Adler
Ross Kilshaw
Thiago Mendes
We’ll email the sample ISO 27001 continuity evidence pack to you.
A.5.30, “ICT readiness for business continuity,” is a control introduced in ISO 27001:2022. It requires that ICT recovery is planned, implemented, maintained, and tested against your business continuity objectives, so critical systems can be restored within agreed timeframes after a disruption.
A disaster recovery plan describes what should happen. The evidence pack proves it does — through a recovery test run against your software, measured to your recovery times, and documented in a certificate. A.5.30 requires the second one.
Escrow satisfies the supplier and outsourced-development controls. A.5.30 is about whether recovery works, and an untested deposit doesn’t prove that. 90% of untested escrow deposits fail when someone tries to rebuild from them. The pack is the test that closes the gap.
ISO 27001 A.5.30 primarily, plus ISO 22301, DORA (Arts. 11 and 24–25), NIS2 (Art. 21(2)(c)), and the SOC 2 Availability criterion. One recovery test gives you evidence for all of them.
A.5.30 requires ICT recovery maintained and tested at planned intervals and after significant changes, and a test only proves recovery as of the day it ran. Systems and dependencies drift, so last year's pass doesn't prove this year's recovery. Codekeeper can rerun the test on a schedule you set. We also keep deposits current with daily syncs, so the certificate reflects your systems as they stand at audit, not as they were.
Setup is live in 24 hours; recovery testing and the completed pack follow on the schedule we agree on for your systems.