Sometime back, a person asked me about the implementation of the ISO standard for Business Continuity Management System (BCMS), through a mobile chat. I replied to him with few points, and somehow, a draft of that message was left in my notes. I just saw it today and thought of publishing it. (Note: This is a very brief read, and the subject can be written more elaborately) 

Lets get started! 

Introduction 

Before we implement a BCMS, we have to see which ISO standard addresses the Business Continuity. The simple answer for that would be ISO 22301:2012. 

What is ISO 22301:2012, by the way?

Let me put it this way. Think as we break the term ‘ISO 22301:2012’ into 3 parts. The first part ISO means, the organization which publishes the standard. It is the International Organization for Standardization. The number in the middle refers to the Family of Standards, which the particular standard belongs. In our case, 22301 comes under Societal Security and specifically, Business Continuity Management System (BCMS). The latter number refers to the year of publishing of the Standard. In our case, it is published in 2012. 

The ISO 22301:2012 is a generic standard and can be applied to any kind of organization, regardless of its type, size or nature of business. 

Enough intro. We’ll get into the subject.

Note: this article suggests a method of doing a Business Continuity Plan (BCP), but this is not the only way to do it. There may be different methodologies used, but the end outcome would be same. 

Getting Started!

The first ever thing to do in a BCP assignment is to do a BIA (Business Impact Analysis). A BIA is simply a process of analyzing the potential impact in case of a disaster or emergency. This is one of the places where we gather all the necessary details, and do the preparations for the development of the BCP. I’m gonna be listing 10 points on how to do the BIA. Trust me, it is a much more detailed process, and cannot be simply put with 10 bullets. 

Getting the full detail of the company/scope 

Here, we gather as much information about the company and its operations. We may gather information on human resources, organizational chart, computers, and equipment, etc. We can use the help of an asset inventory, if available. 

Identify who lives near the location

In this phase, we see who live nearby, what transport facilities available in the area, etc. The reason for this is to figure out and make sure someone can reach the premises with minimum latency, in case of a disaster. When identifying and assigning people for this task, make sure you gather the information of their home (land line) numbers along with the mobile numbers. Cause, landline numbers may be a little more reliable to contact a person in some scenarios. 

Identify all the activities

This is one of the time-consuming activities of the BIA. What we really do in this phase is trying to identify ALL the activities done under the scope. The more granular yo get the information, the better your BIA is going to be. While identifying the activities, we have to consider the employees who do those activities regularly, and ow many of them are needed to run the process, in case of a disaster. In addition, time dependencies, etc. (Trust me, it’s a huge list. Do your homework and list down the rest). Don’t forget to identify the skills needed to carry out those activities, so you can search for people with those skills in case of a disaster. 

List down the dependencies

In this phase, all that we do is identifying all the dependencies for each of the activity. It may be a dependency from an internal department or maybe some external parties like vendors or service providers, or any other thing, which the activity depends on. End of the day, we need to know what dependancies we need have in order to carry out this activity, in a disaster. By the way, don’t forget to identify the level of dependency and the method of dependency for each of them.

Software used

Next is to map out the softwares/applications and digital assets used to carry out those activities. It’s better if you list down the software on the priority basis, which would make your life easy when you try to identify which software is needed for the DR operation. Also, consider the computers needed as a minimum to run all the activities. Because we might have to allocate some computers in our DR site and work from home for some time until our primary site is back.

Recovery Point Objective (RPO)

This is a term where most people confuse about. Simply putting, RPO is where we identify what level of data loss we can tolerate if a disaster happens. Putting it a little more simple, you measure the age of files which needs to be recovered or which time period of data loss can be tolerated. Wait wait wait!. I know, it’s confusing. But, I can’t explain it within a bullet point. So, I urge you to Google it a bit. Trust me, you’ll get a better picture. 

Recovery Time Objective (RTO)

The next jargon is RTO. This means the maximum tolerable downtime for a particular application. In simple terms, how long you can live and run the business without a particular application. In other words, within how long a system or service should be restored. After identifying the Software list, RPO and RTO, now you can come to a conclusion on which software is needed at first and how long we can stay without it, how fast we should recover and what data is needed. You get the idea!

Analyzing the impact

Next thing we have to identify is the impact for the business if a disaster happens. The impact could be either financial or non-financial (Ex: damage to the reputation). It’s better to identify the impact of the loss of each activity and application. So, that will also enable us to prioritize an activity in disaster recovery. 

Manual activities possible

This is again an important task. Here, you identify if there is a possibility for an activity to be conducted manually (without dependency of equipment, or tool), and what are the vital records needed for manual execution. By identifying the manual activities, you could still continue working without IT systems until you make the DR site up and running. That would add significant value to your BCP.  

People requirement

Last, but never least, Human. Here you identify the minimum number of people required to continue each of the activities. Also, don’t forget to identify any single point of failure in terms of people. Because we need to have backup arrangements for those single point of failures.    

Enough with the BIA!

Once the BIA is done, store the information you have, and analyze them. It will help us develop the Business Continuity Plans. We can have a single plan, or many. The number of plans you’re going to have may be vary depending on the organization, and the scope. I’m going to be listing 5 of them. 

Again, I’m not going to be detailing on how to develop each of the plans, but I’ll give you a brief on what the plan should consist with. Here we go!

Crisis Management Pan

This plan talks about how to execute and act on a disaster. This plan may be considered as the major plan, which consists of multiple smaller plans to address each of the smaller aspects. You could have charts, diagrams, call trees, and things to elaborate on how the BCP/DR is going to work. 

Disaster Recovery (DR) Plan

This plan specifically talks about how to recover the business and the site from the disaster. The DR plan may include the recovery of IT systems, buildings, human, reputation, data loss, etc. 

Crisis Communication Plan

This is yet another important plan to have. Here, we talks about how to communicate in the disaster scenario. Most of the times, people get panic and rumors spread. I’ve seen incidents where false information had spread in the media and sometimes in the families of the employees of a particular organization. So, we have to consider all the parties who needs information about the disaster. It could be press & media, families of employees, board of directors, any other interested parties and stakeholders, etc. The message to each of these parties would be communicated in a different way, and the amount of information shared among each off the parties would also be different. So, developing a well planned Crisis Communication Plan is very important. 

Incident Management Plan

This plan talks about how to handle smaller incidents within a disaster or incidents which have not yet been turned into disasters. In many cases, unnoticed incidents turn into disasters. So, management of the incidents is very important. This plan would all the aspects of Incident Management. Again, this is a vast area to cover, which I haven’t taken my time in this blog.    

Support Services Plan

Many organizations doesn’t consider about this plan. But, it is actually an important one. In case of a disaster, we might have to move to a temporary site and the site may need all the support services, and utility supplies. People may need transport, food & lodging, mobile connectivity, Internet connectivity, electricity, and many more in the new location. We have to consider, how, who and when are we going to get those support services to the temporary location. If we identify these beforehand, we can recover fast and continue and resume the business very fast. Not having them may lead to a long interruption in our business operations. 

The above information are just a fraction of what and how a BCMS looks like and what effort is needed to develop a BCMS. But, the above read could give you an understanding on the development of BCMS, and serve as a guideline for you to develop a BCMS. 

How could we help? 

We, at EncryptAsia, comprised of highly experienced BCMS implementers and developers who have been involved in developing Business Continuity Plans and Disaster Recovery (BCP/DR) plans for the largest organizations. It include, banks, conglomerates, manufacturing companies, etc. 

If you’re looking to develop a BCP for your company, we are happy to help you. Call us on 0094 772 365 17 27 or email us on [email protected]. 

Hope this blog was informative. Have a good time and run your business without interruptions.