Iso Disaster Recovery Plan

International Organization of Standardization standard 22301 (ISO 22301) is a proposed standard that specifies security requirements for disaster recovery preparedness and business continuity management systems (BCMS). Download this free guide Download: Complete Your Actionable BC/DR Plan in 11 Steps.

(Redirected from Disaster recovery plan)

Given organizations' increasing dependency on information technology to run their operations, Business continuity planning covers the entire organization, and Disaster recovery focuses on IT.

Auditing of documents covering an organization's business continuity and disaster recovery plans provides a third-party validation to stakeholders that the documentation is complete and does not contain material misrepresentations.

Lack of completeness can result in overlooking secondary effects, such as when vastly increased work-at-home overloads incoming recovery site telecommunications capacity, and the bi-weekly payroll that was not critical within the first 48 hours is now causing perceived problems in ever recovering, complicated by governmental and possibly union reaction.[1]

  • 4Documentation
    • 4.1Disaster recovery plan
  • 5Benefits
  • 7Other considerations

Overview[edit]

Often used together, the terms Business Continuity and Disaster Recovery are very different. Business Continuity refers to the ability of a business to continue critical functions and business processes after the occurrence of a disaster, whereas Disaster Recovery refers specifically to the Information Technology (IT) and.[4] The disaster could be natural, environmental or man-made. Man-made disasters could be intentional (for example, an act of a terrorist) or unintentional (that is, accidental, such as the breakage of a man-made dam).

Types of plans[edit]

Although there is no one-size-fits-all plan,[5] there are three basic strategies:[3][5]

  1. prevention, including proper backups, having surge protectors and generators
  2. detection, a byproduct of routine inspections, which may discover new (potential) threats
  3. correction[6]

The latter may include securing proper insurance policies, and holding a 'lessons learned' brainstorming session.[3][7]

Relationship to the Business Continuity Plan[edit]

The Business Continuity Plan (BCP) is a comprehensive organizational plan that includes the disaster recovery plan, and it consists of five component plans:[8]

  • Business Resumption Plan
  • Occupant Emergency Plan
  • Continuity of Operations Plan
  • Incident Management Plan
  • Disaster Recovery Plan

The first three (Business Resumption, Occupant Emergency, and Continuity of Operations Plans) do not deal with the IT infrastructure. The Incident Management Plan (IMP) does deal with the IT infrastructure, but since it establishes structure and procedures to address cyber attacks against an organization’s IT systems, it generally does not represent an agent for activating the Disaster Recovery Plan, leaving The Disaster Recovery Plan as the only BCP component of interest to IT.[8]

Benefits[edit]

Like every insurance plan, there are benefits that can be obtained from proper planning, including:[4]

  • Minimizing risk of delays
  • Guaranteeing the reliability of standby systems
  • Providing a standard for testing the plan
  • Minimizing decision-making during a disaster
  • Reducing potential legal liabilities
  • Lowering unnecessarily stressful work environment

Planning and testing methodology[edit]

According to Geoffrey H. Wold of the Disaster Recovery Journal, the entire process involved in developing a Disaster Recovery Plan consists of 10 steps:[4]

  • Performing a risk assessment: The planning committee prepares a risk analysis and a business impact analysis (BIA) that includes a range of possible disasters. Each functional area of the organization is analyzed to determine potential consequences. Traditionally, fire has posed the greatest threat. A thorough plan provides for 'worst case' situations, such as destruction of the main building.
  • Establishing priorities for processing and operations: Critical needs of each department are evaluated and prioritized. Written agreements for alternatives selected are prepared, with details specifying duration, termination conditions, system testing, cost, any special security procedures, procedure for the notification of system changes, hours of operation, the specific hardware and other equipment required for processing, personnel requirements, definition of the circumstances constituting an emergency, process to negotiate service extensions, guarantee of compatibility, availability, non-mainframe resource requirements, priorities, and other contractual issues.
  • Collecting data: This includes various lists (employee backup position listing, critical telephone numbers list, master call list, master vendor list, notification checklist), inventories (communications equipment, documentation, office equipment, forms, insurance policies, workgroup and data center computer hardware, microcomputer hardware and software, office supply, off-site storage location equipment, telephones, etc.), distribution register, software and data files backup/retention schedules, temporary location specifications, any other such lists, materials, inventories, and documentation. Pre-formatted forms are often used to facilitate the data gathering process.
  • Organizing and documenting a written plan
  • Developing testing criteria and procedures: reasons for testing include
    • Determining the feasibility and compatibility of backup facilities and procedures.
    • Identifying areas in the plan that need modification.
    • Providing training to the team managers and team members.
    • Demonstrating the ability of the organization to recover.
    • Providing motivation for maintaining and updating the disaster recovery plan.
  • Testing the plan: An initial 'dry run' of the plan is performed by conducting a structured walk-through test. An actual test-run must be performed. Problems are corrected.

Initial testing can be plan is done in sections and after normal business hours to minimize disruptions.Subsequent tests occur during normal business hours.

Types of tests include: checklist tests, simulation tests, parallel tests, and full interruption tests.

Caveats/controversies[edit]

Due to high cost, various plans are not without critics. Dell has identified five 'common mistakes' organizations often make related to BCP/DR planning:[9]

  • Lack of buy-in: When executive management sees DR planning as 'just another fake earthquake drill' or CEOs fail to make DR planning and preparation a priority
  • Incomplete RTOs and RPOs: Failure to include each and every important business process or a block of data. Ripples can extend a disaster's impact. Payroll may not initially be mission-critical, but left alone for several days, it can become more important than any of your initial problems.
  • Systems myopia: A third point of failure involves focusing only on DR without considering the larger business continuity needs. Corporate office space lost to a disaster can result in an instant pool of teleworkers which, in turn, can overload a company's VPN overnight, overwork the IT support staff at the blink of an eye and cause serious bottlenecks and monopolies with the dial-in PBX system.
  • Lax security: When there is a disaster, an organization's data and business processes become vulnerable. As such, security can be more important than the raw speed involved in a disaster recovery plan's RTO. The most critical consideration then becomes securing the new data pipelines: from new VPNs to the connection from offsite backup services.
    • In disasters, planning for post-mortem forensics
    • Locking down or remotely wiping lost handheld devices

Decisions and Strategies[edit]

  • Site designation: hot site vs. cold site. A hot site is fully equipped to resume operations while a cold site does not have that capability. A warm site has the capability to resume some, but not all operations.

    A cost-benefit analysis is needed.

    • Occasional tests and trials verify the viability and effectiveness of the plan. An auditor looks into the probability that operations of the organization can be sustained at the level that is assumed in the plan, and the ability of the entity to actually establish operations at the site.
    • The auditor can verify this through paper and paperless documentation and actual physical observation. The security of the storage site is also confirmed.
  • Data backup: An audit of backup processes determines if (a) they are effective, and (b) if they are actually being implemented by the involved personnel.[10][11]

    The disaster recovery plan also includes information on how best to recover any data that has not been copied. Controls and protections are put in place to ensure that data is not damaged, altered, or destroyed during this process.

  • Drills: Practice drills conducted periodically to determine how effective the plan is and to determine what changes may be necessary. The auditor’s primary concern here is verifying that these drills are being conducted properly and that problems uncovered during these drills are addressed.
  • Backup of key personnel - including periodic training and cross-training.

Other considerations[edit]

Insurance issues[edit]

The auditor determines the adequacy of the company's insurance coverage (particularly property and casualty insurance) through a review of the company's insurance policies and other research. Among the items that the auditor needs to verify are: the scope of the policy (including any stated exclusions), that the amount of coverage is sufficient to cover the organization’s needs, and that the policy is current and in force. The auditor also ascertains, through a review of the ratings assigned by independent rating agencies, that the insurance company or companies providing the coverage have the financial viability to cover the losses in the event of a disaster.

Effective DR plans take into account the extent of a company's responsibilities to other entities and its ability to fulfill those commitments despite a major disaster. A good DR audit will include a review of existing MOA and contracts to ensure that the organization's legal liability for lack of performance in the event of disaster or any other unusual circumstance is minimized. Agreements pertaining to establishing support and assisting with recovery for the entity are also outlined. Techniques used for evaluating this area include an examination of the reasonableness of the plan, a determination of whether or not the plan takes all factors into account, and a verification of the contracts and agreements reasonableness through documentation and outside research.

Communication issues[edit]

The auditor must verify that planning ensures that both management and the recovery team have effective communication hardware, contact information for both internal communication and external issues, such as business partners and key customers.

Audit techniques include

  • testing of procedures, interviewing employees, making comparison against the plans of other company and against industry standards,
  • examining company manuals and other written procedures.
  • direct observation that emergency telephone numbers are listed and easily accessible in the event of a disaster.

Emergency procedures[edit]

Procedures to sustain staff during a round-the clock disaster recovery effort are included in any good disaster recovery plan. Procedures for the stocking of food and water, capabilities of administering CPR/first aid, and dealing with family emergencies are clearly written and tested. This can generally be accomplished by the company through good training programs and a clear definition of job responsibilities. A review of the readiness capacity of a plan often includes tasks such as inquires of personnel, direct physical observation, and examination of training records and any certifications.

Environmental issues[edit]

The auditor must review procedures that take into account the possibility of power failures or other situations that are of a non-IT nature.

  • Flashlights and candles may be needed.
  • Safety procedures in case of gas leaks, fires or other such phenomena

See also[edit]

References[edit]

  1. ^'Are External Auditors Concerned about Cyber Risk disclosure'(PDF).
  2. ^Susan Snedaker (2013). Business continuity and disaster recovery planning for IT professionals (2 Edition. ed.). Burlington: Elsevier Science. ISBN9780124114517.
  3. ^ abcBill Abram (14 June 2012). '5 Tips to Build an Effective Disaster Recovery Plan'. Small Business Computing. Retrieved 9 August 2012.
  4. ^ abcWold, Geoffrey H. (1997). 'Disaster Recovery Planning Process'. Disaster Recovery Journal. Adapted from Volume 5 #1. Disaster Recovery World. Archived from the original on 15 August 2012. Retrieved 8 August 2012.
  5. ^ ab'Disaster Recovery Planning - Step by Step Guide'. Michigan State University. Archived from the original on 8 March 2014. Retrieved 9 May 2014.
  6. ^'Backup Disaster Recovery'. Email Archiving and Remote Backup. 2010. Archived from the original on 22 January 2013. Retrieved 9 May 2014.
  7. ^'Disaster Recovery & Business Continuity Plans'. Stone Crossing Solutions. 2012. Archived from the original on 23 August 2012. Retrieved 9 August 2012.
  8. ^ abChad Bahan. (June 2003). 'The Disaster Recovery Plan'. Retrieved 24 August 2012.
  9. ^Cormac Foster; Dell Corporation (25 October 2010). 'Five Mistakes That Can Kill a Disaster Recovery Plan'. Retrieved 8 August 2012.
  10. ^Constance Gustke (October 7, 2015). 'Hurricane Joaquin Highlights the Importance of Plans to Keep Operating'. The New York Times.
  11. ^Berman, Alan. Constructing a Successful Business Continuity Plan. Business Insurance Magazine, March 9, 2015. http://www.businessinsurance.com/article/20150309/ISSUE0401/303159991/constructing-a-successful-business-continuity-plan
  • Messier, Jr., W. F. (2011). Auditing & Assurance Services: A Systematic Approach (8th ed.). New York: McGraw-Hill/Irwin. ISBN9780077520151.
  • Gallegos, F.; Senft, S.; Davis, A. L. (2012). Information Technology Control and Audit (4th ed.). Boca Raton, FL: Auerbach Publications. ISBN9781439893203.
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Disaster_recovery_and_business_continuity_auditing&oldid=916353030'

Disaster Recovery involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induceddisaster. Disaster recovery focuses on the IT or technology systems supporting critical business functions,[1] as opposed to business continuity, which involves keeping all essential aspects of a business functioning despite significant disruptive events. Disaster recovery can therefore be considered as a subset of business continuity.[2][3]

  • 1IT Service Continuity
    • 1.2Recovery Time Objective
    • 1.3Recovery Point Objective

IT Service Continuity[edit]

IT Service Continuity[4][5] (ITSC) is a subset of Business Continuity Planning (BCP)[6] and encompasses IT disaster recovery planning and wider IT resilience planning. It also incorporates those elements of IT infrastructure and services which relate to communications such as (voice) telephony and data communications.

The ITSC Plan reflects Recovery Point Objective (RPO - recent transactions) and Recovery Time Objective (RTO - time intervals).

Principles of Backup sites[edit]

Planning includes arranging for backup sites, be they hot, warm, cold or standby sites with hardware as needed for continuity.

In 2008 the British Standards Institution launched a specific standard connected and supporting the Business Continuity Standard BS 25999 titled BS25777 specifically to align computer continuity with business continuity. This was withdrawn following the publication in March 2011 of ISO/IEC 27031 - Security techniques — Guidelines for information and communication technology readiness for business continuity.

ITIL has defined some of these terms.[7]

Recovery Time Objective[edit]

The Recovery Time Objective (RTO)[8][9] is the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.[10]

Schematic representation of the terms RPO and RTO. In this example, the agreed values of RPO and RTO are not fulfilled.

In accepted business continuity planning methodology, the RTO is established during the Business Impact Analysis (BIA) by the owner of a process, including identifying options time frames for alternate or manual workarounds.

In a good deal of the literature on this subject, RTO is spoken of as a complement of Recovery Point Objective (RPO), with the two metrics describing the limits of acceptable or 'tolerable' ITSC performance in terms of time lost (RTO) from normal business process functioning, and in terms of data lost or not backed up during that period of time (RPO) respectively.[10][11]

Recovery Time Actual[edit]

A Forbes overview[8] noted that it is Recovery Time Actual (RTA) which is 'the critical metric for business continuity and disaster recovery.'

RTA is established during exercises or actual events. The business continuity group times rehearsals (or actuals) and makes needed refinements.[8][12]

Recovery Point Objective[edit]

A Recovery Point Objective (RPO) is defined by business continuity planning. It is the maximum targeted period in which data (transactions) might be lost from an IT service due to a major incident.[10]

If RPO is measured in minutes (or even a few hours), then in practice, off-site mirrored backups must be continuously maintained; a daily off-site backup on tape will not suffice.[13]

Relationship to Recovery Time Objective[edit]

Recovery that is not instantaneous will restore data/transactions over a period of time; the goal is to do so without incurring significant risks or significant losses.[10]

RPO measures the maximum time period in which recent data might have been permanently lost in the event of a major incident; it is not a direct measure of the quantity of such loss. For instance if the BC plan is 'restore up to last available backup', the RPO is the maximum interval between such backup that has been safely vaulted offsite.

Business impact analysis is used to determine RPO for each service; RPO is not determined by the existent backup regime. When any level of preparation of off-site data is required, the period during which data might be lost often starts near the time of the beginning of the work to prepare backups, not the time the backups are taken off-site.[11]

Data synchronization points[edit]

Although a data synchronization point[14] is a point in time, the timing for performing the physical backup must be included. One approach used is to halt processing of an update queue, while a disk-to-disk copy is made. The backup[15] reflects the earlier time of that copy operation, not when the data is copied to tape or transmitted elsewhere.

Disaster

How RTO and RPO values affect computer system design[edit]

RTO and the RPO must be balanced, taking business risk into account, along with all the other major system design criteria.[16]

RPO is tied to the times backups are sent offsite. Offsiting via synchronous copies to an offsite mirror allows for most unforeseen difficulty. Use of physical transportation for tapes (or other transportable media) comfortably covers some backup needs at a relatively low cost. Recovery can be enacted at a predetermined site. Shared offsite space and hardware completes the package needed.[17]

For high volumes of high value transaction data, the hardware can be split across two or more sites; splitting across geographic areas adds resiliency.

History[edit]

Planning for disaster recovery and information technology (IT) developed in the mid- to late 1970s as computer center managers began to recognize the dependence of their organizations on their computer systems.

At that time, most systems were batch-oriented mainframes. Another offsite mainframe could be loaded from backup tapes pending recovery of the primary site; downtime was relatively less critical.

The disaster recovery industry[18][19] developed to provide backup computer centers. One of the earliest such centers was located in Sri Lanka (Sungard Availability Services, 1978).[20][21]

During the 1980s and 90s, as internal corporate timesharing, online data entry and real-time processing grew, more availability of IT systems was needed.

Regulatory agencies became involved even before the rapid growth of the Internet during the 2000s; objectives of 2, 3, 4 or 5 nines (99.999%) were often mandated, and high-availability solutions for hot-site facilities were sought.[citation needed]

Iso 27001 disaster recovery requirements

IT Service Continuity is essential for many organizations in the implementation of Business Continuity Management (BCM) and Information Security Management (ICM) and as part of the implementation and operationinformation security management as well as business continuity management as specified in ISO/IEC 27001 and ISO 22301 respectively.

The rise of cloud computing since 2010 continues that trend: nowadays, it matters even less where computing services are physically served, just so long as the network itself is sufficiently reliable (a separate issue, and less of a concern since modern networks are highly resilient by design). 'Recovery as a Service' (RaaS) is one of the security features or benefits of cloud computing being promoted by the Cloud Security Alliance.[22]

Classification of disasters[edit]

Disasters can be the result of three broad categories of threats and hazards. The first category is natural hazards that include acts of nature such as floods, hurricanes, tornadoes, earthquakes, and epidemics. The second category is technological hazards that include accidents or the failures of systems and structures such as pipeline explosions, transportation accidents, utility disruptions, dam failures, and accidental hazardous material releases. The third category is human-caused threats that include intentional acts such as active assailant attacks, chemical or biological attacks, cyber attacks against data or infrastructure, and sabotage. Preparedness measures for all categories and types of disasters fall into the five mission areas of prevention, protection, mitigation, response, and recovery.[23]

Importance of disaster recovery planning[edit]

Recent research supports the idea that implementing a more holistic pre-disaster planning approach is more cost-effective in the long run. Every $1 spent on hazard mitigation(such as a disaster recovery plan) saves society $4 in response and recovery costs.[24]

2015 disaster recovery statistics suggest that downtime lasting for one hour can cost

  • small companies as much as $8,000,
  • mid-size organizations $74,000, and
  • large enterprises $700,000.[25]

As IT systems have become increasingly critical to the smooth operation of a company, and arguably the economy as a whole, the importance of ensuring the continued operation of those systems, and their rapid recovery, has increased. For example, of companies that had a major loss of business data, 43% never reopen and 29% close within two years. As a result, preparation for continuation or recovery of systems needs to be taken very seriously. This involves a significant investment of time and money with the aim of ensuring minimal losses in the event of a disruptive event.[26]

Control measures[edit]

Control measures are steps or mechanisms that can reduce or eliminate various threats for organizations. Different types of measures can be included in disaster recovery plan (DRP).

Disaster recovery planning is a subset of a larger process known as business continuity planning and includes planning for resumption of applications, data, hardware, electronic communications (such as networking) and other IT infrastructure. A business continuity plan (BCP) includes planning for non-IT related aspects such as key personnel, facilities, crisis communication and reputation protection, and should refer to the disaster recovery plan (DRP) for IT related infrastructure recovery / continuity.

IT disaster recovery control measures can be classified into the following three types:

  1. Preventive measures – Controls aimed at preventing an event from occurring.
  2. Detective measures – Controls aimed at detecting or discovering unwanted events.
  3. Corrective measures – Controls aimed at correcting or restoring the system after a disaster or an event.

Good disaster recovery plan measures dictate that these three types of controls be documented and exercised regularly using so-called 'DR tests'.

Strategies[edit]

Prior to selecting a disaster recovery strategy, a disaster recovery planner first refers to their organization's business continuity plan which should indicate the key metrics of Recovery Point Objective and Recovery Time Objective.[27] Metrics for business processes are then mapped to their systems and infrastructure.[28]

Failure to properly plan can extend the disaster's impact.[29] Once metrics have been mapped, the organization reviews the IT budget; RTO and RPO metrics must fit with the available budget. A cost-benefit analysis often dictates which disaster recovery measures are implemented.

Adding cloud-based backup to the benefits of local and offsite tape archiving, the New York Times wrote, 'adds a layer of data protection.'[30]

Common strategies for data protection include:

  • backups made to tape and sent off-site at regular intervals
  • backups made to disk on-site and automatically copied to off-site disk, or made directly to off-site disk
  • replication of data to an off-site location, which overcomes the need to restore the data (only the systems then need to be restored or synchronized), often making use of storage area network (SAN) technology
  • Private Cloud solutions which replicate the management data (VMs, Templates and disks) into the storage domains which are part of the private cloud setup. These management data are configured as an xml representation called OVF (Open Virtualization Format), and can be restored once a disaster occurs.
  • Hybrid Cloud solutions that replicate both on-site and to off-site data centers. These solutions provide the ability to instantly fail-over to local on-site hardware, but in the event of a physical disaster, servers can be brought up in the cloud data centers as well.
  • the use of high availability systems which keep both the data and system replicated off-site, enabling continuous access to systems and data, even after a disaster (often associated with cloud storage)[31]

In many cases, an organization may elect to use an outsourced disaster recovery provider to provide a stand-by site and systems rather than using their own remote facilities, increasingly via cloud computing.

In addition to preparing for the need to recover systems, organizations also implement precautionary measures with the objective of preventing a disaster in the first place. These may include:

  • local mirrors of systems and/or data and use of disk protection technology such as RAID
  • surge protectors — to minimize the effect of power surges on delicate electronic equipment
  • use of an uninterruptible power supply (UPS) and/or backup generator to keep systems going in the event of a power failure
  • fire prevention/mitigation systems such as alarms and fire extinguishers
  • anti-virus software and other security measures

Vendors[edit]

Disaster Recovery as a Service (DRaaS) is an arrangement with a third party.[32]

Although vendor lists have been published, disaster recovery is not a product, even though several large hardware vendors have developed mobile/modular offerings that can be installed and made operational in very short time.

A modular data center connected to the power grid at a utility substation

Iso 9001 Disaster Recovery Plan

  • Axcient[33][34]
  • BASELAYER[35] has a patent on software defined modular data center.[36]
  • Cisco Systems[37]
  • Databarracks[38]
  • Google (Google Modular Data Center) has developed systems that could be used for this purpose.[39][40]
  • Bull (mobull)[41]
  • HP (Performance Optimized Datacenter)[42]
  • Huawei (Container Data Center Solution),[43]
  • IBM (Portable Modular Data Center)
  • Schneider-Electric (Portable Modular Data Center)
  • Sun Microsystems (Sun Modular Datacenter)[44][45]

See also[edit]

References[edit]

  1. ^Systems and Operations Continuity: Disaster Recovery. Georgetown University. University Information Services. Retrieved 3 August 2012.
  2. ^Disaster Recovery and Business Continuity, version 2011.Archived January 11, 2013, at the Wayback Machine IBM. Retrieved 3 August 2012.
  3. ^[1] 'What is Business Continuity Management', DRI International, 2017
  4. ^M. Niemimaa; Steven Buchanan (March 2017). 'Information systems continuity process'. ACM.com (ACM Digital Library).
  5. ^'2017 IT Service Continuity Directory'(PDF). Disaster Recovery Journal.
  6. ^'Defending The Data Strata'. ForbesMiddleEast.com. December 24, 2013.
  7. ^'ITIL glossary and abbreviations'.
  8. ^ abc'Like The NFL Draft, Is The Clock The Enemy Of Your Recovery Time'. Forbes. April 30, 2015.
  9. ^'Three Reasons You Can't Meet Your Disaster Recovery Time'. Forbes. October 10, 2013.
  10. ^ abcd'Understanding RPO and RTO'. DRUVA. 2008. Retrieved February 13, 2013.
  11. ^ ab'How to fit RPO and RTO into your backup and recovery plans'. SearchStorage. Retrieved 2019-05-20.
  12. ^'Clock... modifications
  13. ^Richard May. 'Finding RPO and RTO'. Archived from the original on 2016-03-03.
  14. ^'Data transfer and synchronization between mobile systems'. May 14, 2013.
  15. ^'Amendment #5 to S-1'. SEC.gov. real-time ... provide redundancy and back-up to ...
  16. ^Peter H. Gregory. 'Setting the Maximum Tolerable Downtime -- setting recovery objectives'. IT Disaster Recovery Planning For Dummies. Wiley. pp. 19–22. ISBN1118050630.
  17. ^William Caelli; Denis Longley (1989). Information Security for Managers. p. 177. ISBN1349101370.
  18. ^'Catastrophe? It Can't Possibly Happen Here'. The New York Times. January 29, 1995. .. patient records
  19. ^'Commercial Property/Disaster Recovery'. NYTimes.com. October 9, 1994. ...the disaster-recovery industry has grown to
  20. ^Charlie Taylor (June 30, 2015). 'US tech firm Sungard announces 50 jobs for Dublin'. The Irish Times. Sungard .. founded 1978
  21. ^Cassandra Mascarenhas (November 12, 2010). 'SunGard to be a vital presence in the banking industry'. Wijeya Newspapers Ltd. SunGard ... Sri Lanka’s future.
  22. ^SecaaS Category 9 // BCDR Implementation Guidance CSA, retrieved 14 July 2014.
  23. ^'Threat and Hazard Identification and Risk Assessment (THIRA) and Stakeholder Preparedness Review (SPR): Guide Comprehensive Preparedness Guide (CPG) 201, 3rd Edition'(PDF). US Department of Homeland Security. May 2018.
  24. ^'Post-Disaster Recovery Planning Forum: How-To Guide, Prepared by Partnership for Disaster Resilience'. University of Oregon's Community Service Center, (C) 2007, www.OregonShowcase.org. Retrieved October 29, 2018.
  25. ^'The Importance of Disaster Recovery'. Retrieved October 29, 2018.
  26. ^'IT Disaster Recovery Plan'. FEMA. 25 October 2012. Retrieved 11 May 2013.
  27. ^The Professional Practices for Business Continuity Management, Disaster Recovery Institute International (DRI), 2017
  28. ^Gregory, Peter. CISA Certified Information Systems Auditor All-in-One Exam Guide, 2009. ISBN978-0-07-148755-9. Page 480.
  29. ^'Five Mistakes That Can Kill a Disaster Recovery Plan'. Dell.com. Archived from the original on 2013-01-16. Retrieved 2012-06-22.
  30. ^J. D. Biersdorfer (April 5, 2018). 'Monitoring the Health of a Backup Drive'. The New York Times.
  31. ^Brandon, John (23 June 2011). 'How to Use the Cloud as a Disaster Recovery Strategy'. Inc. Retrieved 11 May 2013.
  32. ^'Disaster Recovery as a Service (DRaaS)'.
  33. ^Robert Naegle; John Morency. 'Critical Capabilities for Recovery as a Service'. Gartner.
  34. ^'The Forrester Wave: Disaster-Recovery-As-A-Service Providers, Q1 2014'.
  35. ^Hayley Ringle (December 8, 2014). 'BaseLayer partners with SRP for new modular data centers that plug directly into power grid'. BizJournals.com (Phoenix). Retrieved July 11, 2019.
  36. ^George Slessman (May 7, 2013), System and method of providing computer resources, retrieved February 24, 2016
  37. ^'Info and video about Cisco's solution'. Datacentreknowledge. May 15, 2007. Archived from the original on 2008-05-19. Retrieved 2008-05-11.
  38. ^'Crunchbase | Databarracks'.
  39. ^Kraemer, Brian (June 11, 2008). 'IBM's Project Big Green Takes Second Step'. ChannelWeb. Archived from the original on 2008-06-11. Retrieved 2008-05-11.
  40. ^'Modular/Container Data Centers Procurement Guide: Optimizing for Energy Efficiency and Quick Deployment'(PDF). Archived from the original(PDF) on 2013-05-31. Retrieved 2013-08-30.
  41. ^Kidger, Daniel. 'Mobull Plug and Boot Datacenter'. Bull. Archived from the original on 2010-11-19. Retrieved 2011-05-24.
  42. ^'HP Performance Optimized Datacenter (POD) 20c and 40c - Product Overview'. H18004.www1.hp.com. Archived from the original on 2015-01-22. Retrieved 2013-08-30.
  43. ^'Huawei's Container Data Center Solution'. Huawei. Retrieved 2014-05-17.
  44. ^'Technical specs of Sun's Blackbox'. Archived from the original on 2008-05-13. Retrieved 2008-05-11.
  45. ^And English Wiki article on Sun's modular datacentre

Further reading[edit]

Iso Business Continuity And Disaster Recovery Plan

  • ISO/IEC 22301:2012 (replacement of BS-25999:2007) Societal Security – Business Continuity Management Systems – Requirements
  • ISO/IEC 27001:2013 (replacement of ISO/IEC 27001:2005 [formerly BS 7799-2:2002]) Information Security Management System
  • ISO/IEC 27002:2013 (replacement of ISO/IEC 27002:2005 [renumbered ISO17799:2005]) Information Security Management – Code of Practice
  • ISO/IEC 22399:2007 Guideline for incident preparedness and operational continuity management
  • ISO/IEC 24762:2008 Guidelines for information and communications technology disaster recovery services
  • The Professional Practices for Business Continuity Management, Disaster Recovery Institute International (DRI), 2017
  • IWA 5:2006 Emergency Preparedness—British Standards Institution –
  • BS 25999-1:2006 Business Continuity Management Part 1: Code of practice
  • BS 25999-2:2007 Business Continuity Management Part 2: Specification
  • BS 25777:2008 Information and communications technology continuity management – Code of practice—Others –
  • 'A Guide to Business Continuity Planning' by James C. Barnes
  • 'Business Continuity Planning', A Step-by-Step Guide with Planning Forms on CDROM by Kenneth L Fulmer
  • 'Disaster Survival Planning: A Practical Guide for Businesses' by Judy Bell
  • ICE Data Management (In Case of Emergency) made simple – by MyriadOptima.com
  • Harney, J.(2004). Business continuity and disaster recovery: Back up or shut down.
  • AIIM E-Doc Magazine, 18(4), 42–48.
  • Dimattia, S. (November 15, 2001).Planning for Continuity. Library Journal,32–34.

Disaster Recovery Tier Standards

External links[edit]

Retrieved from 'https://en.wikipedia.org/w/index.php?title=Disaster_recovery&oldid=916353024'

Comments are closed.