Section 13 complaints, on a clock, with a register

What §13 gives a complainant, and what you must publish

Section 13 gives a data principal the right to a readily available means of grievance redressal in respect of any act or omission regarding the performance of obligations, and requires the fiduciary to respond within the prescribed period — which Rule 14 leaves to you to publish, up to a ceiling of ninety days. On the fiduciary's side, §8(10) requires an effective grievance mechanism and §8(9) requires the business contact information of the Data Protection Officer or the person able to answer questions on the fiduciary's behalf to be published. Together they are what a complainant needs before they can complain properly.

The platform enforces this at the point it matters: a consent notice cannot be published until a DPO name and email and a grievance officer name and email are recorded. That is not a nag screen — the publish call fails and names the missing fields. Once set, those contacts are injected into notices and into the preference centre footer, so the published contact and the operating contact are the same contact.

The form a complainant fills in, and the five other ways one arrives

The public form is addressed by organisation slug and asks for a name and an email, because the acknowledgement and every update depend on reaching the person, then a category and a description. The description is what gets quoted back in the closure notice, so the form says so rather than treating it as internal.

Complaints also arrive through the hosted preference centre, through the embedded consent widget, through a partner API, from an operator typing in something that came by email or WhatsApp, and through the rights portal as one of its five request types. Each carries its channel with it, which is the first thing you want when the volume from one surface suddenly changes.

• Twelve categories: data breach, wrongful processing, consent violation, access denial, correction refused, erasure refused, excessive data collection, third-party sharing, retention violation, inaccurate data, withdrawal not honoured, and other.
• Routing rules can test the category, the complainant's email domain, the identifier type or text in the description, and assign to a named owner in priority order.
• An unmatched complaint stays unassigned and visible rather than being routed somewhere convenient.

The two clocks, and which one people actually miss

There are two separate timers and they fail differently. The first is acknowledgement: the complainant is told the complaint was received, and the officer receives an action-required email saying so. The inbox carries a dedicated tile counting complaints that have sat unacknowledged past the acknowledgement window, because an unacknowledged complaint is the one that becomes an escalation even when it would have been resolved easily.

The second is resolution, running to a configurable window against which the inbox counts overdue. Extending it requires a written reason and notifies the complainant. In practice the acknowledgement clock is the one organisations miss: resolution is a project with an owner, acknowledgement is a thirty-second action that nobody has been made responsible for.

Both clocks are computed and displayed. Neither is chased by a background job, and we would rather say that plainly than let you discover it. The tiles exist so a person looks; the emails exist so the officer knows; the chasing is a human routine with a dashboard behind it.

Refusal has to carry a written basis

Closing a complaint as refused without saying why is the fastest way to turn a complaint into an escalation. The platform enforces it at the API: setting a complaint to refused with an empty reason is rejected, from the dashboard and from a direct integration alike, and the refusal email carries the reason. The reason the complainant receives is the reason stored in the record — there is no internal version and external version.

Every transition is written to an append-only event log: submitted, the submission metadata, assignment, each status change, the refusal reason being set, internal notes, and each time the complainant was notified. That log is what makes the register defensible rather than merely tidy.

After closure: satisfaction, and the escalation you have to record

Once a complaint is resolved or refused, the complainant is invited to say whether they are satisfied. A dissatisfied response emails the grievance officer immediately and flags the complaint, because dissatisfaction is the leading indicator of an escalation to the Data Protection Board and the window to fix it is short.

If it does escalate, the platform records it: a Board reference in the expected format, the escalation timestamp, and a copy to the complainant so both sides hold the same reference. Say plainly what that is — a record that you escalated, or were escalated against. Nothing is filed with the Board from here, and no vendor can file on your behalf.

The register, one export away

The register is the artefact an auditor asks for and the one nobody has. Here it is a query rather than a project: complaints by category, by status, by channel, with submission and closure dates, the reason on each refusal, and the full event trail per complaint. Summary counts cover total, open, unacknowledged past the window, overdue, resolved, escalated to the Board and recorded as not satisfied.

One thing to check against your own expectations: the export is a reporting export covering the grievance module alongside consent and breach, not a purpose-built register document with its own layout. If your auditor expects a specific register format, plan on shaping the export rather than assuming a template exists.

Where grievance handling breaks

The pattern is always the same: the complaint is handled and the handling is not recorded.

• The published grievance officer left the company and nobody updated the notice, so complaints go to a mailbox nobody owns while the notice still names them.
• A complaint is resolved in a phone call. The complainant is happy, the record still says open, and the register shows a breach of the resolution window that never happened.
• Support closes a complaint as refused with the word "invalid" in the reason field. It satisfies the field and not the obligation.
• Complaints arrive through the support desk and are categorised as tickets, so the grievance register undercounts and the escalation arrives as a surprise.
• The acknowledgement tile is red for a month because the officer's email goes to a distribution list that nobody treats as an inbox.
• Dissatisfaction is captured and never actioned, which converts a signal that could have prevented an escalation into evidence during one.

What the grievance module does not do

It does not resolve complaints. It routes them, times them, records the decision and the reason, and produces the trail. The investigation and the remedy are yours.

It does not file anything with the Data Protection Board, and it does not represent you in front of it. The escalation record holds a reference number and a timestamp so both sides are working from the same facts.

It does not decide whether a complaint is well founded, or whether refusing it is defensible. Those are judgements a person makes and the platform records.

It does not chase your officer. Deadlines are computed, tiles turn red and emails go out at the transitions; nothing escalates on a timer by itself.