View source for Disaster Preparedness

<h2>Introduction</h2>
<p>Disaster preparedness and disaster recovery ([http://eitbokwiki.org/Glossary#dr DR]) supports business continuity planning and includes planning for [http://eitbokwiki.org/Glossary#eit EIT] resiliency, as well as recovery from adversity, such that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after the event. </p>
<p>[http://eitbokwiki.org/Glossary#dr DR] can be defined as “in computer system operations, the return to normal operation after a hardware or software failure.” [[#One|[1]]] Also, the “activities and programs designed to return the organization to an [http://eitbokwiki.org/Glossary#acceptable acceptable] condition. The ability to respond to an interruption in services by implementing a disaster recovery plan to restore an organization's critical business functions.” [[#Two|[2]]] </p>
<p>This section defines these processes and deliverables, and who should be responsible for planning, creating the documents, and communicating should a disaster occur. The following are some examples for context: </p>
<ul>
<li>'''Examples of disasters'''<br />
<ul>
<li>Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)</li>
<li>Security breach resulting in disaster (destruction of data, admin password changes, virus/malware installation, sabotage)</li>
<li>Usage error (accidental deletion, unplug/turn off system resulting in corruption)</li>
<li>Utility failure affecting datacenters (loss of power even after UPS)</li>
<li>Vendor failure (cloud provider security failure, oil spill)</li>
<li>Staffing issue (employment dispute/walkout, epidemic)</li>
</ul>
<li>'''Examples of unpreparedness'''<br />
<ul>
<li>Requiring use of computers or printers when power is out</li>
<li>Requiring use of internet when power or connectivity is out</li>
<li>Single point of knowledge/control for administration access</li>
<li>Lack of offsite backup storage</li>
<li>Lack of working restoration from backups</li>
<li>Lack of failover datacenters in separate locations</li>
<li>Undocumented or out of date documentation for system interfaces</li>
<li>Requiring use of phones that are out of power</li>
<li>Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)</li>
<li>In general, no cohesive, comprehensive EIT service restoration plan</li></ul></li></ul>
<h2>Goals and Principles</h2>
<p>EIT organizations are responsible for the following goals:</p>
<ul>
<li>To document and plan for appropriate backup and recovery processes for all systems, and priority of systems for restoration. </li>
<li>To create and deploy an EIT disaster recovery plan. </li>
<li>To ensure that the business has business continuity processes in place in case of a disaster.</li></ul>
<p>Fundamental principles of disaster recovery depends on the business functions within the enterprise, and how critical each is to the health of the business. There are several methods for determining criticality of functions. </p>
<ul><li>Hierarchy of need and stated in [http://eitbokwiki.org/Glossary#sla SLAs], which is that the most critical business functions should be restored first, or in the first phase of disaster recovery. </li>
<li>Keep the lights on ([http://eitbokwiki.org/Glossary#ktlo KTLO]) or keep the business running ([http://eitbokwiki.org/Glossary#ktbr KTBR]), which are not the same thing</li>
<li>All non-critical services are in the final phase of recovery.</li>
<li>Industry-specific, so all systems delivering lifesaving functions are the highest priority for recovery efforts, whereas administration systems wait for second or third wave of recovery. </li>
</ul>
<p>However, a fundamental recovery principle is that all systems to be recovered should be attended to within the specifications for recovery time objectives ([http://eitbokwiki.org/Glossary#rto RTO]) and recovery point objectives ([http://eitbokwiki.org/Glossary#rpo RPO]) laid out by the business in the DR plan.</p>
<h2>Context Diagram</h2>
[[File:ContextDiagram_DisasterRecovery.jpg]]
<p>'''Figure 1. Context Diagram for Disaster Preparedness and Recovery'''</p>
<h3>Gather Inputs</h3>
<p>The following inputs are necessary for this process to initiate or continue:</p>
<ul>
<li>Budget for DR plan</li>
<li>Business risk factors/risk assessment</li>
<li>Business and EIT [http://eitbokwiki.org/Glossary#sla SLAs], [http://eitbokwiki.org/Glossary#ola OLAs], and contractual obligations to upstream/downstream systems</li>
<li>Business continuity plan</li>
<li>Configuration management database ([http://eitbokwiki.org/Glossary#cmdb CMDB]) and asset inventory (see the [http://eitbokwiki.org/Operations_and_Support Operations and Support chapter])</li>
<li>Current enterprise architecture artifacts/source code/document management systems</li>
<li>EIT [http://eitbokwiki.org/Glossary#service_cat service catalogue] </li>
<li>EIT staff capabilities</li>
<li>Vendor service agreements/maintenance agreements</li>
</ul>
<p>The obvious business driver is to reduce [http://eitbokwiki.org/Glossary#risk risk] for the business, by providing both mitigation strategies and contingency plans. High-risk projects or operational inefficiencies can lead to lost business, which ultimately causes lost income for the business &mdash; this can be the high price of risk.</p>
<p>Another business driver for formal DR processes may be to meet regulatory (i.e., [http://eitbokwiki.org/Glossary#sox SOX]) or sustainability objectives. Part of the information gathering includes conducting workshops or interviews to document the drivers to ensure deliverables meet these requirements.</p>
<p>Another related information-gathering effort is to define and document the technical drivers driving DR, including aging technology or lack of application support capabilities. </p>
<h2>Description of Activities</h2>
<h3>Business Impact Analysis</h3>
<h4>Define Critical Business Services</h4>
<p>With input from the business, such as the risk management group, the business continuity management, audit departments, and executives, define services critical to operations. Business impact analysis is a technique that can be used. Critical services are those that, if missing, the enterprise could no longer meet commitments and deliver business products or services. Use business process diagrams to assist with analysis. </p>
<p>The following list is a suggested structure for determining the ''service categories'' and corresponding criticality of organizations services (for definitions of the categories, refer to the [[#StandardServiceDefinitions|Standard Service Definitions]] section***where should ref go?***):</p>
<ul>
<li>Mission critical</li>
<li>Business critical</li>
<li>Business operational</li>
<li>Administrative services [[#Three|[3]]] </li> 
</ul>
<p>Examples of typical critical services within an enterprise are safety processes, safety documentation management, communication polices and processes, and financial data and processes.</p>
<h4>Map Critical Business Services to EIT Services</h4>
<p>This function is often referred to as ''building an EIT service catalog'', which is an important input to disaster recovery planning. A service catalog is “a database or structured document with information about all live EIT services, including those available for deployment…The service catalog includes information about deliverables, prices, contact points, ordering, and request processes.” [[#Four|[4]]] Templates exist to assist with this mapping. [[#Five|[5]]] See the [http://eitbokwiki.org/Operations_and_Support Operations and Support chapter] for more information on service catalogs.</p>
<h4>Define Relevant Disaster Scenarios and Responsible Parties</h4>
<p>Clearly define criteria for who declares a disaster, including when and how. Mature organizations have assigned responsible parties when disasters occur so that there is a clear leader determining which processes and procedures to implement during the disaster, and following the communication plan. Not having this in place allows for invalid assumptions about who is in charge, including no one taking ownership, or multiple parties competing for ownership, neither of which helps resolve the disaster and recover service.</p>
<h4>Define Successive Waves for Extending Recovery Across the Business</h4>
<p>Due to the complex nature of EIT systems within the enterprise today, it is unrealistic to provide recovery for all services in the initial recovery phase. There are different levels of recovery for different tiers of business services, and a corresponding, agreed-to timeframe for recovery of each service within the enterprise. These waves of recovery begin with the most critical services as defined, and move through to the least critical in a timeframe [http://eitbokwiki.org/Glossary#acceptable acceptable] based on a risk-mitigation process. For example, level one (i.e., Tier 1) recovery may take place within 72 hours of a disaster and would include services such as product production, shipping, and customer service applications. Note: A non-critical service may be recovered in the first pass of recovery based solely on a critical service having it as a dependency. </p>
<p>Critical systems management is a useful process in the identification and documentation of critical systems. [[#Six|[6]]] Also, it ensures proper application life-cycle management is occurring for these EIT services. [[#Seven|[7]]] </p>
<p>Use risk-assessment techniques to analyze how disaster scenarios could adversely affect the business. One such process would be to tier possible risks into levels such as:</p>
<ul>
<li>Affecting the entire enterprise</li>
<li>Affecting only certain business units</li>
<li>Affecting a single component (either a technology component or a business unit)</li>
<li>Affecting a single business function (such as processing credit card transactions)</li>
</ul>
<h3>Recovery Objectives and DR Plan</h3>
<h4>Determine Recovery Objectives and Develop Plan</h4>
<p>In cooperation with the business, define the recovery point objectives ([http://eitbokwiki.org/Glossary#rpo RPO]) and recovery time objectives ([http://eitbokwiki.org/Glossary#rto RTO]). </p>
<p>[http://eitbokwiki.org/Glossary#rpo RPO] is the point in time to which all integrated systems are recovered, taking into account backup schedules, sync points, and data transfer points to ensure data quality and integrity. </p>
<p>[http://eitbokwiki.org/Glossary#rto RTO] is how long it will take to return an EIT service to active duty. This varies depending on the criticality of the service as well as how integrated the service is with other services. </p>
<p>***add diagram***</p>
<p>Configuration management is a process that helps document the business impact of a service, as well as documenting the backup and recovery requirements. Also, it provides an inventory of applications and supporting infrastructure needed in the restoration processes.</p>
<p>'''Organization and Culture'''</p>
<p>The risk tolerance and depth of capabilities within the organization have a large impact on the disaster preparedness level within the organization. In other words, the business’s disaster tolerance is the “the time gap the business can accept the non-availability of EIT facilities.” [[#Two|[2]]] The lower the tolerance, the more extensive and costly DR practices and techniques are deployed. </p>
<p>Also, the business product deliveries determine the requirements of the planning effort and metrics. </p>
<h4>Develop Communications Plan</h4>
<p>An effective communication plan is an essential component to the successful implementation and adoption of the DR processes. The communication plan should include:</p>
<ul>
<li>How to deliver communications when standard communication systems are unavailable (such as email or phone systems)</li>
<li>Who to contact in a disaster situation, including specific lists for specific situations or systems affected</li>
<li>What the information each communication should include, and not include</li>
</ul>
<p>Contact information lists should include the following [http://eitbokwiki.org/Glossary#stakeholder stakeholders]:</p>
<ul>
<li>External partners (service providers and suppliers)</li>
<li>Police/fire/municipal departments</li>
<li>EIT management and staff</li>
<li>Business management and product owners</li>
</ul>
<p>The DR communication plan should describe the process to provide business updates to business continuity plans after the recovery has been completed.</p>
<p>A process for disaster declaration needs to be included in the DR plan and be well communicated to the team. In this section, all contact information and approval authority should be spelled out (i.e., who has the authority to declare a disaster within the company).</p>
<h4>Develop Backup and Archive Strategies and Schedule</h4>
<ul>
<li>The area of EIT responsible for DR is either responsible for backup and recovery or works closely with the team who is. Backup types such as archiving and incremental backups need to be scheduled for the varying needs of the systems being supported. Backup standards and recovery strategies should be defined to ensure the business requirements are met.</li>
<li>Backup and storage technology has a large role to play in the recoverability of applications and systems. Current backup utilities provide incremental forever-backup processes, which can help reduce the cost of storage used for holding backups. In addition, architecture features such as high-availability options and failover redundancies can both reduce risk of service loss, as well as provide mitigation strategies for unstable or unreliable systems. </li>
</ul>
<h4>Develop and Document DR Plan</h4>
<p>'''Disaster recovery plan ([http://eitbokwiki.org/Glossary#drp DRP])''' is “a set of human, physical, technical, and procedural resources to recover, within a defined time and cost, an activity interrupted by an emergency or disaster.” [[#Two|[2]]]</p>
<p>The DR plan document needs to include all of the information needed to recovery all critical systems a business needs to operate. EIT must work with the business to develop and document a DR plan. See the [[#Template|template at the end of this section]] for recommended sections of a DR plan.</p>
<p>Data collection techniques are critical to the development of a meaningful DR plan that meets the needs of the business. </p>
<h4>Interface with Business Continuity</h4>
<p>EIT must communicate their processes to the business, and make consistent updates to the business continuity plan ([http://eitbokwiki.org/Glossary#bcp BCP]). As the new business components or services are added, the business assigns a criticality level, which then needs to be translated into EIT services, that internally are assigned a tier to determine the disaster recovery requirements. This relationship between business continuity and EIT disaster recovery is a symbiotic relationship that is critical to the success of both functions within the enterprise.</p>
<h3>Implement and Test DR plan (Drill or Simulation)</h3>
<p>The first step to implementing a DR plan is to allocate resources and assign responsibilities. The DR team needs to be assigned early in the process to ensure accountability and understanding of roles at the time of a disaster. Many different roles are needed to define and execute a successful DR plan. The DR test is an opportunity to cross train in the many roles needed, in order to mitigate the risk of key roles not being available should a disaster occur. It is likely that no one from the business DR team will be available for the recovery of the systems, so documentation, testing, and assigning a strategic partner is important to the recovery of business services.</p>
<h4>Roles and Responsibilities</h4>
<p>Input supplier roles are roles and teams that supply the inputs to the process:</p>
<ul>
<li>Enterprise risk management team</li>
<li>BCP manager</li>
<li>EIT managers</li>
<li>Enterprise architecture team</li>
<li>Solution management team</li>
</ul>
<p>Key roles are the responsible individuals or teams that perform the process:</p>
<ul><li>DR team leads</li>
<li>Test team</li>
<li>Recovery center manager</li>
<li>System specialists (multiple)</li>
<li>Business management team<br />
<ul>
<li>Facilities manager</li>
<li>Service manager</li>
</ul></li></ul>
<p>User roles expect and receive the deliverables:</p>
<ul>
<li>Operations management team<br />
<ul>
<li>Backup process manager</li></ul></li>
<li>Test manager</li>
<li>Business management team</li>
</ul>
<p>Stakeholder roles are informed or consulted on the process execution:</p>
<ul>
<li>Enterprise risk management team</li>
<li>Operations management team<br />
<ul>
<li>Business continuity manager</li></ul></li>
<li>Business management team<br />
<ul>
<li>Contract manager</li></ul></li></ul>
<h4>Document Recovery Strategies</h4>
<p>As mentioned above, there are many strategies to recovery services the business needs to function. There is a different [http://eitbokwiki.org/Glossary#solution solution] for every different service out there. The most important element is to choose a strategy, then document and communicate it.</p>
<ul>
<li>Use a third-party hot recovery site. The hot site should be in a geographical separate location to ensure a natural disaster does not take out both the primary production location as well as the backup site location. These distances vary depending on geographic as well as infrastructure dependences (such as power, water, and network commonalities). </li>
<li>Real-time mirroring is a technique used to replicate data to a geographically separate location to ensure data is available should a restore processes be needed.</li>
<li>Manual, non-standard, or ad-hoc/on-demand/unscheduled procedures are also an important aspect that is a responsibility of the business units to ensure business continuity during the time EIT is rebuilding system services. Recommend to business management that manual processes either be automated, or have testing be completed on a regular basis. Also recommended is documenting methods used to mitigate problems caused by aging technology, such as having parts inventories, redundant or cold standby equipment.</li>
<li>Offsite archiving of data is a technique used to ensure backups are available should a disaster make the primary site unavailable. Offsite services are available through many service provides. Due diligence by the DR team is important to ensure the offsite facilities can guarantee secure and proper handling of backup data, an important enterprise asset.</li>
<li>Actions plans and recovery processes differ depending on what type of disaster has occurred. A single-component failure results in a standalone recovery of the failing component (i.e., application, server, or appliance). An enterprise-wide disaster results in a disaster declaration event with a full DR plan being executed with the full DR team being mobilized.</li>
<li>Identify and document potential disaster scenarios which have a high probability of happening to the business. For example, intrusion or denial of service attacks could have very adverse effects on a technology company, whereas adverse environment conditions create higher risks to a construction company. </li>
</ul>
<h4>Define a Schedule for Service Continuity Testing</h4>
<p>Defining a schedule for the disaster recovery testing is a critical factor to the success of a plan. One method often used is to simulate a disaster to test system recovery. Another process strongly recommended is to have production support test refreshes on a regular (i.e., monthly) basis. This not only ensures backups are usable, but also ensures processes are well documented and actually work, ensuring data quality and integration integrity. </p>
<h4>Implement and Test DR Plan (Drill or Simulation)</h4>
<ul>
<li>Implementation can take many forms. A hot site contract is an agreement with a third-party vendor to provide facilities and infrastructure needed to restore agreed to services in the timeframe specified. There are many variants to this type of contract depending on the dollar value of the [http://eitbokwiki.org/Glossary#contract contract] and the expected availability of internal staff at the time of a disaster. If the hot sites are geographically distant from the enterprise offices it is likely the contract includes staff to perform the recovery as well. </li>
<li>Due to the size and complexity of many enterprises, in-house DR facilities are often the norm, meaning these are secondary owned facilities used as recovery centers for primary facilities if needed.</li>
<li>A useful metric from testing processes is timing of actual recovery procedures as well as a measure of the capabilities of the DR team, third-party or secondary facilities, and the level of maturity of both staff knowledge and processes accuracy. </li>
</ul>
<h3>DR Plan &mdash; Change Management</h3>
<p>Regular verification and updates to backup processes is necessary to ensure accurate and usable backups are delivered. This change management process needs to provide updates to the documentation of the backup and recovery processes. For example:</p>
<ul>
<li>DR testing cycle changes as services change or risk tolerances change.</li>
<li>DR test results always cause process improvements and lessons learned to be added to the documentation.</li>
<li>Updates and changes to [http://eitbokwiki.org/Glossary#bcp BCP] go hand in hand with the changes to systems and services.</li>
</ul>
<p>Mature organizations build continual improvement evaluation and activities into all processes.</p>
<h4>Update DR Plan Based on DR Test Results and Validation</h4>
<p>Validation metrics are the measurements that quantify the success of processes, based on the requirements and goals of the business. The following measures can be used to determine the success of a DR test or simple restore procedure execution:</p>
<ul>
<li>Recovery point objectives met</li>
<li>Recovery time objectives met</li>
<li>Testing result measurements (for example, timing of restore, accuracy of data, and integration points)</li>
<li>Verification of backup usability</li>
</ul>
<h2>Summary</h2>
<p>Like most others, DR processes are a closed loop of plan > build > test > review with action. Continuous improvement and maturity of these processes are obtained through regular execution of DR tests, measuring results, and then revising the DR plan as necessary. Stakeholder involvement with setting requirements is critical to the success of DR processes. </p>
<h2>Important Skills</h2>
<ul>
<li>Change management</li>
<li>Enterprise and business architecture</li>
<li>Risk management</li>
<li>Configuration management</li>
<li>Testing and validation</li>
</ul>
<h2>Standards</h2>
<p>ISO/IEC 24765:2009 Systems and software engineering</p>
<h2>References &mdash; Bibliography</h2>
<div id="One"></div><p>[1] Systems and Software Engineering Vocabulary. (2009). ISO/IEC 24765 </p>
<div id="Two"></div><p>[2] ISACA. (n.d.). http://www.isaca.org/Pages/Glossary.aspx</p>
<div id="Three"></div><p>[3] ITIL Service Catalogue: How to produce a Service Catalogue; http://www.itilnews.com/ITIL_Service_Catalogue_How_to_produce_a_Service_Catalogue.html</p>
<div id="Four"></div><p>[4] “Introduction to the ITIL Service Lifecycle”, Second Edition, Office of Government Commerce, 2010</p>
<div id="Five"></div><p>[5] Dwight Kayto, “Defining IT Services”, Art of Change; http://www.artofchange.ca/images/documents/defining%20it%20services.pdf</p>
<div id="Six"></div><p>[6] British Computing Society, BCS “Delivery mission critical system,” 2011; http://www.bcs.org/content/conWebDoc/43139<br />
http://www.downloads.xdelta.co.uk/2011/2011_07_19-bcs-mission_critical-colin_butcher.pdf</p>
<div id="Seven"></div><p>[7] Realtech, “Application Lifecycle Management,” Diagram;
http://www.realtech.com/wInternational/software/solutions/application-lifecycle-management/application-lifecycle-managementW3DnavanchorW262110100.php</p>
<h2>Related and Informing Disciplines</h2>
<ul>
<li>Business continuity management</li>
<li>Application life cycle management</li>
<li>Risk management</li>
<li>Change management</li>
<li>Enterprise and business architecture</li>
<li>Configuration management</li>
<li>Testing and validation</li>
</ul>
<h2>Appendix</h2>
<div id="Template"></div><p>TEMPLATE for a disaster recovery plan</p>
<ol><li>Introduction<br />
<ul>
<li>Scope of the plan</li>
<li>Objectives &mdash; RTO, RPO</li>
<li>Authority</li>
<li>Distribution</li>
<li>Disaster Declaration Process</li>
<li>Plan Review</li></ul></li>
<li>Recovery<br />
<ul>
<li>Recovery Team</li>
<li>Recovery Plan</li>
<li>Disaster Preparation</li>
<li>Recovery Tasks (Short Term and Long Term)</li>
</ul></li>
<li>Backup<br />
<ul>
<li>Backup Strategy for each Critical System</li>
</ul></li>
<li>Contact Information<br />
<ul>
<li>Facilities Information</li>
<li>Recovery Team Information</li>
<li>Other Business Contact of Importance</li>
</ul></li></ol>