1
INTRODUCTION
1.1 Why business continuity?
Meet Jack. Since his early childhood, Jack has spent most of his free time on computers; he dreamed of becoming a programmer once he grew up. His dream came true – during his last year in university he came up with an idea for a groundbreaking software that will help banks serve their clients better. After graduating, he borrowed some money, invited two of his friends to work for him, and started developing the business. After one year he became profitable, and after three years he already had 25% of the market share and a nice team of 10 people.
Only a couple of days after he made a big investment into new equipment and development tools, he came one morning to his office, only to find the door smashed – since they were the only company in the building, the thieves had enough time to take all the valuables from the office, including computers. All this wouldn’t be so bad if they had a backup; they surely did make the backup, but because of the banking regulations they couldn’t store their backup in the cloud, so they backed up all the data on disks which they archived next to the servers – these disks were also stolen.
He went bankrupt – all the code they were developing for years was lost, as well as all the client data. Since he asked his parents to pledge their property as collateral for his bank loan, they were forced to sell their family house. Jack was never able to get into business again.
Moral: it doesn’t take a tsunami to destroy your business, let alone hackers – it can be a much more prosaic reason like described above. But most of all, it is the “It is not going to happen to me” syndrome that kills companies and destroys lives.
1.2 Why is planning important?
Meet Pamela. She was more prudent that Jack, and made sure her marketing company kept her backup in two different locations. Not only that, her company went a step further and developed a mini disaster recovery site where they installed all the spare servers that could be used in case their main servers (i.e. primary location) became unavailable.
On a nice sunny day a fire broke out, spreading so rapidly so that it wasn’t possible to save any of the computers or the documentation. Pamela was thinking rapidly – “Luckily, no one was hurt, and we do have everything we need at a disaster recovery location.” So she ordered everyone to go to this secondary location; but there, chaos ensued. Everyone started to panic, and no one knew what to do or what to start with: IT guys were not sure which system they should recover first; key account managers didn’t know which clients to call and what to tell them; office administrators knew that part of the paper documentation was missing, but weren’t sure how to recover it. No one knew how quickly they needed to respond to their customers. As if that wasn’t enough, they couldn’t recover one of the servers because it turned out that the only person who knew the root password to that server happened to be on a vacation in South America, unreachable by cell phone.
The result: Pamela’s company managed to recover their operations, but it took a full week. By then, 80% of their clients had left them.
Moral: technology is an important element of business continuity, but certainly not sufficient; something else needs to exist: knowledge of the business needs, a clear course of action on what needs to be done, and people who know how to react.
If I may use a military parallel here, business continuity is for a company what an army is for a country – it may cost a lot, not many people see its purpose, it takes a lot of training to maintain it, it is (hopefully) used very rarely, but when it is used it saves the country.
1.3 What business continuity is not
There are many myths about business continuity management, and without clearing up these fallacies it would be very difficult to understand what business continuity is all about:
Business continuity is a job for IT guys. Very often the perception of business continuity is that it is enough to make a backup, a few plans on how to restore your main servers, and – if you’re a bit more ambitious – to build an alternative data center at a remote location. This normally is called disaster recovery, and while all that is quite often necessary (and should be a part of business continuity management), it is by no means enough. In case of a disruption you need not only your information systems operational, but also your people to work with these machines. After all, people are the ones who make things happen, not the computers – otherwise, your company would already consist only of computers, with no human beings employed.
Business continuity equals business continuity plans. “It is enough to write detailed plans, and this is how you will be able to counteract all the tsunamis, hurricanes, thefts and hackers.” Really? And how would you know which of your systems, and which of your processes you should recover firsts? And how quickly do you need to recover certain processes or systems? (Your plan will differ very much if you have to recover within four hours as opposed to four days.) Where would you continue your operations if your main site was unavailable? Which IT systems, which employees, which information would you need at this alternative site? Without having very clear answers to all of these questions before you start writing your plans, your plans will be unusable. Therefore, you need to analyze your needs and make some strategic decisions, but you also need a system to pull all these things together.
Business continuity is a one-time job. “We’ll implement this ISO 22301, and we’ll be fine – after we’re done, we’ll move on to something else.” But what will happen if you implement some new products or some new information systems? What if one of your employees leaves the company and you had written the phone number of this employee in the business continuity plan? Obviously, without maintaining the plans they will become useless very quickly. But even worse: do you really expect these plans to work perfectly since they have never been tried in a realistic situation? I must admit that with all my experience I never managed to write a perfect business continuity plan right at the start, because this is simply impossible; the only way to get around it is to test how those plans would perform in some realistic situations – this is why exercising and testing are important. What I’m trying to say is that once your ISO 22301 implementation project is finished, this doesn’t mean that you can forget about your business continuity – the care and maintenance of your business continuity should become a part of your day-to-day operations, and you should have at least one person who will coordinate the business continuity activities.
1.4 ISO 22301 puts it all together
What I like about ISO 22301 is that it has this comprehensive, and at the same time, balanced approach to building up a business continuity management system (BCMS) – it not only gives a perfect balance between the IT and business sides of the organization, it also requires the direct involvement of top management in the business continuity implementation, ensuring that business continuity not only has all the required resources, but that it also supports the strategic objectives of the company.
ISO 22301 explains how to structure the business continuity plans, but also all the other business continuity elements – business continuity policy, risk assessment, business impact analysis, business continuity strategy, exercising and testing, etc. It gives you the tools to permanently review the whole system and improve it whenever it is possible; it provides you with a system on how to train your employees and make them aware of the importance of business continuity; it includes the requirements on how to plan the resources, including financial resources.
As I will explain later on in greater detail, it gives a perfect implementation path – it is written in such a sequential way that you just have to follow the structure of the standard to implement your BCMS in the most logical way.
Finally, it provides a management framework on how to evaluate whether business continuity has achieved some business value – by setting objectives and measuring whether these objectives are fulfilled. You may be surprised, but I like this part very much – this is because if the management sees concrete benefits in business continuity, it is the best way to ensure the long and successful life of business continuity in your company.
1.5 Who should read this book?
This book is written for beginners in this field – I structured this book in such a way that someone with no prior experience or knowledge about business continuity can quickly understand what it is all about, and how to implement the whole project. So if you are an IT administrator, information security professional, quality manager, or a project manager with a task to implement ISO 22301 in your company, this book is perfect for you.
However, I think this book will be quite useful for consultants, also – being a consultant myself I have tried to present in this book the most logical way to implement a Business Continuity Management System, so by carefully reading this book you will gain the know-how for your future consulting engagements.
Finally, I think this book can be a kind of a checklist for experienced business continuity practitioners – I’m saying this because I’ve had many such experienced professionals in my ISO 22301 courses, and although they didn’t learn anything especially new, they were thankful for getting a comprehensive and structured view of how business continuity should be implemented. And this is exactly how this book is written.
1.6 How to read this book
I’ve tried to make this book as easy as possible to read and to use in practice:
- When certain sections of this book are related to a particular clause in the standard, then the standard clause is written in the title of that section.
- Since Chapters 5, 6 and 7 describe the implementation of particular clauses of the standard, each section has these elements:
- Purpose – describes briefly why such a clause exists and how it can be used for your BCMS
- Inputs – which inputs you need to have in order to implement the requirement
- Options – which options you should consider when implementing the requirement
- Decisions – which decisions you need to make to move forward
- Documentation – describes how to document the requirements of ISO 22301
- Documentation tip – briefly summarizes the documents you need for each requirement
- You’ll find lots of useful information in the appendices – glossary, implementation diagram, checklist of mandatory documentation, etc.
1.7 What this book is not
This book is focused on processes, project management, documentation, etc.; however, it is not focused on technology. This book won’t explain which kind of backup systems you need to purchase, which communication technology you should use, or which kind of servers to install at a disaster recovery site. However, this book will give you a methodology on how to get all the inputs so that you can make relevant technology decisions – how to determine which critical data you have and how often it needs to be backed up, what amount of data you need to communicate and to whom, how distant your alternative site should be, and how quickly you need to restore your IT and communication systems.
This book won’t give you finished templates for all your policies, procedures and plans; however, this book will explain to you how to structure every document required by ISO 22301, which options you have for writing such documents, who should be involved in writing and decision making related to each document, where to find the inputs, etc.
This book is not a copy of the ISO 22301 standard – don’t expect that by reading this book you won’t have to read the standard. This book is intended to explain to you how to interpret the standard, and how to implement every element of the standard; however, this book is not a replacement for ISO 22301 itself.
So, please don’t make the mistake of starting an implementation of a standard without actually reading it – I think you’ll find the ISO 22301 standard and this book to be the perfect combination for your future work. You can purchase the standard at the ISO official website.
So, what is this ISO 22301 all about?
2
A FIRST GLANCE AT ISO 22301
Before we dive into the implementation of this standard, let’s learn some basics first.
2.1 International reach
The standard was published by the International Organization for Standardization (ISO) in May 2012 – the full name of this standard is ISO 22301:2012 Societal security – Business continuity management systems – Requirements. Being an ISO standard means it had to go through a voting process – members of ISO are national standardization bodies, and for a standard to be published the majority of members had to vote for this standard. In effect, this means that most of the countries in the world have accepted this as the leading international standard.
This is particularly obvious with respect to BS 25999-2 – this British standard was a predecessor of ISO 22301, and when ISO 22301 was published, the British Standards Institution withdrew BS 25999-2 and accepted ISO 22301 as a British standard, so in the UK it is now called BS ISO 22301. It is expected that other countries that have their own national business continuity standard will follow the example of BSI.
It is also good to know how this standard was developed: ISO 22301 (as well as other ISO standards) was written by leading experts in this field – you could consider it to be a consensus of leading business continuity practice; therefore, this is not a lone product of one author only.
One of the features that differen...