ISO 27001 A.5.29-30: Business Continuity in the Context of Information Security

Two Controls, One Goal

Controls A.5.29 and A.5.30 belong together in substance and address the same overarching goal: ensuring that information security is maintained even when normal business operations are disrupted.

A.5.29 is titled "Information security during disruption" and requires the organization to plan how it maintains information security during and after disruptions. A.5.30 is titled "ICT readiness for business continuity" and requires that information and communication technology is prepared so that business continuity can be ensured.

The difference between the two controls is subtle but important: A.5.29 considers information security as a whole (including organizational and physical aspects), while A.5.30 focuses specifically on technical ICT readiness. In practice, they overlap significantly, and most companies treat them as a combined package.

Delineation: ISMS Is Not the Same as BCM

A common misconception: ISO 27001 does not require a complete business continuity management system in the sense of ISO 22301. It requires that the information security aspects of business continuity are addressed within the ISMS.

In practice, this means: you do not need a certified BCM, but you need an answer to the question of how you ensure the confidentiality, integrity, and availability of your information when critical systems fail, a location becomes inaccessible, or a cyberattack paralyzes normal operations. Creating a disaster recovery plan is one of the central tasks in this context.

For a company with around 100 employees, a pragmatic approach is sensible: focus on business-critical processes and their IT dependencies. You do not need a plan for every conceivable scenario, but you do need one for the realistic and damaging scenarios.

The Business Impact Analysis (BIA)

The BIA is the methodological foundation for everything that follows. It answers two central questions: which business processes are critical? And how long may each of these processes be down at most?

Step 1: Identify Business Processes

List all significant business processes. For a company with around 100 employees, these are typically 15 to 25 processes. Some examples: order processing, invoicing, customer service, email communication, production control, human resources, procurement, logistics, sales.

Do not work on this solely within the IT department. The BIA is a business topic. The business units must assess how critical their processes are, not IT.

Step 2: Assess the Impact of an Outage

For each business process, you assess the impact of an outage over various time periods. What happens if the process is down for one hour? Four hours? One day? Three days? One week?

The assessment dimensions typically include:

Financial impact: Direct revenue losses, contractual penalties, costs for emergency measures.

Legal and regulatory impact: Violations of laws, reporting deadlines, contractual obligations.

Reputational impact: Loss of customer trust, negative media coverage.

Operational impact: Disruption of downstream processes, backlogs, capacity bottlenecks.

Step 3: Define MTPD and RTO

From the impact assessment, you derive two central metrics:

Maximum Tolerable Period of Disruption (MTPD): The maximum tolerable downtime, after which the impact on the company is no longer bearable. The MTPD is a business decision, not a technical one.

Recovery Time Objective (RTO): The target time within which a system or process must be restored after a disruption. The RTO must be less than the MTPD, ideally significantly less, to provide a safety buffer.

Recovery Point Objective (RPO): The maximum tolerable data loss, expressed as a time span. An RPO of 4 hours means: you accept the loss of the last 4 hours of data. The RPO determines the backup frequency.

Step 4: Map IT Dependencies

For each critical business process, you identify the IT systems it depends on. Order processing might need the ERP system, email, internet access, and the printer. Customer service might need the ticketing system, the phone system, and the knowledge base.

This mapping is essential because it shows which IT systems are critical for business continuity and what priority they have during recovery.

Practical Example: BIA for a Mechanical Engineering Company

A mechanical engineering company with 95 employees conducted its BIA as follows:

This table immediately shows: ERP and email have the highest recovery priority because they have the shortest MTPDs and are needed by the most critical processes.

Recovery Planning

The BIA shows you what is critical. Recovery planning describes how you restore it.

Recovery Plan per Critical System

For each critical IT system, you need a documented recovery plan. The recovery plan answers the following questions:

Recovery scenario: What exactly needs to be restored? The entire server? Just the application? The database?

Recovery steps: A step-by-step guide that an administrator who does not regularly manage the system can execute. This is important because in an emergency, the responsible administrator may be sick, on vacation, or affected themselves.

Dependencies: Which systems must be restored before this one? An ERP system first needs the database server, which in turn needs the network and storage.

Responsibilities: Who performs the recovery? Who is informed? Who authorizes the resumption of operations?

Backup sources: Where are the backups located? How are they accessed? What credentials are needed?

Escalation path: What happens if recovery is not achieved within the RTO? Who is escalated? What external service providers can be called in?

Redundancy and Failover

In addition to recovery after a total failure, you should also provide redundancy measures for the most critical systems:

Server redundancy: Critical servers run as a cluster or have a standby server that takes over in case of failure.

Site redundancy: Backups are stored at a different location, either physically or in the cloud. If the data center burns down, a backup in the same room is of little use.

Network redundancy: A second provider or a mobile fallback solution exists for internet access.

Power redundancy: A UPS bridges short power outages, a generator handles longer ones.

Which redundancy measures are appropriate follows from the BIA: the shorter the RTO, the more redundancy you need, because pure recovery from backup typically takes hours.

Information Security in Emergencies

A.5.29 emphasizes an aspect that is often forgotten: information security must not be abandoned in an emergency. In practice, exactly that happens regularly. Under time pressure, passwords are shared, access rights are generously granted, unencrypted channels are used for data transfer, and security measures are disabled to accelerate recovery.

The recovery plan should therefore explicitly specify which security measures remain in effect during an emergency and which may be temporarily relaxed. Every relaxation must be documented and reversed after normal operations are restored.

Testing Emergency Plans

A recovery plan that has never been tested is a hope, not a plan. A.5.29 and A.5.30 explicitly require that emergency preparedness is regularly tested.

Test Types

Tabletop exercise: Participants sit together and walk through a scenario mentally. "It is Monday, 9 AM, the ERP server is unreachable. What do we do?" This exercise can be conducted with minimal effort and already uncovers many gaps in the plans.

Walkthrough test: Participants go through the recovery plan step by step and verify whether the described steps are still current, whether contact details are correct, and whether required resources are available — without actually performing the recovery.

Technical restore test: A backup is actually restored on a test system to verify that the backup is complete and functional and that recovery is achievable within the RTO.

Simulation test: A realistic scenario is played out where systems are actually shut down and restored from backups. This test has the highest validity but also the highest risk and effort.

Test Frequency for Around 100 Employees

A pragmatic test plan looks like this:

• Tabletop exercises: Twice per year, each with a different scenario (e.g., ransomware attack in spring, cloud provider outage in autumn)
• Technical restore tests: Quarterly for the most business-critical systems, at least annually for all systems with defined recovery plans
• Walkthrough tests: Annually for all recovery plans
• Simulation test: Every two years for the most critical scenario

Lessons Learned

After every test, a debrief is mandatory. What worked? What did not? What gaps were uncovered? What measures are derived? The results feed into updating the recovery plans and close the PDCA cycle.

Typical Audit Findings for A.5.29 and A.5.30

Finding 1: No Business Impact Analysis

The company has recovery plans but no documented BIA. RTOs were set "from gut feeling" without systematically assessing business impacts.

Prevention: Conduct a BIA involving the business units. The BIA does not need to be hundreds of pages. A structured table with processes, impact assessments, and derived RTOs/RPOs is sufficient for a company with around 100 employees.

Finding 2: Outdated Recovery Plans

The recovery plans are two years old. Since then, servers have been migrated, cloud services introduced, and contacts changed. The plans describe systems that no longer exist and name employees who have left the company.

Prevention: Review recovery plans at least annually and after every significant change to IT infrastructure.

Finding 3: No Test Evidence

Plans exist, but there is no evidence they have ever been tested. No test protocol, no exercise report, no lessons learned.

Prevention: Document every test with date, scenario, participants, results, and derived measures. A simple test protocol template is sufficient.

Finding 4: RPO and Backup Frequency Do Not Match

The BIA defines an RPO of 4 hours, but the backup runs only once daily at night. In an emergency, up to 24 hours of data would be lost, even though only 4 hours are tolerable.

Prevention: Align backup frequency with the RPO. An RPO of 4 hours requires a backup at least every 4 hours or continuous data protection (e.g., transaction log backup).

Finding 5: Information Security During Emergency Not Addressed

Recovery plans exist but contain no provisions for information security during recovery. It is unclear whether the same access controls apply in an emergency, how temporary access is handled, and when normal security operations are restored.

Prevention: Add a section on information security during recovery to every recovery plan.

How ISMS Lite Supports Compliance

BCM controls with implementation guidance: ISMS Lite includes the relevant business continuity controls from 11 frameworks with practical implementation recommendations. For A.5.29 and A.5.30, you get actionable guidance on what needs to be documented and implemented.

Structured documentation: Business processes, impact assessments, RTOs/RPOs, and recovery procedures can be documented in a structured way within ISMS Lite. Versioning ensures that changes remain traceable.

AI-assisted policy generation: The local AI helps you create BCM policies and procedure documents tailored to your organization.

Approval workflows: Recovery plans and BCM documents go through defined approval processes, so you can demonstrate at any time who approved what and when.

Further Reading

• Business Impact Analysis (BIA): Systematically Assessing Business-Critical Processes
• Creating a Recovery Plan: Starting IT Systems in an Orderly Manner
• Planning a Tabletop Exercise: Walking Through Emergencies at the Conference Table
• Backup Strategy and Restore Tests: Data Protection That Works in an Emergency
• IT Emergency Handbook: What Belongs Inside and How to Keep It Current