Passing a privacy management audit under ISO/IEC 27701 depends on engineering facts: where personal data lives, how it flows, how long it stays and how it is deleted. A VP of engineering should fund a living data map and tested deletion paths first. Policies are easy once those exist.
What will an auditor ask engineering?
I could not retrieve ISO's own page, so confirm the current edition and clauses against your purchased copy. Whatever the edition, a privacy management audit asks how you know what personal data you process and how you control it. Engineering has to answer with systems, not documents.
Typical questions: list every datastore holding personal data. Which services write to them? Which third parties receive data? How is access controlled and logged? How long is data retained, and what enforces it? What happens when someone asks for their data to be deleted?
What does a working data map look like?
A constructed example: a SaaS platform has a primary database, a search index, an event stream, a data warehouse, a support tool and a marketing platform. The data map is a table with one row per store: owner, data categories, purpose, retention, region, access group, and downstream recipients.
Most teams find three surprises on the first pass: copies in the warehouse nobody owns, logs containing identifiers, and a vendor integration added by another team. Those are the findings an auditor would find, discovered earlier and on your terms.
Where do deletion and retention break?
Deletion fails at the edges. The main database row is removed, but the search index, the cached export, the support ticket and the backup remain. Decide for each store: delete now, delete on a schedule, or anonymize. Backups usually need a documented rule such as expiry on a fixed cycle rather than instant erasure, and that rule must be written and followed.
Retention needs an enforcement job, not a policy statement. A scheduled deletion job with logs is evidence. A page in the wiki is not.
What about vendors and transfers?
Every processor receiving personal data needs a record, a contract and a security review. Keep the list machine readable. Know the region of each store and the transfer mechanism, and review when vendors add subprocessors.
How do you keep the map current?
A map built once decays within a quarter. Tie it to the places change already happens. Require a data map entry in the design review for any new datastore, queue or third-party integration. Add a check in CI that flags new outbound domains or SDKs for review. Run a periodic scan of schemas for columns that look like personal data, such as email, phone or national identifiers, and compare the results with the map.
Assign each row an owner who confirms it twice a year. Treat a store that has no owner as an incident of its own: either someone claims it or it gets decommissioned. This keeps the map accurate and gives the audit a living process to inspect.
How to check or apply this
- Build the data map: one row per store with owner, categories, purpose, retention, region and recipients.
- Scan logs, warehouses and caches for personal data that is not on the map.
- Implement and test a deletion path per store, using a synthetic person.
- Schedule retention jobs and keep their logs as evidence.
- Document the backup expiry rule.
- Maintain a vendor register tied to deployed integrations, and review it when code adds a new SDK.
- Restrict and log access to personal data, and review access every quarter.
Safeguard's dependency scanning and software inventory help you see which libraries and third-party components each product includes, which supports the vendor register. Certification itself comes only from an accredited body.
Quick check
Where should we start?
With the data map. Everything else, from deletion to vendor records, depends on knowing where personal data lives.
Do backups have to be erased immediately on request?
Rules vary by law and context. A documented expiry cycle is a common approach, but confirm it with counsel.
Sources
- ISO/IEC 27701, published by ISO and national standards bodies (paywalled; not fetched here, so clause details need checking against your copy).
Last reviewed: 18 October 2026.
