How to Scope Your ISO 27001 Certification

“Where do we draw the line?”

That question has been asked countless times—by authors, musicians, politicians, and yes, organizations seeking ISO 27001 certification. When building out your information security management system (ISMS) that is to become certified, it can be tricky to know where to draw the boundaries of what’s in scope.

Because the ISO 27001 standard is comprised of requirements that can be applied to any organization regardless of type, size, or nature, this widely applicable approach is not overly prescriptive; rather, it defines the general requirements and control criteria, but it does not specify how to design or implement these requirements or controls. 

As such, you can address these requirements based on your needs, objectives, processes in place, and security requirements—correspondingly ISMS scope statements always differ from organization to organization as they are tailored to the uniqueness of each one.

But how exactly do you go about this tailoring—this drawing of the line?

In this article, we’ll delve into the scoping requirements of ISO 27001 and where they’re referenced—clauses 4.1, 4.2, and 4.3 so that you can get a full picture of possible scoping elements. That way, as you approach your certification, you’ll have simplified a fundamental part of the process.

Scoping Requirements of ISO 27001

Broadly put, the scope of your ISMS is intended to concisely sum up its objective—though this will vary from organization to organization as mentioned above, ISO 27001 does provide details that could help guide your chosen scope definition, found within clause 4:

• 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:
    • the external and internal issues referred to in 4.1;
    • the requirements referred to in 4.2; and
    • interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations.

Before we can dive right into 4.3, it’s important to examine the cross-references in the two preceding clauses mentioned here.

4.1 Understanding the Organization and Its Context

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

To put it more simply, you’re required to identify and understand the issues—both internal and external—that could affect, either positively or negatively, the ISMS and impact your organization’s ability to achieve its information security objectives.

When identifying internal issues, consider your:

• Governance structure
• Company culture
• Contracts in place
• Infrastructure
• Available resources 

In identifying external issues, consider:

• The influence of legal and regulatory requirements
• External stakeholders
• Environmental factors (political, economic, social, and competitive) 

While these factors can help jumpstart your scoping exercise, if this all reads more like the beginning of a risk assessment, you’re not far off—ISO 27001’s clause 6.1.1 also requires consideration of clauses 4.1 and 4.2 when you reach the point of determining risks that your ISMS will address.

4.2 Understanding The Needs and Expectations of Interested Parties

Once you’ve examined the relevant external and internal issues, you can move on to clause 4.2, which requires the determination of interested parties and their requirements in relation to your ISMS—“interested parties” may constitute top management, shareholders, employees, customers, suppliers, and governments or non-governmental organizations. 

Note that it’s not enough just to pick these entities out—you also must assess the requirements of each of those specified parties, which “may include legal and regulatory requirements and contractual obligations.” Example approaches to this include below:

• If you’ve signed an agreement with a customer to undergo a SOC 2 examination that includes the Security category on an annual basis, then it makes sense that this customer is an interested party with a contractual requirement.

• If you’re responsible for applying proper security around a client’s sensitive financial data, you would have a legal and contractual obligation to that customer.

• If you’re considered a business associate relative to the HIPAA Security Rule, you would have to include the government as an interested party with a legal and regulatory requirement.

Once you’ve considered and documented the external and internal issues of your organization along with the interested parties and their requirements for information security, you should have all the information you need to begin specifying your ISMS scope. 

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

To begin, you need to define what you want the ISMS to do—its objective—and whether it should be associated with a service line, application, or business unit, or if it should be organization-wide. These boundaries and ISMS applicability—or, what falls within and what falls outside of the ISMS—can range from the limits of information systems to organizational restrictions to physical boundaries.

Here are some places to start:

• If you consider your customers as interested parties, identify the information they expect you to protect—the systems utilized to collect, process, and store this information should be included within the scope of your ISMS.
  • (Though we only mention customers as interested parties here, keep in mind you’ll likely have more than just them to factor in.)
• The inclusion of business units/departments works the same way—for each one, ask which processes or people interact with data needing protection. Those persons, departments, systems, processes, locations, etc. that do interact with, host, control, or support the relative security will likely be included within the scope of the ISMS.

(Distinguishing these boundaries of interested parties and departments won’t necessarily be easier for smaller organizations. While the idea of only having one service or location seems to bode well for a clearer ISMS perimeter, that may also mean fewer people that perform more roles, which would make the boundaries increasingly difficult to segregate from other processes. That’s why, in these situations, it’s very common for the scope of the ISMS to include the full organization.)

The last things you’ll need to include in your ISMS scope are the interfaces and dependencies between activities you perform and those that are performed by other organizations. For organizations that have third-party relationships, this is a key consideration—check out our article that delves deeper into your options regarding your third-party data centers or colocation providers.

You’ll perform formal scoping activities during your certification process, which will establish the foundation of the ISMS and guide all subsequent activities. Despite the brevity of clause 4 and its procedures for scoping—the entirety of which only comprises about a half of page in the ISO 27001 standard—scoping is an incredibly important step and its significance, plus the effort required to draw the right boundaries, should not be understated.

Scope Modification During ISO 27001 Certification

With so much riding on setting the right confines, are they set in stone once you’ve established them? The answer is no—you’ll be able to modify your scope (in between assessments) whether by reduction or expansion to ensure that it continues to be fit for purpose.

Say your goal right now is to respond to a customer request of certification for an ISMS applicable to a product or service—it’s then entirely reasonable to initially scope the ISMS around that product or service so as to meet the objective and satisfy the customer. Sometimes, that’s all you need for the moment, but should you want to expand to other services or products, you’ll need to set back and redraw your ISMS boundaries.

However, it should be easier if there does turn out that you need another scoping exercise—by that point, you’ll have the ISMS implemented and operating effectively and your involved personnel should have gleaned experience and knowledge of the process, both internal and external, to support any expansion (or reduction) efforts.

More Considerations for Your ISO 27001 Certification

Regardless of type, size, or nature, organizations manage information assets that need to be protected and fortunately, a globally recognized standard can assist in managing the security of those information assets—ISO 27001. With its requirements for the implementation of an ISMS and a systemic approach to managing sensitive company information, after successful certification you (and your customers) can be more confident that your data remains secure.

But because ISO 27001 is systemic in nature, you’ll need to specify which systems—and their interfaces—will be included in your ISMS scope. Now that we’ve walked you through the relevant clauses within the standard and their guidance, you should be more comfortable going into your scoping exercise.

As this is an incredibly complex standard, make sure you also check out our other content that can help you set clear expectations and take the right steps in building out your ISMS:

• 6 Factors That Can Affect Your ISO 27001 Timeline
• 10 Steps to Help You Prepare For ISO 27001 Certification
• What to Do When You Have an ISO-Related Nonconformity