For ISO 27701, engineers build the privacy plumbing: a personal data inventory, retention and deletion that really run, access logging, encryption, masked test data, a processor register, and a workable path for access and deletion requests. Policy covers intent, and these controls prove it.
What is ISO 27701?
ISO/IEC 27701 is the privacy extension to the ISO 27001 family, describing a privacy information management system (PIMS). The 2019 edition was an add on to 27001, and a newer edition exists. ISO's pages blocked our fetch and the standard is paid, so confirm the current edition and its clause numbers with your certification body. This checklist is deliberately general engineering practice that applies under any edition, and it is not a substitute for the standard text.
1. Personal data inventory
You cannot protect what you have not found. Build a record of processing: each data category, purpose, system, owner, retention period, legal basis, and recipients. Generate it from your schemas and data stores where you can, then have owners confirm. Re-run quarterly, because every new feature adds fields.
2. Classification and tagging
Mark personal and sensitive fields in your schema or data catalog. Tags let you apply masking, retention and access rules by policy instead of by hand.
3. Access control and logging
Restrict personal data to roles that need it. Log reads, exports and admin actions on personal data, protect the logs, and avoid putting personal data in the logs themselves. Review privileged access on a schedule.
4. Encryption and key handling
Encrypt personal data in transit and at rest, manage keys in a dedicated service, rotate on a schedule, and limit who can use or export keys.
5. Minimization and masking
Collect what you need. Mask or synthesize data in development and test, and block production copies into lower environments. Pseudonymize where analytics does not need identities.
6. Retention and deletion
Implement retention as code: scheduled jobs that delete or anonymize by tag and age, with a log that proves they ran. Cover backups, search indexes, caches and analytics copies, or document how and when they age out.
7. Data subject requests
Build a path to find a person's data across systems, export it, correct it and delete it. Test it with a dummy account. Keep a record of requests, dates and outcomes.
8. Processors and transfers
Keep a register of every vendor that touches personal data, what they do, where they host and which agreement covers them. Review annually, and record transfers across borders with their mechanism.
9. Breach detection and response
Alert on unusual access or export of personal data, and keep a runbook that covers assessment, notification decisions and records. Run a tabletop each year.
10. Secure development
Add privacy review to design for features that handle personal data, scan code and dependencies for known vulnerabilities, and keep change records.
Evidence to keep
Inventory with dates, access logs samples, key management settings, deletion job logs, request log, processor register, tabletop notes and change tickets.
Mistakes to avoid
- Deleting from the main database but not from backups, exports or analytics.
- Personal data in application logs.
- A processor register that stops at the vendors procurement knows.
- Subject request process that has never been tested.
What to do
- Build the personal data inventory and assign owners.
- Tag personal fields in schemas.
- Restrict and log access, and keep personal data out of logs.
- Encrypt data and manage keys centrally.
- Mask non-production data.
- Automate retention and deletion with proof.
- Test a data subject request end to end.
- Maintain the processor and transfer register.
- Rehearse breach response.
Quick check
Is ISO 27701 separate from ISO 27001?
It builds on the ISO 27001 family as a privacy management system. Editions differ, so confirm with your certification body which edition and prerequisites apply.
What do engineers own in a PIMS?
Inventory, tagging, access and logging, encryption, masking, retention and deletion jobs, request handling and breach detection.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. The privacy controls above are checks that can run on a schedule, which is where a platform helps.
Technical evidence comes from your real code and dependencies, through scans, SBOMs and reachability, not only policies, which supports secure development evidence. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. Certification is granted by an independent certification body. Safeguard helps prepare and keep evidence ready, and does not certify you.
Want to see it on your own stack? Book a call.
Sources
Last reviewed: 18 October 2026.