Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Starter Kit · Policy

Business Continuity Policy

Updated on 7 min Reviewed by: Cenedril Editorial
A.5.29A.5.30 ISO 27001NIS2 Art. 21(2)(c)BSI 200-4

The Business Continuity Policy governs how your organisation maintains operations when critical ICT services fail. Technical failure, cyberattack, natural disaster, human error, supply chain disruption — the cause is secondary. What matters is that pre-defined plans exist and can be activated immediately.

ISO 27001 dedicates two Annex A controls to the topic: A 5.29 (information security during disruption) and A 5.30 (ICT readiness for business continuity). NIS2 explicitly requires measures to maintain operations under Art. 21(2)(c), including backup management and crisis management. BSI provides a comprehensive BCM guide with Standard 200-4 and supplements it with DER.4 (emergency management) and CON.3 (backup concept). Further down you will find the complete template in English and German.

What does it actually cover?

Business continuity starts long before an incident occurs. The policy defines what preparations your organisation takes so that an outage remains manageable. This involves three layers: the organisational structure (who decides, who acts), the technical preparation (backups, redundancy, recovery plans) and regular verification (tests, training, lessons learned).

A 5.29 addresses the period during a disruption: when regular security controls no longer function (because a system is down, a site is unreachable, or emergency access is needed), compensating controls must step in. Who may access systems that are normally locked down? Which security requirements still apply in crisis mode? These questions sound straightforward, but they regularly cause chaos in practice when they have not been documented in advance.

A 5.30 covers preparation and recovery: Business Impact Analysis, ICT continuity plans with activation criteria and step-by-step instructions, contact lists, resource requirements and a testing cadence that ensures the plans actually work.

Why does it matter so much?

Regulatory breadth. NIS2 names business continuity in Art. 21(2)(c) as one of ten minimum measures. BSI dedicates an entire standard to the topic (200-4) and supplements it with DER.4 (emergency management) and CON.3 (backup concept). ISO 27001 requires two controls (A 5.29 and A 5.30) that depend on each other.

Economic weight. Every hour of downtime costs — directly through lost revenue, indirectly through eroded trust among customers and partners. The BIA makes these costs visible and provides the basis for investment decisions in redundancy and recovery capability.

Interface to IT operations and incident response. The business continuity policy takes over where normal IT operations reach their limits. It extends incident response processes with a focus on recovery and maintaining business operations. Without this policy, there is no bridge between “incident detected” and “business running again.”

What goes into it?

The template covers eight core areas — here are the most important at a glance:

  • ICT continuity organisation — BCM manager, recovery team leads, technical specialists, each with a backup person. Clear escalation paths and decision authority.
  • Business Impact Analysis (BIA) — identification of business-critical processes and supporting ICT services, RTO and RPO per service, prioritisation by impact severity.
  • ICT continuity plans — activation criteria, step-by-step recovery, contact lists, resource requirements (hardware, licences, personnel), fallback procedures.
  • Security during disruption (A 5.29) — compensating controls for failed primary controls, disruption-mode procedures, emergency access rules.
  • Early warning indicators — capacity thresholds, replication lag, vendor degradation notices, automated alerting.
  • Backup concept — both creation and restoration, secure storage at geographically separated locations, regular restoration tests.
  • Test and exercise programme — tabletop exercises quarterly, technical recovery tests semi-annually, full simulations annually, documented results and improvement actions.
  • Training — annual training for recovery staff, awareness for all personnel on how to behave during disruptions.

How to roll it out

  1. 01

    Conduct a Business Impact Analysis

    Identify all business-critical processes and the ICT services that support them. Determine the RTO (how quickly must it be running again?) and RPO (how much data loss is tolerable?) for each service. This analysis is the foundation — without it, every subsequent step is guesswork. Involve the business units, because they understand the business impact of an outage far better than IT does.

  2. 02

    Build the continuity organisation

    Appoint a BCM manager, recovery team leads for each critical service, and technical specialists for execution. Every role needs a backup person — a plan that depends on a single individual is no plan at all. Document escalation paths and decision authority so that no time is wasted on jurisdiction questions during an actual incident.

  3. 03

    Create recovery plans

    Write a recovery plan for each prioritised ICT service with activation criteria, step-by-step instructions, contact list and resource requirements. The plans must be concrete enough that a backup person can execute them without asking questions. Abstract statements like 'restore the system' help nobody in a real incident.

  4. 04

    Adapt the template and get approval

    Replace the placeholders in our template and remove sections that do not apply. Have the policy approved by top management (ISO 27001, Clause 5.2) and communicate it to all personnel. Recovery staff in particular must know the content — an email is not enough for that.

  5. 05

    Test, train, improve

    Start with a tabletop exercise in the first quarter: a fictional scenario, all stakeholders at the table, walk through the process. Next, run a technical recovery test for the most critical service. Document the results, identify weaknesses and update the plans. The annual full simulation then shows whether the overall system works.

Where it goes wrong in practice

From audit experience, sorted by frequency:

1. BIA is missing or outdated. The Business Impact Analysis was created once and never updated. New services have been added, old ones decommissioned, but the RTOs still date from last year. Without a current BIA, there is no prioritisation — in an incident, everything gets restored simultaneously, which effectively means nothing does.

2. Plans exist but have never been tested. The recovery plan lives in the wiki, looks plausible and has been signed off by management. During the first real test, it turns out: the contact list is outdated, the backup server lacks storage, and the step-by-step instructions assume software that has since been replaced.

3. No backup persons. The only person who can restore the database server is on holiday, off sick, or themselves affected by the incident. Every role in the continuity organisation needs a named backup who knows and has practised the recovery process.

4. Backup restoration never verified. Backups are created reliably — but nobody has ever tested whether they can actually be restored. Corrupt backups, missing encryption keys or incompatible software versions only surface when it is too late.

5. Compensating controls not defined. During a disruption, security controls get loosened (“In an emergency, we give everyone admin access”). Without pre-defined compensating controls, security gaps emerge that persist beyond the actual disruption.

Template: Business Continuity Policy

Full policy text

Business Continuity Policy

.md · EN.md · DE

Document control
Owner: [POLICY_OWNER_ROLE, e.g. Information Security Officer]
Approved by: [APPROVER_NAME_AND_ROLE]
Version: [VERSION]
Effective date: [EFFECTIVE_DATE]
Next review: [NEXT_REVIEW_DATE]

1. Legal/Regulatory Basis

ISO/IEC 27001:2022 / ISO/IEC 27002:2022, Annex A:

  • A 5.29 — Information Security During Disruption
  • A 5.30 — ICT Readiness for Business Continuity

BSI IT-Grundschutz:

  • DER.4 (Business Continuity Management)
  • DER.2.1 (Security Incident Handling)
  • CON.3 (Backup Concept)

BSI-Standard 200-4 (Business Continuity Management).

Additional jurisdiction-specific laws and regulations — in particular NIS2, DORA and sector-specific resilience requirements — are listed in the Legal Register and incorporated by reference.

2. Purpose & Scope

This policy establishes the business continuity management framework for [YOUR_ORGANISATION_NAME]. It defines how information security is maintained during disruptions, how ICT services are prepared for business continuity, and how the organisation plans, tests and improves its ability to recover from adverse events.

The policy covers business impact analysis, recovery objective setting, ICT continuity planning, testing and exercising, and the maintenance of information security controls throughout all phases of disruption and recovery. It applies to all business processes, ICT services and information assets within the scope of the ISMS. All employees, contractors and third-party service providers involved in business continuity planning, response or recovery activities are bound by this policy.

Emergency management planning prioritises critical business processes. Incident escalation procedures define clear thresholds for transitioning from incident response to emergency and crisis activation.

3. Information Security During Disruption (A 5.29)

Information security is maintained at an appropriate level during disruptions. Security controls remain active throughout incident response, failover and recovery operations. Where primary controls become unavailable, pre-approved compensating controls take effect immediately. Recovery from various failure scenarios — including technical failure, supply chain disruption, natural disaster and cyberattack — is planned in advance as part of emergency management.

  • Security Controls in Continuity Plans: Each continuity plan documents the relevant information security controls in normal operation and defines which compensating controls apply during disruption. Failover environments maintain the same access control levels, network segmentation and monitoring capabilities as production systems. Backup encryption is verified before restoration to ensure data integrity and confidentiality.
  • Disruption-Mode Security Procedures: For critical security controls, continuity plans define disruption-mode procedures that describe how protection is maintained when primary systems are unavailable. Staff with recovery responsibilities receive annual training on these procedures and participate in exercises that validate their ability to operate controls under degraded conditions.
  • Compensating Controls: For security controls that cannot function during a disruption, continuity plans document compensating controls that provide equivalent protection. Each compensating control entry specifies the primary control it replaces, the activation trigger and the responsible person. Compensating controls are tested during continuity exercises and reviewed after every real activation.

4. ICT Readiness for Business Continuity (A 5.30)

ICT readiness for business continuity ensures that the ICT services required to support critical business processes can be restored within defined timeframes. The ICT continuity programme covers the full lifecycle: business impact analysis, recovery objective setting, planning, implementation, testing, maintenance and continual improvement. The backup concept covers both backup creation and restoration, regular restoration testing, and secure backup storage at geographically separated locations. Detailed backup documentation — including scope, method, schedule, retention, storage locations and restore test results — is maintained as part of each system's disaster recovery plan.

4.1 Business Impact Analysis & Recovery Objectives

  • Minimum Performance & Capacity Requirements: Each ICT continuity plan specifies minimum performance and capacity requirements during disruption, including acceptable bandwidth, storage capacity, processing power and user concurrency thresholds. These specifications are derived from the business impact analysis (BIA) and validated by the process owners of the dependent business activities. Degraded-mode service levels are formally documented and communicated to all stakeholders.
  • Recovery Time Objectives (RTO): A Recovery Time Objective (RTO) is defined for each prioritised ICT service. Restoration procedures specify the exact sequence of recovery steps, system dependencies and verification checkpoints. RTOs are validated through regular testing. Any test result that exceeds the defined RTO triggers a corrective action and plan revision. RTO values are reviewed annually and after significant changes to the ICT landscape.
  • Recovery Point Objectives (RPO): A Recovery Point Objective (RPO) is defined for each prioritised information resource. Backup strategies and frequencies are aligned to meet or exceed RPO requirements. Backup restoration is tested regularly to verify RPO achievement. Where RPO requirements demand near-zero data loss, synchronous replication or continuous data protection mechanisms are implemented. RPO values drive the backup schedule documented in the disaster recovery plan for each system.

4.2 Organisational Structure

  • ICT Continuity Organisation: An ICT continuity organisation is established with defined roles: ICT continuity manager, recovery team leads and technical recovery specialists. Each role has a designated backup person to ensure availability during absences. Competency requirements are documented and verified through training records. The ICT continuity manager reports to management and coordinates with the Information Security Officer on all security-related continuity matters. Escalation paths from incident response to emergency and crisis management are defined and documented.

4.3 ICT Continuity Planning

  • Documented ICT Continuity Plans: Comprehensive ICT continuity plans are documented for each critical ICT service. Each plan includes activation criteria, step-by-step recovery instructions, contact lists with primary and backup contacts, resource requirements (personnel, hardware, software, network, facilities) and expected timelines. Plans reference the applicable security controls from the Information Security During Disruption section. Communication procedures define how internal and external stakeholders are informed at each phase of the disruption.
  • Management Approval: ICT continuity plans are formally approved by management before activation readiness is declared. Approval includes review of executive summaries, cost implications, residual risk assessments and resource commitments. Re-approval is obtained annually and after significant changes to the ICT environment, organisational structure or threat landscape. Approval records are retained as documented information within the ISMS.

4.4 Testing & Exercises

  • Regular Testing & Exercises: ICT continuity plans are tested at defined intervals: tabletop exercises at least quarterly, technical recovery tests at least semi-annually and full simulation exercises at least annually. Test results, identified gaps and corrective actions are documented in test reports. Each test verifies that RTOs and RPOs are achievable under realistic conditions. Backup restoration is tested regularly to confirm that backed-up data can be recovered within RPO targets. Lessons learned feed into plan revisions, and unresolved findings are tracked through the ISMS corrective action process.

4.5 Continuity Management

  • Cause-Agnostic Response: ICT continuity plans address disruptions regardless of cause, including technical failure, natural disaster, cyberattack, human error and supply chain failure. Response procedures are designed to be cause-agnostic where possible, with cause-specific supplements for targeted scenarios such as ransomware, data centre loss or critical vendor failure. Recovery planning covers diverse failure scenarios.
  • Prioritised Activity Support: Prioritised business activities identified in the BIA are mapped to their required ICT services, including all dependencies on infrastructure, applications, data and external service providers. Gap analyses verify that continuity plans ensure these services are available within defined RTOs. Where gaps are identified, remediation actions are assigned, tracked and verified before plans are declared operational.
  • Proactive Response & Early Warning: Continuity plans define activation criteria that enable early response before a full disruption occurs. Plans activate upon detection of incidents that could escalate to service disruption, including capacity threshold breaches, replication lag alerts, vendor service degradation notices and security incident escalations.

5. Roles & Responsibilities

  • Top Management: Approves this policy, allocates resources for business continuity management and ensures that continuity objectives are aligned with the overall business strategy.
  • Information Security Officer (ISO): Ensures that information security controls are integrated into all continuity plans and that compensating controls provide adequate protection during disruptions.
  • ICT Continuity Manager: Coordinates the ICT continuity programme, maintains continuity plans, schedules tests and exercises, and reports on programme effectiveness to management.
  • Recovery Team Leads: Manage the execution of recovery procedures for their assigned ICT services, coordinate with technical recovery specialists and report progress to the ICT continuity manager.
  • Technical Recovery Specialists: Execute step-by-step recovery procedures, verify system integrity after restoration and confirm that security controls are re-established.
  • Process Owners: Define business requirements for RTOs, RPOs and minimum service levels through the BIA process. Validate that continuity plans meet their operational needs.
  • All Employees & Contractors: Participate in continuity exercises, follow disruption-mode procedures and report incidents that may trigger continuity plan activation.

6. Review & Maintenance

This policy is reviewed:

  • At least annually, as part of the ISMS management review cycle.
  • After significant business continuity incidents, including actual activations of continuity plans.
  • When business impact analysis results change significantly, including changes to critical process prioritisation or recovery objectives.
  • Following significant changes to the ICT infrastructure, organisational structure or supplier landscape.
  • After continuity exercises that reveal material gaps or improvement opportunities.
  • When new legal, regulatory or contractual requirements affecting business continuity are identified.

Sources

ISO 27001 Controls Covered

A.5.29 Information security during disruption A.5.30 ICT readiness for business continuity

Frequently asked questions

Is one policy enough for business continuity?

Yes. Our template covers both Annex A controls (A 5.29 and A 5.30) in a single document. A 5.29 addresses information security during disruption, A 5.30 covers ICT readiness. Some organisations separate BCM and IT-DR into different documents — that can make sense when different teams are responsible. For most SMEs, a single document creates less maintenance overhead.

What is the difference between RTO and RPO?

RTO (Recovery Time Objective) is the maximum downtime your business can tolerate — how quickly a service must be running again. RPO (Recovery Point Objective) is the maximum data loss, measured in time — how old the last usable backup may be. You determine both values per ICT service during the Business Impact Analysis.

How often do I need to test recovery plans?

The policy recommends three test types at different cadences: tabletop exercises quarterly, technical recovery tests semi-annually, full simulations annually. ISO 27001 does not prescribe an exact frequency, but auditors expect documented tests at least once a year. More frequent testing increases maturity and shortens actual recovery times.

Do I need a dedicated BCM manager?

ISO 27001 does not require a dedicated role, but A 5.30 presupposes clearly assigned responsibilities. In practice, a three-tier structure works well: a BCM manager coordinates, recovery team leads own one service each, and technical specialists perform the actual recovery. Every role needs a backup person — otherwise the plan fails when the key person happens to be on holiday.

Does the BIA need to cover non-IT processes?

Yes. The Business Impact Analysis evaluates all business-critical processes, including those without a direct IT component (e.g. logistics, production, customer service). For the ICT continuity plans under A 5.30, you then prioritise the IT services that support those processes. Without this link between business process and ICT service, RTOs remain arbitrary.