If you run an ISO 27001 ISMS, you already have most of the machinery a privacy information management system needs: a scope, a risk method, a Statement of Applicability, internal audit, and management review. The work of building a PIMS is mostly extending that machinery so privacy runs through it.
Teams that struggle usually do one of two things. They build a parallel privacy program with its own risk register and its own review cycle, which doubles the overhead and drifts from the ISMS within a year. Or they bolt a few privacy policies onto the ISMS and change nothing underneath, which fails the first time an auditor asks how privacy risk was assessed.
This article lays out the extension in order, clause by clause, with the artifact each step should produce. It assumes the ISMS is real and operating. If it is not, fix that first.
Check what the ISMS gives you to build on
Before extending anything, confirm four things are working, because the PIMS inherits their weaknesses.
A scope statement that matches reality. If the ISMS scope excludes the systems where most customer data lives, the PIMS will inherit the gap.
A risk method that has been run at least once. You will extend it, not replace it.
A Statement of Applicability with real justifications. Privacy controls will be added to it.
Internal audit and management review that have happened. These are where the PIMS will be tested and steered.
Where any of these is thin, privacy work will expose it quickly. That is not a reason to delay, but it is a reason to schedule the fix in the same plan.
The extension, step by step
Each step names the ISO 27001 clause being extended and the artifact you should end up with.
Determine your roles (clause 4). For each processing activity, record whether you act as a PII controller, a PII processor, or both. Output: a role column in your processing inventory, and a statement of roles in the scope document.
Extend context and interested parties (clause 4). Add applicable privacy laws, contractual privacy obligations, regulators, and PII principals themselves. Our guide to ISO 27001 clause 4 covers the base exercise. Output: an updated register of interested parties and their requirements, with privacy obligations listed explicitly.
Extend the scope (clause 4). State that the management system covers the processing of PII, and which activities and roles are in scope. Output: a revised scope statement.
Build the processing inventory. List each activity with purpose, categories of PII and principals, systems, recipients, transfers, retention, and role. Output: the inventory, owned and dated. It becomes the reference for most later steps.
Update policy and roles (clause 5). Add a privacy policy, or extend the information security policy, and name who is accountable for privacy. Output: an approved policy and a documented role with authority.
Extend risk assessment and treatment (clause 6). Add privacy risk to the method, including risk to PII principals. Output: a revised methodology and privacy risks in the register. This step is covered in detail below.
Connect privacy impact assessment to risk. Decide when an impact assessment is triggered, and make its findings feed the risk register. Output: a procedure and at least one completed assessment.
Select controls and update the Statement of Applicability (clause 6). Add the controller and processor controls that apply, with justifications. Our explainer on ISO 27701 controller and processor controls describes both sets, and our guide to writing a Statement of Applicability covers the document itself. Output: a revised SoA.
Set privacy objectives (clause 6). Choose a few measurable ones, such as request response times or completion of impact assessments before launch. Output: objectives with owners and a measurement method.
Extend competence and awareness (clause 7). Train staff who handle PII on what the policy requires of them. Output: training content and completion records.
Operate and record (clause 8). Run the controls and keep the records: requests, assessments, transfers, deletions. Output: evidence, dated and attributed.
Extend internal audit and management review (clause 9). Put the privacy controls in the audit program and privacy results on the review agenda. Output: an audit report and minutes that cover privacy.
Corrective action under clause 10 needs no new process. Privacy nonconformities go through the same one as security nonconformities.
The risk assessment change most teams underestimate
ISO 27001 risk assessment is usually written from the organization's point of view. Impact is scored on revenue, reputation, contractual exposure, and regulatory penalty. Our guide to ISO 27001 clause 6 describes that method.
A PIMS adds a second point of view: the PII principal's. The question becomes what harm the individual could suffer if this risk occurred. Harm can be financial, physical, psychological, or a loss of control over their information, and it can be serious even when the business impact is minor.
Take a hypothetical. Say a 60-person SaaS company stores free-text support notes that sometimes contain health details volunteered by end users. Scored on business impact alone, exposure of those notes looks moderate: a contained incident and a customer conversation. Scored on harm to the individuals, it looks high. Both views belong in the register.
In practice, you have three options:
Add a separate impact scale for harm to individuals, and take the higher of the two scores.
Keep one scale but require the assessor to consider harm to individuals explicitly when scoring.
Keep privacy risks in the same register with a category flag, and apply a privacy-specific scale only to them.
Any of these can work. What does not work is a register in which no risk mentions individuals at all. An auditor will read that as a risk method that was not extended.
Who owns what
The PIMS needs clear ownership across functions that may not usually work together.
| Area | Typical owner | What they own |
|---|---|---|
| PIMS as a whole | Privacy lead or DPO | Policy, objectives, processing inventory, management review input |
| Legal interpretation | Counsel | Lawful basis, transfer mechanisms, notice wording |
| Technical controls | Security lead | Access, encryption, logging, deletion mechanisms |
| Product decisions | Product and engineering | Privacy review before launch, minimization choices |
| Vendor and subprocessor terms | Procurement or legal | Processor agreements, subprocessor list |
The privacy lead does not need to own every control. They do need authority to stop a launch that has not been reviewed, and that authority should be written down. A privacy role with no ability to say no is an advisory function, and an auditor will test whether the role has teeth.
Mistakes that cost time later
Separate documents for everything. A privacy risk register, a privacy audit program, a privacy management review. Each one doubles work. Extend the existing artifacts unless there is a specific reason not to.
Copying a GDPR document set wholesale. GDPR records are useful inputs, but they were written for a regulator, not for a management system. They rarely include objectives, measurement, or links to the risk register.
A scope that names the product and forgets the company. Your HR, recruiting, and marketing systems hold PII. If you are a controller for that data, it belongs in scope.
Deletion described, not demonstrated. Retention schedules are easy to write. Evidence that deletion actually happened is harder. Design the evidence when you design the control.
No trigger for change. New features and new vendors change processing. Tie updates of the processing inventory to your change and procurement processes so it does not go stale between annual reviews.
How TrustLynce helps
TrustLynce keeps one risk register where privacy and security risks sit side by side with their own scoring, and holds your processing inventory, impact assessments, and requests in its data privacy workflows. Controls shared between ISO 27001 and ISO 27701 are mapped once, so the same evidence serves both.