Define your ISO 27701 Audit Scope
Overview
Audit scope definition is always part of any audit. The scope sets the boundaries of the audit and identifies the object in focus.
The object can include the people, data, system or product in review. The scope definition allows the auditors to focus on an aspect of the organization rather than the whole. This is why it is important to clearly define the scope in review for your given audit.
Determining your ISO 27701 audit scope requires your organizations to specify the product, the data, the systems, vendors, location, department, internal and external parties, etc.. in scope.
Since ISO 27701 is an extension of ISO 27001, the scopes have to match and align. ISO 27001 scope is usually defined or targeted to a specific business unit, service or product, refer to this article for a deep-dive on ISO 27001 scope.
Processor vs Controller Scope
ISO 27701 provides controller- and processor-specific controls that help organizations overcome the challenges of privacy and security by establishing a point of connection between what could be two different functions. The difference between the controller and the processor classification is straightforward: the former collects the information and provides the reason and means for it, and the latter is a service provider to the controller, because it processes the data on the controller’s behalf.
Therefore it is important to determine the organization’s scope, because of the different requirements for processors vs controllers.
Generally, all organizations are controllers regarding their own employee data or marketing data, however, in the context of the ISO 27701 certification, employee or marketing data falls out of scope, because it’s usually outside of the ISMS scope confined to a specific business unit, service or product.
The challenge is that some specific business unit, service or product can be both controllers and processors, for example, an organization may collect vendor, client related information and also perform data processing on behalf of clients or vendors. In those cases, both organizations would comply with both classification’s requirements.
A quick question to determine whether your organization is one or the other is to ask:
Who is collecting the PII? If you collect the PII directly from an individual, you are the controller,
if some other organization collects it on your behalf, you are the processor.
Read below for guidance on how to determine each scope item. A table listing each item is provided down below to use as a template for this exercise.
Product(s) in scope
This should be relatively easy. For a Software as a Service (SaaS) provider, the scope is typically the software application(s) offered to clients. Some organizations have multiple products and it is important to define for your ISO 27001 & ISO 27701, what product is in focus and what product isn’t.
Data in scope
In order to identify the data in scope, the ideal step is to focus on the type of data and people that flow through the product or service identified. For a (SaaS) provider, it’s typically all the data held in it (i.e customer data, etc..) and the people that support it such as vendors, employees.
Systems in scope
To identify all your systems in scope, take an inventory of all the various systems and internal controls that are critical to delivering your service or product in scope. This could include email, Slack, the key is the focus on the systems and tools that are essential in delivering your service / product. Production systems have a direct impact on your product or service in lieu or non-production systems.
For HR systems, focus on systems that manage employee’s onboarding and training processes. Everything else such as time off requests, benefits are out of scope since they are not critical to delivering service or product.
For a (SaaS) provider, it’s typically all the infrastructure that hosts it and the procedures that support it such as AWS, Github, JIRA etc..
Vendors in scope
In order to identify the vendors in scope, focus on the critical vendors such as cloud hosting, production related companies used to support the product or service in scope
Internal and External Parties in scope
You would need to list out all internal stakeholders (i.e employees, Board of Directors) and external parties (i.e customers, regulators; government) needs and interests and relevant for your ISMS – PIMS.
Relevant laws and regulations in scope
You should list the most relevant laws and regulations that are relevant for information security according to your business and describe how you are willing to fulfill those requirements
Physical Office / location in scope
There is no mandatory requirement to include an organization’s headquarters in the scope for the ISMS-PIMS. Physical location can usually be carve-out from the scope. However, an office site can be added to the scope depending on its relevance to the ISMS (i.e hosts a server or serves as a satellite office).
Scoping guidance template
Scoping guidance |
Provide a detailed description of your organization’s products or services.
Focus on the product or service under review |
Provide the type of data and people that flows through the product or service under review |
Please provide the list of systems / tools that flow through or support the product or service under review |
Please provide the list of critical vendors and subprocessors being used to support the product or service under review |
Please provide the list of internal and external parties relevant with needs relevant to the ISMS-PIMS |
Please provide the list of relevant laws and regulations regulating the product or service under review |
Please provide the list of locations serving as an operation center to support the product or service under review |