ISO 27001 & BS 25999

Have you ever tried to convince your management to fund the implementation of information security? If you have, you probably know how it feels – they will ask you how much it costs, and if it sounds too expensive they will say no.

Actually, you shouldn’t blame them – after all, their ultimate responsibility is profitability of the company. That means, their every decision is based on the balance between investment and benefit, or to put it in management’s language – ROI (return on investment).

This means you have to do your homework first before trying to propose such an investment – think carefully how to present the benefits, using language the management will understand and will endorse.

I’ll try to help you – the benefits of information security, especially the implementation of ISO 27001 are numerous. But in my experience, the following four are the most important:

1. Compliance

It might seem odd to list this as the first benefit, but it often shows the quickest “return on investment” – if an organization must comply to various regulations regarding data protection, privacy and IT governance (particularly if it is a financial, health or government organization), then ISO 27001 can bring in the methodology which enables to do it in the most efficient way.

2. Marketing edge

In a market which is more and more competitive, it is sometimes very difficult to find something that will differentiate you in the eyes of your customers. ISO 27001 could be indeed a unique selling point, especially if you handle clients’ sensitive information.

3. Lowering the expenses

Information security is usually considered as a cost with no obvious financial gain. However, there is financial gain if you lower your expenses caused by incidents. You probably do have interruption in service, or occasional data leakage, or disgruntled employees. Or disgruntled former employees.

The truth is, there is still no methodology and/or technology to calculate how much money you could save if you prevented such incidents. But it always sounds good if you bring such cases to management’s attention.

4. Putting your business in order

This one is probably the most underrated – if you are a company which has been growing sharply for the last few years, you might experience problems like – who has to decide what, who is responsible for certain information assets, who has to authorize access to information systems etc.

ISO 27001 is particularly good in sorting these things out – it will force you to define very precisely both the responsibilities and duties, and therefore strengthen your internal organization.

To conclude – ISO 27001 could bring in many benefits besides being just another certificate on your wall. In most cases, if you present those benefits in a clear way, the management will start listening to you.

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

Quite often I see information security policies written in too much detail, trying to cover everything from strategic objectives to how many numerical digits a password should contain. The only problem with such policies is that they contain 50 or more pages, and – no one is really taking them seriously. They usually end up serving as artificial documents whose sole purpose is to satisfy the auditor.

But why are such policies extremely difficult to implement? Because they are too ambitious – they try to cover too many issues, and are intended for a wide circle of people.

This is why ISO 27001, the leading information security standard, defines different levels of information security policies:

• High-level policies, such as the Information Security Management System Policy – such high level policies usually define strategic intention, objectives etc.
• Detailed policies – this kind of policy usually describes a selected area of information security in more detail, with precise responsibilities, etc.

ISO 27001 requires that Information Security Management System (ISMS) Policy, as the highest-ranking document contains the following: the framework for setting objectives, taking into account various requirements and obligations, aligns with the organization’s strategic risk management context, and establishes risk evaluation criteria. Such a policy should be actually very short (maybe one or two pages) because it’s main purpose is for top management to be able to control their ISMS.

On the other hand, detailed policies should be intended for operational use, and focused on a narrower field of security activities. Examples of such policies are: Classification policy, Policy on acceptable use of information assets, Backup policy, Access control policy, Password policy, Clear desk and clear screen policy, Policy on use of network services, Policy for mobile computing, Policy on the use of cryptographic controls, etc. Note: ISO 27001 does not require all these policies to be implemented and/or documented, because the decision whether such controls are applicable, and to what extent, depends on the results of risk assessment.

Because such policies should prescribe more details, they are usually longer – up to ten pages. If they were much longer than that, it would be very difficult to implement and maintain them.

In other words, information security is too complex an issue to be defined in a single policy – for different aspects of ISMS and different “target groups” there should be different policies. Middle-sized organizations usually build up to fifteen policies for their ISMS.

One could argue that this number of policies is nothing but overhead for a company. I would certainly agree if such policies are written only with the certification audit in mind – such policies will bring nothing but more bureaucracy. However, if a policy is written with the intention of decreasing the risks, then it will most probably show its value – if not right away, then probably in two or three years, by decreasing the number of incidents.

If you heard that ISO 27001 requires many procedures, this is not quite true. The standard actually requires only four documented procedures: a procedure for the control of documents, a procedure for internal ISMS audits, a procedure for corrective action, and a procedure for preventive action. The term “documented” means that “the procedure is established, documented, implemented and maintained” (ISO/IEC 27001, 4.3.1 Note 1).

Note: in this blog post I will not write about other mandatory documents like ISMS Scope, ISMS Policy, Risk Assessment Methodology, Risk Assessment Report, Statement of Applicability, Risk Treatment Plan, etc. – here I focus on procedures only.

The procedure for the control of documents (document management procedure) should define who is responsible for approving documents and for reviewing them, how to identify the changes and revision status, how to distribute the documents, etc. In other words, this procedure should define how the organization’s bloodstream (the flow of documents) will function.

The procedure for internal audits must define responsibilities for planning and conducting audits, how audit results are reported, and how the records are maintained. This means that the main rules for conducting the audit must be set.

The procedure for corrective action should define how the nonconformity and its cause are identified, how the necessary actions are defined and implemented, what records are taken, and how the review of the actions is performed. The purpose of this procedure is to define how each corrective action should eliminate the cause of the nonconformity so that it wouldn’t occur again.

The procedure for preventive action is almost the same as the procedure for corrective action, the difference being that it aims at eliminating the cause of the nonconformity so that it wouldn’t occur in the first place. Because of their similarities, these two procedures are usually merged in one.

But why is it that ISO 27001 requires documented procedures that are not related to information security, while security procedures are not mandatory?

The answer is in risk assessment – ISO 27001 does require you to perform risk assessment, and when this risk assessment identifies certain unacceptable risks, then ISO 27001 requires a control from its Annex A to be implemented that will decrease the risk(s). The control can be technical (for instance, anti-virus software for decreasing the risk of malicious software attack), but could also be organizational – to implement a policy or a procedure (for instance, implement a back-up procedure). Therefore, the procedures are becoming mandatory only if the risk assessment identifies unacceptable risks.

One important note though – as opposed to the four mandatory procedures which must be documented, the procedures arising from controls in Annex A  do not have to be documented. It is up to the organization to estimate whether such a procedure is to be documented or not.

You could consider the four mandatory procedures as the pillars of your management system (together with the security policy) – after they are firmly set in the ground, you can start building the walls of your house. This becomes obvious when you look at other management systems – the same four procedures are mandatory there, too – in ISO 9001 (quality management systems), ISO 14001 (environmental management systems), and BS 25999-2 (business continuity management systems). As a consequence, you can use these procedures as the main link between different management systems if you want to develop the so called “integrated management system”.

If you started implementing business continuity management, probably the biggest challenge you are facing is writing the business continuity plans.

Why is it so difficult? Well, you have to think of various scenarios under which a disaster (or other kind of disruption of business activities) can occur, and you have to think of a way how to handle such exceptionally rare but potentially catastrophic incidents.

The problems that people who write such plans usually have include what the plan should contain (what are the main elements), how long (how detailed) it should be, what steps to include etc.

One of the best solutions to all these dilemmas is using the BS 25999-2 standard, which together with BS 25999-1 defines a framework as to how the plans should be written.

According to those standards, the business continuity plans should consist of (1) incident response plan, and (2) recovery plans. An incident response plan is usually a single plan written for the whole organization, and describes what has to be done immediately after a disaster occurs – reducing the effects of the incident, communicating to emergency services, evacuating the building, gathering at assembly points, organizing transport to alternative locations etc.

Recovery plans are usually written separately for each critical activity, and the steps to be included in the recovery plans are usually the following: when and how to communicate with various stakeholders (employees and their families, shareholders, customers, partners, government bodies, public media etc.), how to assemble the team, how to recover the infrastructure, how to check whether the applications are functioning and whether the access rights are appropriate, how to check which data is missing or has been corrupted by the disaster, how to recover the data, and how to decide when the recovery is completed so that normal operations can begin.

Disaster recovery plans (the recovery plans of ICT infrastructure) are the ones to be written with great care because they should describe how to set each system running within the recovery time objective of a particular critical activity. This is usually done by writing a detailed recovery plan for each system to be recovered.

The rule of the thumb says that the level of details in all these plans should be such that other employees (or external staff) should be able to execute the plan if the people working with that critical activity are not available. Therefore, use common sense when writing the plans – they should be understandable to anyone, not just you.

In my experience, the biggest challenge when writing these plans is that employees have to face something completely different, something they never had to think about. To overcome such a problem it is best to organize a workshop where, with or without a moderator, they could share their views about what would happen if… , how to react when…, etc.

The truth is, the mere fact that your employees have started thinking about business continuity is 50% of the job done – with such an approach, the results of business continuity planning will be much better.

Why is it that ISO 27001 and BS 25999-2 put such an emphasis on the control of documents? Both standards define very strictly how the documents must be managed, and require that the organization must have a documented procedure for managing documents – even worse, you won’t get certified unless you have such a procedure.

Documents can be in various forms – paper documents, text or spreadsheet files, video or audio files etc. Not only must an organization manage internal documents (for example, various policies, procedures, project documentation etc.), but also external documents (for example, different types of correspondence, documentation received with equipment etc.). In other words, managing the documents is quite a complex and comprehensive task.

So why is it important to manage those? Well, did you ever find yourself in a situation when you didn’t know where to find some important document? Or you found out that your employees were using a wrong (older) version of a procedure? Or some employees didn’t receive an important procedure at all? Or perhaps it wasn’t clear what was the version of this procedure? Or some confidential document was distributed to wrong people? If you never found yourself in those problematic situations, you probably did experience this one – your procedures are simply not up-to-date.

If you don’t have a systematic approach for managing your documents, you will probably recognize yourself in some of these situations – therefore, ISO 27001 and BS 25999-2 require organizations to introduce such a systematic approach by writing down a procedure for document management.

This procedure must clearly define responsibilities for the documents – who can approve them, how they are distributed and archived, how they are kept up-to-date, which versioning system is in use, how you track changes to documents, what you do with external documents, etc.

Since document management is such an essential thing, be sure that the certification auditor will not only look for such a procedure, but also examine whether your documentation is really managed as you have defined in your document management procedure. Introducing this procedure will probably mean that you will have to change your system for handling documents, that you will have to store documentation on your intranet or implement a more complex document management system, and that you will have to organize the archive for paper documents.

When you start implementing ISO 27001 / BS 25999-2, you start seeing the importance of writing things down, but you also see that those written things must be organized unless you want to lose control over them. The documents are in fact the bloodstream of your management system – take good care of it if you want your system to remain healthy.

If this is the first time you have come across the notion of internal auditor, you are probably puzzled – Why would I need another control? Who is going to pay for it? Who should I employ to do it? It is such a waste of time…

Well, it doesn’t have to be so bad – besides complying with ISO 27001 & BS 25999-2 standards, internal audits could be quite useful for your other business affairs (whether related to information security & business continuity or not).

The point with internal audits is that they should discover problems that would otherwise stay hidden and would therefore harm the business. Let’s be realistic – it is human to make mistakes, so it‘s impossible to have a system with no mistakes; it is however possible to have a system which improves itself and learns from its mistakes. Internal audits are a crucial part of such a system.

There are a few ways to perform internal audit:

a) Employ a full time internal auditor – this is suitable only for larger organizations who would have enough work for such a person (some types of organizations – e.g. banks – are obliged by law to employ such functions)

b) Employ part time internal auditors – this is the most common situation – the organizations use their own employees to perform internal audits alongside their regular job functions. One important thing to pay attention to: in order to avoid conflict of interest (the auditors cannot audit their own work), there should be at least two internal auditors so that one could audit the regular job of the other.

c) Employ internal auditor from outside of the organization – although this is not a person employed in the organization, it is still considered internal audit because the audit is performed by the organization itself, according to its own rules. Usually this is done by a person who is knowledgeable in this field (independent consultant etc.).

However, from my experience as an auditor, the sad truth is that most of the organizations perform internal audits just to satisfy the certification body. The result of such internal audits are a few non-conformities which do not get deep into the real problems of information security management system (ISMS) or business continuity management system (BCMS). This is a waste of time – if the companies have invested time of their internal auditors to perform such jobs, they should gain some benefits out of it.

But how then to approach internal audits in the right way – here are some thoughts:

1. The management should view the internal audit as one of the best tools to improve the system, not only as a means to get certified.
2. The internal auditor should be qualified – this means he/she must have experience in information security, information technology and auditing techniques. It does not mean that the auditor must be an expert in those fields.
3. The internal audit should be performed in a positive way – the aim should be to improve your system, not to blame the employees for their mistakes.

On the positive side, as a certification auditor I did see some organizations performing internal audits in a right way. Although their employees did feel a little uncomfortable about someone checking their activities, very soon they saw the benefits of such approach – problems became transparent, and were resolved rather soon.

You are thinking about implementing the business continuity management/BS 25999-2 standard? But then you hear it will cost you a lot? It probably will cost you, but not necessarily as much as you thought – this you can solve with good business continuity strategy.

Business continuity strategy, as defined in BS 25999-2 standard, is an “approach by an organization that will ensure its recovery and continuity in the face of a disaster or other major incident or business disruption”. Therefore, the point is to prepare yourself in the best possible manner to counteract a disaster if such would occur. This preparation can include organizational measures (drawing up plans, making contracts with suppliers/partners, exercising, reviewing, awareness raising, etc.), and measures including investment in equipment, infrastructure etc.

Time is a very important factor in recovery – if you do not recover your business in time, you will probably lose your customers and consequently lose your business as well. So the business continuity strategy must set the recovery time objective (RTO) for each of your critical activities, whereas RTO can be different for each of those.

One important consideration: the shorter the RTO, the bigger the investment you will need – for instance, if you want to recover your data centre in less than one hour, you will have to invest in an alternative location almost the same equipment as in the primary location; on the other hand, if you want to recover your data centre in two weeks, the investment will be much lower because it would be enough to store the backup tapes at the alternative location, allowing you two weeks to obtain the necessary equipment. All this means that your RTO must not be too long, but not too short either.

Once the RTO is set, you will still need to make some investment; however, with a good business continuity strategy you will be able to decrease that investment, while still being able to recover your critical activities within the recovery time objective. Here are some examples:

• you might not need your own data centre at an alternative location – in most countries you can rent such a location from a specialized company, which means you don’t need to invest in infrastructure, maybe not even in equipment or software,
• you might not need offices at an alternative location – employees who do not have to meet customers face-to-face can work from their homes,
• you might not need an alternative location at all if you have other business units at different locations which could take over the critical activities affected by the disaster,
• you might not need to purchase equipment in advance if you can find the supplier that could guarantee the delivery of equipment within your RTO,
• etc.

In all these examples you will need to increase your organizational capabilities, but if you want to save some money, it sure is something worth thinking about.

You have already implemented ISO 9001? You have heard that ISO 27001 might be a good idea? But how can something that has to do with quality help you implement information security?

It can, more than you may think. ISO 9001 specifies how the quality management systems (QMS) must look like, while ISO/IEC 27001 specifies the information security management systems (ISMS). Therefore, the “management systems” part is the same – so what is it actually?

The philosophy of management systems has grown from the theory developed by W. Edwards Deming during the second half of 20th century, and is based on the Plan-Do-Check-Act cycle. Basically, this cycle consists of the following: in the Plan phase you have to plan what you want to achieve with the management system, in the Do phase you implement it, in the Check phase you constantly monitor whether you have achieved what you planned, and in the Act phase you make improvements, i.e. fill the gap between what you have planned and what you have achieved.

Although this cycle was invented with quality management in mind, it was established as a foundation for all other management systems – information security (ISO/IEC 27001), environment (ISO 14001), business continuity (BS 25999-2), etc. It means that some of the elements you have implemented for the quality management system according to ISO 9001 you can use for the information security management system as well – here is the list:

• Document management – the procedure used for document management in QMS can be used for the same purpose in ISMS, with only minor adjustments
• Internal audit – the same procedure can be used for both QMS and ISMS, although the internal audit itself would usually be done by different people since it is not very likely that one person would have deep enough knowledge of both information security and quality
• Corrective and preventive actions – the procedure used for QMS can be used for the same purpose in ISMS, although it is likely that different persons will be solving issues related to QMS or ISMS
• Human resources management – the same cycle of HR planning, training and evaluation is used for both management systems; naturally, the difference is in the profile of needed skills and knowledge
• Management review – the principles for management review are the same for both management systems; although it would not be recommendable to perform both reviews in parallel, management will already be accustomed to making decisions in QMS, so they will have better understanding of how to make decisions in the context of ISMS
• Setting the business goals and tracking whether they have been achieved – the same mechanism is laid down in both standards, so management will be used to such systematic planning

Therefore, if you have already implemented ISO 9001, you will have an easier job implementing ISO 27001 (and vice versa) – you could save up to 30% of time. Further, you will have cheaper certification audits since certification bodies are offering the so called “integrated audits”, which means they will do both ISO 9001 and ISO 27001 in the same audit, charging you a smaller fee compared to separated audits.

If your QMS is functioning well, you will find your ISMS project developing rather smoothly – management will have better understanding of potential business benefits, while all organizational units will be accustomed to the necessity of defining precise procedures, responsibilities and documentation.

Having a QMS indeed provides very good foundation for information security – if you already have ISO 9001, do give a serious thought to ISO 27001.