[Company] Disaster Recovery & Business Continuity Plan

• Version: 1.0
• Owner: Founder/CTO
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan sets out how [Company] keeps its business running and restores its systems and data after a serious disruption, such as a cloud infrastructure outage, a supplier failure, a cyberattack, or an event that prevents employees from working. It is intended to let [Company] continue serving its customers, or resume doing so quickly, with minimal loss of data and minimal disruption to its 8-person team.

This plan sits beneath [Company]'s information security policy. Where a disruption is caused by a security incident, the company's incident response plan governs investigation, evidence handling, and any regulatory or customer notification. This plan governs the continuity of business operations and the recovery of systems and data, and does not repeat notification timelines set out elsewhere.

2. Scope

This plan applies to all systems, data, and suppliers that support [Company]'s product and day-to-day operations, including its infrastructure hosted on AWS, its Google Workspace email and file storage, its GitHub source code repositories, and its remote working environment. It applies to all employees, regardless of location, since the company has no physical office.

3. Policy

[Company] must maintain, keep current, and test this plan so that critical systems and data can be recovered within the objectives set out in Section 7, and so that the business can continue operating during a disruption using the arrangements described in this plan. This plan also supports the evidence [Company] needs for its SOC 2 report by documenting its business continuity and disaster recovery practices.

4. Roles and Responsibilities

Given the size of [Company]'s team, this plan uses a small number of roles rather than a formal committee structure. The Founder/CTO leads recovery in most scenarios; a designated deputy stands in when the Founder/CTO is unavailable; and the most senior business decision, such as whether to pay a ransom, is reserved for the Chief Executive Officer.

• Recovery Lead (Founder/CTO): Owns this plan, decides whether to activate it (except where reserved below), leads technical recovery, coordinates with suppliers, and communicates with customers and employees during a disruption.
• Deputy Recovery Lead ([Deputy Recovery Lead name/role]): Performs the Recovery Lead's duties if the Recovery Lead is unreachable or unable to act.
• Chief Executive Officer: Decides whether to pay a ransom demand, approves major customer communications during a significant disruption, and acts as Recovery Lead if both the Recovery Lead and Deputy Recovery Lead are unavailable.
• All employees: Follow instructions issued during an activation, use the fallback communication channel in Section 6 if needed, and report any disruption to the Recovery Lead as soon as they notice it.

5. Plan Activation

This plan may be activated by the Recovery Lead. If the Recovery Lead is unreachable, the Deputy Recovery Lead or the Chief Executive Officer may activate it instead. Activation should be based on the following criteria:

• A disruption to any system or service is expected to last longer than the recovery time objective set for it in Section 7.
• Loss of access to a supplier, tool, or account needed to deliver [Company]'s product or serve customers, for longer than 24 hours.
• A confirmed security incident, including ransomware, that affects the availability of production systems or customer data.
• An event that prevents more than half of [Company]'s employees from working for more than one calendar day.

6. Communications and Escalation

The primary channels for internal communication during a disruption are the team chat tool and email. Because email may run on Google Workspace, which could itself be affected by an outage, the fallback channel is a phone call or text message to employees' mobile phones, since this does not depend on any of [Company]'s cloud accounts or suppliers. The Recovery Lead must maintain an up-to-date list of employee mobile numbers outside the systems this plan protects, as described in Appendix A.

Customers must be told promptly about any disruption that affects the customer-facing application or their data, using email or another channel the customer has agreed to. The Recovery Lead must check the affected customer's contract for any availability commitment or notice period before sending or finalizing the communication, since these vary by customer.

7. Recovery Time and Recovery Point Objectives

A recovery time objective (RTO) is the longest a system or service may be unavailable, measured from the start of the disruption, before the company must have it working again. A recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, meaning the maximum acceptable gap between the last usable backup and the point of failure. Where a system is run by a supplier that [Company] cannot restore itself, the RTO is the longest [Company] can work without that system before switching to a workaround.

Because [Company] has 8 employees and no on-call rota, any of these RTOs may fall outside normal business hours or across a weekend. The Recovery Lead must be reachable by phone call to their mobile number at any time to meet these objectives; the Deputy Recovery Lead must be reachable in the same way if the Recovery Lead cannot be.

8. Backup and Restoration

[Company] must maintain backups that are made at least as often as the recovery point objectives in Section 7, with at least one copy of each backup kept separate from production systems and accounts, so that an attacker or an administrator error affecting production cannot also delete or encrypt the backup.

• Automated backups of the production database must be taken at least once every hour and retained for at least 30 days.
• The production application's infrastructure configuration must be stored in version control and mirrored to a storage location outside AWS at least once every 24 hours, retained for at least 90 days.
• GitHub repositories must be cloned or mirrored to a storage location outside GitHub at least once every 24 hours and retained for at least 90 days.
• Google Workspace email and file storage must be exported or backed up to a storage location outside Google Workspace at least once every 24 hours and retained for at least 30 days.
• Restoration of each critical system listed in Section 7 must be tested at least once per year, with results recorded as set out in Section 12.
• Backups containing personally identifiable information must be protected with the same access controls as the production data they are copied from.

9. Continuity of Critical Services

[Company]'s core service runs on AWS, and the company is responsible for restoring that infrastructure and its data itself, following the backup and restoration requirements in Section 8. If AWS experiences an outage affecting the region [Company] uses, the company must be able to restore its infrastructure into a different AWS region from its backups, since it operates no standing infrastructure elsewhere.

Google Workspace and GitHub are run by their respective providers, and [Company] depends on those providers to restore their own services. Those providers may not be able to recover data that [Company]'s own users deleted, or that an attacker encrypted or deleted, so [Company] must hold its own separate copy of the data it cannot afford to lose from each of these tools, as set out in Section 8, rather than relying solely on the provider.

10. Alternate Work Facilities

[Company] has no physical office; all employees work remotely. If an employee loses power or internet access at home, they must use a mobile phone, a mobile hotspot, or an alternate location such as a coworking space or public internet access point to continue working, and must notify the Recovery Lead using the fallback channel in Section 6.

If an event affects multiple employees at once, such as a regional power or network outage, the Recovery Lead must assess how many employees are affected and adjust expectations for response and recovery accordingly, communicating any resulting delay to customers as described in Section 6.

11. Business Continuity Procedures by Scenario

11.1 Customer-Facing Application Unavailable

This scenario covers unavailability of [Company]'s customer-facing application hosted on AWS due to an infrastructure failure, application error, or capacity issue, where the cause is not a security incident.

1. Monitoring or a customer report alerts the Recovery Lead that the application is unavailable.
2. The Recovery Lead assesses the scope, cause, and expected duration of the outage using AWS status information and internal monitoring.
3. If the outage is expected to exceed the recovery time objective in Section 7, the Recovery Lead activates this plan under Section 5.
4. The Recovery Lead restores the affected service from the most recent backup or infrastructure configuration, following Section 8.
5. The Recovery Lead verifies that the application is functioning correctly and that customer data is intact before declaring the incident resolved.
6. The Recovery Lead notifies affected customers of the outage and its resolution, per Section 6.
7. The Recovery Lead records the event for review under Section 12.

11.2 Internal Applications Inaccessible

This scenario covers loss of access to internal tools [Company] depends on for its own operations, such as Google Workspace email and file storage or the GitHub source code repository, where the disruption originates with the supplier rather than [Company]'s own infrastructure.

1. The employee who first notices the disruption reports it to the Recovery Lead, using the fallback channel in Section 6 if the primary channel is affected.
2. The Recovery Lead checks the supplier's status page and support channels to confirm the outage and estimate its duration.
3. If the expected outage exceeds the recovery time objective for the affected tool in Section 7, the Recovery Lead activates this plan and directs employees to the fallback channel and to the separate backup copies described in Section 8.
4. Employees continue essential work using the fallback channel and the available backup copies until the supplier restores service.
5. The Recovery Lead confirms restoration of service and checks that no data was lost beyond the recovery point objective in Section 7.
6. The Recovery Lead records the event for review under Section 12.

11.3 Cybersecurity Breach Recovery

This scenario covers restoring business operations after a confirmed security incident. Investigation, evidence handling, and any regulatory or customer notification about the breach are governed by [Company]'s incident response plan; this plan governs only the continuity and recovery of affected systems and services.

1. The Recovery Lead confirms with whoever is leading the incident response that affected systems have been contained and are safe to recover.
2. The Recovery Lead assesses which business services are disrupted and whether the disruption is expected to exceed the recovery time objective in Section 7.
3. If so, the Recovery Lead activates this plan under Section 5.
4. The Recovery Lead restores affected systems from a backup confirmed to predate the incident, following Section 8.
5. The Recovery Lead verifies system integrity and functionality before returning the system to production use.
6. The Recovery Lead communicates with affected customers as needed, per Section 6.
7. The Recovery Lead records the event for review under Section 12.

11.4 Ransomware Attack

This scenario covers recovery from ransomware or similar malware that encrypts or destroys company data. This plan governs isolation and restoration; the incident response plan governs investigation and notification.

1. The person who discovers the ransomware immediately disconnects the affected system(s) from the network to stop it spreading, and reports it to the Recovery Lead using the fallback channel in Section 6 if needed.
2. The Recovery Lead isolates any other systems that may be affected and notifies whoever is leading the incident response process.
3. The Recovery Lead identifies the most recent backup confirmed to be clean and unaffected by the ransomware before restoring anything.
4. The Recovery Lead restores affected systems only from that clean backup, following Section 8.
5. The Chief Executive Officer decides whether to pay any ransom demand, after obtaining legal advice and confirming that payment would not breach sanctions law; this decision is not delegated to any other role.
6. If [Company] holds cyber insurance, the Recovery Lead or Chief Executive Officer notifies the insurer promptly.
7. The Recovery Lead records the event for review under Section 12.

11.5 Natural Disaster or Loss of a Site or Region

This scenario covers loss of the AWS region hosting [Company]'s infrastructure, or an event that prevents employees from working from their home location, such as a regional power outage or natural disaster.

1. The Recovery Lead determines whether the disruption affects the AWS infrastructure, individual employees, or both.
2. If the AWS region is affected, the Recovery Lead works with AWS support to assess restoration timelines and, if the outage is expected to exceed the recovery time objective in Section 7, restores infrastructure into a different AWS region from backups, following Section 8.
3. If employees are affected, they use the fallback communication channel in Section 6 and, where possible, an alternate location or connection to continue working, per Section 10.
4. If the Recovery Lead is personally affected and unavailable, the Deputy Recovery Lead assumes the role.
5. The Recovery Lead confirms restoration of service and communicates with customers if the disruption affected the customer-facing application, per Section 6.
6. The Recovery Lead records the event for review under Section 12.

11.6 Failure of a Critical Supplier

This scenario covers unavailability of a supplier [Company] depends on to deliver its product or run its business, including AWS for infrastructure, Google Workspace for email and file storage, and GitHub for source code hosting.

1. The Recovery Lead identifies the affected supplier and checks its status page and support channels for an estimated restoration time.
2. If the estimated outage is within the recovery time objective for the affected service in Section 7, the Recovery Lead monitors the situation and keeps employees updated.
3. If the outage is expected to exceed the recovery time objective, the Recovery Lead activates this plan and directs employees to the applicable workaround or backup copy described in Section 8.
4. If the outage is extended or repeated, the Recovery Lead evaluates whether an alternate supplier is needed and raises this with the Chief Executive Officer.
5. The Recovery Lead communicates any customer impact per Section 6.
6. The Recovery Lead records the event for review under Section 12.

12. Testing and Review

[Company] must run a tabletop exercise of this plan at least once per year, in which the Recovery Lead and Deputy Recovery Lead walk through at least one scenario from Section 11. Restore testing under Section 8 must be carried out at least once per year for each critical system. This plan must be reviewed and updated after every activation, after any significant change to [Company]'s systems or suppliers, and at least once per year regardless of whether either of those events has occurred.

13. Appendix A: Emergency Contact and Recovery Information Template

This plan and the contact list below must remain reachable even when [Company]'s main systems are down, for example as a printed copy or a copy stored outside Google Workspace, AWS, and GitHub.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Disaster Recovery & Business Continuity Plan

• Version: 1.0
• Owner: Head of Security
• Approved by: Executive Leadership Team
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

[Company] provides services relied on by banks and other FCA-regulated firms, and holds personal data and financial data on their behalf. This plan sets out how [Company] keeps its critical services running, and how it recovers its systems and data, following a serious disruption such as a system outage, the failure of a supplier, a cyberattack, or the loss of its office or of an AWS region.

This plan sits beneath [Company]'s information security policy. Where a disruption is caused by a security incident, the incident response plan governs investigation, evidence handling and breach notification. This plan governs the continuity of services and the recovery of systems and data during and after such an incident, and the two plans are used together.

2. Scope

This plan covers all of [Company]'s employees, systems and premises, including its AWS-hosted infrastructure, the Okta identity service, Microsoft 365 email and file storage, the team chat tool, its single UK office, and the suppliers that support the services [Company] provides to its financial services and enterprise customers.

3. Policy

[Company] must maintain a documented and tested disaster recovery and business continuity plan that assigns clear roles, sets recovery time and recovery point objectives for its critical systems, requires backups to be kept separately from production systems and accounts, and is reviewed and updated regularly. The Executive Leadership Team must ensure that the people, budget and supplier arrangements needed to meet this plan's objectives are in place.

4. Roles and Responsibilities

[Company]'s security team is small, so recovery responsibilities are concentrated in a small number of named roles, each with a deputy who can act if the primary role-holder is unavailable.

• Crisis Lead (Head of Security): decides whether to activate this plan, leads the response, and reports progress to the Executive Leadership Team throughout the disruption.
• Deputy Crisis Lead (Head of Engineering): stands in for the Crisis Lead when unavailable, and leads the technical recovery of AWS infrastructure, the identity service and other systems.
• Communications Lead: coordinates internal staff communications and customer notifications during an activation, and checks relevant customer contracts for notice periods or availability commitments.
• Security Team: leads investigation of security-related incidents under the incident response plan, advises the Crisis Lead on containment and on when it is safe to restore affected systems, and works with the Deputy Crisis Lead on ransomware recovery.
• Executive Leadership Team: approves this plan, decides whether to pay a ransom after legal advice, and is accountable for [Company]'s overall continuity arrangements.

5. Plan Activation

The Crisis Lead is authorised to activate this plan. If the Crisis Lead is unreachable, the Deputy Crisis Lead may activate it. Activation should be considered as soon as any of the following criteria are met, and does not require every criterion to be satisfied.

• An outage or disruption to a system listed in Section 7 is expected to last longer than its recovery time objective.
• A security incident under investigation by the incident response plan is assessed as also threatening the availability of a critical system, service or facility.
• [Company]'s office is unavailable for normal use for more than 24 hours.
• A supplier notifies [Company] of an outage to a service it provides that is expected to exceed the recovery time objective set for that service in Section 7.
• Senior management judges that a disruption is likely to materially affect [Company]'s ability to serve its customers, even if none of the above thresholds has been formally reached.

6. Communications and Escalation

For day-to-day updates during an activation, the Crisis Lead uses email and the team chat tool to coordinate the response and keep staff informed. Because an outage of Microsoft 365 or of the team chat tool's provider would also take down that channel, the fallback for reaching the Crisis Lead, Deputy Crisis Lead and other response roles is a mobile phone call or SMS, using the contact details held in Appendix A. This fallback must not depend on the same accounts or provider as the primary channel.

The Communications Lead is responsible for telling customers about any disruption that affects the services they receive from [Company]. Before making contact, the Communications Lead must check the relevant customer contract for any agreed availability commitment, notice period or reporting format, since some customer contracts, particularly with financial services customers, set specific expectations for how and when [Company] must notify them of a disruption. Where a customer has its own regulatory obligations arising from the disruption, [Company] must give that customer accurate and timely information to support them, as required by the contract.

7. Recovery Time and Recovery Point Objectives

A recovery time objective (RTO) is the longest a system or service may be unavailable, measured from the point the disruption began. A recovery point objective (RPO) is the maximum amount of data, measured in time, that [Company] can afford to lose, based on how recent its most recent usable backup is. Both are set out below for [Company]'s critical systems, ranked by how much [Company]'s business and its customers depend on them.

If the production AWS account holding the customer-facing application and its databases is itself unavailable or compromised, and recovery must rely on the separate copy described in Section 8, the effective recovery point objective for those systems is 24 hours, matching how often that separate copy is made. Any RTO in this table may fall on a weekend or overnight, so the Crisis Lead and Deputy Crisis Lead must be reachable by mobile phone at all times during an activation, as set out in Section 6.

8. Backup and Restoration

Backups must be taken often enough to meet the recovery point objectives in Section 7, and at least one copy of each type of backup must be kept separate from the production systems and accounts it protects, so that an attacker or an administrator error reaching production cannot also delete or encrypt the backup.

• Application databases must use automated snapshots or point-in-time recovery at least once every hour, retained for at least 30 days.
• Database snapshots must be copied to a separate AWS account at least once every 24 hours, so that a usable copy exists even if the production AWS account is compromised or deleted.
• Infrastructure configuration (server images and infrastructure-as-code templates) needed to rebuild the AWS environment must be version-controlled and stored separately from the production AWS account.
• Okta configuration, including user directory structure, policies and application integrations, must be exported and stored securely outside Okta at least once every 24 hours, retained for at least 90 days.
• Microsoft 365 email and files must be backed up independently of the Microsoft 365 tenant at least once every 24 hours, using credentials and storage separate from the Microsoft 365 administrator account, and retained for at least 90 days. This protects against data deleted by users, administrator error, or an attacker who gains access to the tenant.
• No independent backup is kept of the team chat tool. If the tool becomes unavailable or its data is lost, [Company] accepts the loss of chat history.
• Each critical system (the customer-facing application, its databases, Okta configuration and Microsoft 365 data) must be test-restored from backup at least twice a year, with results recorded and any issues remediated before the next test.

9. Continuity of Critical Services

[Company]'s critical services, the customer-facing application, the supporting databases, staff access through the identity service, and internal communications, run entirely on infrastructure and platforms provided by AWS, Okta and Microsoft 365. Because [Company] hosts its own application infrastructure in the cloud rather than relying solely on a supplier's application, [Company] is responsible for rebuilding that infrastructure itself if it is lost, using the backups described in Section 8. Where a critical service is entirely provided by a supplier, such as identity through Okta or productivity tools through Microsoft 365, [Company] cannot restore that supplier's platform itself; the recovery time objective set for that service in Section 7 instead reflects how long [Company] can operate without it before falling back to the workaround described in the relevant scenario in Section 11.

[Company]'s customers include banks and other firms subject to the EU Digital Operational Resilience Act (DORA), which requires those firms to ensure that suppliers supporting their critical or important functions have, and test, business contingency arrangements. DORA's continuity obligations bind [Company]'s financial services customers rather than [Company] directly, but [Company] meets its customers' expectations through its contracts with them. This plan, together with the testing described in Section 12, is how [Company] demonstrates and maintains the contingency arrangements that those contracts require. [Company] must check each relevant customer contract for any specific continuity, testing or reporting commitments it has agreed to.

10. Alternate Work Facilities

[Company] operates a single office in the United Kingdom and works on a hybrid basis, so most staff already have the laptops and remote access needed to work from home. If the office is unavailable, for example due to fire, flood or a prolonged power or utility failure, the Crisis Lead must direct staff to work from home until the office is usable again, or until a temporary location is arranged.

Where an individual member of staff loses their home internet connection or power, they must use a mobile hotspot or another suitable location to remain reachable and, where their role requires it, continue essential work. Staff who cannot restore connectivity within a reasonable time must inform their manager so that urgent tasks can be reassigned.

11. Business Continuity Procedures by Scenario

11.1 Customer-Facing Application Unavailable

This scenario covers an outage of the customer-facing application or its databases hosted on AWS, whether caused by an AWS platform issue, a faulty deployment or a configuration error.

1. The Deputy Crisis Lead confirms the outage and checks AWS service health for platform-wide issues.
2. Determine whether the cause is within AWS's platform or within [Company]'s own configuration or code.
3. If the outage is expected to exceed the 4-hour recovery time objective, notify the Crisis Lead and consider activating this plan under Section 5.
4. Attempt to restore service by rolling back the recent change, restarting affected components, or rebuilding from the infrastructure configuration and database snapshots described in Section 8.
5. If service cannot be restored within the recovery time objective, the Communications Lead notifies affected customers in line with Section 6.
6. Once restored, verify data integrity against the recovery point objective, document the incident, and review the cause with the engineering team.

11.2 Internal Applications Inaccessible

This scenario covers an outage affecting Microsoft 365 email and file storage, the identity service, or the team chat tool, where staff cannot access one or more internal tools.

1. Confirm which internal system is affected and check the relevant supplier's status page.
2. Switch to the fallback communication channel (mobile phone) described in Section 6 to notify staff of the outage and any workaround.
3. Log a support request with the supplier and monitor its estimated time to resolution.
4. Staff continue essential work using any available alternative, such as mobile access to email or an alternative file location, where one exists.
5. If the outage is expected to exceed the recovery time objective in Section 7, the Crisis Lead decides whether further contingency measures are needed.
6. Once service is restored, review the supplier's incident report and update this plan if the outage revealed a gap.

11.3 Cybersecurity Breach Recovery

This scenario covers restoring services and data following a security incident. The incident response plan governs investigation, evidence handling and any required notifications; this plan governs how affected services and data are recovered once the security team confirms it is safe to do so.

1. Confirm with the security team that the incident response plan has been activated.
2. Identify, with the security team, which systems must be isolated or taken offline to contain the incident.
3. The Crisis Lead decides whether to activate this plan, based on the criteria in Section 5.
4. Once the security team confirms it is safe to do so, restore affected systems from the most recent backup known to be unaffected by the incident.
5. Verify that restored systems are patched and that any compromised credentials have been rotated before returning them to production.
6. The Communications Lead informs staff, and customers where required by contract, once the security team confirms what information can be shared.

11.4 Ransomware Attack

This scenario covers a ransomware attack affecting [Company]'s systems. Affected systems must be isolated before any recovery action is taken, and restoration must only use backups confirmed to be free of the ransomware. Investigation and any required notifications are handled under the incident response plan.

1. Immediately isolate affected systems and accounts from the network, including disabling accounts and revoking access through the identity service.
2. Notify the Crisis Lead and activate the incident response plan for investigation and evidence handling.
3. Do not restore any system or pay any ransom until instructed by the Executive Leadership Team.
4. Identify the most recent backup confirmed to be free of the ransomware before restoring any system.
5. The Executive Leadership Team decides whether to pay a ransom, only after taking legal advice and confirming that payment would not breach applicable sanctions law; the security team and legal counsel must be consulted before any decision.
6. Notify [Company]'s cyber insurer promptly if a policy is in place.
7. Restore systems from clean backups in the priority order set out in Section 7, and verify their integrity before returning them to production.
8. After recovery, review the incident with the security team and update this plan and the backup arrangements in Section 8 if gaps are identified.

11.5 Natural Disaster or Loss of a Site or Region

This scenario covers the loss of [Company]'s UK office or of the AWS region hosting its infrastructure.

1. Confirm the nature and expected duration of the loss, whether it affects the office or the AWS region.
2. If the office is affected, confirm the safety of any staff on site and direct staff to work from home in line with Section 10.
3. If an AWS region is affected, the Deputy Crisis Lead assesses AWS service health and determines whether infrastructure must be rebuilt in another region using the backups described in Section 8.
4. The Crisis Lead activates this plan if the expected downtime exceeds the relevant recovery time objective in Section 7.
5. The Communications Lead notifies staff, and customers if customer-facing services are affected.
6. Once the site or region is restored, or infrastructure has been rebuilt elsewhere, verify all systems and data before resuming normal operations.

11.6 Failure of a Critical Supplier

[Company] depends on AWS for infrastructure hosting, Okta for identity and access, and Microsoft 365 for email and file storage, together with other suppliers that support the services it provides to its financial services and enterprise customers.

1. Confirm the outage with the supplier's status page or support channel and obtain an estimate of expected duration.
2. Assess the estimate against the recovery time objective for the affected service in Section 7.
3. If the outage is expected to exceed the recovery time objective, the Crisis Lead decides whether to activate this plan.
4. The Deputy Crisis Lead implements the fallback identified for that service, such as a manual workaround or an alternative access route, until the supplier restores service.
5. The Communications Lead notifies any customers whose contracted service is affected by the supplier failure.
6. Once the supplier confirms restoration, verify the service and any affected data before resuming normal reliance on it.
7. Record the incident and consider, as part of ongoing supplier oversight, whether the supplier's own resilience arrangements need to be reviewed.

12. Testing and Review

[Company] must run a tabletop exercise of this plan at least once a year, in addition to the backup restore tests required in Section 8. This plan must also be reviewed, and updated where necessary, after every activation and after any significant change to [Company]'s systems, hosting arrangements or critical suppliers.

13. Appendix A: Emergency Contact and Recovery Information Template

A copy of this plan and the completed contact list below must be kept reachable when [Company]'s main systems are down, for example as a printed copy or a copy stored outside [Company]'s primary systems and accounts.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Disaster Recovery & Business Continuity Plan

• Version: 1.0
• Owner: Security Lead
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan sets out how [Company] keeps its business running and restores its systems and data after a serious disruption, such as an outage of a cloud service, the failure of a supplier, a cyberattack, or the loss of the company's office. It sits beneath [Company]'s information security policy and supports [Company]'s obligations as a HIPAA business associate to hospitals and health systems, its SOC 2 Type II examination, and its ongoing work toward HITRUST certification.

Where a disruption is caused by a security incident, [Company]'s incident response plan governs the investigation, evidence handling, and regulatory or customer notification for that incident. This plan governs continuity of operations and the restoration of systems and data, and does not repeat the notification requirements set out in the incident response plan.

2. Scope

This plan covers all systems, applications, and data that support [Company]'s business, including the customer-facing clinical decision support application and supporting infrastructure hosted on Microsoft Azure, Microsoft 365 email and file storage, the team chat tool, and the suppliers [Company] depends on. It applies to all employees and contractors, whether working from [Company]'s office or remotely, and to the personally identifiable information and health data [Company] processes on behalf of its hospital and health system customers.

3. Policy

[Company] must maintain a documented, tested plan for restoring critical systems and continuing business operations after a disruption; must assign clear responsibility for declaring a disaster, leading recovery, and communicating with staff and customers; must define recovery time and recovery point objectives for its critical systems and keep backups sufficient to meet them; and must review and test this plan on the schedule set out in Section 12.

4. Roles and Responsibilities

[Company]'s security function consists of one dedicated Security Lead supported by a security contractor. Recovery from a disruption also depends on the Engineering/IT Lead responsible for [Company]'s Azure environment and application, the Customer Support Lead responsible for customer communications, and executive leadership for decisions with significant business, legal, or financial impact.

• Security Lead: owns this plan, decides whether to activate it, leads recovery efforts, and coordinates with the security contractor and Engineering/IT Lead. Where the Security Lead is unavailable, the security contractor must act in this role.
• Security Contractor: supports investigation and technical recovery activities, confirms backups are clean before restoration, and stands in for the Security Lead when the Security Lead cannot be reached.
• Engineering/IT Lead: restores the Azure-hosted application and databases, Microsoft 365 services, and the team chat tool; executes backup restoration; and reports recovery progress to the Security Lead.
• Customer Support Lead: communicates with affected customers, tracks contractual notice obligations, and coordinates messaging with the Security Lead.
• Executive Leadership (Chief Executive Officer or Chief Operating Officer): approves activation of this plan for events with major business impact, approves any decision to pay a ransom, and approves this plan and material changes to it.
• All employees: report suspected disruptions promptly to the Security Lead and follow instructions issued during an activation.

5. Plan Activation

The Security Lead may activate this plan. Where the Security Lead is unavailable, the security contractor may activate it instead, in consultation with executive leadership where practical. The Security Lead and Engineering/IT Lead must be reachable by mobile phone at all times to meet the recovery time objectives in Section 7, since several of them are shorter than 72 hours and may fall outside business hours or across a weekend.

Activation criteria include:

• An outage of the customer-facing application, or of the Azure infrastructure or databases behind it, that is expected to exceed its recovery time objective.
• Loss of access to Microsoft 365 email and file storage, or to the team chat tool, that is expected to exceed its recovery time objective.
• A confirmed cybersecurity incident, including ransomware, that affects the availability or integrity of production systems or data.
• Loss of, or inability to access, [Company]'s office for more than 24 hours.
• Failure of a critical supplier that is expected to last longer than [Company] can operate without that supplier, as set out in Section 7.

6. Communications and Escalation

The primary channels for internal communication during a disruption are the team chat tool and email. Because email runs on Microsoft 365, an outage of Microsoft 365 will also take down email, so mobile phone calls and text messages must be used as the fallback channel, since they do not depend on Microsoft 365 or the team chat tool's provider. The Security Lead must maintain an up-to-date list of mobile numbers for the roles in Section 4 and keep it reachable independently of [Company]'s main systems, as described in Appendix A.

Customers are hospitals and health systems whose own operations may depend on [Company]'s services, so the Customer Support Lead must notify affected customers promptly of any disruption expected to affect them, using the contact method and notice period set out in the relevant customer contract. The Security Lead must check each material customer contract for availability commitments and notice periods before responding, since these may set stricter timeframes than the recovery objectives in Section 7.

7. Recovery Time and Recovery Point Objectives

A recovery time objective (RTO) is the longest a system or service may be unavailable, measured from the start of the disruption, before [Company] must have it working again. A recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, which determines how often that system's data must be backed up. Objectives for services run by a supplier reflect how long [Company] can operate without that service before switching to an alternative described elsewhere in this plan.

8. Backup and Restoration

Every system with a recovery point objective in Section 7 must have a backup made at least as often as that objective, and at least one copy of critical backups must be kept separate from [Company]'s production systems and administrator accounts, so that an attacker or an administrator error that reaches production cannot also destroy the backup.

• Databases containing clinical and patient data hosted on Azure must be backed up automatically at least once every hour and retained for at least 30 days.
• A copy of Microsoft 365 email and file storage must be exported to a separate backup service at least once every 24 hours and retained for at least 90 days, since Microsoft 365's own retention settings cannot be relied on to recover data an attacker or a user has deleted.
• At least one copy of each backup must be stored in a separate Azure subscription, account, or storage location that is not accessible using the same administrative credentials as production systems.
• Backups of health data must be protected with the same access controls and encryption as the production systems they are copied from.
• The Engineering/IT Lead must test a full restoration of the customer-facing application and its databases from backup at least once every 6 months, and must test restoration of Microsoft 365 data at least once every 12 months. Results of each test must be reported to the Security Lead.

9. Continuity of Critical Services

[Company]'s critical services are the customer-facing clinical decision support application and the Azure infrastructure and databases behind it, Microsoft 365 email and file storage, the Microsoft 365 identity service, and the team chat tool. Because the application supports clinical workflows for hospital and health system customers, an extended outage can affect patient care decisions at those customers, so restoring it takes priority over other services during a disruption.

[Company] maintains continuity of these services by assigning clear recovery responsibility to the Engineering/IT Lead for technical restoration, the Security Lead for coordinating the response, and the Customer Support Lead for keeping customers informed, and by keeping the backups described in Section 8 ready to restore from. Where a critical service is run by Microsoft and [Company] cannot restore it directly, [Company] must monitor the supplier's status communications and switch staff to the fallback channel described in Section 6, or to manual workarounds, once the recovery time objective for that service is reached.

As a HIPAA business associate, [Company] must maintain a contingency plan that includes a data backup plan, a disaster recovery plan, and an emergency mode operation plan. This plan meets that requirement: the data backup plan is set out in Section 8, and the disaster recovery plan is set out in Section 11. The emergency mode operation plan is as follows: while operating in an emergency, on a restored but unverified system, or on a manual workaround, access to health data must remain restricted to authorized personnel using the same authentication controls used in normal operations, and access to health data during that period must continue to be logged so that it can be reviewed once normal operations resume.

10. Alternate Work Facilities

[Company] works in a hybrid model from a single office. If the office is unavailable, staff who would normally work there must work from home instead, using their company laptop, mobile phone, and the communication channels described in Section 6. Where an individual employee's home internet connection or power is unavailable, that employee must work from another location with internet access, such as a coworking space or a public location with Wi-Fi, and notify their manager of the change.

If the office is expected to be unavailable for more than 5 business days, the Security Lead must arrange access to a temporary shared workspace for staff who cannot work effectively from home, or extend remote-work arrangements for the duration of the outage.

11. Business Continuity Procedures by Scenario

11.1 Customer-Facing Application Unavailable

This scenario covers an outage of the clinical decision support application or its supporting Azure infrastructure that is not caused by a confirmed security incident, such as a deployment failure, a capacity issue, or an Azure regional problem.

1. Engineering/IT Lead confirms the outage and its scope using application monitoring and Azure logs.
2. Engineering/IT Lead checks Azure's service health page for a regional incident affecting the hosting region.
3. Security Lead is notified and decides whether to activate this plan against the criteria in Section 5.
4. Engineering/IT Lead restores the application from the most recent clean deployment or backup, per Section 8.
5. Customer Support Lead notifies affected customers per Section 6, checking contractual notice obligations.
6. Once restored, Engineering/IT Lead confirms the restored data is within the recovery point objective in Section 7.
7. Security Lead records the timeline and, if the recovery time objective was missed, flags the event for the next review under Section 12.

11.2 Internal Applications Inaccessible

This scenario covers loss of access to Microsoft 365 email and file storage, the Microsoft 365 identity service, the team chat tool, or other internal business applications, where the customer-facing application is unaffected.

1. Affected employees report the issue to the Security Lead using the fallback channel in Section 6.
2. Security Lead confirms the scope by checking Microsoft 365's service health page and the team chat tool's status page.
3. Employees switch to the fallback communication channel in Section 6 for the duration of the outage.
4. Engineering/IT Lead monitors the supplier's restoration progress and provides regular updates to the Security Lead.
5. If the outage exceeds the recovery time objective in Section 7, the Security Lead directs staff to use manual or alternate methods until the service is restored.
6. On restoration, Engineering/IT Lead confirms no data loss beyond the recovery point objective and reports to the Security Lead.

11.3 Cybersecurity Breach Recovery

This scenario covers restoring systems after a confirmed security incident. Investigation, evidence handling, and regulatory or customer notification for the incident itself are governed by [Company]'s incident response plan; this section covers only the continuity and recovery actions.

1. Security Lead confirms the incident response plan has been activated and containment actions are underway.
2. Engineering/IT Lead isolates affected systems from the network as directed under the incident response plan.
3. Security Lead determines which systems must be restored first, using the priorities in Section 7.
4. Engineering/IT Lead restores affected systems from backups the Security Lead or security contractor has confirmed to be clean.
5. Security Lead verifies restored systems before they are returned to production.
6. Customer Support Lead prepares customer communications, coordinated with the notification steps in the incident response plan.
7. Security Lead documents the recovery timeline and actions taken for the post-incident review.

11.4 Ransomware Attack

This scenario covers a ransomware attack affecting [Company]'s systems. Recovery must not begin until affected systems are isolated and a clean backup has been confirmed, since restoring from an infected backup would reintroduce the attack.

1. Engineering/IT Lead immediately isolates affected systems and accounts from the network to stop further spread.
2. Security Lead activates the incident response plan for investigation and evidence handling.
3. Security Lead and security contractor identify the most recent backup confirmed to be free of the ransomware before any restoration begins.
4. Engineering/IT Lead restores affected systems only from that confirmed clean backup, rebuilding systems from a known-good image where needed.
5. Executive leadership decides, after legal advice and a check that payment would not breach sanctions law, whether to pay any ransom; the Security Lead must not authorize payment without that approval.
6. Security Lead notifies [Company]'s cyber insurance provider promptly, if one is in place.
7. Security Lead coordinates regulatory and customer notification with the incident response plan.
8. Security Lead confirms restored systems are clean before they are returned to production.

11.5 Natural Disaster or Loss of a Site or Region

This scenario covers the loss of [Company]'s office, or the loss of the Azure region hosting the application or its databases.

1. Security Lead confirms the nature and expected duration of the loss.
2. If the office is affected, Security Lead directs staff to work from home or a temporary location per Section 10.
3. If the Azure region hosting the application or databases is affected, Engineering/IT Lead follows Azure's regional recovery guidance and restores systems in an available region from the backups described in Section 8.
4. Security Lead notifies the Customer Support Lead to communicate any customer impact.
5. Security Lead tracks recovery progress against the recovery time objectives in Section 7 and escalates to executive leadership if they cannot be met.
6. Security Lead documents the event and any deviation from the planned recovery timeline.

11.6 Failure of a Critical Supplier

[Company] depends on Microsoft Azure for infrastructure hosting and Microsoft 365 for email and file storage, and on other outsourced service providers that process data on its behalf. This scenario covers the unavailability of any of these suppliers.

1. Security Lead identifies the affected supplier and the expected duration of the outage.
2. Security Lead checks the supplier's status page and support channels for updates.
3. If the outage is expected to exceed the recovery time objective for the affected service in Section 7, Security Lead directs the Engineering/IT Lead to switch to the fallback described for that service.
4. Security Lead reviews the supplier contract for applicable service level commitments and support escalation paths.
5. Customer Support Lead communicates any customer impact per Section 6.
6. After resolution, Security Lead reviews the event and considers whether the supplier's contract or [Company]'s dependency on it should change.

12. Testing and Review

The Security Lead must run a tabletop exercise of this plan at least once every 12 months, in addition to the backup restoration tests required in Section 8. This plan must also be reviewed, and updated where necessary, after every activation and after any significant change to [Company]'s systems, hosting arrangements, or suppliers.

13. Appendix A: Emergency Contact and Recovery Information Template

This plan and the contact information below must remain reachable when [Company]'s main systems are down, such as through a printed copy held at the office and with the Security Lead, or a copy stored outside [Company]'s Microsoft 365 environment.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Disaster Recovery & Business Continuity Plan

• Version: 1.0
• Owner: Chief Information Security Officer (CISO)
• Approved by: Chief Executive Officer (CEO)
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan sets out how [Company] keeps its business operating and recovers its systems and data following a serious disruption, including an outage of a cloud service, a failed supplier, a cyberattack, or the loss of a building or a cloud region. [Company] provides managed IT and security services, including security operations center (SOC) monitoring, to defense contractors and government agencies, so a disruption to its own operations can directly affect customers who depend on continuous monitoring and support.

This plan sits beneath [Company]'s information security policy. Where a disruption is caused by a security incident, the incident response plan governs investigation, evidence handling, and notification obligations; this plan governs how [Company] keeps critical services running and restores systems and data during and after that incident. This plan does not repeat breach notification deadlines, which are set out in the incident response plan.

1.1 Scope

This plan covers all systems, applications, facilities, and staff that support [Company]'s operations and its delivery of services to customers, including systems hosted in Microsoft Azure Government, Microsoft 365 email and file storage, on-premises systems at [Company]'s facilities, and the tools [Company] uses to communicate internally and with customers. It applies to disruptions of any cause, including technical failure, cyberattack, supplier failure, and loss of access to a facility, and to all employees and contractors involved in restoring services or supporting customers during a disruption.

2. Policy

[Company] must maintain a documented disaster recovery and business continuity plan that identifies its critical systems and services, sets recovery objectives for each, defines how backups are made and tested, and assigns clear responsibility for activating and running the recovery effort; the plan must be reviewed and tested at the intervals set out in this document and kept up to date as systems, suppliers, and staffing change.

3. Roles and Responsibilities

Recovery is led by the CISO, supported by the Business Continuity Coordinator and a small set of recovery teams aligned to [Company]'s main platforms. Each role identified below must have a deputy, nominated by the role's lead, who can act if the primary person is unavailable.

• Chief Information Security Officer (CISO): owns this plan, has authority to activate it, and chairs the Crisis Management Team during an activation.
• Business Continuity Coordinator: maintains the plan and the contact information in Appendix A, coordinates testing and review, and may activate the plan if the CISO is unavailable.
• IT Operations Director: leads technical recovery of Azure Government–hosted systems and on-premises infrastructure, and may activate the plan if both the CISO and the Business Continuity Coordinator are unavailable.
• SOC Manager: leads the response to disruptions caused by a security incident, working alongside the incident response plan, and directs the SOC team's monitoring of customer environments during the disruption.
• Communications Lead: manages internal updates to staff and external communications to customers and, where needed, regulators or other authorities.
• HR Lead: coordinates staff welfare, alternate work arrangements, and communications with employees who cannot reach a facility.
• Legal and Compliance Lead: advises on contractual notice obligations, regulatory considerations, and, for a ransomware event, sanctions and legal exposure.
• Cloud Infrastructure Recovery Team, On-Premises Recovery Team, and Service Desk Recovery Team: carry out the technical steps needed to restore their respective systems, reporting to the IT Operations Director.
• Crisis Management Team: the CISO, IT Operations Director, SOC Manager, Communications Lead, HR Lead, and Legal and Compliance Lead, convened by the CISO to direct the response to a major disruption.

4. Plan Activation

The CISO must activate this plan. If the CISO is unavailable, the Business Continuity Coordinator may activate it; if both are unavailable, the IT Operations Director may activate it. Activation must be considered whenever any of the following applies:

• A disruption to a customer-facing or revenue-critical system is expected to last longer than that system's recovery time objective as set out in Section 6.
• A confirmed security incident affects the availability of a system, a facility, or customer-facing services.
• A [Company] facility is unavailable, whether due to a natural disaster, utility failure, or other cause, and staff cannot work from it.
• A critical supplier notifies [Company], or [Company] otherwise determines, that an outage is expected to last longer than 8 hours.
• Any disruption is expected to prevent [Company] from meeting its contractual service commitments to customers.

5. Communications and Escalation

The primary internal channel during a disruption is email (Microsoft 365) and the team chat tool. Because both can be affected by an outage of Microsoft 365, the fallback channel is telephone, using mobile and landline numbers held in Appendix A; the Crisis Management Team must use a phone call tree to reach recovery teams and staff if email and the team chat tool are both unavailable. The Business Continuity Coordinator must keep Appendix A up to date so that contact details remain usable during an outage of the systems that normally hold them.

Customers must be told promptly of any disruption that affects the services [Company] provides to them. The Communications Lead is responsible for customer notification, using the customer's designated contact channel and, where email or the team chat tool is unavailable, telephone. Customer contracts, particularly those with defense and government customers, may set specific availability commitments and notice periods; the Legal and Compliance Lead must check the relevant contract before or as part of any customer notification to confirm what is required.

6. Recovery Time and Recovery Point Objectives

A recovery time objective (RTO) is the longest a system or service may be unavailable, measured from the start of the disruption, before it must be restored or replaced with a workaround. A recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, and therefore how often that data must be backed up. Systems are ranked below by how directly they affect customers and revenue.

Every recovery time objective in this table is a calendar figure, not a business-hours figure, and can fall across a weekend or holiday. To meet any objective of less than 72 hours outside normal working hours, the IT Operations Director must be reachable by mobile phone at any time, and must be able to reach the relevant recovery team by phone using the call tree in Appendix A.

7. Backup and Restoration

Backups must be made frequently enough to meet the recovery point objectives in Section 6, and at least one copy of each backup must be kept separate from production systems and accounts, using storage and credentials that a compromise of production systems or a production administrator account cannot reach, so that an attacker or an administrator error cannot delete or encrypt both the original and the backup.

• Logs and data in the SOC monitoring and SIEM platform must be backed up or snapshotted at least every 15 minutes and retained for at least 90 days.
• The customer service desk and ticketing platform must be backed up at least every hour and retained for at least 30 days.
• Azure Government–hosted customer environments must be backed up or snapshotted at least every hour, retained for at least 30 days, and a copy must be kept in a separate Azure subscription or account from the production environment.
• On-premises systems, including the CUI enclave, must be backed up at least every 4 hours, with backups retained for at least 90 days; backups of controlled unclassified information must be protected with the same access controls and encryption as the original data.
• Microsoft 365 email and file storage must be exported or backed up to a location outside Microsoft 365 at least once every 24 hours and retained for at least 90 days, since Microsoft cannot restore data that a user or an attacker has deleted from the tenant.
• The Microsoft 365 identity service and the team chat tool are supplier-managed and hold no data that [Company] backs up separately; [Company] relies on the supplier's own resiliency for these services.
• A restore of each critical system listed in Section 6 must be tested at least twice every 12 months for the SOC monitoring platform, the service desk platform, and Azure Government–hosted customer environments, and at least once every 12 months for all other systems; the results must be recorded and any failure corrected before the next test.

8. Continuity of Critical Services

[Company]'s most critical service to customers is continuous SOC monitoring and alerting, so the Cloud Infrastructure Recovery Team and SOC Manager must prioritize restoring or working around the SOC monitoring and SIEM platform above all other systems during a disruption. Where the platform itself is unavailable, the SOC team must fall back to manual review of available logs and direct communication with affected customers until the platform is restored, and must document any period during which monitoring coverage was reduced.

Internal critical functions, including the service desk and the ability of staff to access customer environments, must also be maintained during a disruption; where the service desk platform is unavailable, service desk staff must use the fallback communication channels in Section 5 to log and track customer requests manually until the platform is restored. Given that [Company] handles controlled unclassified information under NIST SP 800-171 and CMMC Level 2, backups of that data must retain the access controls and protections described in Section 7 throughout any period of degraded or manual operation.

9. Alternate Work Facilities

[Company] operates more than one facility, so if a facility becomes unavailable, staff normally based there must work from another [Company] facility or from home, using the hybrid work arrangements already in place. HR must coordinate with affected staff to confirm where they will work and how they will be reached.

Where a facility houses on-premises systems, the loss of that facility also affects power, hardware, and physical access to those systems; the IT Operations Director must assess whether on-premises systems can be restored at another [Company] facility or whether services must run on Azure Government alone until the affected facility is restored or replaced.

10. Business Continuity Procedures by Scenario

10.1 Customer-Facing Application Unavailable

This scenario covers the SOC monitoring and SIEM platform, the customer service desk platform, or Azure Government–hosted customer environments becoming unavailable to customers.

1. The person who first identifies the outage must report it immediately to the SOC Manager or IT Operations Director.
2. The IT Operations Director must confirm the scope of the outage and estimate how long it is expected to last.
3. If the expected outage exceeds the system's recovery time objective in Section 6, the IT Operations Director must notify the CISO, who decides whether to activate this plan.
4. The Communications Lead must notify affected customers, following Section 5.
5. The relevant recovery team must restore the system from the most recent clean backup or, where the cause is a supplier outage, monitor the supplier's status and prepare a manual workaround for the service desk or SOC team.
6. Once restored, the IT Operations Director must confirm the system is functioning correctly and the Communications Lead must notify customers that service has resumed.
7. The Business Continuity Coordinator must record the cause, duration, and impact of the outage.

10.2 Internal Applications Inaccessible

This scenario covers Microsoft 365 email and file storage, the Microsoft 365 identity service, the team chat tool, or on-premises administrative systems becoming inaccessible to staff.

1. IT staff who identify the issue must report it to the IT Operations Director.
2. The IT Operations Director must determine whether the cause is internal (for example, an on-premises network or hardware fault) or a supplier outage.
3. If a supplier outage, the IT Operations Director must check the supplier's service status and estimate the expected duration.
4. Staff must switch to the fallback communication channel in Section 5 for the duration of the outage.
5. If an on-premises system is affected, the On-Premises Recovery Team must restore the system from the most recent backup.
6. If the outage of a supplier-run service is expected to exceed its recovery time objective in Section 6, the IT Operations Director must notify the CISO, and staff must continue working using the fallback channel and manual processes until the service is restored.
7. Once resolved, the IT Operations Director must confirm normal access is restored and notify staff.

10.3 Cybersecurity Breach Recovery

This scenario covers restoring systems following a confirmed security incident; investigation, evidence handling, and any notification to customers, regulators, or authorities are governed by the incident response plan, not this plan.

1. The SOC Manager must confirm with the incident response team which systems are affected and whether it is safe to begin recovery.
2. The IT Operations Director must not restore any affected system until the incident response team confirms the cause has been contained.
3. Affected systems must be restored from a backup confirmed to predate the compromise.
4. The Cloud Infrastructure Recovery Team or On-Premises Recovery Team must rebuild or patch affected systems before reconnecting them to the network.
5. The SOC Manager must confirm restored systems are being monitored before they are returned to normal use.
6. The Business Continuity Coordinator must record the systems affected, the recovery actions taken, and the time to restore each system.

10.4 Ransomware Attack

This scenario covers a ransomware attack that encrypts [Company] systems or data.

1. The person who discovers the attack must immediately notify the SOC Manager and IT Operations Director.
2. Affected systems must be isolated from the network immediately to stop further spread, following direction from the SOC Manager.
3. The incident response plan governs investigation and evidence handling from this point; recovery must not begin until the incident response team confirms which backups are clean.
4. Systems must be restored only from backups confirmed to be unaffected by the attack, never from the encrypted systems themselves.
5. Senior management, referred to here as the Crisis Management Team together with the CEO, must decide whether to pay any ransom, only after legal advice from the Legal and Compliance Lead and confirmation that payment would not breach sanctions law; [Company] must not pay a ransom without this review.
6. If [Company] holds cyber insurance, the Legal and Compliance Lead must notify the insurer promptly.
7. Once systems are restored and confirmed clean, the IT Operations Director must reconnect them to the network in a controlled sequence, monitored by the SOC team.
8. The Business Continuity Coordinator must record the systems affected, the recovery actions taken, and lessons learned.

10.5 Natural Disaster or Loss of a Site or Region

This scenario covers the loss of a [Company] facility or an Azure Government region.

1. The person who becomes aware of the event must notify the CISO or Business Continuity Coordinator immediately.
2. The CISO must confirm staff safety and, working with HR, account for all staff normally based at the affected facility.
3. If a facility is lost, affected staff must move to another [Company] facility or work from home, per Section 9.
4. If an Azure Government region is affected, the Cloud Infrastructure Recovery Team must assess whether services can be restored in the same region once available, and must restore data and systems from backup once the region or a replacement is available.
5. The Communications Lead must notify customers of any effect on service, per Section 5.
6. Once the facility or region is restored, the IT Operations Director must confirm systems are fully operational before returning to normal operations.

10.6 Failure of a Critical Supplier

[Company] depends on suppliers including its cloud provider (Microsoft Azure Government and Microsoft 365), internet and telecommunications providers, and hardware maintenance vendors supporting its on-premises systems.

1. The person who identifies the supplier failure must notify the IT Operations Director.
2. The IT Operations Director must contact the supplier to confirm the cause and expected duration of the outage.
3. If the expected outage exceeds the recovery time objective for the affected system in Section 6, the IT Operations Director must notify the CISO and activate the relevant fallback described in this plan, such as the manual workaround in Section 10.1 or the alternate communication channel in Section 5.
4. The Communications Lead must notify affected customers where the supplier failure affects services delivered to them.
5. The Business Continuity Coordinator must record the supplier, the duration of the failure, and the impact on [Company]'s services, and the CISO must consider whether the supplier relationship needs review as a result.

11. Testing and Review

[Company] must run a tabletop exercise of this plan at least once every 12 months, involving the Crisis Management Team and the recovery teams, in addition to the restore tests described in Section 7. This plan must also be reviewed, and updated as needed, at least once every 12 months, after any activation of this plan, and after any significant change to [Company]'s systems, facilities, or suppliers. The Business Continuity Coordinator must record the results of each exercise and each review, and track any corrective actions to completion.

12. Appendix A: Emergency Contact and Recovery Information Template

A copy of this plan and the contact list below must be kept reachable when [Company]'s main systems are down, such as a printed copy held at each facility or an electronic copy stored outside [Company]'s primary systems and accounts.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Disaster Recovery & Business Continuity Plan

• Version: 1.0
• Owner: Chief Information Security Officer (CISO)
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan sets out how [Company] keeps its business operating and restores its systems and data after a serious disruption, including a technology outage, a failed supplier, a cybersecurity incident, or the loss of a building or a cloud region. It supports [Company]'s wider information security policy and its alignment with ISO 27001 and its SOC 2 program by describing, in advance, who decides to activate a recovery response, how the business communicates during a disruption, and how quickly each critical system and its data must be recovered.

Where a disruption is caused or suspected to be caused by a security incident, [Company]'s incident response plan governs investigation, evidence handling and regulatory or customer notification. This plan governs the continuity of the business and the recovery of systems and data during and after that incident. The two plans run in parallel: the incident response plan answers "what happened and who must be told," and this plan answers "how does the business keep running and how do systems come back."

2. Scope

This plan applies to all [Company] employees, contractors, and business units worldwide, including its offices in the United States, United Kingdom, European Union, and India, and to all systems that support [Company]'s products and internal operations, whether hosted on Amazon Web Services (AWS), Microsoft Azure, Google Cloud, or provided by a third-party software-as-a-service (SaaS) supplier such as Okta or ServiceNow. It covers disruptions of any cause, including infrastructure and cloud provider outages, supplier failures, cybersecurity incidents, and the loss of a physical facility.

3. Policy

[Company] must maintain a current business continuity and disaster recovery plan covering its critical systems and services, with defined recovery objectives, backup arrangements, and recovery procedures for foreseeable disruption scenarios. The plan, its recovery objectives, and its contact information must be reviewed and tested regularly, kept up to date as systems and suppliers change, and made available in a form that staff can reach even when [Company]'s primary systems are unavailable.

4. Roles and Responsibilities

Because of [Company]'s size, recovery is coordinated by a Crisis Management Team (CMT) supported by named recovery teams for each major platform. Each role below has a designated deputy who can act if the primary holder is unavailable, and outsourced suppliers act only within the scope of their contracted services; decisions about whether to activate this plan and how to respond remain with [Company].

• Crisis Management Team (CMT): convened for any disruption meeting the activation criteria in section 5; chaired by the Chief Operating Officer (COO), deputized by the Chief Technology Officer (CTO); coordinates the overall business response, approves major decisions, and authorizes external communications.
• Business Continuity Lead: a role within the CISO's team; coordinates plan activation, tracks recovery progress against the objectives in section 7, and calls the CMT together; deputized by a named member of the security team.
• Cloud Infrastructure Recovery Team: responsible for recovering systems hosted on AWS, Microsoft Azure, and Google Cloud, led by a Director of Platform Engineering with a named deputy.
• Identity and Access Recovery Team: responsible for recovering and, where necessary, working around the Okta identity service, led by a Director of Identity and Access Management with a named deputy.
• IT Service Management Team: responsible for the ServiceNow platform and for logging and tracking incidents when ServiceNow itself is unavailable, led by a Head of IT Operations with a named deputy.
• Regional Site Leads (US, UK, EU, India): confirm staff safety, coordinate the local response to loss of a facility, and report status to the CMT; each site has a named deputy.
• Legal and Privacy Team: advises on regulatory and contractual notification obligations, sanctions law, and, in the case of ransomware, whether payment is lawful.
• Communications Team: manages internal and customer-facing communications during a disruption, in coordination with account teams for enterprise customers.
• Senior Management: decides whether to authorize payment of a ransom, as set out in section 11.4; this decision rests with senior management and no other role.

5. Plan Activation

The Business Continuity Lead may activate this plan; if unavailable, the CISO or the CISO's deputy may activate it. Activation must be reported to the CMT chair without delay. The plan must be activated when any of the following criteria are met:

• An outage of a customer-facing or revenue-critical system is expected to exceed its recovery time objective as set out in section 7.
• A physical facility becomes unavailable or unsafe to occupy.
• A cybersecurity incident, including a confirmed ransomware attack, affects the availability or integrity of a critical system.
• A critical supplier's service is unavailable and is expected to remain unavailable for longer than the recovery time objective assigned to it in section 7.
• The CMT chair, CISO, or Business Continuity Lead judges that a disruption otherwise poses a material risk to [Company]'s ability to serve its customers or operate normally.

6. Communications and Escalation

The primary channel for internal communication during a disruption is corporate email and the team chat tool. Because an outage of the underlying provider can take down both of these at the same time, the fallback channel is a direct phone call or text message to mobile phones, using the contact details held in Appendix A, which does not depend on the same accounts or provider. Video calls may be used once initial contact has been established through the fallback channel, to bring the CMT and recovery teams together.

Escalation runs from the person who first detects or reports a disruption, to the relevant recovery team lead or site lead, to the Business Continuity Lead, to the CMT. Security-related disruptions are escalated to the CISO in parallel, in line with the incident response plan. Enterprise customers affected by an outage of a customer-facing system must be told through their account team and, where available, a status page, as soon as the impact and expected duration are known; customer contracts may set availability commitments and notice periods, and the Legal team must check these before or as part of any customer communication.

7. Recovery Time and Recovery Point Objectives

A recovery time objective (RTO) is the longest a system or service can be unavailable, measured from the start of the disruption, before the impact on the business becomes unacceptable. A recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, which determines how frequently that system's data must be backed up. Both objectives are set out below for [Company]'s most significant systems, ranked by how much the business depends on them.

Any RTO shorter than 72 hours can fall across a weekend or overnight, so recovery teams must be reachable outside normal business hours by a phone call to the relevant recovery team lead's mobile number, held in Appendix A. For systems run by a supplier that [Company] cannot restore itself, such as Okta, ServiceNow, and the corporate email, chat, and video tools, the RTO is the longest [Company] can work without that service; when that time is reached, staff must switch to the manual workaround described for that system in section 11.2.

8. Backup and Restoration

Backup arrangements must be at least as frequent as the recovery point objective set for each system in section 7, and at least one copy of every backup must be kept separate from production systems and accounts so that an attacker or an administrator error affecting production cannot also delete or encrypt the backup.

• Production databases and customer data stores must be backed up continuously or at least every 15 minutes, retained for at least 30 days, and copied to a cloud account and region separate from production, with access restricted from production credentials.
• Infrastructure configuration and deployment scripts for systems running on AWS, Microsoft Azure, and Google Cloud must be stored in version control and backed up at least once a day.
• The configuration of the Okta identity service must be exported and backed up at least every 24 hours and stored separately from the live Okta tenant.
• Data held in SaaS applications that [Company] does not run itself, including ServiceNow and the corporate email, chat, and financial and HR systems, must be exported and backed up by [Company] at least every 24 hours and stored outside the supplier's account, because the supplier may not be able to restore data that [Company]'s own users have deleted or that an attacker has encrypted.
• Backups containing personal data or sensitive personal data must be protected with the same access controls and encryption as the original data.
• A restore from backup must be tested for each critical system at least twice a year, and the results recorded as described in section 12.

9. Continuity of Critical Services

[Company]'s highest continuity priority is the availability of its customer-facing product, which runs on infrastructure across AWS, Microsoft Azure, and Google Cloud and depends on the Okta identity service for staff and, where applicable, customer access. Because these are enterprise customers, sustained unavailability of the product carries both revenue and contractual risk, so recovery of the customer-facing product and its underlying databases takes priority over internal systems in any disruption affecting more than one service at once.

Internal services, including the ServiceNow platform used for IT service management, and corporate email, chat, financial, and HR systems, support [Company]'s operations across its US, UK, EU, and India offices and its cross-border transfers of data between group entities. These systems are recovered after customer-facing services unless a disruption to them alone triggers activation under section 5. Recovery teams must coordinate across regions so that a disruption affecting one office or one cloud provider does not stop staff in other locations from continuing to support customers.

10. Alternate Work Facilities

[Company] operates more than one physical office, in the United States, United Kingdom, European Union, and India, and works on a hybrid basis. If a single office becomes unavailable, staff at that site must move to remote working from home, or to another [Company] office in the same region if one is available, until the affected site is restored. Because [Company]'s systems run in the cloud rather than in any office, the loss of an office does not by itself affect the availability of the customer-facing product or other hosted systems; it affects only the staff based at that location.

Where a disruption affects an individual employee's home internet connection or power rather than a whole site, that employee must use their mobile phone to stay reachable and, where practical, relocate temporarily to another [Company] office or a public workspace to continue working.

11. Business Continuity Procedures by Scenario

11.1 Customer-Facing Application Unavailable

This scenario covers unplanned unavailability of the customer-facing product caused by an infrastructure fault, a cloud provider incident, or a failed deployment, where there is no indication of a security incident.

1. Monitoring or a user report triggers an incident record in ServiceNow and alerts the on-call engineer.
2. The Cloud Infrastructure Recovery Team assesses the scope of the outage and estimates the time to restore service.
3. If the estimated downtime is expected to exceed the recovery time objective in section 7, the Business Continuity Lead activates this plan per section 5.
4. The Cloud Infrastructure Recovery Team restores or fails over the affected components using established recovery runbooks.
5. The Communications Team updates the status page and notifies affected enterprise customers per section 6.
6. Once restored, the recovery team verifies functionality and data integrity before closing the incident.
7. The incident is recorded for review as described in section 12.

11.2 Internal Applications Inaccessible

This scenario covers unavailability of internal tools, including ServiceNow, corporate email and the team chat tool, and financial or HR systems, where the cause is not a security incident.

1. Staff report the issue to IT Operations by phone, since the usual ticketing tool may itself be affected.
2. IT Operations confirms whether the cause is internal to [Company] (for example, a network or Okta issue) or a fault at the SaaS provider.
3. If the provider is at fault, IT Operations checks the provider's status page and obtains an estimated restoration time.
4. If the outage is expected to exceed the recovery time objective in section 7, the Business Continuity Lead directs staff to the fallback communication channel in section 6 and to the manual workaround for the affected system, such as logging requests by phone instead of in ServiceNow.
5. If the cause is internal, the relevant recovery team (for example, the Identity and Access Recovery Team for an Okta issue) restores the system using its recovery runbook.
6. Once restored, the recovery team confirms data integrity, and the incident is recorded for review as described in section 12.

11.3 Cybersecurity Breach Recovery

This scenario covers restoring the availability and integrity of systems following a confirmed security breach. Investigation, containment decisions, evidence handling, and regulatory or customer notification of the breach itself are governed by the incident response plan; this section governs how [Company] keeps operating and gets systems back.

1. The security team confirms the breach and hands investigation to the incident response plan.
2. The Business Continuity Lead assesses the impact on availability of critical systems and checks whether the activation criteria in section 5 are met.
3. Recovery teams isolate affected systems as directed under the incident response plan, while continuing to plan for restoration.
4. Recovery teams restore affected systems from backups confirmed to be unaffected, per section 8, coordinating with the security team to avoid reintroducing compromised access or data.
5. The Communications Team, working with Legal, notifies affected customers and regions as required per section 6.
6. Once systems are confirmed clean and restored, normal operations resume, and the incident is recorded for review as described in section 12.

11.4 Ransomware Attack

This scenario covers an attack in which [Company]'s systems or data are encrypted or held hostage. Investigation, evidence preservation, and regulatory notification proceed under the incident response plan; this section governs containment for continuity purposes and restoration of service.

1. On detection, IT Operations and the security team immediately isolate affected systems from the network to stop the spread, as directed by the incident response plan.
2. The Business Continuity Lead confirms the scope of affected systems and the likely approach to restoration.
3. Recovery teams restore only from backups confirmed to be clean and unaffected, per section 8; backups taken after the suspected point of compromise must not be used until verified clean.
4. The decision whether to pay a ransom rests solely with the Chief Executive Officer, taken only after legal advice from the Legal team and confirmation that payment would not breach sanctions law.
5. If [Company] holds cyber insurance, the insurer must be notified promptly, using the contact details in Appendix A.
6. Investigation, evidence handling, and any regulatory or customer notification proceed under the incident response plan.
7. Once clean systems are restored and verified, normal operations resume, and the incident is recorded for review as described in section 12.

11.5 Natural Disaster or Loss of a Site or Region

This scenario covers the loss of, or loss of access to, a [Company] office, or a disruption to a cloud provider region hosting production systems.

1. The relevant Site Lead confirms the loss or inaccessibility of the office and notifies the regional lead and the CMT.
2. Employee safety is confirmed first, using the mobile phone contact tree in Appendix A.
3. The Business Continuity Lead assesses whether staff need to move to an alternate facility per section 10 and communicates the plan to affected staff.
4. Staff at the affected site move to remote working or to another [Company] office as directed.
5. If the disruption also affects a cloud provider region hosting production systems, the Cloud Infrastructure Recovery Team fails over to another region or provider using established runbooks, working to the objectives in section 7.
6. Once the site or service is confirmed restored, the event is recorded for review as described in section 12.

11.6 Failure of a Critical Supplier

[Company] depends on its cloud infrastructure providers (AWS, Microsoft Azure, Google Cloud), its identity provider (Okta), and its IT service management provider (ServiceNow), among other enterprise suppliers.

1. IT Operations or vendor management confirms the outage through the supplier's status page or support channel and obtains an estimated restoration time.
2. The Business Continuity Lead checks whether the outage is expected to exceed the recovery time objective assigned to that supplier's service in section 7.
3. If exceeded, the relevant team switches to the defined workaround for that supplier, such as break-glass access if Okta is unavailable, or manual, phone-based incident logging if ServiceNow is unavailable.
4. Vendor management escalates directly with the supplier's account or support team under the terms of the applicable contract.
5. The Legal team reviews the supplier's contractual service levels and remedies if the outage breaches an agreed commitment.
6. Once the supplier's service is restored, the recovery team confirms data integrity and the event is recorded for review as described in section 12.

12. Testing and Review

This plan must be tested through a tabletop exercise at least once a year, involving the CMT and the main recovery teams. Restore testing for critical systems, as described in section 8, must be carried out at least twice a year. A failover test for the systems supporting the customer-facing product across [Company]'s cloud providers must be carried out at least twice a year. In addition to scheduled testing, this plan must be reviewed after every activation under section 5 and after any significant change to [Company]'s systems or suppliers, and reviewed in full at least once a year.

13. Appendix A: Emergency Contact and Recovery Information Template

This table, and the rest of this plan, must be kept reachable when [Company]'s main systems are down, such as through a printed copy held at each office or a copy stored outside [Company]'s primary systems.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Disaster Recovery & Business Continuity Plan

• Version: 1.0
• Owner: Operations Manager
• Approved by: Executive Director
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan describes how [Company] keeps essential programs and services running, and how it recovers systems and data, after a serious disruption such as a system outage, a failed supplier, a cybersecurity incident, or the loss of the company's office. Because [Company] serves donors and vulnerable beneficiaries, a disruption to its ability to accept donations, communicate, or access beneficiary records can have a direct effect on the people it depends on and the people it serves.

This plan sits beneath [Company]'s information security policy. Where a disruption is caused by a security incident, [Company]'s incident response plan governs investigation, evidence handling, and notification, and this plan governs continuity of operations and the recovery of systems and data. This document does not repeat the notification steps or deadlines set out in the incident response plan.

2. Scope

This plan applies to all systems, tools, and services used by [Company], including Microsoft 365 and other cloud-based (software-as-a-service, or "SaaS") tools, and covers all staff and volunteers, whether working from the office or remotely; it does not cover on-premises servers or data centers because [Company] does not operate any of its own.

3. Policy

[Company] must maintain a documented, tested plan that allows it to continue essential programs, protect donor and beneficiary data, and restore its systems within the recovery time objectives set out in this plan; the Operations Manager must keep this plan current, and all staff must know how to find it and who to contact in a disruption.

4. Roles and Responsibilities

[Company] does not run its own IT infrastructure and relies on an outsourced IT/security provider for technical support; the roles below define who decides to activate this plan, who coordinates the response, and who carries out technical recovery.

• Executive Director: has final authority to activate this plan, makes decisions with significant financial, legal, or reputational impact (including whether to pay a ransom), and authorizes the return to normal operations.
• Operations Manager (Continuity Lead): may activate this plan if the Executive Director is unavailable, coordinates the response, keeps this plan and the contact list in Appendix A up to date, and is the main point of contact with the outsourced IT/security provider.
• Outsourced IT/Security Provider: monitors and restores access to Microsoft 365 and other SaaS tools, carries out backup and restore procedures, advises on cybersecurity incidents, and supports the investigation described in the incident response plan.
• Program and Department Managers: carry out this plan's procedures within their teams, keep staff and volunteers informed, and prioritize continued delivery of services to beneficiaries.

5. Plan Activation

Only the Executive Director, or the Operations Manager if the Executive Director is unavailable, may formally activate this plan. Activation should be based on the scale and expected duration of the disruption, using the criteria below.

• A system or service listed in Section 7 is unavailable and the outage is expected to exceed its recovery time objective.
• The company's office is inaccessible for more than 24 hours.
• A confirmed cybersecurity incident affects the availability, integrity, or confidentiality of donor, beneficiary, or payment data.
• A critical supplier (including the outsourced IT/security provider, Microsoft 365, or the online donation and payment platform) is unavailable for longer than the recovery time objective of the service it supports.
• Any event threatens the safety of staff, volunteers, or beneficiaries, or [Company]'s ability to deliver essential programs.

6. Communications and Escalation

The primary channel for internal communication during normal operations is email through Microsoft 365. Because an outage of Microsoft 365 would also take down this email, staff must use mobile phone calls and WhatsApp as the fallback channel, since neither depends on Microsoft 365 accounts; a video call may be used for coordination meetings where useful, but must not be relied on as the sole fallback if the underlying video service is also affected. The Operations Manager must confirm, at the start of any activation, which channels are working and tell staff and volunteers which one to use.

Donors and beneficiaries affected by a disruption must be told through the company's website, social media, or direct email or phone contact, as appropriate to the disruption and the audience. Some donor agreements, grant agreements, or partner contracts may set expectations or notice periods for service disruptions; the Operations Manager must check these before external communications are sent where a known agreement applies.

7. Recovery Time and Recovery Point Objectives

A recovery time objective (RTO) is the longest a system or service can be unavailable, measured from the start of the disruption, before it must be restored or replaced with a manual alternative. A recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, which determines how often that data must be backed up. The table below sets these objectives for [Company]'s main systems, ranked by how critical they are to the business.

Because these recovery time objectives are shorter than 72 hours, they can fall across a weekend or holiday. The Operations Manager must be reachable outside normal business hours by mobile phone, and must have a way to reach the outsourced IT/security provider's emergency contact, so that these objectives can still be met.

8. Backup and Restoration

[Company] relies entirely on SaaS tools and does not operate its own servers, so backups exist to protect against data loss caused by user error, an administrator mistake, or an attacker who reaches production accounts, rather than to restore physical infrastructure.

• Data in the online donation and payment platform, Microsoft 365 email and file storage, the beneficiary case management system, the donor and volunteer database, and the finance and accounting system must each be backed up or exported at least once every 24 hours.
• At least one copy of each backup must be stored in a location separate from the production system and separate from the Microsoft 365 tenant administrator accounts, so that a compromise of Microsoft 365 credentials cannot also destroy the backup copy.
• Backups containing payment-related records or sensitive personal data must be encrypted and restricted to the same level of access as the original data.
• Backups must be retained for at least 90 days; finance and accounting records must additionally be retained in line with statutory recordkeeping requirements.
• The outsourced IT/security provider must test the restoration of each system listed in Section 7 at least once every 12 months and record the result.
• Where only the separate backup copy survives an incident, the 24-hour recovery point objective in Section 7 applies equally to that copy.

9. Continuity of Critical Services

[Company]'s most critical services are accepting donations, communicating with staff, volunteers, donors, and beneficiaries, and maintaining access to beneficiary records to continue essential programs. Because [Company] has no infrastructure of its own, continuity for these services depends on the availability of its SaaS suppliers and on [Company] holding its own copy of the data it cannot afford to lose, as set out in Section 8.

Because [Company] processes payment card data through its online donation platform, continuity procedures must not introduce insecure workarounds for handling card data during a disruption, such as staff collecting card numbers by phone, email, or WhatsApp; if the donation platform is unavailable beyond its recovery time objective, staff must direct donors to an alternate donation method that does not involve staff handling card details directly, such as check or bank transfer.

10. Alternate Work Facilities

[Company] already works on a hybrid basis, so most staff can continue working from home if the office is unavailable, using their own or company-issued devices to connect to Microsoft 365 and the other SaaS tools listed in this plan. If the office is lost or inaccessible for an extended period, the Operations Manager must arrange a temporary site or confirm that home working can continue to meet program needs, including for any staff or volunteer activities that normally require the office.

Where an individual staff member loses their home internet connection or power, they must tell their manager and work from an alternate location, such as another staff member's home or a public location with internet access, until their own connection is restored.

11. Business Continuity Procedures by Scenario

11.1 Customer-Facing Application Unavailable

This applies where the online donation and payment platform is unavailable to donors.

1. Confirm the scope of the outage using the supplier's status page or support channel.
2. Notify the Continuity Lead and post an update for donors via the company website, social media, or email.
3. If the outage is expected to exceed the 24-hour recovery time objective, direct donors to the alternate donation method (see Section 9) using the fallback communication channel.
4. Record any donations received through the alternate method for later reconciliation.
5. Resume normal processing and reconcile records once the platform is restored.

11.2 Internal Applications Inaccessible

This applies where Microsoft 365, the beneficiary case management system, or another internal application is inaccessible.

1. Confirm whether the issue affects Microsoft 365 broadly or a specific application.
2. Notify staff using the fallback communication channel, since email may be unavailable.
3. Switch to the manual or offline alternative for the affected system, such as paper logging or an offline spreadsheet, until access is restored.
4. The outsourced IT/security provider investigates with the supplier's support channel and provides status updates to the Continuity Lead.
5. Reconcile any manually recorded data into the system once access is restored.

11.3 Cybersecurity Breach Recovery

This applies where a confirmed cybersecurity incident affects the availability or integrity of [Company]'s systems or data; investigation, evidence handling, and notification are governed by the incident response plan.

1. Confirm the incident response plan has been activated for investigation and containment.
2. The Continuity Lead assesses the impact on service availability and data recovery needs.
3. Restore affected systems from backups confirmed to be clean, coordinated with the outsourced IT/security provider.
4. Verify the integrity and completeness of restored data before returning systems to normal use.
5. Communicate with affected donors, beneficiaries, or staff as directed by the incident response plan.
6. Resume normal operations once the outsourced IT/security provider confirms the systems are secure.

11.4 Ransomware Attack

This applies where systems or data are encrypted or held hostage by an attacker.

1. Isolate affected devices and accounts immediately, disconnecting them from the network and disabling any compromised accounts.
2. Notify the Continuity Lead and the outsourced IT/security provider without delay.
3. Do not pay or negotiate a ransom without authorization; this decision rests with the Executive Director, after legal advice and confirmation that payment would not breach sanctions law.
4. Hand investigation, evidence preservation, and notification to the incident response plan.
5. Restore systems only from backups confirmed to be free of malicious code.
6. Notify [Company]'s cyber insurer promptly, if [Company] holds cyber insurance.
7. Resume normal operations once the outsourced IT/security provider confirms systems are clean and secure.

11.5 Natural Disaster or Loss of a Site or Region

This applies where the company's office, or a region relied on by a SaaS supplier, becomes unavailable.

1. Ensure the safety of any staff, volunteers, or visitors present at the office.
2. The Continuity Lead confirms the scope of the loss, including office access, power, and connectivity.
3. Activate the alternate work facilities procedure in Section 10.
4. Notify staff, volunteers, and key partners of the change using the fallback communication channel.
5. Confirm that Microsoft 365 and other SaaS tools remain accessible remotely.
6. Resume office-based operations once access is restored, or arrange a longer-term alternate site if the office will remain unavailable.

11.6 Failure of a Critical Supplier

This applies where a supplier that [Company] depends on, such as the outsourced IT/security provider, Microsoft 365, or the online donation and payment platform, is unavailable.

1. The Continuity Lead identifies which supplier is affected and the expected duration of the outage.
2. Confirm whether the outage is expected to exceed the recovery time objective for the service the supplier provides.
3. Once the recovery time objective is reached, switch to the manual or alternate process defined for that service in Section 7 or Section 9.
4. Maintain regular contact with the supplier for status updates and an estimated restoration time.
5. Document the disruption and its impact for later review and, where relevant, discussion with the supplier about its contract terms.
6. Resume normal use of the supplier once service is confirmed restored and any affected data has been reconciled.

12. Testing and Review

[Company] must run a tabletop exercise to test this plan at least once every 12 months, in addition to the annual restore tests required in Section 8. This plan must also be reviewed, and updated where necessary, after any activation under Section 5 and after any significant change to [Company]'s systems or suppliers.

13. Appendix A: Emergency Contact and Recovery Information Template

This plan and the contact information below must remain accessible even when [Company]'s main systems are down, such as a printed copy kept at the office or a copy stored outside Microsoft 365.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.