ISO 27001 & BS 25999

You probably knew that the first step in ISO 27001 implementation is defining the scope. What you probably didn’t know is that this step, although simple at first glance, can sometimes cause you quite a lot of trouble. Namely, a lot of companies are trying to decrease their implementation costs by narrowing the scope, but they often find themselves in a situation where such a scope gives them a headache.

So, where is the problem?

The problem when the ISO 27001 scope is not the whole organization is that the Information Security Management System (ISMS) must have interfaces to the “outside” world – in that context, the outside world are not only the clients, partners, suppliers etc., but also the organization’s departments that are not within the scope. It may seem funny, but a department which is not within the scope should be treated in the same way as an external supplier.

For instance, if you choose that only your IT department is within your scope, and this department is using the services of the purchasing department, the IT department should perform risk assessment of your purchasing department to identify if there are any risks for the information for which the IT department is responsible; moreover, those two departments should sign terms and conditions for the services provided.

Why is such an overhead necessary? You have to put yourself in the certification body’s shoes – it must certify that within your scope you are able to handle the information in a secure way, while it cannot check any of your departments outside the scope. The only way to handle such a situation is to treat such departments as if they were external companies. (Please note: certification auditors never like a narrow scope.)

This is not where the trouble stops. Sometimes, a narrow scope is simply not possible, because there is no interface with the outside world. For instance, if employees from both within the scope and outside the scope are sitting in the same room, such a scope is hardly feasible; if both the employees within and outside the scope use the same local network (with no segregation) and have the access to various network services, such a scope is definitely not possible – there is no way you would be able to control the information flow only inside the scope.

The point here is – narrowing your ISMS scope is sometimes impossible, and in most cases it will bring you unnecessary overhead. Therefore, what initially didn’t seem like a good solution, might be the optimal one after all – try to extend your scope to the whole organization. The rule of the thumb is: if your organization has no more than a few hundred employees, and one or just a few locations, the best thing would be for the ISMS to cover the whole organization.

On the other hand, if you really cannot cover the whole organization with your ISMS scope, try to set it in an organizational unit which is sufficiently independent; try to solve the relationships with other organizational units outside the scope by determining their service through internal documents (policies, procedures etc.) that would serve as “agreements” – in such a way you could document those organizational unit’s obligations in a manner that is usable in daily operations.

There you go – you have solved the first step in your ISO 27001 implementation.

You have probably wondered why you have to perform business impact analysis (BIA) once you already did the risk assessment. You identified all the risks, didn’t you? Spent quite a lot of time analyzing your company, why then yet another analysis?

Well, the purpose of BIA is different. In business continuity everything is about time – it doesn’t matter if you can recover your business activities if it isn’t achieved in reasonable time. “Reasonable” is what the BIA has to determine – its main purpose is to find out what the recovery time objective is for each critical activity within an organization.

This kind of analysis is often taken lightly – first, the company is usually not aware that wrong results could incur unnecessary expenses or create an inadequate business continuity strategy, but also the effort needed to perform BIA is underestimated.

Therefore, here are some tips that will make your business impact analysis more effective:

Treat it as a (mini) project. Define the person responsible for its implementation and his or her authority; define the scope, objectives, and time frame.

Do your homework, prepare a good questionnaire. A well structured questionnaire will save you quite a lot of time, and will make the results more accurate. BS 25999-1 and BS 25999-2 standards will give you a fairly good idea about what it must contain – among other things, you have to identify impacts resulting from disruptions and determine how these vary over time, identify the resources needed for recovery etc. It is a good practice to use both qualitative and quantitative questions to identify impacts.

Define clear criteria. If your interviewees have to answer questions by assigning values for instance from 1 to 5, be sure to explain exactly what each of these five marks means. It is not uncommon that the same event is evaluated as catastrophic by the lower-level employees, while top management assesses its impact as moderate.

Collect data through human interaction. The best results are achieved when someone skilled in business continuity performs an interview with the person responsible for a critical activity. That way a lot of unresolved questions are cleared, and well-balanced answers are achieved. If interviews are not feasible, do at least one workshop with all the participants so they can ask everything that is troubling them. In other words, don’t just send them the questionnaires and scold them if they didn’t send them back in time.

Determine the recovery time objectives only after you have identified all the interdependences. For instance, through the questionnaire you might conclude that for critical activity “A” the maximum tolerable period of disruption is 2 days; however, the maximum tolerable period of disruption for critical activity “B” is 1 day and it cannot recover without the help of critical activity A. This means that the recovery time objective for “A” will be 1 day instead of 2 days.

In my experience, the results of BIA are often unexpected – usually the recovery time objective is longer than it was initially thought, and BIA reveals dependencies on some resources that are actually a single point of failure. But the best thing of all, business impact analysis is the most effective way to get people thinking about the unexpected – by creating such awareness, you increase the chances of your company’s survival.