Information Security Aspects of Business Continuity Policy

1. Purpose

This policy makes sure that the Organisation keeps the confidentiality, integrity and availability of its information at an agreed level during and after a disruption. Business continuity plans restore services; this policy requires that they do so without leaving data, systems or access unprotected.

• Security requirements are defined and agreed before a disruption, not improvised during one.
• Recovery sites, alternative working methods and emergency access are as well protected as the normal ones, or the difference is a risk that has been accepted.
• The arrangements are tested, and what is learned changes the plans.

2. Scope

The policy applies to the business continuity and disaster recovery plans of every department, system and site that supports the Organisation's critical services, and to suppliers whose failure would stop those services.

• In scope: the security aspects of the business impact analysis, continuity strategies, disaster recovery plans, crisis communications, alternate sites, remote working in a disruption, supplier dependencies, backups and the testing programme.
• In scope: events such as cyber attack, loss of a data centre or cloud region, loss of a key supplier, loss of premises, pandemic, loss of key staff, power or network failure and natural disaster.
• Out of scope: the general business continuity programme, which the BCP and DR Procedure governs; this policy supplies the security requirements to it.

3. Terms and Definitions

4. Roles and Responsibilities

5. Continuity Policy Statements

Steps and forms are in the BCP and DR Procedure. The statements below set what the plans must achieve for information security.

5.1 Information security requirements

• The business impact analysis must state, for each critical process, the confidentiality, integrity and availability needs, the RTO, the RPO and the MTPD, and be reviewed [every 12 months] and after any major change.
• Continuity plans must keep the security controls that protect the information the service handles. Where a control cannot be kept, such as a disabled security tool or manual workaround, the plan must name the risk, the compensating control, the approver and the time limit.
• Information must keep its classification in a disruption. Sensitive data must not be moved to unapproved places, personal devices or unmanaged services, even in an emergency.
• Information security events during a disruption must be reported and handled under the Information Security Incident Management Policy, and a disruption caused by an attack is both an incident and a continuity event.

5.2 Planning information security continuity

• The Organisation must plan, for each scenario that matters, how it would keep: access control, logging, malware protection, monitoring, backups and encryption working.
• Scenarios must include, at least: loss of the primary data centre or cloud region; ransomware on production and backups; loss of identity services; loss of a critical supplier; loss of the main office; and loss of access to key staff.
• Each scenario must have an owner, a documented trigger for activation, the decision-maker, and a list of the security steps to be taken at activation, in the first [hour], first [day] and first [week].

5.3 Including information security in the business continuity management process

• A security representative must sit on the continuity working group and review each plan before approval.
• Plans must hold the minimum security content in the table below, and a plan without it is not approved.

5.4 Recovery strategies

• Each critical service must have a recovery strategy that meets its RTO and RPO and that has been tested: for example active-active across sites, warm standby, restore from backup, or manual workaround.
• Restoration from backup must use clean, verified images and patched baselines. Backups taken after a compromise must be checked for the attacker's persistence before use.
• Where staff work from home or an alternate location during a disruption, the Mobile Device and Teleworking Policy applies in full, and capacity of remote access, multi-factor authentication and support must be tested in advance.
• Recovery priorities must be agreed by the service owners and Head of IT Security, and security services (identity, logging, monitoring, key management) must be restored first so that other services come back protected.

5.5 Disaster recovery plan

The DR plan for each critical system must be written so that someone who did not build it can follow it, and must include the items below.

• Recovery objectives, dependencies, restoration order and the decision tree for failover and failback.
• Runbooks with exact commands, console steps, credentials location (not the credentials), and expected results.
• Contact points for suppliers, cloud providers and data centre operators, and the contractual recovery commitments.
• Data integrity checks to run after recovery, and the sign-off needed before customers are told that the service is restored.
• A copy of the plan, available offline and at the alternate site, protected and versioned.

5.6 Redundancies and availability of information processing facilities

Information processing facilities must have redundancy that meets the availability required by the BIA. The table below gives sample tiers; the service owner sets the real tier.

• Power, cooling, network paths, internet links and security appliances for Tier 1 and Tier 2 services must be duplicated and, where practicable, supplied through independent routes or providers.
• Failover must be tested; redundancy that has never been exercised is not accepted as evidence.
• Capacity at the standby location must be monitored so that a switch does not overload it, as the Capacity Management and Planning Procedure describes.

5.7 Testing, maintaining and reassessing the plan

• Each test must have an objective, a scope, a safe way to stop it, a record of the results, and actions for any gap. Actions must be tracked to closure under the corrective action register.
• Tests that fail the RTO or RPO must be repeated within [90 days] after the fix.
• Plans must be updated within [30 days] of a change to systems, suppliers, locations or the law that affects them.

5.8 Verify, review and evaluate information security continuity

• The Head of IT Security must verify at least [once a year] that the security controls in the plans exist, work and are usable in a disruption, by walkthrough, test or inspection of evidence.
• Results of tests, real disruptions and audit findings must be reported to top management in the management review, with proposals to change strategy, funding or objectives.
• After a real disruption, a review must be held within [10 working days] and the plans updated for what was learned.

6. Compliance and Monitoring

• The Head of IT Security reviews the measures [quarterly]. Internal audit tests the programme as part of the audit plan, and the results are reported in the management review.

7. Records and Evidence

Annexure A: Security continuity checklist for a continuity plan

Annexure B: Continuity test record

8. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

9. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

10. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• BCP and DR Procedure
• Backup and Restoration Policy
• Information Security Incident Management Policy
• Physical and Environmental Controls Policy
• Supplier Relationship Management Policy
• Risk Management Policy