Privacy-by-design checklist for freelance developers

At a glance

Privacy-by-design means building the DPDP requirements into an app from the start, instead of bolting them on later. For a developer that comes down to a few habits: collect the minimum data, capture consent and notice at the point of collection, secure data in transit and at rest, log access, make deletion and withdrawal real features, and don’t over-share with third-party SDKs. The checklist below is what to build in — and it’s easier and cheaper done at design time than retrofitted after launch.

Educational resource only. This is a privacy-by-design checklist under India’s Digital Personal Data Protection Act, 2023 (DPDP Act); it is not formal legal advice.

Who this is for

Freelance and small-team developers building apps or backends that handle personal data — usually for a client. Whether the compliance duty is the client’s or partly yours depends on your role (below), but either way, a build that ignores privacy creates problems someone will have to pay to fix. Baking it in is the cheap path.

The privacy-by-design checklist

Design each item in before data starts flowing — retrofitting privacy is the expensive way.

Collect less

• Only request fields the feature genuinely needs; drop “might be useful later.”
• Avoid collecting sensitive IDs (Aadhaar, PAN, passport, driving licence, Voter ID) unless there’s a real purpose; accept masked versions where possible.
• Default to not collecting; add fields only with a reason.

Consent & notice at capture

• Present a clear, specific notice at the point of collection — not buried in a linked policy.
• Build per-purpose consent (separate, unticked opt-ins), not one blanket agree.
• Capture a consent record — what notice was shown, what was agreed, when.

Secure by default

• Encrypt personal data in transit (TLS) and at rest.
• Enforce least-privilege access; no shared admin logins.
• Keep secrets and keys out of the codebase and client-side.

Log & retain correctly

• Log access to and processing of personal data (who, what, when); retain those logs for at least a year.
• Don’t dump raw personal data into logs or analytics.
• Set data retention per purpose; delete personal data when it’s no longer needed.

Rights as features

• Build a real deletion path (erasure), not just account deactivation.
• Build consent withdrawal that actually stops the processing it covered.
• Support access and correction requests.

Third parties

• Vet every SDK, analytics, and cloud service that touches personal data.
• Share only what each third party needs; check they’re covered by proper terms.
• For under-18 users, don’t wire in behavioural tracking or ad-targeting.

Where you fit: fiduciary or processor?

Know which hat you wear, because it sets what’s legally yours. If you’re building and running something for a client on their instructions, you’re usually a Data Processor for that data — your duties run through your contract with them, and you should have one. If you’re building your own product and deciding why the data is collected, you’re the Data Fiduciary and the full duties are yours. Many freelancers are both across different projects. Either way, privacy-by-design makes you easier to hire — clients increasingly check.

FAQ