Determining the scope of the PIMS

Determining the scope of the PIMS is one of the fastest ways to fail an ISO 27701 audit if you treat it like a one-line paragraph in a policy. Clause 5.2.3 expects a clear, defensible scope that explains what the PIMS covers and why. In practice, that means you can answer (and evidence) three questions: (1) what PII processing activities are covered, (2) where those activities happen across the organization and its systems, and (3) whether you act as a PII controller, PII processor, or both for each activity.

A good scope statement does two jobs at once. It sets boundaries so the program is manageable, and it prevents “scope theater” where critical processing gets quietly excluded. Auditors will test scope by sampling PII flows, systems, business units, and third parties. If your documented scope doesn’t match reality (or if “out of scope” includes high-risk processing without rationale), you will spend the audit explaining inconsistencies instead of demonstrating control operation.

This page gives requirement-level implementation guidance you can execute quickly: how to define scope, what artifacts to retain, common audit hangups, and a practical execution plan you can run with your privacy, security, legal, and procurement teams.

Regulatory text

ISO/IEC 27701 Clause 5.2.3 requires that: “The organization shall determine the boundaries and applicability of the privacy information management system to establish its scope, taking into account the PII processing activities and the roles of the organization as PII controller and/or PII processor.” ¹

What the operator must do:
Create and maintain a documented PIMS scope that (a) names the organizational and technical boundaries of the management system, (b) ties those boundaries to actual PII processing activities, and (c) explicitly identifies where you operate as controller and/or processor.

Plain-English interpretation

“Determining the scope of the PIMS” means you must write down, in a way an auditor can test, what your privacy management system covers. The scope is not a wish list. It is the perimeter of processes, people, systems, locations, and third parties where PII is processed under your responsibility.

A practical scope statement answers:

• Where: business units, legal entities, countries/sites, cloud tenants, networks, and environments (production vs. non-production).
• What: the PII processing activities (collection, use, disclosure, storage, deletion) and the products/services that drive them.
• How: key systems and data stores that process PII, plus material third parties involved.
• Your role: controller, processor, or mixed role per processing activity.

Who it applies to

This requirement applies to any organization implementing ISO/IEC 27701 that processes PII as:

• A PII controller (you decide purposes/means of processing), and/or
• A PII processor (you process on behalf of another party).
  ¹

Operationally, it applies to:

• Privacy and security leadership responsible for management system boundaries
• Business owners of in-scope products, services, and workflows
• IT and engineering owners of in-scope systems and environments
• Procurement and third-party risk teams where third parties process PII within your service delivery
• Legal/contracting teams who define controller/processor responsibilities in customer and supplier agreements

What you actually need to do (step-by-step)

Step 1: Choose the scoping “unit” you will certify against

Decide the primary frame for scope. Common frames include:

• A specific legal entity (or group of entities)
• A specific product line/service
• A specific business unit and its supporting systems Document the choice and why it is operationally coherent (governance, control ownership, and auditability).

Step 2: Build or refresh your PII processing inventory (minimum viable)

You cannot scope a PIMS without knowing what PII processing exists. Create a list of PII processing activities that includes:

• Activity name and business purpose
• Data subjects (customers, employees, users)
• PII categories (high level is fine for scoping)
• Systems/data stores involved
• Key third parties involved in the activity
• Geographic footprint (where processing occurs)
• Your role: controller vs. processor (or both, by context)

If your organization already maintains Records of Processing Activities (RoPA), use it as the base. If not, start with a high-risk subset (customer onboarding, marketing, HR, support ticketing, analytics, logging/monitoring).

Step 3: Map processing activities to boundaries

Create a mapping that ties each processing activity to:

• Organizational boundary: which team/business unit owns it
• Technical boundary: which applications, databases, SaaS tools, and infrastructure support it
• Operational boundary: which sites/regions/environments are involved This is where scope becomes testable. Auditors will pick a processing activity and trace it to systems and owners. Your mapping should make that trace straightforward.

Step 4: Decide “in scope” vs. “out of scope” using explicit criteria

Define criteria that determine inclusion. Examples of criteria (write your own, but make them auditable):

• Activities that process PII for the in-scope products/services are in scope.
• Systems that store or transmit PII for those activities are in scope.
• Third parties that process PII as part of those activities are in scope for due diligence and contract controls, even if they are not part of your certification boundary.

For out-of-scope decisions, record:

• The processing activity/system excluded
• The reason for exclusion (e.g., separate legal entity with separate governance)
• The interface controls (how data crosses boundaries, if it does)

Step 5: Identify controller/processor role per activity (and document conflicts)

Role is not a label for the whole company in many businesses. For example:

• You may be controller for employee HR data processing.
• You may be processor when hosting customer data in a SaaS platform.
• You may be controller for your own product analytics even while acting as processor for customer content in the same platform.

Document role by activity and reference the governing contract type or internal purpose statement. This avoids audit disputes where privacy notices, DPAs, and actual processing disagree.

Step 6: Publish the PIMS scope statement (the “single source of truth”)

Create a formal scope statement approved through your governance process. Include, at minimum:

• In-scope legal entities/business units
• In-scope products/services
• In-scope locations and environments
• In-scope systems and key repositories
• In-scope PII processing activities (at least by category/group)
• Statement of controller/processor roles (by category or by reference to the inventory)
• Explicit exclusions and rationale
• Dependencies and interfaces with out-of-scope components

Step 7: Align downstream program elements to scope

Your scope must match what you do next:

• Risk assessments and treatment plans should only claim coverage for in-scope processing.
• Policies and procedures should state applicability consistent with scope.
• Internal audits should sample within scope.
• Third-party due diligence should cover third parties involved in in-scope processing.

If you use a GRC platform like Daydream, treat “scope” as a controlled object with workflow: draft, review, approval, versioning, and linkage to processing activities, systems, and third parties. That linkage is what makes audits faster and reduces scope drift.

Required evidence and artifacts to retain

Auditors typically expect a trail from requirement to reality. Retain:

• PIMS scope statement (version-controlled, approved)
• PII processing inventory (or RoPA-like register), including controller/processor role per activity
• System/application inventory mapping to processing activities
• Data flow diagrams or narratives for key in-scope activities (high risk first)
• List of material third parties involved in in-scope processing, mapped to activities
• Rationale for exclusions and boundary interface controls (data sharing, API integrations, transfers)
• Governance evidence: meeting notes, approvals, change management records for scope updates

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me your scope statement. How do you know it reflects actual processing today?”
• “Pick one in-scope processing activity and walk me through systems, owners, and third parties.”
• “Where are you controller vs. processor? Show the basis for that determination.”
• “What is explicitly out of scope, and how do you prevent PII from crossing into out-of-scope systems without controls?”
• “How do you handle acquisitions, new products, or new SaaS tools that process PII? When does scope get updated?”

Hangups that slow audits:

• Scope says “global” but inventories are regional, or vice versa.
• Scope includes “all systems” but you cannot list them.
• Processor role claimed, but you run analytics/marketing that looks like controller activity.

Frequent implementation mistakes and how to avoid them

Mistake 1: Writing scope as marketing language

Avoid broad phrases like “all personal data is protected” with no boundaries. Replace with enumerated entities, services, and systems.

Mistake 2: Ignoring third parties because they are “not part of certification”

Even if a third party is outside your certification boundary, its processing can be inside your PIMS operational scope for due diligence, contracting, and oversight. Map third parties to in-scope processing activities and retain evidence.

Mistake 3: Treating controller/processor as a company-wide label

Role changes by context. Document role per processing activity, and ensure contracts, privacy notices, and internal practices align.

Mistake 4: “Out of scope” includes the messiest systems

Auditors notice. If legacy systems process PII for in-scope services, they are functionally in scope. If you cannot include them, document compensating interface controls and a plan to migrate or remediate.

Mistake 5: Scope never changes

Scope drift is normal: new integrations, products, regions. Put scope under change control and link scope updates to intake processes (new vendor intake, SDLC gates, DPIA triggers).

Enforcement context and risk implications

No public enforcement cases are provided for this requirement in the source catalog, so this page does not cite specific regulator actions.

Operational risk still matters. A weak scope creates predictable failure modes:

• Control gaps: teams assume something is covered, but it sits outside the management system.
• Audit exposure: sampling quickly finds “shadow” PII processing outside scope.
• Third-party exposure: processors/sub-processors handle PII without being pulled into due diligence and contracting workflows.
• Role confusion: controller/processor mislabeling leads to misaligned notices, DPAs, and incident response obligations.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Appoint a single owner for the scope statement and a cross-functional reviewer group (privacy, security, IT, procurement, legal).
• Draft an initial scope statement using what you already know (entities, products, known systems).
• Start a minimum viable processing inventory focused on the highest-risk workflows.
• Create an exclusions log for anything you are tempted to exclude, with rationale and interface notes.

By 60 days (Make it testable)

• Complete mapping of in-scope processing activities to systems and third parties.
• Document controller/processor role per activity and resolve obvious conflicts (contract language vs. practice).
• Publish scope statement v1.0 with approvals and version control.
• Align third-party due diligence intake so in-scope processing automatically triggers reviews and contract checks.

By 90 days (Operationalize and prevent drift)

• Add scope checks to change processes: new systems, new SaaS, new regions, new products.
• Run an internal audit-style walkthrough: sample a processing activity end-to-end and verify evidence.
• Train control owners on what “in scope” means for their systems and workflows.
• Move artifacts into a system of record (often a GRC tool such as Daydream) so scope, processing inventory, and third-party mappings stay linked and reviewable.

Frequently Asked Questions

Can I scope ISO 27701 to only one product or business unit?

Yes, if the boundaries are explicit and you can show that the scoped product/unit has defined PII processing activities, systems, and governance. Document exclusions carefully, especially any shared platforms that also process PII for the in-scope offering.

Do third parties have to be “in scope” if they process PII for us?

They usually won’t be within your certification boundary, but they are operationally in scope for oversight. Map them to in-scope processing activities and retain due diligence and contract artifacts tied to those activities.

How detailed does the PII processing inventory need to be to set scope?

For scoping, you need enough detail to tie each processing activity to an owner, key systems/data stores, key third parties, and controller/processor role. You can refine categories and attributes later, but the mapping must be auditable.

What if we are both controller and processor in the same platform?

Document role by processing activity and purpose. Separate customer-directed processing (processor) from your own purposes like billing, product analytics, and security monitoring (often controller), then make sure contracts and notices match.

How do we handle shared IT systems that support both in-scope and out-of-scope business units?

Treat the shared system as in scope for the parts that process PII tied to in-scope activities. Document logical segregation, access controls, and data flow boundaries that prevent uncontrolled spillover.

How often should we update the PIMS scope?

Update it when changes affect boundaries or applicability: new products, major system migrations, new regions, acquisitions, or new third parties that materially change PII processing. Put scope updates behind a documented change control and approval step.

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management