Writing the scope statement for an ISO 27001 ISMS

One of the first steps in the implementation of an ISO 27001 information security management system (ISMS) is to identify and define the scope of the system. Equally, for those tasked with assessing or auditing an ISMS, reviewing the scope will be, or should be, a first step.

In this post I’ll be discussing the importance of properly scoping your ISMS and will try to identify some key points to consider when documenting the “scope statement” – the statement which will appear on your ISO/IEC 27001 registration certificate and is typically a short, one paragraph or less, summary statement.

[Note: This post refers to the now obsolete 2005 version of the standard.]

Requirement

Let’s start with the requirement, ISO/IEC 27001:2005 clause 4.2.1 a) which falls under the PLAN component of the standard, or “Establish the ISMS.”

What’s expected is a clear, concise, unambiguous and documented (4.3) description of what’s ‘in’ and what’s ‘out’ of your ISMS umbrella.

Let’s put it another way. If its in scope, it will be audited; if its out of scope, it will not. If its in scope, it is subject to ISMS Policies; if itsout of scope, its not. If they’re in scope, they will attend the Awareness Training; if they’re out of scope, they will not. Etc. You get the idea.

How we describe this will depend on what we have, but generally speaking we’re talking about: assets, processes, people, technology, and locations.

In determining and documenting the scope of your ISMS, the standard requires that you define it in terms of:

1. The characteristics of the business
2. The organization
3. Assets
4. Technology
5. Locations

Characteristics of the Business

What does this mean? Well, just that you should be describing what your business is all about and generally, how it works. What do you do – sell products? Provide a service? I think about this as being the elevator pitch given by the company’s best sales guy when you meet him for the first time. Or how the CEO would describe her organization.

If you’re a bank, you’ll be telling me all about current and savings accounts, credit cards, loans, and mortgages. If your a telecoms company, you’ll tell me all about your mobile services, roaming services, data and internet services. If you’re an airline, you sell tickets and fly people about. And so forth.

The Organization

How is it structured? What does it do? You might consider a description of your products and services, departments and their activities, as well as the org. chart under this heading.

Assets

Probably the next most important point in defining the scope is to have some clarification on what assets are covered by the ISMS. The definition of the term “asset,” according to ISO 27001, is: “Anything that has value to the organization.”

So under this topic, we probably want to identify major organizational assets such as: information, process, people, reputation, equipment, facilities.. to name a few. And if the main purpose of your ISMS is to protect a specific asset or asset group, it will be the place to emphasize those assets. So for example you might identify your scope as covering “all customer information.”

Technology

What type of technologies do you depend on and use to operate your business. Are you high-tech, or low-tech? Technology, of course, is not just a reference to computers and servers.

It is also common to include network diagrams to help to show the boundaries and logical interfaces under this topic.

Locations

Make reference to all of the business locations, for example, offices, workshops, branches, warehouses, and any other place of business. Are you situated in one location, or multiple locations? Local, regional, or international? You’ll want to identify and make reference to them all if your ISMS policies will be implemented at those locations.

Note that if you are planning to exclude any location from your scope, under most circumstances your head office will always have to be included.

You do not necessarily have to separate the information under each of these headings but the scope documentation that you produce should collectively reflect all of these points.

Scope Exclusions

The elements mentioned above are all a necessary part of your scope description and will tell us what is in scope. You may also choose to exclude parts of your business so long as this does not contradict your ISMS policy or hinder the ability of the ISMS to achievement your stated security objectives.

In short, if something doesn't need to be included as a part of your ISMS, then it can be excluded from the scope.

It is a common practice to exclude parts of the business from the ISMS scope (for certification purposes at least) as a larger scope equates to a lot more $$$ and effort and will also lead to bigger auditor bills. However, it is also a common practice to exclude parts of the business that should necessarily be included. This is often done either due to a lack of knowledge, or just a lack of management commitment for the implementation. Either way, its bad.

The argument goes like this: “its our ISMS and its our top management’s right to say what’s covered. Its not for the auditors to tell us what the scope should be.”

This is a fair enough argument, and perfectly correct. However, the point is that auditors are not telling anybody what the scope should be, they are reviewing the ISMS for conformity against requirements and judging its ability to achieve its intended purpose (the purpose is defined by top management of course). In this case, clause 4.2.1 a) is very clear about the scope being relevant and appropriate for the organization – “characteristics of the business” as described earlier. Therefore, any organization having a scope definition that does not in some way reflect core business is probably going to fall short in meeting this requirement and the good auditor will rightly challenge it.

Another common argument goes like this, ”Our data center is our most important asset with regard to information security because that’s where all our customer information is processed and stored.”

Again, probably true enough, but once more, your “data center” is probably not (for most companies) the topic of conversation for your sales people or your CEO – on its own, its not “characteristic” of your business – its simply a support service in most organizations no matter how big or important you think it is.

The standard is clear on this concept of being business-driven for a good reason, let’s see an example:- A training company wants to become certified to ISO/IEC 27001:2005, and their scope statement reads: “ISMS covering the information in the data center.” – Correct me if I am wrong, but I don’t see the sales guy or CEO of a training company explaining to customers the ins and outs of their data center. What the training company are doing in this example, is including the data center in the scope (because they believe its critical for information security), and excluding all of their training activities – it should be the other way around!

OK, so this is one view on how the standard requires the ISMS to be aligned with organizational goals and objectives. Let’s dig deeper and try to understand why this is so important.

Consider the security objectives and policy of this training company, it probably reads something along the lines of: “It is the intention of management to ensure the confidentiality, integrity, and availability of all information in relation to our training courses and examinations, and the personal information of our students.”

Now consider that in order to be effective and to achieve this goal you’re going to have to identify and manage risks at all points wherein that information is created, communicated, shared, used, stored, destroyed, etc.. within the business and across its boundaries. Most likely, you’ll find that numerous departments and functions within the training company are in some way involved in this process as well as external 3rd parties too.

Consider how and when the “personal information of .. students” comes to be in the hands of the training organization; probably, students are asked to fill up a form and send it in to the sales department. The sales department share this with finance so that the credit card can be charged or the customer invoiced, and then the data is entered into a database and the information is stored. Then the course instructor will be provided the necessary information in order that [s]he can conduct the course.. Clearly, in order to achieve the objective of “protecting information” the scope of the ISMS must include all of these process activities, people, technologies, locations and so forth for security to be effective. If anything in this process is exclude then you are not in a position to claim that you are in control. Out of scope equates to the fact that you did not do a risk assessment, did not train your people, and do not audit, to name a few.

Be careful about your exclusions as you also have to be able to provide a sensible business justification. Can you imagine when the auditor asks the CEO of our training company, “Dear CEO, you've told me that you are committed to ensuring the security of your students information, including their personal information and exam results – can you please explain to me why you have excluded your training department, personnel (who mark the exams and post the scores) and your instructors from the scope of your ISMS??”

Ok, a big mention there on exclusions, but vitally important!

Boundaries

In identifying the scope, we are also identifying the boundaries of the ISMS. A boundary is the demarcation point between the in-scope and out-of-scope processes of our ISMS. You may have functions, people, assets, departments that are a part of your organization but are out of scope of your ISMS as described previously under “exclusions.” Where there is an exchange of information between in-scope and out-of-scope elements, this is a boundary.

You also have relationships, partnerships, vendors, suppliers, and customers that are not a part of your scope (you can’t control them.. directly), but they must be identified. For example, where your network cabling terminates and connects to the external network owned by your telecoms provider, this represents a boundary. Or where your customers cross from the public walkway in to your shop, this is a physical boundary.

Identifying boundaries is important because you need to recognize that just because you can’t control what’s on the other side, doesn't mean you don’t have a responsibility for protecting your assets when they cross the line. Meaning, you should be conducting a risk assessment to identify the threats that those 3rd parties present to you – including any internal boundaries.

Once the relationships and risks are understood, you will need to implement some level of control to manage those risks. This is often achieved with some form of contractual agreement where you will stipulate your requirements for security and the protection of your assets while in the hands of the third party.

For example, if you use a 3rd party courier service to deliver your product to your customer. The courier service is an intermediate entity between you and your client and you’ll want to ensure the security aspects of the courier service when entrusting them with your company assets.

You may, for example, stipulate in the contract your right to audit the 3rd party to ensure that they are confirming to their contractual obligations.

Writing the scope statement

Now that we have some idea about what is involved in defining and documenting scope related information, let’s take a brief look at how we can approach writing a smart little certification scope statement, the one that will go on the registration certificate issued by your certification body. The following are just suggestions and tips on how to approach the task and what you might include.

1. Focus on high level processes, activities, services, and/or your major assets, rather than departments.

For example, saying that the ISMS covers “customer information” infers that any part of your business that touches or handles customer information is now within scope. There is no need to say instead, the ISMS covers “The sales department, the finance department, the customer services department…” due to the fact that  if any of those departments are a part of the process then they will be included.

Another example would be, “The ISMS at our bank covering loans, mortgage and accounts management.” – indicating all assets and resources relating to these banking products/services are within the scope of the ISMS.

2. Tack on some location information.

Adding to the activities or coverage of specific assets described above, it is a good idea to now state the locations that are covered. For example, “at our head office in ..” or if you have multiple locations, “at our London head office and all branch offices within the United Kingdom.”

3.  Consider your audience

Although this is not a policy statement or a news paper advertisement, it is still worth considering that your customer or client may see your scope statement – its going to be on your certificate. Most companies are in-fact looking to achieve certification for this exact reason, as a marketing or competitive edge, used to promote the worth of the company to clients.

This is another reason why it could be more useful to describe your scope in terms of coverage by product or service rather than departments and internal functions. A customer is more likely to read, understand, and appreciate a scope statement that says, “..covering customer information” or “.. covering our flight booking service..” than a statement that lists out your internal departments, like, “.. covers in the IT, HR, Finance, Sales departments and call center.”

4. Keep it clear, unambiguous, and accurate

The certification scope statement should be a simple statement that indicates what is covered, and in case of exclusion, what is not covered, and should not be misleading.

5. Statement of Applicability

Certification bodies may want you to include reference to the statement of applicability (SoA) too. This normally goes something like, “.. in accordance with the statement of applicability version 1.2 dated 25/12/2012.”

Examples

Now that we have some idea about writing the scope statement, let’s take a look at some real life examples. The following are randomly select from an online database [link removed as the website has unfortunately vanished] and are consistent with most of the suggestions in this post. Have a look and see what you think.

Axalto Canada

“The information security management system that covers the card service bureau activities including the customer data reception, the data processing, the smart cards and PIN mailers personalization, the packaging and shipment of personalized products and the key management of the Burlington Plant of Axalto Canada, Ltd. This is in accordance with the statement of applicability version B5.”

B6 Integrated Entertainment

“Provision of consulting activities through the innovation of special formats in media and contents as added value for the advertising investment management, including the handling of competing clients information”

Camelot Group Plc

“The management of information security in the operation of the National Lottery. This is in accordance with version 1.1 of the Statement of Applicability.”

Centrum Medyczne LIM Sp. z o.o.

“Provision of medical services (including medical data protection) by CM LIM Sp. z o.o. as well as by associated support processes carried out by CM LIM Invest Sp. z .o.o. and ACCMED Sp. z o.o. in accordance with the Statement of Applicability issue 3 dated 27.03.2007.”

Chiyoda Almana Engineering L.L.C.

“ISMS is applicable to the provisioning of Engineering, Procurement and Construction of Brown Field and Green Field Projects for clients from Oil & Gas, and Petrochemical Industries, in the State of Qatar as per the Statement of Applicability Version # 1, dated: 02 Nov-2011.”

Finally

Remember, ISO/IEC 27001 is a process-based standard, and as we've seen in some of the examples, to effectively protect our assets we need to consider the threats and vulnerabilities throughout the entire process in order to have confidence that our ISMS can and will be effective. So – think about what you’re actually trying to achieve in having an ISMS and make sure that your scope allows you to achieve it.

A note on the IT driven scopes. If you feel that IT really is the scope of your ISMS then my suggestion is to check out ISO/IEC 20000-1 for IT Service Management instead. This standard is specifically written for this purpose and will be far more useful than ISO/IEC 27001 as a management framework. The standard provides a suitable framework to manage all aspects of IT service which includes the information security commitment to users and the greater organization within the IT context.

Note that this post is based on ISO/IEC 27001 2005 requirements. I'll be updating with regard to the new 2013 version soon.