Keep Calm and Carry On: Business Continuity for the Rest of Us
Introduction Your livelihood and that of your employees and customers may depend on having a business continuity plan (BCP) containing one or more Disaster Recovery Plans (DR Plans). And not just having one to comply with some ISO standard but actually being in the position to utilise it when the occasion arises. Sleepless nights for the C-Level – especially the COO / CIO – can also be avoided if the BCP becomes an integral part of a business culture. But it is also the task of the CEO and CIO not to allow everyone to become over zealous with the goals. Photo by Javier Bailey on Unsplash Within this blog I am going to talk primarily here about the aspects of a BCP as related to IT but a good BCP should also consider facilities, partners, financial dependencies etc. BCP v. DR Plan There are almost religious wars on the views related to the difference between BCPs and DR Plans, but within this blog I will use the names as I have found them most useful in practice. There is usually one BCP for a company with probably multiple DR Plans within. The BCP will typically contain the high level requirement gathering information which I mention below as well as how the business functions while a DR Plan is in action or until full recovery is in place. To illustrate this more clearly, consider a specific example of a mid-sized company: the data centre where the CRM system is hosted goes down. They have a DR Plan on how to bring up initially a read-only copy of the CRM system locally in the HQ before starting another DR Plan to activate a new CRM instance in an alternative data centre. Before the new CRM instance in the alternative data centre is up and running the Call Centre utilises the BCP which explains to Call Centre Agents to arrange a call back to clients who wish to make changes to their contracts whilst being fully able to support customers only with questions. Requirement Gathering – Cost v. Benefit It is always important to remain realistic when coming up with a BCP and associated DR plans. It makes no sense to design a BCP which would bankrupt the very business it is intending to save. In order to do this it makes sense to analyse two aspects: What do you need to operate (IT systems and IT data)? What do you want to protect yourself against (disaster scenarios)? IT Systems & IT Data If possible, assign a monetary value to each system and dataset. If this is too hard, think about how much of your business’s value would be lost if a particular system or piece of data was suddenly gone. You can also use a percentage of your overall business value instead of an exact amount. This exercise doesn’t have to be perfect, but it will help you understand the value of your systems and data, which will help you decide how much to spend to protect them. If you can’t assign a monetary value, then group your computer systems and data into categories like “absolutely critical” (e.g. customer account information) and “not that important” (e.g. the latest marketing presentation). Create as many categories as you need, but try to keep it to 2-5 unless you have lots of time. This assignment will be important for discussions with your IT department to define Recovery Time Objective (RTO) for each system and the Recovery Point Objective (RPO) for each dataset. The RTO is how long you can be without a particular system after a problem before it starts to really hurt your business, and the RPO is how up-to-date the data needs to be when you get it back. As a guideline, in telecommunications, the RTO and RPO are often four hours, but, as cloud computing becomes more common, for “absolutely critical” system and data both RTO and RPO are slowly moving towards zero. As a next step document where geographically this system or data is – e.g. “Data Centre A, Vienna, Austria”. Disaster Scenarios This step is not trivial and is often based on (bad) experience. To help get your brain juices flowing consider the story of GlobalConnect Corp shown below “In Action”. SaaS Providers It is important not to ignore public cloud based systems or SaaS providers in the requirement gathering phase. It is important to request and digest the BCPs from such service providers. Here you might find additional disaster scenarios and other data sets. E.g. If salesforce goes down do you have regular reports being exported of your most important data? DR Plan Design – The Balancing Act Once you have your RPOs, RTOs and disaster scenarios the fun starts in trying to understand how you can achieve your targets without requiring a new round of funding from your investors. Technical and business experts need to collaborate on fine-tuning RTOs and RPOs, considering the financial implications of future implementations. Leadership is necessary to balance technical requirements and financial realities. Example: It might be financially unviable to have two geographically remote data centres synchronising all data, but daily backups stored remotely or in the cloud, with live data synchronised to the cloud, might be required. The leader of the BCP phase should pay close attention to RPOs and RTOs defined as “zero” and ensure they are truly necessary, as costs increase when these values approach zero. C-Level executives may need to ask probing questions to challenge departments that rate their systems as essential, such as “Would the whole business stand still?” or “Would the company suffer irreparable reputational damage?” Photo by Jordan Harrison on Unsplash DR Plan Implementation: Methods of Planning and Organisational Considerations Once the IT architecture has been implemented the next step would be to produce tested MOPs (methods of procedure). Here again the level of detail required in a MOP will be business specific but it is important to remember that probably the shit will
