The DRP - Disaster Recovery Planning

 

Disaster Recovery Planning

DRP audits help ensure that it infrastructure and all reference equipment used to develop, test, operate, monitor, govern, and/or support IT services (e.g., hardware, program, networks, data centers, etc.) are properly maintained and safeguarded to ensure their continued availability according to the organization's goals. A DRP audit estimates components such as naming alternative sites, staff training, and insurance drawbacks, among others.

Disasters, whether natural (e.g., earthquakes, tsunamis, hurricanes, tornadoes, floods, fires, etc.) or unnatural (e.g., cyberattacks, service disruption, fraud, terrorism, market collapse, etc.) invent economic chaos and severe trade disruptions. That's why having a Disaster Recovery Strategy (DRP) in place is such a fundamental instrument for organizations.

A DRP is a survival tool that helps organizations respond to threats and recover from an event that disrupts classic business operations. Continuously that the Project is supported by management, is updated often and is tested and maintained due to which, it gives the possibility for organizations to survive. In the event of a disaster, the reward is to recover without a time of significant inaction and loss of business or operations. Disasters have the potential to happen to organizations at any time and have the potential to affect them significantly. Exemplifying

• On September 11, 2001, since the Twin Towers disaster in New York, many organizations lost connectivity with banks, stockbrokers, and other financial institutions, disrupting their ability to do business and determining whether financial transactions such as the purchase and marketing of occupations, etc., had been fully and strictly executed. 
• On August 14, 2003, a major power failure shut down population centers from New York to Cleveland, Detroit and Toronto, crippling transportation networks and trapping tens of thousands of individuals in the subway, elevators and railroads. PCs became useless for those who didn't have a battery.
• One of Japan's largest car producers, Honda, suffered a fundamental drop (nearly 90%) in its second-quarter profits in 2011 after a massive tsunami and earthquake hit its production and sales. Small and medium-sized organizations would not have been able to tolerate such losses.
• In 2013, part of the Chinese Internet fell apart in what the regime called the largest denial-of-service (DoS) attack it has ever faced. The attack made machines and networks inaccessible, and disrupted Internet services. According to the Wall Street Journal, the attack has been an indicator of how susceptible the universal Internet infrastructure is.

The impact of these and many other related disasters is felt not only in the business, but also in the suppliers and customers who relied on that business for their products and sales.

One of the critical first steps in DRP is to detect who is responsible for distributed disaster recovery. Is the recovery of all technology the sole responsibility of IT or business units? The answer is dependent on who has control over the hardware, program, and data. Generally, IT and users have to work together to detect critical information and resources that will need to be recovered in the event of a disaster.

A DRP should address the partial and total devastation of computing resources. Distributed systems and microcomputer systems have to be included in the project. You have to detect the critical functionalities that are made in these platforms and establish methods to restore operations. Microcomputers are a fundamental instrument for the daily processing of work, and the recovery of these tools should not be overlooked. Data about the elementary configuration of the microcomputer, including hardware and program, should remain there to facilitate the recreation of the processing scope. In addition, a stability replica of critical data files should remain out of place along with operational and recovery methods.

A DRP should be based on the assumption that any computer system is individual to various different types of failures. In particular, the methods have to exist and be tested for recovery from failures or loss of sets, programs or data files. In the scenario of assembly failures, each installation could have a contractual agreement covering the use of an alternative location with a comparable PC configuration. Examples of such are cold sites and hot sites. A frigid place is an empty building that is pre-wired for the primary telephone and internet connection, as well as a contract with one or more suppliers to grant all the primary accessories in a specific period of time. A hot spot, however, is related to a facility that is not only pre-wired for telephone and Internet entry, but also has all the computer and office accessories the organization requires to do its fundamental business occupations.

Before assembling a DRP, you have to detect the assets of the organization (for example, hardware, program, facilities, personnel, administrative, data, etc.) and their replacement values. in addition, the specific hazards that would result in the temporary or persistent loss of assets (e.g. fire, flood, sabotage, viruses, etc.) must be recognized. Next, the effect of these losses (e.g. modification, devastation, 2, etc.) should be assessed. In the end, the cost of the asset should be compared to the frequency of loss to justify the disaster recovery solution. After finishing the above, a DRP can be assembled. 

DRP Components

The DRP should detect various levels of recovery, from a separate event to a widespread disaster. The timeliness of recovery will depend on the loss of exposure for the particular program or system. Once the project is complete, it should be tested for likely drawbacks. Tests have to be developed periodically to validate assumptions and update the project in functionality of the ever-changing scope. The tests also provide the possibility to exercise recovery methods and detect missing resources that may need to be added. The DRP should address elements, such as:

• Purposes and testimony of task
• Key personnel involved
• Integer and incremental stability copies of programs and data
• Tests and drills
• Stability copies of programs and data stored out of place
• Disaster Recovery Chair and Committee
• Emergency telephones
• List of each of the critical hardware and program applications
• Insurance coverage
• Communication plans
• Updated system and management documentation
• Employee Relocation Plans to Alternative Workplaces

All members of the organization must be familiar with the DRP. If an emergency passes, it could be simple for staff members to perform their roles in the project. The exercise of the project ensures that efforts are not redoubled and each of the correct measures are taken. It is critical to have a DRP written with detailed steps, because individuals who do not remain familiar with the process have the possibility of needing to do the disaster recovery process in a real emergency.

Audit of a DRP

As noted above, a DRP is a default strategy to enable businesses and their IT arenas to quickly restore operations and resume commerce in the event of a disaster. The project should be updated regularly to minimize the possibility of incorrect choices being made throughout the recovery process and reduce the degree of stress that can be placed on disaster recovery team members throughout this process.

From the perspective of the audit, the DRP that should be evaluated and tested by the IT auditor should integrate a task and purpose statement. These ends must be realistic, achievable and economically viable. The goals provide guidance in the preparation of the project and in the continuous re-evaluation of its usefulness. Documentation supporting the simulations or simulation tests of disasters made should be available to evaluate the technical and non-technical points of the organization's DRP method. Testing decreases the chance of miscommunication once the project is implemented throughout an actual disaster. They also offer management the possibility to identify weaknesses and improve methods. Several of the control occupations that the IT auditor can evaluate and test would relate to whether:

• All media (tapes, manuals, guides, etc.) are stored in a safe and environmentally controlled place. 
• Adequate insurance coverage has been purchased and maintained.  
• Continuous readability of backup and retained data is periodically tested through restoration or other methods.  
• Removable media is labeled to allow proper identification.

Unfortunately, companies are constantly unwilling to test thanks to the disruption in day-to-day operations and the fear that a real disaster will arise as a result of testing methods. Therefore, a gradual approach to testing could be effective in arriving at a complete test. A phased testing approach would consider, exemplifying, offering staff advance notice of the test so that they are prepared. The approach would also simulate the disaster with advice (that is to mention, in a correct time and over a slow period) and without prior notice.

Unless a DRP is tested, it rarely remains usable. A practice test of the project could really well be the difference between your triumph or failure. The process parallels the old adage about the 3 things that are required for a retailer to succeed: location, location, location. What is necessary for an organization's DRP to enable it to advance trade is testing, testing, and more testing.

The audit of a DRP is a fundamental verification for both the IT auditor and management. The primary project resources and areas need to be validated and evaluated to ensure that, in the event of a disaster, critical business processes and information systems are able to recover in time.

Policy: Disaster Recovery Plan and test

• Security and IT operations staff are responsible for developing, documenting, and testing DRP.
• Disasters considered in the DRP include natural (e.g., earthquakes, tsunamis, hurricanes, tornadoes, floods, fires, etc.) or unnatural (e.g., cyber attacks, service disruption, fraud, terrorism, market collapse, etc.) disasters, which create economic chaos and severe business disruptions..
• The DRP is supported and approved by management, and must address components such as:
• Objectives and mission statement
• Critical support services and resources needed to deliver products or services
• List of all critical hardware and software applications
• Minimum service level requirements for information and telecommunications
• Key personnel and minimum personnel required to operate during the disaster
• Employee Relocation Plans to Alternative Workplaces
• Alternative processing facilities and steps to transfer the necessary resources to such facilities
• Backups of programs and data stored off-site
• Full and incremental backups of programs and data
• Chair of Disaster Recovery and Designated Committee(s)
• Contact lists, emergency phone numbers, and alert systems with steps to follow
• Insurance Coverage
• Tests and drills
• Up-to-date system and operation documentation
• An appropriate test plan, procedures, and test scenarios should be developed and documented in accordance with the purpose, goals, and/or objectives of DRP. 
• Management must approve an appropriate test plan, procedures, and test scenarios. 
• Tests should be run at least once a year. 
• Testing should be coordinated and agreed with alternative off-site locations. 
• Testing should include fully restoring the backup media and validating that the data remains complete and accurate. 
• Test results should be documented and any gaps, weaknesses or deficiencies resulting from those tests should be addressed and corrected in a timely manner.

Reference:

Otero, A. R. (2018, 26 julio). Information Technology Control and Audit, Fifth Edition (5.^a ed.). Auerbach.