A product may process data for account creation, security, support, fraud prevention, analytics and marketing. Those purposes should not automatically share one legal switch.
Section 4 of the DPDP Act requires a lawful purpose. Section 6 governs consent, while Section 7 sets out specified legitimate uses. The engineering job is to map each processing activity to the correct route instead of collecting consent everywhere by default.
Start with purpose
Ask:
Why are we processing this data?
Then separate account operation, security, legal requirements, support, analytics, marketing and personalisation.
Consent has technical requirements
Consent must be free, specific, informed, unconditional and unambiguous, with clear affirmative action. Withdrawal must be as easy as giving consent.
That means a marketing consent flag cannot live only in a database. If withdrawal is received, relevant downstream systems must stop the consent-based processing.
Do not use “legitimate use” as a shortcut
Section 7 contains specified situations. It is not a general alternative to consent whenever a product team dislikes a checkbox. The facts and statutory conditions matter.
Build a purpose matrix
| Processing | Purpose | Route |
|---|---|---|
| Account creation | Provide service | Applicable basis |
| Transaction messages | Account operation | Applicable basis |
| Marketing | Marketing | Consent if relied on |
| Fraud prevention | Security/fraud | Applicable basis |
| Analytics | Product measurement | Depends on purpose and basis |
The important thing is not to force every row into “consent.” It is to make the reasoning explicit.
Model consent per purpose
Avoid:
has_consent = true
Prefer a record that can express purpose, status, notice version, timestamp, source and withdrawal history.
That lets a user withdraw marketing consent without accidentally disabling password resets or account-security messages.
The self-test
Take five processing activities. Can you explain the purpose, data, legal route, consent state where relevant, downstream processors and evidence? If not, the consent architecture is hiding a purpose-mapping problem.
Where Privra fits
Privra connects processing purposes to the systems that execute them, so consent becomes an operational state rather than a front-end checkbox.