One PIMS, Two Roles: Collapsing Parallel Controller and Processor Manuals
Meridian Insights is a 300-person marketing-analytics firm. For forty retail clients it hosts and analyses customer purchase data as a processor; for its own website, event registrations and prospect database it is a controller. Under the 2019 edition the privacy team maintained two parallel documentation sets - a 'PIMS-Controller Manual' and a 'PIMS-Processor Manual' - each with its own risk assessment, supplier list and retention schedule. The same contact dataset is covered by a 36-month retention rule in the controller manual and a 24-month rule in the processor manual, and nobody can say which applies to which rows. The gap analysis for 27701:2025 has flagged that the two manuals duplicate 60% of their content and that five clause-level requirements are addressed in one manual but not the other. Meridian wants a single PIMS covering both roles before its transition audit in five months, without losing the role-specific obligations its enterprise clients audit against.
1. Design the target documentation structure so one PIMS covers both controller and processor roles. What stays common, what must remain role-specific, and where is the role decision recorded?
Read the worked answer
Structure by requirement, not by role. A single PIMS addressing clauses 4-10 fits the extension model: context, leadership, planning, support, operation, performance evaluation and improvement are role-agnostic management-system requirements. What varies by role is the input to those requirements and the applicable guidance.
Practical design: (a) one core set of documented information - policy, risk methodology, competence, internal audit, management review; (b) a processing register that records, per activity, the role (controller or processor), the PII principals, purposes, recipients, retention and the client contract reference - this becomes the routing table for everything else; (c) role-specific work instructions generated from the register, because PII principal request handling differs sharply depending on whether Meridian answers the request or forwards it to the client; (d) one risk register with a role attribute so a single method serves both, rather than two registers that drift.
The role decision must be documented per activity with rationale, because it drives obligations and client commitments, and it is the first thing an auditor tests when one organisation claims both roles. Sixty per cent duplication is a symptom of organising by role instead of by requirement.
2. How should the PIMS scope (clause 4.3) and the client-facing descriptions be written to reflect both roles without ambiguity?
Read the worked answer
The scope must be accurate, bounded and traceable. Suggested shape: name the legal entities, locations and systems in scope, then the two service categories with the role stated for each - 'controller for prospect and website data', 'processor for client customer data processed on documented instructions'. Three tests: does every processing activity in the register fall inside or outside the scope with a stated reason; can a client read the scope and know which obligations Meridian accepts on its behalf; does the scope match the certification scope the auditor will see, including shared infrastructure.
Do not write 'controller and processor' as a bare phrase - it invites the assumption that roles are interchangeable. Add interfaces: where Meridian is a processor, breach notification, request handling and sub-processor authorisation flow to the controller; where it is a controller, it owns those decisions. Reflect the same wording in contracts and in the client audit-response pack, otherwise documented scope and operational reality diverge exactly where clients test it.
3. Resolve the 36 versus 24 month retention conflict: what is the correct reasoning path, and what evidence should exist?
Read the worked answer
Retention is set by purpose and obligation, not by which manual was written first. Path: (1) split the dataset by activity in the register - prospect data held as controller versus client contact data held as processor; (2) for the controller part, determine retention needed for the stated purpose plus any statutory requirement, and document the justification; (3) for the processor part, the controller's documented instructions govern - if a client contract says 36 months, Meridian cannot shorten it unilaterally, and equally cannot extend beyond instruction; (4) where one dataset genuinely serves both, either separate it technically (flag, field, partition) or apply the stricter constraint and record why; (5) delete or anonymise at the boundary with evidence.
Twenty-four months for client data held on instruction is a defect, not a policy choice, unless the contract says so. Evidence the auditor wants: the register mapping rows to roles, the relevant contract clause, deletion job logs, approved exceptions, and a reconciliation showing no dataset is governed by a rule nobody can attribute.