18.1 Azure Disaster Recovery ScenariosThere are several possible factors related to PaaS disaster thar XX has considered applicable to its Business Operations. Out IT teams are aware of these so that in the event of a disaster, data recovery can be done efficiently. Region-wide service interruption is not only responsible for application-wide failures. Poor design and administrative errors can also be the cause of outage.

1. Application Failure: Application errors can occur due to catastrophic exceptions caused by bad logic or data integrity issues. If the administrator has full knowledge of Azure PaaS disaster recovery processes, resolving critical errors becomes easy.
2. Data Corruption: Microsoft Azure automatically stores data on Azure SQL Database and it stores the data three times in different fault domains in the same region. If users use geo-replication then data stored in different region three additional times. If the primary copy gets corrupted then, data quickly replace with the other copies, and multiple copies is the cause of corrupt data.
3. Network Outage: Data may become inaccessible when networks are unable to access. If we are unable to access our data in PaaS due networks outage, then we are required to have in place and the design of a PaaS disaster recovery template to run with reduced functionality in our apps.
4. Region-Wide Service Disruption: Admin should prepare for service interruption of the entire region. In the event of region-wide service disruption, the local copies of data get missed. You can recover the data if you have geo-replication. Once Microsoft declares the region is lost, azure remaps all DNS entries to the geo-replicated region.
5. Azure-Wide Service Disruption: While planning the disaster recovery solution we have considered the entire range of possible disasters. It may possible that all the region get affected by the disaster. For that, you must prepare in prior. Take backup of PaaS database so that we can access our data while a critical catastrophe occurs.

By using the Azure disaster recovery plan template we have assured that all data can be recovered.

We have defined the minimum level of functionality required during the disaster and will implement the DR plan to minimise the risk. Azure PaaS disaster recovery is focused on recovering from a catastrophic loss of application functionality. For that, we have been required to plan to run the application and access the data in another region.

18.2 Utilising Azure therefore allow XX to adopt:

1. Multiple Data Center Regions: Azure maintains multiple data center in different regions all over the world. This supports several PaaS disaster recovery scenarios. As it provides geo-replication of Azure storage to secondary regions. Storing data into multiple regions helps to secure the application from major disaster.
2. Azure Site Recovery: It provides a way to replicate virtual machines between region. It requires minimum management overhead, as it doesn’t require any additional resources in the second region. It provides automated continuous replication and enables to perform failover with a single click.
3. Admin can run Azure PaaS disaster recovery drills by testing failover, without disturbing production workload or ongoing replication.
4. Azure Traffic Manager: Whenever a specific- region failure occurs, it redirects traffic to services in another region. It is the most convenient way to handle a disaster via Azure traffic manager automatically redirect the traffic when primary region gets fail. Therefore, traffic manager is important, while designing a PaaS disaster recovery plan and keep it in DR strategy

18.3 How Azure Recovery Services Work

At the moment of disaster we can access the data from our portal. Azure works remotely and continually monitors the servers for data centre failure. A security key establishes the connection between cloud environment and on-premises

19.1 Communicating with EmployeesThe Communications Team’s second priority will be to ensure that the entire company has been notified of the disaster. The best and/or most practical means of contacting all of the employees will be used with preference on the following methods (in order):

• E-mail (via corporate e-mail where that system still functions)
• E-mail (via non-corporate or personal e-mail)
• Telephone to employee home phone number
• Telephone to employee mobile phone number

The employees will need to be informed of the following:

• Which services are still available to them
• Work expectations of them during the disaster

Employee Contacts

Add or delete rows to reflect the employees in your organization.

19.2 Communicating with Clients

After all of the organization’s employees have been informed of the disaster, the Communications Team will be responsible for informing clients of the disaster and the impact that it will have on the following:

• Anticipated impact on service offerings
• Anticipated impact on delivery schedules
• Anticipated impact on security of client information
• Anticipated timelines

19.3 Communicating with Vendors

After all of the organisation’s employees have been informed of the disaster, the Communications Team will be responsible for informing vendors of the disaster and the impact that it will have on the following:

• Adjustments to service requirements
• Adjustments to delivery locations
• Adjustments to contact information
• Anticipated timelines

Crucial vendors will be made aware of the disaster situation first. Crucial vendors will be E-mailed first then called after to ensure that the message has been delivered. All other vendors will be contacted only after all crucial vendors have been contacted.

Vendors encompass those organisations that provide everyday services to the enterprise, but also the hardware and software companies that supply the IT department. The Communications Team will act as a go-between between the DR Team leads and vendor contacts should additional IT infrastructure be required.

Communication of relevant DR information throughout XX will also be provided by DR Team Leader and during severe instances to the Senior Leadership Team for appropriate communication to all employees contractors. It is essential that accurate information regarding expectations and realistic recovery timescales is conveyed through proper channels.

In some events such as that of personal data compromise or loss, the DPO must be informed in order to discharge the legal obligations of informing relevant authorities such as the Information Commissioners Office.

Press releases or external communication is strictly under the control of the Senior Leadership Team Dissemination of information by other paths will be viewed as inappropriate and may well instigate disciplinary action.

21-Reporting & Incident Analysis

Full documentation of the incident must be completed in an appropriate timescale. The following must be included in the report:

1. Date & Time of initial incident occurrence
2. Method and details of notification
3. Steps leading to identification of the problem
4. Assessment criteria used to formulate a level of response
5. Third Party / Service Provider involvement
6. Description of causes vii. Events record for each step/action/process undertaken including outcomes
7. Resources involved
8. Effectiveness of solution and analysis of target objectives/actuals
9. Possible list of mitigations
10. Lessons to be learned

22-Standby Facility Activation

The Standby Facility will be formally activated when the Disaster Recovery Lead determines that the nature of the disaster is such that the primary facility is no longer sufficiently functional or operational to sustain normal business operations.

Once this determination has been made, the Facilities Team will be commissioned to bring the Standby Facility to functional status after which the Disaster Recovery Lead will convene a meeting of the various Disaster Recovery Team Leads at the Standby Facility to assess next steps. These next steps will include:

1. Determination of impacted systems
2. Criticality ranking of impacted systems
3. Recovery measures required for high criticality systems
4. Assignment of responsibilities for high criticality systems
5. Schedule for recovery of high criticality systems
6. Recovery measures required for medium criticality systems
7. Assignment of responsibilities for medium criticality systems
8. Schedule for recovery of medium criticality systems
9. Recovery measures required for low criticality systems
10. Assignment of responsibilities for recovery of low criticality systems
11. Schedule for recovery of low criticality systems
12. Determination of facilities tasks outstanding/required at Standby Facility
13. Determination of operations tasks outstanding/required at Standby Facility
14. Determination of communications tasks outstanding/required at Standby Facility
15. Determination of facilities tasks outstanding/required at Primary Facility
16. Determination of other tasks outstanding/required at Primary Facility
17. Determination of further actions to be taken

During Standby Facility Operations, Networks, Servers, Applications, and Operations teams will need to ensure that their responsibilities, as described in the “Disaster Recovery Teams and Responsibilities” section of this document are carried out quickly and efficiently so as not to negatively impact the other teams.

23-Reestoring IT Functionality

Should a disaster actually occur and XX need to exercise this plan, this section will be referred to frequently as it will contain all of the information that describes the manner in which XX’s information system will be recovered.

This section will contain all of the information needed for the organisation to get back to its regular functionality after a disaster has occurred. It is important to include all Standard Operating Procedures documents, run-books, network diagrams, software format information etc. in this section.

24, Current System Architecture

In this section, include a detailed system architecture diagram. Ensure that all of the organization’s systems and their locations are clearly indicated.

<<System Architecture Diagram>>

25-Plan Testing & Maintenance

While efforts will be made initially to construct this DRP is as complete and accurate a manner as possible, it is essentially impossible to address all possible problems at any one time. Additionally, over time the Disaster Recovery needs of the enterprise will change. As a result of these two factors this plan will need to be tested on a periodic basis to discover errors and omissions and will need to be maintained to address them.

26-Maintenance

The DRP will be updated annually or any time a major system update or upgrade is performed, whichever is more often. The Disaster Recovery Lead will be responsible for updating the entire document, and so is permitted to request information and updates from other employees and departments within the organization in order to complete this task.

Maintenance of the plan will include (but is not limited to) the following:

1. Ensuring that call trees are up to date
2. Ensuring that all team lists are up to date
3. Reviewing the plan to ensure that all of the instructions are still relevant to the organization
4. Making any major changes and revisions in the plan to reflect organizational shifts, changes and goals
5. Ensuring that the plan meets any requirements specified in new laws
6. Other organisational specific maintenance goals

During the Maintenance periods, any changes to the Disaster Recovery Teams must be accounted for. If any member of a Disaster Recovery Team no longer works with the company, it is the responsibility of the Disaster Recovery Lead to appoint a new team member. 

27-Testing

In order to be effective, regular testing of the disaster recovery plan should be undertaken. It is only during testing that parameters such as the RTO and RPO can be confirmed as appropriate and to ensure that the data backups are wholly capable of providing the required level of recovery. It is not sufficient to assume that just because data is being backed up that it will be recoverable.XX is committed to ensuring that this DRP is functional. The DRP should be tested annually in order to ensure that it is still effective. Testing the plan will be carried out as follows:

XX  will employ the following to test the DR:

1. Walkthroughs– Team members verbally go through the specific steps as documented in the plan to confirm effectiveness, identify gaps, bottlenecks or other weaknesses. This test provides the opportunity to review a plan with a larger subset of people, allowing the DRP project manager to draw upon a correspondingly increased pool of knowledge and experiences. Staff should be familiar with procedures, equipment, and offsite facilities (if required).
2. Simulations– A disaster is simulated so normal operations will not be interrupted. Hardware, software, personnel, communications, procedures, supplies and forms, documentation, transportation, utilities, and alternate site processing should be thoroughly tested in a simulation test. However, validated checklists can provide a reasonable level of assurance for many of these scenarios. Analyze the output of the previous tests carefully before the proposed simulation to ensure the lessons learned during the previous phases of the cycle have been applied.
3. Parallel Testing– A parallel test can be performed in conjunction with the checklist test or simulation test. Under this scenario, historical transactions, such as the prior business day’s transactions are processed against preceding day’s backup files at the contingency processing site or hot site. All reports produced at the alternate site for the current business date should agree with those reports produced at the alternate processing site.
4. Full-Interruption Testing– A full-interruption test activates the total DRP. The test is likely to be costly and could disrupt normal operations, and therefore should be approached with caution. The importance of due diligence with respect to previous DRP phases cannot be overstated.

Any gaps in the DRP that are discovered during the testing phase will be addressed by the Disaster Recovery Lead as well as any resources that he/she will require.

There may be certain elements that are difficult to fully test in this situation, but these will also only be identified during testing.

28-Call Tree Testing

Call Trees are a major part of the DRP and XX requires that it is tested annually in order to ensure that it is functional. Tests will be performed as follows:

• Disaster Recovery Lead initiates call tree and gives the first round of employees called a code word.
• The code word is passed from one caller to the next.
• The next work day all Disaster Recovery Team members are asked for the code word.
• Any issues with the call tree, contact information etc will then be addressed accordingly.

29-Policy and Procedure review

All policies including the DR Plan will be reviewed when there are changes in employment law that are relevant, where there is a change in the business need or when feedback from HR, line managers or Trade Unions suggest that the policy is either out of date or unfit for purpose. 

30-Ownership and Revision

This Plan is owned by the Board of Directors of the Business who has delegated this task to the Chief Information Security Officer or other designated person. This policy shall be revised once in two years by the CISO or other designated person and every time that the Board of Directors of the Business decides to do so.

Version Control