ISO 27701 · IMPLEMENTATION
Most teams that already hold ISO 27001 build a PIMS by copying the ISMS and changing the headings. That fails at Stage 2. The reason is one word in the risk assessment, and it decides how much of the rest you have to rebuild.
TL;DR
A PIMS is a management system for personal data, built to clauses 4 to 10 of ISO/IEC 27701:2025 and the controls in Annex A. Work in this order. Settle your role. Scope the system. Build the records of processing. Assess risk to the people in your data. Write the Statement of Applicability, then run the system long enough to audit it.
Sources: ISO/IEC 27701:2025 · Schellman preparation guidance
Start with your role, not the standard #
Before you read a clause, answer one question. For each set of personal data you hold, are you the PII controller or the PII processor?
The controller decides why and how personal data gets processed. The processor acts on someone else’s instructions. ISO/IEC 29100:2024 supplies that vocabulary, and ISO 27701 uses it throughout.
The answer is seldom one word. A software firm acts as a processor for the customer data inside its product. It acts as a controller for staff records, job applicants, its marketing list and its own website analytics. Both answers are true at once, for different data.
This matters because your role picks your controls. Annex A splits into three groups.
A.1
Conditions for collection and processing, obligations to PII principals, privacy by design and by default, and rules for sharing, transfer and disclosure.
A.2
The same four subjects, written for a party acting on instructions rather than setting them.
A.3
Information security controls that apply whichever role you hold, reflecting the ISO 27001:2022 control set.
Annex B carries the implementation guidance in the same split, as B.1, B.2 and B.3.
Get this wrong and you build the wrong half
Teams often pick one role for the whole company. Then they implement A.1 and skip A.2, or the reverse. An auditor finds it in the first hour, because the records of processing show data the missing group governs. Decide role per data set and write the answer down.
Design the system #
Three artifacts carry everything else. Build them in this order.
Scope the PIMS #
Goal: a boundary you can defend in one sentence.
Clause 4 asks for your context, your interested parties and your scope. The interested parties list is where a PIMS differs from an ISMS. It has to name PII principals, the people whose data you hold, alongside customers and regulators.
Name the privacy laws that apply to you here too. PIPEDA, Quebec Law 25, Alberta and B.C. PIPA on one side of the border. HIPAA and the state privacy statutes on the other. The GDPR where you serve the EU.
What goes wrong: a scope copied from the ISMS certificate. The two systems can share a boundary, but you have to decide that rather than inherit it. The same method as defining an ISMS scope applies, pointed at data instead of systems.
Write the privacy policy and name an owner #
Goal: one accountable person, not a committee.
Clause 5 wants top management commitment, a privacy policy and assigned roles. Give the PIMS a named owner with real authority. A privacy lead who cannot stop a launch is not an owner.
What goes wrong: a policy that reads like a website privacy notice. The two are different documents. The notice tells the public what you do. The policy tells your staff what the company commits to.
Build the records of processing #
Goal: the inventory every later step reads from.
This is the load-bearing artifact. For each processing activity, record the data and the purpose. Record your role, the lawful basis and who receives it. Record where it goes and how long you keep it.
Nothing downstream works without it. You cannot assess privacy risk on data you have not listed. You cannot answer a deletion request for a system you forgot. You cannot scope an audit around an inventory that does not exist.
What goes wrong: someone builds the record once for the audit and nobody touches it again. Tie it to a change that already happens, such as vendor onboarding or a new feature review. Then it stays current without a reminder.
Assess privacy risk, which is not security risk #
Here is the error that costs the most rework.
An ISO 27001 risk assessment asks what could harm the organization. Breach, outage, fine, lost contract. A privacy risk assessment asks what could harm the person in the data. Those are different questions, and they rank risks in a different order.
Take a marketing list. Losing it hardly registers on a security register. No outage, no regulator, small contract exposure. Now ask the privacy question. The harm lands as unwanted contact, profiling the person never agreed to, and a retention period nobody set. Same data, a much higher score.
Clause 6 wants the privacy assessment. Copy your ISO 27001 register and change the title, and an auditor reads three rows. Every consequence there describes company loss. That is a nonconformity, not a style note.
Where a privacy impact assessment fits #
Do a full privacy impact assessment for high-risk processing. New product, new data type, new country, automated decisions about people. ISO/IEC 29134:2023 gives the process and the report structure, so you do not have to invent a format.
Run it before the processing starts, not after. A PIA written to justify a decision already made is a document, not a control.
A useful test for any risk row
Read the consequence out loud. Does the sentence end with something that happens to your company? Then you wrote a security risk. Does it end with something that happens to a person? Then you wrote a privacy risk. A PIMS needs the second kind.
Decide the controls and write them down #
Risk treatment produces choices. The Statement of Applicability records them.
List every Annex A control in the groups your role brings in. For each one, say whether it applies, why, and what its status is. Justify every exclusion. The structure matches an ISO 27001 Statement of Applicability, which helps if you have written one before.
Then produce a risk treatment plan for anything you are not accepting. Who does what, by when.
| Document | What it proves | Read by |
|---|---|---|
| Scope statement | What the certificate covers | Auditor, buyers |
| Privacy policy | Management commitment and direction | Auditor, staff |
| Records of processing | You know what data you hold and why | Auditor, regulator |
| Privacy risk assessment and treatment plan | You judged risk to people and acted on it | Auditor |
| Statement of Applicability | Which controls apply, and why the rest do not | Auditor |
| Privacy impact assessments | High-risk processing was assessed before it started | Auditor, regulator |
| Internal audit and management review records | The system runs, rather than exists | Auditor |
The core documented information a PIMS carries. Your role and your scope add to this list, never subtract from it.
Run the system before you book the audit #
Clauses 9 and 10 are the ones teams leave until the month before fieldwork. That timing is the problem, because both need history.
An internal audit has to cover the PIMS and produce findings. A management review has to happen, with privacy on the agenda and decisions in the minutes. Nonconformities need corrective action that closed, not corrective action somebody planned.
An auditor reads these as evidence that the system operates. One internal audit run three weeks before Stage 2, finding nothing, tells them the opposite.
Borrowing from the ISMS stops here
Under the 2019 edition you could fold privacy into the ISMS internal audit and the same management review. The 2025 edition gives the PIMS its own clauses. So the auditor wants privacy objectives, a privacy internal audit and a review that names privacy. One combined meeting can still cover both systems. The minutes have to show privacy on the agenda in its own right.
The certification audit #
Certification runs in two stages, the way it does for ISO 27001.
Stage 1 is a readiness check. The auditor reads your documents, tests whether your scope makes sense and tells you what is missing. Stage 2 is the real examination, where they sample evidence and interview people.
Pick the certification body with care. A recognized accreditation body must accredit it for ISO 27701. That means ANAB in the United States, or the Standards Council of Canada at home. Ask which edition it can audit against. The 2025 edition is new and the transition still has years to run. Our guide to what ISO 27701 certification is covers that transition and its 2028 deadline.
How long this takes #
Budget six to nine months for a first PIMS if you hold ISO 27001 already, and longer if you do not. The clause work is quick. Building the records of processing and running the system long enough to have evidence is what sets the floor.
Check your version numbers before you buy
The privacy family all re-published in the past three years. ISO/IEC 27701 is on its 2025 edition, ISO/IEC 29100 on its 2024 edition, and ISO/IEC 29134 on its 2023 edition. Plenty of guidance online still describes the older text as current. Buy by year, not by title.
Frequently asked questions #
What is a PIMS?
A privacy information management system. It is the set of policies, records, risk decisions and reviews through which a company governs personal data. ISO/IEC 27701:2025 sets the requirements in clauses 4 to 10, with controls in Annex A. A certificate says an accredited body audited that system.
How do you implement ISO 27701 step by step?
Settle your role for each data set. Scope the system and name the laws that apply. Write the privacy policy and assign an owner. Build the records of processing. Assess privacy risk and treat it. Write the Statement of Applicability. Implement the Annex A controls for your role. Run internal audit and management review. Then book Stage 1.
Can you reuse your ISO 27001 risk assessment for ISO 27701?
Not as it stands. An ISO 27001 assessment measures harm to the organization. A PIMS has to measure harm to the person whose data it is. The method and the register carry over. You have to rewrite the consequences, and the ranking often changes when you do.
Is a Statement of Applicability required for a PIMS?
Yes. It lists every Annex A control in the groups your role brings in, with an applicability decision and a justification for each. Exclusions need a reason an auditor accepts. If you have written one for ISO 27001, the format carries straight over.
Do you need a privacy impact assessment?
For high-risk processing, yes. New products, new categories of data, new jurisdictions and automated decisions about people all qualify. ISO/IEC 29134:2023 gives the process and the report format. Run it before the processing starts, because a PIA written afterwards documents a decision rather than shaping one.
How long does a first PIMS take?
Six to nine months is realistic when you already hold ISO 27001, and longer when you do not. Writing the clause documents is fast. Building complete records of processing and accumulating enough operating evidence for Stage 2 is what sets the floor.
Key takeaways #
- Decide your role per data set before anything else. Most software firms are both a controller and a processor.
- Annex A splits into A.1 for controllers, A.2 for processors and A.3 for security controls that apply to both. Annex B mirrors that split as guidance.
- The records of processing carry every later step. Build them early and tie them to a change that already happens.
- A privacy risk assessment measures harm to the person, not harm to the company. Copying your ISO 27001 register is the most common failure.
- Your PIMS needs a Statement of Applicability, with a justification for every exclusion.
- Clauses 9 and 10 need history. Run the internal audit and management review early enough to have findings that closed.
- Budget six to nine months with ISO 27001 in place. Confirm which edition your certification body can audit against.
Build the PIMS once #
The order of the work decides how much of it you repeat. Talk to us about ISO 27701 readiness, and about running a PIMS alongside an ISMS rather than twice over.
