Business Continuity Policy

Document reference: ISO_webpage_legal-business-continuity_v1

Last modified: 28 March 2026

1. Purpose and Scope

Coaley Peak Limited is committed to maintaining the continuity of its critical business operations and protecting the confidentiality, integrity, and availability of its information assets during and after a disruptive incident. This policy establishes the framework by which the organisation prepares for, responds to, and recovers from events that could interrupt normal operations.

This policy applies to all employees, contractors, consultants, and third parties who operate on behalf of Coaley Peak Limited, and to all systems, services, data, and processes that underpin our business activities. It covers disruptions arising from any cause, including but not limited to cyber incidents, infrastructure failure, loss of key personnel, supply chain disruption, natural events, and utility outages.

The policy is informed by and aligned with:

  • ISO 27001:2022 — Annex A controls A.5.29 (Information security during disruption) and A.5.30 (ICT readiness for business continuity).
  • ISO 22301:2019 — the international standard for business continuity management systems (BCMS).
  • UK data protection legislation, including UK GDPR and the Data Protection Act 2018, insofar as continuity obligations relate to personal data.

2. Regulatory and Standards Alignment

2.1 ISO 27001:2022 — Information Security Continuity

Under Annex A control A.5.29, Coaley Peak Limited is required to plan how information security will be maintained during an adverse situation. Our business continuity arrangements ensure that security controls are not weakened or bypassed under the pressure of incident response. Security requirements — access control, data integrity, and audit logging — remain in force during any recovery phase.

Under Annex A control A.5.30, the organisation is required to ensure that ICT systems are ready to support business continuity. This includes documented recovery procedures, tested backup mechanisms, defined recovery objectives, and evidence of rehearsal. The IT disaster recovery procedures in Section 7 of this policy give effect to this control.

2.2 ISO 22301 — Business Continuity Management

ISO 22301 provides the management system framework within which this policy sits. Key principles include leadership commitment, context analysis, business impact analysis, risk treatment, documented continuity plans, competence and awareness, regular exercising, and a cycle of continual improvement. This policy reflects those principles and is supported by operational procedures maintained separately by the IT and operations functions.

3. Business Impact Analysis

Coaley Peak Limited conducts a Business Impact Analysis (BIA) to identify which processes are critical to our operations and to quantify the consequences of their interruption. The BIA is reviewed at least annually and following any material change to the organisation, its systems, or its service offering.

3.1 Critical Process Identification

The BIA considers all business processes across service delivery, client management, IT operations, and administrative functions. Processes are evaluated against the following criteria:

  • Financial impact — revenue loss, penalty clauses, remediation costs, and regulatory fines arising from interruption.
  • Regulatory and legal obligations — processes whose failure could breach contractual, statutory, or regulatory requirements.
  • Reputational impact — the degree to which disruption would damage client trust or public confidence in Coaley Peak Limited.
  • Operational dependency — whether other critical processes depend on this process to function.
  • Data sensitivity — whether the process handles personal data or commercially sensitive information subject to heightened protection obligations.

3.2 Recovery Priorities

Processes identified through the BIA are assigned a recovery priority tier:

  • Tier 1 — Mission Critical: processes whose interruption for more than four hours would cause unacceptable harm. These receive the highest allocation of recovery resources and are addressed first.
  • Tier 2 — Business Critical: processes that must be restored within 24 hours to avoid significant operational or financial impact.
  • Tier 3 — Important: processes that must be restored within 72 hours to maintain normal service levels.
  • Tier 4 — Deferrable: processes that can be suspended for up to one week without material harm, to be reinstated once higher-priority functions are stable.

4. Recovery Objectives

Recovery time and recovery point objectives are defined for each critical system and process. These objectives are established through the BIA process, agreed by senior leadership, and reviewed annually.

4.1 Recovery Time Objectives (RTOs)

The Recovery Time Objective defines the maximum acceptable period of time within which a process or system must be restored following a disruption. RTOs are set per tier:

  • Tier 1 systems: RTO of 4 hours.
  • Tier 2 systems: RTO of 24 hours.
  • Tier 3 systems: RTO of 72 hours.
  • Tier 4 systems: RTO of 7 days.

RTOs are tested through exercises (see Section 9) and updated where testing reveals that objectives are not achievable within current recovery capabilities.

4.2 Recovery Point Objectives (RPOs)

The Recovery Point Objective defines the maximum tolerable period of data loss, measured in time from the point of disruption back to the most recent recoverable backup or replication checkpoint. RPOs are set as follows:

  • Tier 1 systems: RPO of 1 hour.
  • Tier 2 systems: RPO of 4 hours.
  • Tier 3 systems: RPO of 24 hours.
  • Tier 4 systems: RPO of 48 hours.

Backup schedules and replication configurations are aligned to these objectives. Any gap identified during backup audits or exercising must be reported to the IT Manager and remediated without undue delay.

5. Business Continuity Plan

The Business Continuity Plan (BCP) provides the operational procedures that staff follow when an incident threatens or disrupts normal operations. The BCP is maintained by the IT Manager and Operations Lead, approved by the Managing Director, and stored in a location accessible to key personnel even when primary systems are unavailable.

5.1 Activation Triggers

The BCP may be activated in whole or in part when any of the following conditions are met:

  • A Tier 1 or Tier 2 system or process has been unavailable for more than one hour without a confirmed resolution timeline.
  • A cyber security incident has been declared that threatens the availability or integrity of critical systems.
  • A significant loss of key personnel renders normal operations undeliverable.
  • A failure in a critical third-party supplier has disrupted the delivery of services to clients.
  • Physical access to the primary place of business has been prevented by an emergency, legal order, or infrastructure failure.
  • A statutory authority or regulatory body has required suspension of a regulated activity.

The decision to activate the BCP rests with the Managing Director or, in their absence, the most senior available member of the leadership team.

5.2 Response Roles and Responsibilities

Upon activation, the following roles are assigned:

  • Incident Commander — typically the Managing Director. Holds overall accountability for the response, makes decisions on resource allocation, and acts as the primary interface with the board and external stakeholders.
  • IT Recovery Lead — the IT Manager. Responsible for executing disaster recovery procedures, coordinating with hosting and infrastructure providers, and reporting system status to the Incident Commander.
  • Operations Lead — responsible for maintaining client-facing service delivery to the extent possible, managing staff allocation during the incident, and activating supplier contingency arrangements.
  • Communications Lead — responsible for internal and external communications, including client notifications, regulatory notifications where required, and media enquiries if applicable.
  • Documentation Lead — responsible for maintaining a contemporaneous log of all decisions, actions taken, and their outcomes during the incident.

Named individuals for each role, together with their contact details and deputies, are maintained in the BCP and updated at each annual review or upon a change in personnel.

5.3 Communication During an Incident

Clear and timely communication is essential to an effective response. The following communication principles apply:

  • Internal communication: the Incident Commander ensures all response team members are briefed at least every two hours during an active incident. An out-of-band communication channel (independent of affected systems) is designated in the BCP.
  • Client communication: clients affected by a disruption are notified by the Communications Lead as soon as the nature and likely duration of the impact is understood, and updated at agreed intervals until service is restored.
  • Regulatory notification: where a disruption involves a personal data breach or a reportable incident under applicable regulation, notification obligations are assessed immediately and actioned within the required timeframes (72 hours to the ICO under UK GDPR where applicable).
  • Supplier communication: the Operations Lead contacts affected suppliers to invoke contingency arrangements and to obtain status updates.

6. IT Disaster Recovery

The IT disaster recovery (DR) procedures operationalise Annex A control A.5.30 and ensure that technology systems can be recovered within the RTOs and RPOs defined in Section 4.

6.1 Backup Procedures

All critical data and system configurations are backed up in accordance with the following requirements:

  • Frequency: backups are taken at intervals consistent with the RPO for each system tier. Tier 1 systems employ continuous or near-continuous replication. Tier 2 systems are backed up at least every four hours. Tier 3 and Tier 4 systems are backed up daily.
  • Retention: daily backups are retained for 30 days; weekly backups for 12 weeks; monthly backups for 12 months. Retention schedules are reviewed annually against regulatory and contractual obligations.
  • Offsite and cloud storage: all backups are stored in a geographically separate location from the primary data environment. At least one backup copy is maintained in encrypted cloud storage hosted within the UK or European Economic Area.
  • Encryption: backup data is encrypted in transit and at rest using current cryptographic standards. Encryption keys are stored and managed separately from the backup data itself.
  • Backup verification: automated integrity checks are performed on each backup. The IT Manager reviews backup reports weekly and investigates any failure or anomaly without delay.

6.2 System Recovery

Recovery procedures for each critical system are documented in individual system recovery runbooks held within the BCP. These runbooks specify:

  • The sequence of recovery steps and their dependencies.
  • The personnel authorised to execute each step.
  • Access credentials and recovery keys, held in a secure, offline-accessible format.
  • Verification steps to confirm that the system has been restored to a functional and secure state before it is returned to production use.

Where a primary system cannot be restored within its RTO, a pre-approved fallback or workaround procedure is activated to maintain minimum service capability until full recovery is achieved.

6.3 Data Integrity

Following any recovery event, the IT Recovery Lead performs data integrity checks to confirm that restored data is complete, accurate, and consistent. Specific checks include:

  • Comparison of record counts and checksums against pre-incident baselines where available.
  • Review of application-level audit logs to identify any anomalies in data state.
  • Confirmation that no unauthorised modification occurred during the incident window.

Where data loss or corruption is identified, the Documentation Lead records the extent and nature of the loss and the Communications Lead notifies affected clients and, where required, the Information Commissioner's Office.

7. Incident Response and Escalation

The following escalation framework applies to all incidents that may trigger or affect business continuity:

  • Level 1 — Localised disruption: an issue affecting an individual user or non-critical system, resolved by the IT support function without BCP activation. Logged and closed within normal IT service management processes.
  • Level 2 — Operational impact: an issue affecting a Tier 3 or Tier 4 system or a team's ability to operate normally. The IT Manager is notified. A resolution timeline is established and communicated. The BCP may be partially activated at the IT Manager's discretion.
  • Level 3 — Significant disruption: an issue affecting a Tier 1 or Tier 2 system, or multiple systems simultaneously. The BCP is activated. The Incident Commander assumes control and convenes the response team within one hour.
  • Level 4 — Crisis: a disruption with widespread impact on the business, its clients, or its regulatory standing. Board-level notification is required. External support (legal counsel, cyber security specialists, public relations advisers) may be engaged. Regulatory notifications are assessed as a matter of urgency.

All incidents at Level 2 and above are formally documented. A post-incident review is conducted within five business days of incident closure to identify root causes and lessons learned.

8. Testing and Exercising the Plan

A business continuity plan that has not been tested cannot be relied upon. Coaley Peak Limited maintains a programme of regular exercises to validate the effectiveness of this policy and the associated BCP.

8.1 Exercise Types

  • Desktop walkthrough: a facilitated discussion exercise in which the response team works through a hypothetical scenario, reviewing their actions against the BCP. Conducted at least annually for all response team members.
  • Technical backup and restore test: a live test of backup restoration for at least one Tier 1 and one Tier 2 system, confirming that data can be recovered within the defined RPO and the system returned to service within the RTO. Conducted at least twice per year.
  • Full simulation exercise: a realistic simulation of a significant disruption event, activating the full BCP and testing communication, escalation, and recovery procedures end to end. Conducted at least once every two years.

8.2 Exercise Outcomes

Each exercise produces a written outcome report identifying gaps, weaknesses, or improvements required. The IT Manager is responsible for ensuring that any remediation actions are assigned, tracked, and completed within an agreed timeframe. Exercise outcomes and remediation records are retained as evidence of continual improvement and made available to auditors upon request.

9. Supply Chain Continuity

Coaley Peak Limited relies on third-party suppliers for a range of services including cloud hosting, software platforms, and communications infrastructure. The failure of a key supplier can have the same impact as an internal system failure, and supply chain continuity is therefore a material component of our business continuity management.

9.1 Third-Party Dependency Mapping

The Operations Lead maintains a register of all third-party services on which the business depends for delivery of Tier 1 and Tier 2 processes. For each dependency, the register records:

  • The service provided and its criticality tier.
  • The supplier's contractual service level commitments, including any uptime guarantees and support response times.
  • The supplier's own published business continuity and disaster recovery arrangements.
  • The estimated impact on Coaley Peak Limited if the supplier experiences a disruption of one hour, one day, and one week respectively.

9.2 Contingency Arrangements

For each Tier 1 and Tier 2 supplier dependency, Coaley Peak Limited maintains at least one of the following contingency arrangements:

  • Identified alternative supplier: a pre-qualified alternative that could be engaged within the RTO window. Procurement terms and onboarding requirements are documented in advance.
  • Manual workaround: a documented procedure enabling the affected process to continue at reduced capacity without the supplier's service, valid for at least the duration of the RTO.
  • Contractual protections: where neither of the above is feasible, contractual clauses requiring the supplier to provide appropriate continuity arrangements, including the right to audit their DR provisions.

Third-party continuity arrangements are reviewed as part of the annual supplier review process and whenever a material change to a supplier relationship occurs.

10. Responsibilities

10.1 Leadership

The Managing Director is accountable for the business continuity management system and ensures that adequate resources are allocated to its implementation, maintenance, and improvement. The board receives a summary report on BCP status, exercise outcomes, and any significant incidents at least annually.

10.2 IT Manager

The IT Manager is responsible for the technical components of business continuity, including backup procedures, system recovery runbooks, DR testing, and the ICT readiness measures required under ISO 27001:2022 Annex A control A.5.30. The IT Manager reports directly to the Managing Director on all continuity-related matters and escalates material concerns without delay.

10.3 Operations Lead

The Operations Lead is responsible for maintaining the BCP documentation, co-ordinating supplier continuity arrangements, and ensuring that operational procedures remain current and aligned with the outcomes of business impact analyses and exercises.

10.4 All Staff

Every member of staff has a responsibility to:

  • Familiarise themselves with the BCP provisions relevant to their role.
  • Report any incident or near-miss that could threaten business continuity to their line manager or the IT Manager promptly.
  • Follow the guidance of the Incident Commander and their designated lead during an activated response.
  • Complete business continuity awareness training at induction and at each subsequent annual refresh.
  • Not take any action during an incident that could compromise information security controls, even where doing so might appear to accelerate recovery.

11. Review and Maintenance

This policy is reviewed at least annually by the IT Manager and Operations Lead, with approval from the Managing Director. A review is also triggered by any of the following:

  • A material change to the organisation's structure, systems, or service offering.
  • The activation of the BCP in response to an actual incident.
  • A significant change to the threat landscape or applicable regulatory requirements.
  • The identification of material gaps or weaknesses through exercising.

All versions of this policy are version-controlled. Superseded versions are retained for a minimum of three years. Changes to the policy are communicated to all staff and relevant third parties promptly following approval.

For queries relating to this policy, please contact compliance@coaleypeak.co.uk.

Document reference: ISO_webpage_legal-business-continuity_v1

Last modified: 28 March 2026

Legal & Compliance·Business Continuity Policy