Becoming Resilient – The Definitive Guide to ISO 22301 Implementation (eBook)

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...