"For Best View, Please Open this Website on Laptop / Desktop Or Mobile"

Search
Cancel
14 January 2013 / Others

Simplifying key definitions in ISO 22301

Application Controls Audit

Others

Business Continuity Management, by nature is a simple and logical process. It is not rocket science. Anyone who knows about the business can write a business continuity plan with a little reading. The problem arises because those who know the business do not understand the terms and definitions used in a ‘formal’ BCP, and those who know the terms and definitions understand nothing about the business processes. This post aims at simplifying some of the key terms used in ISO 22301 (the latest standard for BCMS).  ACTIVITY and PROCESS: ISO 22301 defines activity as a set of processes and a process as a set of activities (Seriously! What were the brains who wrote the standard thinking?). These conflicting definitions are a hangover from BS 25999, the predecessor to ISO 22301. I cannot count the number of man-hours (a weird unit of time used by consultants and understood by nobody) I wasted trying to convince a client what the difference between an activity and a process is. Practically speaking, you need to identify the key product or service delivered by the organization and then identify what needs to be done to deliver the product or service. The reason to identify activities or processes is to simplify the process of creating a BCP. For example, if I am an insurance company, my key product is ‘insurance’. How do I write a BCP for that? I start breaking it down into say, (1) new business, (2) renewal, (3) claims and so on. This new list that I just created, is my list of processes OR activities that support my key product or service. Now it is easier to plan for continuity. You can ask, “What do I need to do to ensure that renewals continue in case of an IT disaster?”, etc. For your organization, identify your activities/processes or whatever and then use the same definition throughout. Do not get stuck with the theory of definitions. MTPD (Maximum Tolerable Period of Disruption) and MAO (Maximum Allowable Outage): MTPD was used previously in BS 25999, while MAO is a new addition. They both have the same definition word for word. It is almost like the writers of the standards stopped thinking and said, “We have a good definition for MTPD, let us use the same for MAO as well” MTPD and MAO is defined as the time it would take for an adverse impact (of unavailability of product/service) to become unacceptable. It basically means the outer limit of the unavailability of the product or service. For example, If I am an airline, and my key service of ‘Internet Booking’ is down, what is the maximum length of time I can tolerate it before having to cancel a flight? The length of time that I identify is my MTPD/ MAO. To get this data, talk to the owners of the key products or services. Keep asking them for alternatives. Your conversation would most likely go like this: Business Head (BH): “We absolutely cannot stop the manufacturing even for 10 minutes. We will lose x dollars!” You: “Why would you lose x dollars? Will the customer refuse to accept delivery, because you were delayed by extenuating circumstances?” BH: No, we have a force major clause in place. However, we are losing productivity. You: So, you are saying, aside for productivity loss, there would be no monetary losses? How much time can you hold on like that? BH: I guess a day or so, but we will have to be back after that. You: So, if you do not deliver in a day, you have some fines to pay and will end up losing a lot of money? … and so on till you arrive a reasonable MTPD/MAO. RTO (Recovery Time Objective): This is the period of time after the incident occurs within which you are looking to recover product/ service/activity. Simply put, this is a time that an organization before which it must resume functioning. This, obviously will be lower than your MTPD/MAO. The actual time taken would depend on the organization’s risk appetite, and cost benefit analysis for the product/service. RPO (Recovery Point Objective): This is the amount of data that the organization can afford to lose after an incident. For ex: If I am a bank, I may not be able to afford even a single transaction loss on my Internet Banking site, while I may be able to lose some information on new customer enquiries. This typically sets the organization’s backup policies. These were some of the most critical definitions in ISO 22301 and a practical look at them.  I have not covered all of them. Hope this is useful for those seeking to do a practical BCMS implementation.