Business continuity & BIA
A business impact analysis and continuity register, the ISO 27001 Annex A 5.29 and 5.30 requirement, with RTO, RPO, recovery strategy, and continuity-test tracking on every critical process.
| Process | Criticality | RTO | RPO | Plan |
|---|---|---|---|---|
| Customer app | Critical | 4 hours | 15 min | Tested |
| Billing | High | 8 hours | 1 hour | Tested |
| Support desk | Medium | 1 day | 4 hours | Untested |
| Internal wiki | Low | 3 days | 1 day | Draft |
ISO 27001 Annex A 5.29 asks you to keep protecting information during disruption, and 5.30 asks you to be ready, with recovery objectives you can meet and that you’ve tested. Keel gives you the register for both: a business impact analysis where each critical process carries a criticality, an RTO and RPO, its impact and dependencies, a recovery strategy, and a record of when its continuity was last tested.
A continuity plan nobody has tested
Plenty of teams have a business continuity document; far fewer can show a per-process impact analysis with recovery objectives, and fewer still can prove they tested it. Annex A 5.30 is explicit about ICT readiness, objectives that are established and exercised, and that’s exactly where audits find gaps.
What business continuity & bia does
A per-process business impact analysis
Inventory your critical processes and services, each with a criticality rating and the impact of losing it, the BIA that everything else in continuity planning builds on.
Recovery objectives that are explicit
Capture an RTO (how fast it must recover) and RPO (how much data loss is tolerable) for each process, the numbers Annex A 5.30 expects you to set and meet.
Dependencies and a recovery strategy
Record what each process depends on (systems, vendors, people) and how you recover it within its RTO, so the plan is actionable rather than aspirational.
Continuity tests, evidenced
Record each continuity test with a single click; the process moves to “tested” and stamps the date. ICT readiness (5.30) is then something you can show, not just claim.
Readiness at a glance
See how many processes are high or critical, how many have been tested, and which are still untested or without an owner, the readiness summary an auditor and your leadership can read instantly.
Why it matters
- Cover ISO 27001 Annex A 5.29 and 5.30 with one continuity register
- Set and track RTO and RPO for every critical process
- Evidence that your continuity plans are actually tested, with dates
- Spot untested or unowned critical processes before an incident does
Get audit-ready, and prove it
Business continuity & BIA is one module of a full GRC platform: controls crosswalked across every framework, so you collect evidence once and comply everywhere. Start free, no credit card, no sales call.
Start freeFrequently asked questions
What is a business impact analysis (BIA)?
An assessment of your critical processes: how important each is, the impact of disruption, and how quickly it must recover. It’s the foundation of business continuity planning and what ISO 27001 Annex A 5.29/5.30 build on.
What are RTO and RPO?
Recovery Time Objective is how quickly a process must be back after disruption; Recovery Point Objective is how much data loss is acceptable (how far back you might have to restore). Keel records both per process.
Which ISO 27001 controls does this map to?
Annex A 5.29 (information security during disruption) and 5.30 (ICT readiness for business continuity) in ISO/IEC 27001:2022. It also complements Keel’s DR/BCP runbook.
How does it show our plans are tested?
Each process records when its continuity was last tested and moves to a “tested” status when you log a test, so ICT readiness under 5.30 is evidenced with a date, not assumed.
Related features: Risk register · Information asset register · Security incident register
Works with: ISO/IEC 27001