Continuity under ISO 27001 is two promises: stay secure while disrupted, and recover in time.

1. 5.29
   Information security during disruptionPlan how security controls keep working, or are replaced, while the business runs in an abnormal state.
2. 5.30
   ICT readiness for business continuityPlan, build and test the technology recovery that the business's continuity needs depend on.

The first is easy to forget. During an outage people share passwords, bypass approvals and copy data to personal devices to keep work moving. Control 5.29 asks you to decide in advance which controls must hold, which can relax, and what replaces them.

A business impact analysis (BIA) asks each part of the business what it does, what happens as time passes without it, and what it depends on. The answers set how fast each activity must come back and how much recent data it can afford to lose. Those become the objectives IT must meet.

Recovery time objective (RTO)

The target time to bring an activity or system back after it stops.

Recovery point objective (RPO)

How far back in time the restored data may be; in effect, how much recent data you can accept losing.

Maximum tolerable downtime

The point after which the damage becomes unacceptable. The RTO must sit inside it.

We give no figures on purpose. The right objectives come from your own BIA and your customer commitments.

1. 1WalkthroughThe team reads the plan against a scenario and checks contacts, steps and dependencies. Cheap, and catches stale plans.
2. 2Component restoreRestore one system or database from backup and time it against the RTO, then check data age against the RPO.
3. 3FailoverSwitch a service to its standby site or region and back, under controlled conditions.
4. 4Full exerciseRun a whole business activity on recovered systems, including the security controls 5.29 requires.

How to design a restore test an auditor can trust is covered on the SOC 2 recovery-testing page, and the same design works for ISO 27001. Here the point is the link: each test should name the objective it proves and record whether it was met.

• SOC 2 guideBackup and recovery tests that satisfy SOC 2Designing a test an auditor can sample and trust.

1. Pick one critical activity from your BIA and read its stated impact and dependencies.
2. Find the RTO and RPO set for the systems it needs, and who approved them.
3. Ask for the most recent test that covered those systems, and compare results with the objectives.
4. Look at what happened when a test missed: a finding, an action, a retest.
5. Check the plan says how security controls run during disruption, for 5.29.

• Objectives set by IT alone. Without business input, the RTO reflects what is easy, not what is needed.
• Backups mistaken for continuity. Backups help. A plan still needs people, order of restore, and communication.
• Tests with no timing. A restore that worked, with no record of how long it took, cannot prove an RTO.
• Security forgotten in the outage. No rule on emergency access or temporary workarounds leaves 5.29 unmet.
• A plan that never changes. New systems and suppliers since the last BIA are not in it.

Sources: ISO/IEC 27001:2022 Annex A control names 5.29 and 5.30; ISO/IEC 27002:2022 as background (not quoted); NIST SP 800-34 Rev. 1 on contingency planning, for business impact analysis and the RTO and RPO ideas; ISO/IEC 27031 on ICT readiness for business continuity and ISO 22301 on business continuity management systems, named only. Tables and examples are our own illustration.