Feature · grievance clocks
Ninety days is the ceiling, not the plan
Rule 14 lets you set the period in which your grievance redressal system responds, provided you publish it and it does not exceed ninety days. Treating ninety days as the target is how a grievance becomes a Board complaint, because the person who complained stopped waiting somewhere around week three. This page is about the clocks that sit inside the statutory one.
Part of
This page is about the clocks and the escalation route. The module covers the officer, the register and the rest of the §13 obligation.
Two clocks, and only one of them is in the Rules
The statutory clock is the response period: the one you publish, and never more than ninety days from receipt. That is the outer limit and the thing you are measured against if anyone asks.
The operational clock is acknowledgement, and it runs at seven days. It is not in the Rules at all — they set only the outer response period — but it is the one that determines whether a grievance escalates, because a person who has heard nothing for a week concludes they are being ignored. The platform counts grievances still unacknowledged after seven days as a distinct breach state with its own tile and its own banner, separate from overdue.
The resolution window the platform works to is configurable per organisation and defaults to thirty days rather than ninety. That is a deliberate gap: a thirty-day internal target inside a ninety-day statutory ceiling leaves room for the requests that turn out to be complicated, instead of spending the whole budget on the ones that were not.
Twelve categories, and the one that is not a synonym
Category matters because it drives routing and because the pattern across categories is the actual signal. Twelve exist: data breach, wrongful processing, consent violation, access denial, correction refused, erasure refused, excessive data collection, third-party sharing, retention violation, data accuracy, withdrawal not honoured, and other.
Withdrawal not honoured is deliberately separate from consent violation, and the distinction is worth internalising. A consent violation is "you processed my data without valid consent". Withdrawal not honoured is "I withdrew, you accepted the withdrawal, and you kept processing anyway" — which is a §6(4) and §6(6) failure with a completed audit trail proving the organisation knew. They are different findings with different remediation and they should not be aggregated into one bucket.
The category a person selected is preserved as they selected it, even where the operator later reclassifies, because what somebody thought was wrong is evidence about your process regardless of how you file it.
Where a grievance actually lands
The public form takes a name, which is optional, an email, which is not, a category, a subject and a body, with minimum lengths on the last two so a grievance is at least a sentence. Submissions are rate limited per address per organisation. The success screen shows a short reference the person can quote and the date the resolution is due.
Routing is to the organisation's named grievance officer, taken from the organisation profile rather than from a queue configuration. That officer receives an alert whose subject line carries the reference and the acknowledgement deadline, because an email that says "new grievance" gets triaged like a newsletter and one that says acknowledge within seven days does not.
There is an enforcement point behind that. A consent notice cannot be published at all without both a grievance officer name and a grievance officer email on the organisation profile. §8(9) and §8(10) require the contact and the mechanism to exist and be published; a notice that describes a grievance route to an officer who does not exist is the failure mode that check exists to prevent.
Escalation to the Board is manual, and that is correct
There is no automatic escalation ladder. No rule that promotes a grievance at day thirty and again at day sixty. Anyone describing one is describing something that would be dangerous if it existed — escalating to a regulator is a decision with consequences for the person and the organisation, and a cron job should not be making it.
What exists instead is a prompt and a control. After resolution or refusal the person is asked whether they are satisfied, with three possible answers. Not satisfied fires an alert to the grievance officer whose subject line names the escalation risk explicitly, which is the trigger for a human to look again.
Escalation itself is an operator action, available on grievances only, and it takes the Board's own reference. That reference is validated — non-empty, minimum length, restricted character set, canonical form — because the whole point of recording it is that it ties your record to the regulator's. It can be done once; a second attempt is refused rather than creating a duplicate.
Closing and refusing
A grievance closes one of two ways. Resolved moves it to fulfilled with a response to the person. Refused moves it to rejected and requires a reason drawn from the same refusal taxonomy the rights machinery uses — identity unverified, legally required to retain, a request without foundation, duplicate, not a data principal of this fiduciary, or insufficient information.
The reason is not an internal note. It goes into the closure email, because a refusal is only useful to the person if they can see why — and a reason recorded in a database that the person never sees has not been communicated.
Enforcement sits at the API, not only in the interface. The dashboard will not let you refuse without selecting a reason, and the free-text explanation sits alongside the selected code; behind it, a refusal whose reason is blank is rejected outright, so a direct integration cannot post one either.
What the register is, and what it is not
Grievance records are exported through the compliance report, filtered to the grievance module, over a chosen period, carrying the records along with the counts and charts, branded to your organisation. Up to five hundred records go into a single export.
There is no separate one-click grievance register download today, and it would be easy to imply otherwise. The export above is the artefact you would hand over; it is a report containing the register rather than a register file.
What is available continuously is the summary: total, open, acknowledgement-SLA breaches, overdue, resolved, escalated to the Board, not satisfied, and a breakdown by category. That last one is the number that tells you something — thirty grievances is a workload, thirty grievances of which nineteen are withdrawal not honoured is a defect in your consent propagation.
Questions teams ask about this
What is the difference between the acknowledgement clock and the resolution clock?
Acknowledgement is an operational seven-day target for telling the person you have their grievance and who is handling it, tracked as its own breach state. Resolution is the statutory one — the period you publish, capped at ninety days by Rule 14 — against which the platform works to a configurable internal window that defaults to thirty. A grievance can be inside the resolution window and already in acknowledgement breach, and that combination is the one that produces escalations.
Does a grievance escalate to the Data Protection Board automatically?
No, and deliberately not. Escalation is an operator action that records the Board's own reference against the grievance, validated for format and permitted once. What is automatic is the prompt: after closure the person is asked whether they are satisfied, and a negative answer alerts the grievance officer with the escalation risk named in the subject line.
Can a grievance be refused without giving a reason?
No. The interface requires a reason before the refusal can be confirmed, and the API rejects a refusal whose reason is blank, so a direct integration cannot skip it either. The reason is included in the closure email rather than kept internally, because a refusal the person cannot read the reasons for has not really been communicated to them.
Why is "withdrawal not honoured" a separate category from "consent violation"?
Because they are different failures. A consent violation is processing without valid consent. Withdrawal not honoured means the withdrawal was received and accepted and processing continued anyway — a §6(4) and §6(6) failure where your own records show you knew. Aggregating them hides the more serious one inside the more common one.
Describes how ProtectComply implements one obligation under the DPDP Act, 2023 and the DPDP Rules. General information, not legal advice.
Priya Gupta — Priya writes on compliance operations at ProtectComply, including data principal rights, grievance handling and sector-specific programmes.
Stand up a grievance channel this week
A public form, a named officer, an acknowledgement clock and a route to the Board if it goes wrong.
See Grievance Management →