One in three companies has already experienced an incident or outage that required the activation of a disaster recovery plan.
the question is not whether a company's information system will experience a disaster, but rather when it will occur.
And when it occurs, will the company concerned be ready to face it?
The causes of incidents affecting information system infrastructure can be varied: hardware failure, software failure, backup failure, cyberattack, human error, natural disaster, etc.
Due to the proliferation of computer networks, companies must now establish their data protection strategies while also taking into account potential attacks and frequent intrusions on information systems (ransomware, cryptolocker, phishing, etc.). The emergence of a market for solutions designed to combat cyberattacks clearly reflects this issue, which has become a major concern for many companies.
Cyberattacks should no longer be considered as isolated incidents in the course of a company's operations.
What are the risks faced by a company that has not developed a business continuity plan or has not at least begun to reflect on the matter?
THE IMPACTS OF A DISASTER ON THE BUSINESS
The effects felt will first be operational and functional in nature. If no measures exist for service restoration, teams can be directly impacted in their work (machine downtime, server outages, loss of network access, etc.), internal and external communication tools may become unusable, and so forth.
Quite rapidly, the company's pulse slows and its activity, along with its visibility, can disappear from the radar of its suppliers, partners, customers and prospects. In other words, the shorter the "invisibility window", the less negative the impact will be for the company.
From a commercial and financial perspective, this can result in lost sales or contract signings. It also means the loss of customers, or even market share. The shorter the sales cycle inherent to the company's business model, the more immediate the commercial losses will be.
Conversely, with a medium to long average sales cycle, the company has a better chance of incurring fewer direct losses. The priority will then be to restore its services as quickly as possible.
However, this may have other impacts, such as on the company's image and reputation, or on partner trust. A marketplace, an online payment system, or a hotel room booking platform could see a portion of users turn to new service providers or communicate negatively about the failing service.
PREPARING FOR A DISASTER AFFECTING YOUR ORGANISATION'S OPERATIONS
It is imperative to build a business continuity plan in advance — that is, a plan for data recovery and restoration of lost services — which must be thoroughly tested and validated before being implemented on the day of a disaster.
The objective for an organization will therefore be to develop a disaster recovery plan which, ideally, should be coupled with a business continuity plan.
During the business continuity plan development process, it will be mandatory to identify the company's activities considered critical, to interview the managers of each activity, to identify the probable origin of future incidents, to define the human and material resources that will support the implementation of the plan, to estimate the costs associated with the execution and rollout of the recovery plan, etc.
All these criteria must be understood — the more numerous and precisely collected they are, the more they will facilitate the triggering and execution of the business recovery plan by all stakeholders involved.
THE STEPS TO FOLLOW TO PROPERLY DOCUMENT A BCP
Whether the DRP is built on a backup site, a datacenter, or constructed in the Cloud on virtualised IT resources, it is essential to adopt a logical and thoroughly documented approach to ensure the performance of a disaster recovery plan.
Here are the preliminary steps to keep in mind in order to successfully develop a business continuity plan for your company.
Conduct an audit of all possible failure risks to the information system and identify probable causes: hardware failure, software failure, cyberattack, power outages, fire, natural disaster, human error, etc.
Detect and assess each risk to identify the business applications that will not be able to operate in degraded mode. It is therefore essential to fully understand and measure the fault tolerance of the entire information system.
Define the criticality of application environments and the backup and recovery requirements that will need to be applied. The RTO (Recovery Time Objective) and RPO (Recovery Point Objective) must be defined here.
Schedule automatic backups at a frequency that matches the organisation's needs.
Implementing "Crisis Management" means assigning roles and tasks to specific individuals who will be responsible for responding when the time comes. In other words, teams must be organised to act effectively during a disaster.
Define recovery priorities and costs: assess service unavailability thresholds and prioritize them in order to define the operating cost of the infrastructure that will enable business recovery. When recovery must be completed in under one minute, the implementation of a synchronous environment will rapidly drive up costs, for example.
Define the choice of backup and disaster recovery equipment as well as the budget to be allocated to it. It should be noted that simply doubling the existing hardware on a remote site may not be sufficient in some cases. The choice of hardware is therefore important if it is to be able to handle the load.
Regularly test the disaster recovery plan: although the cost of a DRP test is significant, it is imperative to regularly assess its reliability at least twice a year.
Update the disaster recovery plan in line with changes made to the information system: a company's IT system is constantly evolving. It is therefore essential to reflect these changes in the initially constructed DRP in order to ensure its reliability.
Precisely document the DRP: it is important to encourage feedback from stakeholders responsible for ensuring the reliability of the DRP by documenting it accurately. Sharing knowledge of the IS will directly impact the performance of a DRP. As such, testing phases and reported failures must be systematically documented, which is generally rarely the case.
It should not be forgotten to take into account the regulatory constraints arising in certain legal frameworks upon which an organisation may be dependent.