Scoping Out: An ISO 27001 Certification

June 8, 2017 TERRY OBRIEN

 

Organizations, regardless of type, size, or nature, possess information assets that need to be protected.  Fortunately, a globally recognized standard is available to assist organizations in managing the security of their information assets. Of these, the ISO/IEC 27001:2013 (ISO 27001) is the most well-known standard in the 27000 family—it provides requirements for the implementation of an information security management system (ISMS) and a systematic approach to managing sensitive company information so that it remains secure.

The ISO 27001 standard is comprised of requirements that can be applied to any organization regardless of type, size, or nature.  Given its widely applicable approach, this standard cannot be overly prescriptive; rather, it defines the general requirements and control criteria, but it does not specify how an organization can design or implement these requirements or controls.  As such, each organization can address these requirements differently based on their needs, objectives, processes in place, and security requirements and, correspondingly, ISMS scope statements differ as they are tailored to the uniqueness of the individual organization.

When performing an ISO 27001 certification engagement, I find it beneficial to begin by discussing the scope statement with the client.  While the scope statement itself is concise, it is actually the result of numerous considerations that provide insight into the company.  A conversation on the scope can detail the organization’s product/service, the reasons they are in business, managerial involvement, the supporting infrastructure, who their customers are and what they expect, and so on.  Scoping is fundamental to the ISMS and the ISO 27001 certification process—broadly put, it is intended to concisely sum up the objective of the ISMS and is documented on the final certificate.

Scoping requirements are included within clause 4 of the ISO 27001 standard - see below:

4.3 Determining the scope of the information security management system

The organization shall determine the boundaries and applicability of the information security management system to establish its scope.

When determining this scope, the organization shall consider:

a. the external and internal issues referred to in 4.1;

b. the requirements referred to in 4.2; and

c. interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations.

Now, to better understand the potential scoping elements, we need to consider the cross references mentioned above.

4.1 Understanding the Organization and Its Context

As previously stated, clause 4.1 states “the organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its ISMS.” In more colloquial terms, clause 4.1 requires the organization to identity and understand the uncertainties, both internal and external, that could impact the organization’s ability to achieve its objectives.  To identify internal issues, an organization should consider the governance structure, company’s culture, contracts in place, infrastructure, and available resources.  In identifying external issues, the influence of legal and regulatory requirements, external stakeholders, and environmental factors (political, economic, social, and competitive) should be considered. If this reads like the beginning of a risk assessment, that interpretation is not far off; clause 6.1.1 of ISO 27001 requires consideration of clauses 4.1 and 4.2 when determining the risks that need to be addressed.

4.2 Understanding The Needs and Expectations of Interested Parties

After the external and internal issues have been considered, clause 4.2 requires the organization to determine the interested parties and their requirements in relation to the ISMS.  Some commonplace parties include top management, shareholders, employees, customers, and governments.  There is no documentation requirement for clause 4.2, so it is acceptable to address these within the scoping approach.  Formally identifying the needs of interested parties will lead to a more effective way to identify their expectations.  

In addition to identifying the interested parties, an organization needs to assess the requirements of each of those specified parties.  As ISO 27001 notes, “these requirements may include legal and regulatory requirements and contractual obligations.” Examples of possible ways to approach this are included below.

  • If an organization has a signed agreement with a customer to undergo a SOC 2 examination of the Security principal on an annual basis, then it makes sense that the customer in question is an interested party with a contractual requirement.
  • If an organization is responsible for applying proper security around a client’s sensitive financial data, the organization would then have a legal and contractual obligation to that customer.
  • If an organization is considered a business associate relative to the HIPAA Security Rule, the organization would then have to include the government as an interested party with a legal and regulatory requirement.

4.3 Determining the Scope of the Information Security Management System (ISMS)

At this point we have considered the external and internal issues of an organization, along with the requirements of the interested parties—it’s only after these have been considered that an organization should begin to define their scope. 

For the sake of clarity going forward, I will select one example of an interested party and its customers to guide further discussion of scope.  In reality, there will be multiple interested parties, both internal and external to the organization, each possessing their own requirements that should be considered; however, many of these parties’ requirements will parallel one another as they are components of a common objective. Understanding that—the objective--allows the organization to better identify and define the scope of their ISMS and whether it should be associated with a service line, application, business unit, or organization-wide.

The standard requires the organization to define the boundaries and the applicability of the ISMS, and in doing so, the organization can determine what falls within and what falls outside of the ISMS.  While the meaning of boundaries is not specifically defined, it can range from the limits of information systems to organizational restrictions to physical boundaries.  For example, using the customer as a relevant interested party, it is logical to identify the information that the customer expects the organization to protect, and so the inclusion of information systems utilized to collect, process, and store this information should be included within the scope of the ISMS.  

Business unit/departmental boundaries work in the same manner when determining which processes or people within the organization interact with the customer’s data.  Those persons, departments, systems, processes, locations, etc. that do interact with, host, control, or support the security relative to the customer’s data will likely be included within the scope of the ISMS. Of course, if the organization is smaller with only one service or location, it may be an easier discussion.  There are going to be fewer people that perform more roles which make the boundaries increasingly difficult to segregate from other processes.  In these situations, it is very common for the scope of the ISMS to include the full organization.

It should be mentioned that once an ISMS has been certified, organizations are able to modify their ISMS scope by reduction or expansion, in order to ensure that the scope continues to be fit for purpose. For instance, if the goal is to respond to a customer request of certification for an ISMS applicable to a product or service, then it is entirely reasonable to initially scope the ISMS around that product or service.  It will meet the objective and satisfy the customer, and sometimes that is all an organization may need.  What’s better is that it will get the ISMS implemented and operating effectively.  Should expansion be considered in the future for the ISMS, the organization would have personnel with experience and knowledge of the process, both internal and external, to support the effort.

Lastly, in addition to clauses 4.1 and 4.2, the organization must consider the interfaces and dependencies between activities performed by the organization and those that are performed by other organizations.  For organizations that have third party relationships, this is a key consideration.

In short, an ISMS should create value for the organization. However, that quality of the output is dependent on the quality of the inputs, and the ISO 27001 standard can help mold each system’s guidelines for maximum value. During examination, activities performed for the scoping provide the foundation of the ISMS, which guides all subsequent activities. Clause 4 and its procedures for scoping--the entirety of which only comprises about a half of page in the ISO 27001 standard—is incredibly important in this matters, and its significance should not be understated.

 

Previous Article
Powered by Purpose
Powered by Purpose

What is purpose? We hear the word often, but have we stopped to think about it.

Next Article
Match on: FedRAMP vs. ISO 27001
Match on: FedRAMP vs. ISO 27001

Over the last few years, there has been a push to obtain cloud computing solutions at almost eve...

×



Subscribe now
to receive content updates once a week

First Name
!
Success
Error - something went wrong!