Data Privacy Module¶
Applies to: Data Privacy · Which modules do I have?
Purpose¶
Configure the module that supports obligations under India's Digital Personal Data Protection Act: notices, consent, grievances and the evidence needed to demonstrate compliance.
Audience¶
Data protection officers, compliance teams, and administrators configuring the module.
Prerequisites¶
- Module licensed and enabled
- Privacy notice content drafted and approved by the customer's legal advisers
- Processing purposes defined by the customer
- Grievance process and owner established
- Downstream systems identified, if consent state must propagate
This page describes what the software does. The customer's obligations under the Act are determined by their circumstances and their legal advisers, not by this portal. See Data Protection and DPDP.
Steps¶
1. Define purposes first¶
A purpose describes why personal data is processed. Consent is captured against a purpose, so purposes must exist before any consent is meaningful.
| Practice | Reason |
|---|---|
| Specific rather than broad | "Processing invoices" is defensible; "business operations" is not |
| Defined by the customer, not the implementer | It is a legal determination |
| Retired rather than deleted when no longer used | Existing consent records still reference it |
2. Author and version the notice¶
Notices are authored, versioned, and a specific version is published.
Versioning is the most operationally important feature in this module. Consent is recorded against a specific version of a specific notice, so it remains meaningful after the notice changes. A consent record that cannot say what was consented to is difficult to defend.
| Step | Note |
|---|---|
| Author the notice | Content supplied by legal advisers |
| Create a version | Each material change is a new version |
| Publish the version | Only a published version can be consented to |
| Keep superseded versions | They are the evidence for consents captured under them |
3. Configure consent capture¶
| Capability | Use |
|---|---|
| Capture | Record consent against a purpose and published notice version |
| Withdraw | Record withdrawal, with a timestamp |
| History | The full sequence for a data principal |
| Consent check | Query whether valid consent exists before processing |
Build the consent check into any downstream process that depends on it. A consent record that nothing consults is a record, not a control.
4. Configure grievance handling¶
Record grievances, assign an owner, resolve them. A grievance process with no named owner is a process that misses its response window.
5. Configure downstream propagation¶
Where consent state must reach other systems:
| Mechanism | Use |
|---|---|
| Webhooks | Push notification to a downstream endpoint |
| Connectors | Configured integrations with delivery logging |
Both keep delivery logs. Check them — a withdrawal that fails to propagate leaves a downstream system processing on a basis that no longer exists, and nothing will surface that unless someone looks.
6. Configure evidence packs and the audit ledger¶
| Artefact | Purpose |
|---|---|
| Evidence pack | A printable set of evidence for a point in time, generated on demand |
| Audit ledger | A tamper-evident record of privacy-relevant actions |
Generate an evidence pack once during implementation. It reveals gaps in configuration far more effectively than a review of the configuration screens.
7. Configure the public-facing surfaces¶
Where used, the module exposes a public privacy notice and a vendor or data-principal privacy centre for capturing consent, viewing history and raising grievances. Confirm these are reachable and correct before publicising them.
Validation¶
| Check | Method | Pass condition |
|---|---|---|
| Purposes defined | Review the list | Specific and approved by the customer |
| A notice is published | Open the published notice | Present, with a version identifier |
| Consent names its version | Capture a test consent and inspect it | Names the purpose and the notice version |
| Withdrawal works | Withdraw the test consent | Recorded with a timestamp |
| History is complete | View the principal's history | Shows capture and withdrawal in sequence |
| Consent check returns correctly | Query before and after withdrawal | Reflects the current state |
| Grievance flow works | Raise and resolve a test grievance | Recorded end to end, with an owner |
| Propagation works | Test a webhook or connector | Delivered, and visible in the log |
| Evidence pack generates | Generate one | Complete and printable |
| Audit ledger records | Perform an action and inspect the ledger | Entry present |
| Public surfaces reachable | Open them from outside the network | Load correctly |
| Superseded versions retained | Review notice history | Earlier versions still available |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| Consent records do not identify what was consented to | Captured without a published notice version | Re-capture against a published version |
| Cannot publish a notice | No version created, or content incomplete | Create and complete a version first |
| Withdrawal not reflected downstream | Webhook or connector failing | Check the delivery log and re-test. This is the failure that leaves downstream systems processing without a basis |
| Evidence pack incomplete | Purposes or notices not fully configured | Complete the configuration and regenerate |
| Grievance response window missed | No owner assigned | Assign one and add grievance review to the operational routine |
| A purpose cannot be deleted | Existing consent references it | Retire it instead. Deleting would orphan the consent records |
| Public privacy centre unreachable | Not published, or blocked by network policy | Confirm reachability from outside the network before publicising it |
| Module absent | Not licensed, or not enabled for the registration | See Modules and Licensing |
| Retention conflicts with a deletion request | Statutory retention applies to compliance evidence | Statutory retention wins. Record the decision and its basis |
Related Articles¶
- Data Protection and DPDP — the obligations context
- Security Hardening — the technical measures
- Housekeeping — retention in operation
- Assumptions Register — the open retention questions