The privacy review often happens too late.
A feature is already built.
The database schema exists.
The analytics events are flowing.
Three vendors have been integrated.
Then somebody asks:
“Do we need a privacy review?”
That is backwards.
Privacy by design means privacy requirements are considered during product and system design, before the architecture becomes expensive to change.
GDPR makes privacy by design and by default an explicit concept in Article 25. The DPDP framework does not simply reproduce GDPR terminology, but many of the underlying engineering practices are useful for Indian businesses as well.
Start with the data decision
For every new feature ask:
What personal data does this feature actually need?
Then ask:
What is the minimum data that lets us achieve the same product outcome?
Example:
A feature needs age eligibility.
Option A:
Store full date of birth forever
Option B:
Verify age threshold
→ store eligibility result
→ minimise raw DOB access
The correct architecture depends on the product and legal requirements, but the second question should always be asked.
Privacy by design is mostly architecture
Typical decisions include:
- What fields exist
- Which service owns them
- Who can read them
- Which vendors receive them
- How long they remain
- Whether logs capture them
- Whether analytics copies them
- Whether test environments contain them
- How deletion propagates
These are engineering decisions.
Build purpose into the data model
Do not represent personal data as an unbounded blob.
A useful model can connect:
Data field
→ purpose
→ processing activity
→ lawful basis / applicable route
→ recipients
→ retention
→ deletion mechanism
This makes later changes easier to reason about.
Default should mean something
Privacy by default is often reduced to:
“Use safe settings.”
Make it concrete.
Examples:
- Analytics identifiers are disabled until the relevant processing can begin lawfully.
- Marketing is off until the relevant preference exists.
- Production data is not automatically copied to development.
- Sensitive fields are not visible to every support agent.
- Logs do not capture request bodies by default.
The principle is to make the safer state the normal state.
Add privacy requirements to the development lifecycle
A practical flow:
Product requirement
↓
Data requirements
↓
Purpose + processing review
↓
Architecture
↓
Implementation
↓
Privacy/security tests
↓
Release
↓
Continuous monitoring
The review should be proportionate. A static UI change does not need the same process as a feature that introduces identity documents and behavioural profiling.
Test privacy like any other feature
Engineering teams test:
- Authentication
- Payments
- Performance
- Security
Privacy should have tests too.
Examples:
Consent test: Does an opted-out user still trigger marketing events?
Erasure test: Does account deletion remove data from the relevant systems?
Access test: Can an unauthorised support role see sensitive fields?
Logging test: Does a failed request dump personal data into logs?
Vendor test: Does the new integration send fields that were not approved?
Privacy drift is inevitable without monitoring
A design review is a snapshot.
The product changes next week.
A developer adds a field.
Marketing adds an SDK.
Support turns on a new integration.
The privacy architecture should therefore include change detection.
This is one reason continuous discovery is more useful than an annual privacy workshop.
Where teams go wrong
Treating privacy as legal sign-off. Legal review is valuable, but it does not replace engineering controls.
Collecting data “just in case.” Storage is easy. Explaining why years later is not.
Ignoring logs. Sensitive data can leak into observability systems without anyone adding a database column.
Copying production into test. Convenience during development becomes another privacy environment.
Where Privra fits
Privra brings the privacy review closer to the infrastructure where the decisions actually become real.
We discover personal data, identify processing changes, surface mismatches, and connect findings to implementation and evidence.
Privacy by design only works when the design reaches production.