Skip to main content

Engineer checklist

Use this checklist for any feature that touches personal data. Copy it into the ticket or the pull request description. Tick each box, or write "N/A" and why.

How it works​

"Personal data" means any information about a person who can be identified, directly or indirectly. A device ID, an IP address, a hashed email and a free-text message all count.

The checklist​

Any new personal-data field or store​

  • Do we need it? Collect the minimum. A field we never collect cannot leak.
  • Data element added to the data map, with category and special-category flag (religion, health, sexual orientation, biometrics, and so on).
  • Stored in the right tier: user-owned personal data in the user's home region.
  • Retention rule agreed and a purge job scheduled. See Retention and deletion.
  • Erasure sweep covers it (all copies, all file versions). Test it.
  • Data export includes it, or the data map says why not.
  • Not in logs, URLs, cache key names, metric dimensions or analytics events.
  • Encrypted at rest and in transit (the platform default; confirm for new stores).
  • Access is limited to the roles that need it; staff reads of it are audited.

Any new processor, SDK or third-party API​

  • Data processing agreement (DPA) signed, or a ticket to get it before launch.
  • Vendor added to the register: role, country, transfer mechanism, retention, whether it trains on our data.
  • SDK starts only after the consent it depends on. No init at app boot.
  • Privacy policy lists it (or its category, if the policy uses categories).
  • Apple privacy label and Google Play Data safety form updated.
  • Erasure: deletion API called from the sweep, or vendor retention stated.

Any new purpose, or a new use of data we already hold​

  • Lawful basis written down for each regime: GDPR basis and DPDP basis. See GDPR vs DPDP.
  • If consent: a new consent purpose, seeded on the server in every environment first. See The consent model.
  • Notice copy written, versioned, hashed on the server, not editable over the air.
  • Withdrawal is one switch, and stops the processing.
  • Marketing? Follow Marketing and email.
  • AI provider? Follow AI processing.
  • Profiling, automated decisions or large-scale special category data? Ask the DPO about a DPIA.

Data leaves the country or region​

  • Transfer basis recorded (adequacy, standard contractual clauses, or other) for each destination.
  • Checked against any data-residency promise in the policy or contracts.

Users under 18 can reach it​

  • Age gate enforced on the server, from one config value.
  • No tracking, behavioural monitoring or targeted ads for children.
  • Follow Children's data.

Ship day​

  • New privacy policy version published before the app that needs it.
  • "Material" change flagged, so users are told and re-asked where needed.
  • Store privacy labels match the build.
  • Deploy order: API (purpose rows, enforcement) first, then web, then app.
  • After deploy, check logs for consent rejections or validation errors.

Rules​

Rule

Do not merge a personal-data change without the data map update in the same pull request. The next deletion or access request will miss what the map does not know.

Rule

The privacy policy, the in-app copy, the store labels and the code must say the same thing. App reviewers and regulators compare them. Any one being wrong is a rejection or a finding.

Mistakes we made​

  • The policy, the store and the code disagreed on age. Engineering decided one minimum age; the terms still said another; the store rating matched the terms. Changing the store setting alone would have been the misrepresentation. Start age changes with legal.
  • Store labels were treated as an afterthought. The Play Data safety form and the App Store privacy labels are separate from the policy text, and they are what gets a submission rejected. Update them in the same release as the code.

See the full list on Privacy mistakes.

Last updated on