ISO 27701 PII controller or processor: how to scope your PIMS

What does an ISO 27701 scope have to say?

A privacy information management system scope answers two questions at once: which personal data processing the PIMS governs, and in what capacity. Clause 4, Context of the organisation, asks you to work out the issues and interested parties that shape your privacy obligations, to determine whether you act as a controller, a processor or both, and then to fix the boundary of the PIMS. The result must match what you actually do.

A usable statement names the processing activities or services covered, the sites and teams doing the work, the systems holding the data, and the role for each. Leave out the role and the certificate says nothing a client can rely on; leave out a system and the auditor will find it while tracing a request.

The 2025 edition is a standalone management system standard, so the PIMS scope no longer has to sit inside an ISO/IEC 27001 certificate, as it did under the 2019 edition. Our guide to ISO/IEC 27701:2025: what changed and how to transition covers the edition change itself.

Deciding the role for each processing activity

Start from an inventory, not a label. For each processing activity, ask who decides the purpose, who decides the essential means (what data, for how long, shared with whom) and whose instructions the staff follow. The answer can differ between two activities in one building. A payroll bureau processes its clients' employee data on those clients' instructions, yet it decides for itself how to run its own recruitment, marketing and staff records.

Contracts are evidence, not the answer. A data processing agreement that calls you a processor does not make you one if you reuse the data for your own analytics, Where practice and paperwork disagree, fix one of them before you write the scope. How these roles map onto the laws you are subject to is covered in ISO/IEC 27701 and data protection law: evidencing accountability; the PIMS is not a substitute for legal advice on that question.

What can be excluded, and what cannot

Clauses 4 to 10 describe the management system itself, from leadership and risk planning to internal audit and improvement. They apply to the whole scope, whatever the role, and none can be declared not applicable.

Annex A is different. Clause 6 asks you to decide which controls treat your privacy risks and to record a reason for any you leave out. The role you hold drives most of that decision:

• Table A.1, controller controls. These cover purpose, lawful basis, consent, notices, the rights of individuals, privacy by design and by default, retention and disclosure. If any in-scope activity makes you a controller, this table applies to it.
• Table A.2, processor controls. Instructions, support for the customer's obligations, sub-processors, disclosure requests, transfers, and return or deletion of data. A pure controller can justify leaving it out.
• Table A.3, security controls. These apply whatever the role.

A reason such as "we are a processor, so A.1 does not apply" holds only if nothing in scope makes you a controller. The detail of each table is in our guide to Annex A: controller, processor and security controls explained.

Sub-processors, cloud providers and shared services

Processors rely on hosting providers and support tools; controllers rely on payroll bureaux and marketing platforms. Handing work to them moves the activity, not the accountability. Name these dependencies at category level and show how each is controlled: a contract with privacy terms, an approval or notification route for new sub-processors, the transfer safeguard relied on where data crosses borders, and a record of how their performance is checked.

Group shared services need a decision. A regional IT or HR centre that handles personal data for the certified entity can be brought inside the scope, in which case its sites and people are audited, or treated as an external party and controlled through an intra-group agreement. Either works; leaving the question unanswered does not.

Aligning the PIMS scope with an ISO/IEC 27001 scope

Where an information security management system exists, aligning the two scopes is usually simplest: same entities, sites and systems, one risk method and one audit calendar. The scopes may differ, but differences create work. A PIMS wider than the ISMS needs its own evidence that the Table A.3 security controls operate where the ISMS does not reach. A PIMS narrower than the ISMS, covering only the client-facing services, is common and simple. Draw both boundaries on one diagram before you commit.

How the scope reads on the certificate and sets the audit days

The accredited certification body confirms the scope wording after its audit; review the draft as carefully as a contract clause.

Scope also drives the audit effort. The certification body sets its days from the processing activities and roles in scope, the number of people and locations, and whether the PIMS is audited together with an ISMS; adding a role or a site adds time. How that becomes a quotation is covered in ISO/IEC 27701 certification cost: what moves the price.

Scoping mistakes that surface in the audit

• A role that contradicts the contracts. Certified as a processor while client agreements, or actual reuse of data, show controller decisions. The mismatch becomes a finding against clause 4.
• Processor-only scope that forgets the processor's own processing. Staff and marketing data exist in every service company; decide deliberately whether they sit inside the scope.
• Unlisted sub-processors and transfers. The auditor finds a hosting region the scope never named. Build the list from system records, not memory.
• A scope written for one client. The next client's due diligence asks about the rest. Scope for the clients you expect over the certification cycle.

ISO 27701 PII controller or processor: questions buyers ask