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!
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.
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.
Next is to map out the
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
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
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
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,
Support Services Plan
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.