Data privacy overview
Privacy by design means every step of a person's data, from collection to deletion, has a control built in, not bolted on after launch. This page is the map for the module. Start here before any work that touches personal data.
This module is engineering guidance. It explains what the law asks of the systems we build, so we can build them correctly. It is not legal advice. For any decision about a lawful basis, a notice, a transfer, a breach, children or a new market, involve the DPO (data protection officer) or legal counsel. Laws change: every legal fact here carries an "as of" date and an official link.
How it works
| Step | The question | The control | Read |
|---|---|---|---|
| Collect | Do we need this field at all? | Data minimisation; a notice at the point of collection; age gate before data | Children's data |
| Consent | What did the person agree to, and can we prove it? | Purpose registry, versioned notices, append-only ledger | The consent model |
| Use | Is this use covered by the purpose? | Server and SDK gates per purpose; logs redacted | Retention and deletion |
| Share | Who else gets it, under what contract, in which country? | DPAs, vendor register, transfer basis, store labels | Data map and RoPA |
| Retain | When does it end? | One retention rule and one purge job per data type | Retention and deletion |
| Delete | Can we find and remove every copy? | DSR queue with steps generated from the data map | Data subject requests |
Controller and processor, in plain words
- The controller decides why data is processed and how. For our own users, that is the company that runs the product (here, Example Ltd). Under India's DPDP Act the same role is called the data fiduciary.
- A processor processes data only on the controller's instructions: our cloud host, our email service, our AI provider. The controller signs a data processing agreement (DPA) with each one.
- A vendor that uses the data for its own purposes (for example, an ad platform building its own profiles) may be a separate controller. That needs a different disclosure.
- When we build software for a client and process their users' data on their instructions, we are the processor and the client is the controller.
Which legal entity is the controller matters. It must be the same name in the privacy policy, the terms, the store developer accounts, the DPAs and the payment provider's records. A mismatch confuses users, reviewers and regulators, and payment and store reviews reject on names that do not match registered records exactly.
The module
| Page | Read it when |
|---|---|
| GDPR | You have EU or UK users |
| India DPDP Act | You have users in India |
| GDPR vs DPDP | You need one design for both |
| Staying current | You run the monthly review or publish a policy version |
| The consent model | You add any purpose, SDK or toggle |
| Marketing and email | You send anything that is not transactional |
| AI processing | You send user content to an AI provider |
| Data subject requests | You build deletion, export or a privacy queue |
| Data map and RoPA | You add a field, a store, a vendor or a flow |
| Retention and deletion | You add a table, bucket, log or cache key |
| Children's data | You set an age floor or add user-generated content |
| Breach response | Before you are on call |
| Engineer checklist | Every feature that touches personal data |
| Privacy mistakes | Your first week |
Rules
Guests are data subjects. A device ID, IP address and event stream are personal data even with no account. Every privacy control applies to guests too.
The privacy policy, in-app copy, store privacy labels and the code must describe the same processing. Reviewers and regulators compare them, and any mismatch is a finding.
Mistakes we made
- Privacy was planned after the features. Analytics, attribution and AI were wired first; consent, deletion and retention were retrofitted, and each retrofit found data that had already left. Put the control in the first version of the feature.
- The controller named in the policy did not match reality. Different documents and accounts named different legal entities over time. Agree the controller once, and update every document and account together.
The full list is on Privacy mistakes.
Checklist
- You know who the controller is for the product you work on.
- You know who the DPO is and how to reach them.
- You have read the Engineer checklist.