DISASTER RECOVERY PLAN
Classification: Internal
This document may not be shared externally without written approval from the document owner.
Version Approved Owner Date Last Review Next Comments
By Updated Frequency Review
Contents
Purpose of Document ............................................................................................................ 2
Policy .................................................................................................................................... 2
Scope .................................................................................................................................... 2
Summary of Architecture & Services ................................................................................... 2
Invocation Process ................................................................................................................ 3
Risk Assessments .................................................................................................................. 5
Disaster ................................................................................................................................. 7
Key External Contacts ............................................................................................................ 7
Hierarchy of Notifications....................................................................................................... 8
Comms Plan .......................................................................................................................... 9
Contact list - Key Stakeholders ........................................................................................... 9
Testing................................................................................................................................. 10
Document Maintenance ....................................................................................................... 10
Key Reference Materials ....................................................................................................... 11
Vendor SLA Agreements ....................................................................................................... 11
Important Information .......................................................................................................... 11
Backup Summaries .............................................................................................................. 12
Recovery Procedures ........................................................................................................... 12
Purpose of Document
The following disaster recovery plan (DRP) is designed to assist [Company Name] in preparing
for and recovering from disruptive events, such as the loss of a site, service, cyber-attacks,
power outages, or other incidents that could result in data loss or system downtime.
The key reasons for the DRP are as follows.
• Minimising Downtime: By having a DRP in place, [COMPANY NAME] can reduce the
time that its IT systems are offline and minimise the impact of a disaster on its
operations and, therefore, impact upon its customers.
• Protecting data: A DRP helps ensure that critical data is backed up regularly and can
be restored quickly in a disaster, reducing the risk of data loss.
• Enhancing business resilience: A DRP helps [COMPANY NAME] become more
resilient and better prepared to deal with unexpected events or disruptions.
• Maintaining customer confidence: With a DRP in place, [COMPANY NAME] can
demonstrate to customers and stakeholders that it takes business continuity seriously
and is committed to maintaining operations in the face of unexpected disruptions.
Policy
• The Head of Engineering is accountable for ensuring this document is reviewed and
tested annually.
• The DRP shall cover all critical IT infrastructure, including systems and networks.
• All staff responsible for executing and maintaining the DRP will be trained appropriately.
• Procedures for recovery will be kept up to date as soon as any changes are made.
Scope
Summary of Architecture & Services Commented [A1]: Just something brief to summarise
the scope of what's in / out. You can delete a lot of this if
The scope of this DRP is for the recovery of [COMPANY NAME] product services. It is not a it's too wordy. The important point is; Are these just the
Business Continuity plan and does not address broader issues of building infrastructure, customer services you are writing a DR plan for, or does it
include backoffice systems (HR / Finance, etc)? I'd
employee management, customer communications and business processes.
suggest different plans for different scopes if there is a
separation between them?
The infrastructure of [Company Name] comprises a multi-tiered architecture designed to
support a scalable tenant-landlord ecosystem.
Commented [A2]: Add a high-level diagram to give
scope of DR solution.
Key services include client-facing applications, internal administration interfaces,
development operations, and analytics.
Core functionalities are facilitated through a combination of cloud-hosted services, including
[Insert summary of SaaS technologies used]
The architecture supports continuous integration and deployment (CI/CD), with [If you have
a development pipeline, summarise the tools here].
The system's resilience is critical for maintaining uptime and ensuring data integrity for all
stakeholders involved in the moving process.
Invocation Process
The following steps outline the process to declare a disaster and activate the disaster recovery
plan formally:
1. The incident lead (typically the Head of Engineering) will assess the incident to
determine if it meets the criteria for a disaster declaration.
2. The incident lead will confer with the DR team members to review the assessment
and gain consensus on formally declaring a disaster.
3. If the event meets the disaster declaration criteria, the incident lead will formally
activate the DR plan and turn incident management over to the DR team.
4. The incident lead will notify senior management of the disaster declaration and DR
activation.
5. The DR team will follow the procedures and checklists outlined in the DR plan to
recover critical systems and functions.
6. External partners and vendors will be engaged as needed to provide additional
resources and capabilities.
7. The DR team will execute the communications plan to inform impacted
stakeholders of progress.
8. Once critical systems have been recovered, the DR team will initiate efforts to
restore wider operations.
9. The incident lead will perform a formal handoff back to normal operations once DR
objectives have been met.
10. A deactivation of the DR plan will be communicated, and a retrospective will be
conducted to identify improvements.
Disaster Recovery Plan
Risk Assessments
Hosting Service Critical Potential Risks Likelihood Impact Resilience Strategy Priority
Provider Component Service Sequence Commented [A3]: The whole table is designed to tick off
Microsoft Office 365 Email, Service outages, Data Moderate High Multi-geo redundancy, High several things at once;
Documents breaches, Phishing Regular backups, MFA - List of components and who hosts them.
- Risk review
attacks - Recovery sequence if you lost the whole thing at once
Sage Sage Payroll Payroll Data loss, Unauthorized Low High Regular backups, Role- High (highly unlikely given design)
Services access, Service based access control - The stategy (i.e. backsup / HA / Failover) - these need
downtime validating against what you are paying for with suppliers.
SAP ERP System Business Data corruption, System Moderate High High Availability, Regular High Things you could / should add in future versions;
Operations failures, Cyber attacks backups, Patch
management RTO / RPO
Salesforce CRM Customer Data breaches, Service Low High Multi-region failover, High Owners
Management interruptions, Regular security audits,
Unauthorized access Data encryption
Amazon EC2 Hosting Server downtime, Data Low High Auto-scaling, High
(AWS) loss, Security breaches Snapshots, Security
groups
Google G Suite Email, Service outages, Data Moderate High Geo-redundancy, High
Documents breaches, Unauthorized Regular backups, MFA
access
Oracle Oracle DB Database Data corruption, Moderate High Data replication, High
Services Unauthorized access, Encryption, Regular
Service interruptions backups
Intuit QuickBooks Accounting Data loss, Unauthorized Low Moderate Regular backups, Role- Medium
access, Service based access control
downtime
Page 5 of 12
Disaster Recovery Plan
Atlassian Jira Project Service outages, Data Low Moderate Regular backups, Medium
Management breaches, Unauthorized Security patches, Data
access encryption
Dropbox Cloud Storage File Storage Data loss, Unauthorized Low High Multi-region replication, High
access, Service outages Encryption, Regular
backups
Microsoft Office 365 Email, Service outages, Data Moderate High Multi-geo redundancy, High
Documents breaches, Phishing Regular backups, MFA
attacks
Likelihood is rated as:
• High: Event is expected to occur frequently.
• Moderate: Event might occur occasionally.
• Low: Event is unlikely to ever occur.
Impact is rated as:
• High: Event would have a serious impact on operations or would cause a significant financial loss.
• Moderate: Event would cause a noticeable disruption and require management attention.
• Low: The event would cause minimal disruption.
Resilience Strategies
• High Availability: Ensures that the service is distributed across different physical and virtual servers, reducing the chance of a single point
of failure.
• Backups: Regularly scheduled backups that can be used to restore data to a point-in-time should data corruption or loss occur.
• Multi-AZ Failover: Utilisation of multiple availability zones within the same region to provide failover capabilities.
• Geo-Redundancy: Storing data in geographically diverse locations to protect against regional disasters.
• Version Control & Backups: Use of version control systems for code and infrastructure, combined with backups for critical configurations.
• Dyno Redundancy: In Heroku, dynos can automatically recover from hardware failures, and using more than one dyno can provide
redundancy.
Page 6 of 12
Disaster Recovery Plan
• Platform's Built-in Redundancy: Reliance on the inherent resilience and redundancy features provided by the platform (e.g., GitHub,
CircleCI, Slack).
• DNS Failover: The capability to switch traffic from the failing site to a backup site in case of an outage.
• Data Export: Regular exports of data and reports to ensure that analytics data can be recovered in case of a loss of service.
Disaster Recovery Team Commented [A4]: You may wish to split this into 'Exec
Team' who handle the comms outward, the insurance,
finances, etc. and then the actual DR team who are the
The following are the key staff that will co-ordinate the recovery of the services and report into the Disaster Management Team members. technical people needed to recover systems.
Name Role Contact Details Responsibilities
Key External Contacts
The following are the contact details for any 3rd parties that may be needed in the event of execution of part or all of the DRP.
Organisation Role Contact Details Comments
ICO – Information Legislative oversight of GDPR / Self-assessment & Reporting To report any major breaches to
Commissioner's Office (UK) DPA data guide sensitive personal data under
GDPR / DPA
0303 123 1113
Insurance Insurance Company Details on insurance policy held
here
Reliance ACSN Cyber-attack response experts [Link] Can offer support with how to
dent-response/
approach major cyber attack
issues (e.g. Ransomware, etc).
Page 7 of 12
Disaster Recovery Plan
Hierarchy of Notifications Commented [A5]: The order in which people cascade
information and are notified.
The following summarises who will be responsible for contacting and communicating with whom in the event of a disaster.
Page 8 of 12
Disaster Recovery Plan
Head of
Engineering
Head of.. Head of.. Head of..
Application Database
Helpdesk Supplier 2
Support admin
Infrastructur
Supplier 1
Team
Comms Plan
Contact list - Key Stakeholders
Name Role Communication Method Communication Owner
Page 9 of 12
Disaster Recovery Plan
Testing Commented [A6]: There should be some description of
how you test the plan and make sure it's still viable a year
Component Testing Approach (paper / backup Date of last test Instructions confirmed down the line. With most of your services being cloud
test / failover) hosted by suppliers, you probably can only undertake
backup / restores etc. Not a complete failover, unless it's
part of your contract.
Document Maintenance
The Disaster Recovery Plan will be
To ensure the disaster recovery plan remains up-to-date, it will be reviewed and updated regularly as changes occur.
• The disaster recovery plan will be reviewed in full on an annual basis by the Head of Engineering.
• Any significant changes to systems, processes, or contracts should trigger a DR plan review.
• The following items will be reviewed for accuracy and updated as needed during DR plan maintenance:
• Contact details for disaster recovery team members and key stakeholders
• System inventory and architecture
• Business impact analysis and risk assessments
• Recovery procedures and instructions
• DR invocation process
• Testing schedule
• Contracts and SLAs with vendors
• Appendix documents like server specs, credentials, checklists
• The DR plan review will also be completed after any DR invocation, test, or change in recovery facilities to incorporate lessons learned.
Page 10 of 12
Disaster Recovery Plan
• Any changes to the DR plan will be communicated to relevant stakeholders.
APPENDICIES
Key Reference Materials
Description Location
Cyber Response Plan
Cyber insurance response policy
System Passwords and keys
Vendor SLA Agreements
Important Information
Item Note
Passwords Stored in LastPass?
Page 11 of 12
Disaster Recovery Plan
Backup Summaries Commented [A7]: Summarise the backup strategies of
your systems. In many cases this may be handled by the
System service provider, but;
Owner
1) Check what is offered; can they recover just your
Risk Assessment organisation’s data if you request it in the event of an
Backup Strategy issue. Some providers take backups, but only at a
system-wide level cannot recover only your data, and
would only instigate a recovery if they went into full DR
recovery.
Recovery Procedures 2) Some solutions like Salesforce and Office 365
commonly need additional backup services in order to
Procedure A
recover old or accidentally deleted data.
Step Action Owner Commented [A8]: If there are manual steps you and the
team need to take, then either summarise here, or link to
documentation that others have tested and can follow in
the event of a major issue.
Procedure B
Step Action Owner
Key Records & Contracts
Record Primary Location Alternative Location
Cyber insurance
Page 12 of 12