Getting started with ISO 27001

The first step toward ISO 27001 (even before blowing your budget on the PDFs) is to establish and heartily commit to the reasons you're pursuing certification. It's going to take a lot of man hours, potentially ruffle a lot of feathers within your organization, and cost you, depending on the size and complexity of your company, likely tens of thousands of dollars -- more if you hire consultants to help with the effort. If you can't explain in your sleep why it's something you need to do, you won't get the buy-in from both upper management and the support you will need from staff that will end up following a more complicated set of procedures that you will need to be successful.

Will being certified help you gain or retain customers? Will it make your products or your production environment more secure? Will it help you discover and assess risks you might not have previously considered? Will it ensure that your technical staff follows best practice with respect to system security? Will it ultimately make you more secure? Whatever the reasons, you need to be able to express them simply and convincingly.

Of course, this all means that you will have to gain clear insights into what the standard is about. Fortunately, you can get some high level information on the ISO 27001 standard from this introduction and a useful flow chart of the certification process here. There are also a number of, albeit overly priced, books available that can give you insights into what to expect.

Before you start spending a lot of money or strong-arming your compatriots at work to support the cause, you need to make sure that upper management backs you unwaveringly. Endorsement from the highest levels in your organization is going to be critical if you're going to reach certification. It's the only way that you're going to overcome the resistance you'll inevitably get from all the hard working people in your organization who will predictably feel that the extra procedures the standard imposes on them are going to make it impossible for them to meet their already threatened production deadlines. You need to reassure them that the extra effort is going to pay off for the organization and for them.

At this point, you will also need to figure out who will be leading your certification efforts. If you can gather a team of people who represent different parts of the organization, you will more likely avoid "NIH" (not invented here) resistance from groups who feel they have no say in how the new ways of managing security are being defined. In addition, having representatives from different parts of the organization will be a great help when you get around to identifying the assets you are ultimately trying to protect and the procedures currently in place to safeguard them.

The question of whether you need outside help in the form of a consulting firm depends to a large degree on whether your implementation team will be able to command the cooperation that will be required. If bringing in some highly paid consultants is the only way to get the attention you are going to require, then it might be worth what it will cost you to bring in some help. If you go this route, however, make sure the consultants you hire are well familiar with the ISO 27001 process and have supported at least one certification. Having gone through the process just once will help ensure that they are able to make the best use of each stage in the process.

One of the initial steps is to outline your high level security policy -- the over-arching document that outlines your major security objectives and goals, such as how and how often you will review your ISMS and whose approval will be required to make changes. In general, it's a good idea to avoid involving the upper brass in every security decision. They are not likely going to want to be involved in decisions such as how you construct password policies. Involving them in establishing the basic goals and structure, on the other hand, is absolutely critical. Issues such as who reviews and approves policy changes need to be addressed up front.

The next thing you need to do is scope the effort. You need to decide whether you're going after certification for your entire organization or one business unit or product. This decision often depends on how large and how homogenous your organization is. If you're a complex organization with largely independent business units, each with its own way of managing systems and information resources, going after a "whole organization" certification will likely be tough. You're basically going to be asking a lot of people to switch to a uniform, possibly more cumbersome, method of managing their systems and data.

Before you reach this "how much, how far" stage, you will need to look over the standard itself and gain a solid grasp of what will need to be done. You will have to establish and then grow your "ISMS". It will eventually embody all the policies, procedures, processes, practices, resources and structures that will come into play as you move toward certification.

The ISO 27001 standard includes the “Plan Do Check Act” model. This cycle is not altogether different from what I was taught decades ago. You make a plan, you work the plan, and you check that the plan worked. No technical task is complete until you verify its success. But the PDCA model goes further by sticking the tail back into the mouth. After you make a change, you make sure the improvement works its way back into the overall process. So, you create your ISMS (plan), operate under the new rules (do), review the process to ensure it’s working (check) and then use what you’ve learned to improve the process (act).

The next stage -- performing a risk assessment for all identified assets within the scope of your ISO 27001 efforts -- will be covered next week.