Every rights request, on a clock you can prove

The five things a data principal can ask you to do here

Section 11 gives a data principal the right to a summary of their personal data and of the processing activities undertaken, the identities of other fiduciaries and processors with whom it has been shared along with a description of what was shared, and any other information prescribed. Around it sit the right in §12 to correction, completion, updating and erasure, the right in §14 to nominate another individual to exercise these rights in the event of death or incapacity, and the separate right to a readily available means of grievance redressal.

The module accepts exactly five request types, which map onto that: access, correction, erasure, nominee and grievance. It does not offer a portability request, because the Act does not confer one and offering a right your statute does not grant creates an expectation you then have to manage.

• Access — a summary of what is held and who it went to.
• Correction — correcting, completing or updating what is inaccurate.
• Erasure — deletion where the purpose is served or consent is withdrawn and no law requires retention.
• Nominee — accepting and tracking a nomination, which then has to have its authority confirmed by a person before anything is acted on.
• Grievance — a complaint routed to the published officer, which is the separate right of grievance redressal rather than a rights request in the narrow sense.

The portal a principal actually lands on

There is a public page per organisation, reachable by slug, that does not require an account. A request needs the organisation, the type, an identifier — email, phone, a customer reference or an external reference — and a description, and it accepts a proof file if the person has one. A mistyped slug returns a did-you-mean rather than a dead end, and a hidden field catches the bots that fill everything.

Three other intake routes write into the same store. The consent widget carries a rights tab, where a person who has already verified against the widget is not asked to verify twice. An authenticated API lets a system that has already identified its customer file on their behalf. And an operator can log a request that arrived some other way — by post, over the phone, in a shop — which matters because the obligation attaches to the request, not to the channel it used.

Verifying identity without collecting more than you need

Acting on an unverified erasure request is worse than being slow. Verification is a six-digit code sent to the identifier the person supplied — email if they gave an email, SMS if they gave a phone — valid for fifteen minutes, with five verify attempts per code, at most ten codes in any rolling twenty-four hours and a cooldown between sends. Codes are stored hashed; the raw value is never written down.

Around that sit the controls that stop the portal becoming an attack surface: a cap on requests per contact per hour and per source address per hour, automatic deletion of requests that were never verified after a day, and masked identifiers in every public view so a tracking link does not leak someone else's email. The clock does not start at submission — it starts when verification succeeds, because until then you do not know whose request it is.

Routing, the window, and the extension that has to be justified

Routing rules are evaluated in priority order and the first match wins. A rule can test the request type, the domain of the identifier, the identifier type, the grievance category, or text in the description, using equality, inequality, contains or set membership, and assigns the request to a named owner. A rule with no conditions matches everything, which is the way to express a default owner. If nothing matches, the request stays unassigned and visible rather than being routed somewhere plausible.

The response window defaults to thirty days from verification and is configurable per tenant anywhere from one to a hundred and twenty. An extension is possible, must be to a date after the current deadline and within the configured maximum, requires a written reason, and sends the principal a notice saying so. The inbox has one definition of overdue — the extension date if there is one, otherwise the deadline, and never for a closed request — so the number on the tile and the rows behind it always agree.

Be clear about what runs by itself and what does not. The clock is computed and displayed, tasks are created, and the principal is emailed at each transition. There is no background job that chases an owner as a deadline approaches. Escalation here is something a person does, prompted by a dashboard, not something the system does at three in the morning.

Erasure that reaches your processors, or refuses to pretend

On verification, an access, correction or erasure request fans out into one task per party that is recorded as having actually received that person's data — export, update or delete respectively — each with its own deadline, a place to record what was discovered and how many records, and a slot for evidence. The parent request auto-fulfils when every task that was not skipped is complete. The principal's tracking page shows the party, the action and its status, and hides the internal notes.

The important behaviour is the refusal. If the platform cannot resolve which processors hold this person's data, it does not erase anything and does not mark the request done. It refuses, says why, and only an accountable role — compliance administrator, organisation administrator or platform administrator — can override by acknowledging that processors will be notified by hand. A request filed by a nominee waits until someone confirms the nominee's authority. These are deliberate stops, and they are the reason the timeline is worth showing to a regulator.

Refusal, and what gets written down

A refusal stores its reason on the request, writes a rejected event carrying that reason, and emails the principal a closure notice containing it. The operator interface offers a labelled taxonomy rather than a blank box — identity not verified, legally required to retain, a request without foundation, duplicate, not a data principal of this fiduciary, insufficient information to act — so the wording that reaches the person is professional and consistent.

The reason is not optional, and not only in the interface. A refusal whose reason is blank is rejected at the API on every request type, so a direct integration cannot close a request as refused without one either. What the platform cannot check is whether the reason is a good one; that is the judgement below.

Where rights requests break in practice

Almost none of these are software problems, which is why they survive a platform rollout unless someone goes looking.

• The request arrives in a shared support inbox and is answered there. It never enters the portal, so there is no clock, no verification and no record — and that is the request the Board will ask about.
• Nobody notices the deadline because the inbox is checked weekly and the clock is thirty days. The system computes overdue; it does not chase anyone.
• An erasure is marked done in the platform and the person is still in the marketing warehouse, because that system was never recorded as a recipient and so no task was ever created for it.
• Verification is switched off to reduce friction, and the first malicious erasure request succeeds.
• A nominee files on behalf of a deceased relative and staff act before confirming authority, because the confirmation step feels like bureaucracy until it is the thing that saved you.
• The extension is used as a default rather than an exception, and the written reason becomes a copy-pasted sentence that will not survive being read aloud.

What the Rights Manager does not do

It does not find the person's data for you. It resolves which parties received data and creates the task; discovering what sits in a given system, and deleting it there, is work the owning system does. The platform records the outcome and the evidence.

It does not decide whether a request should be refused. Whether retention is legally required, or whether a request has any foundation, is a judgement. The platform captures the decision, the reason and the timestamp.

It does not chase people. There is no scheduler sending reminders, marking requests late by itself or escalating up a hierarchy on a timer. Deadlines are computed and surfaced; acting on them is a human responsibility with a dashboard behind it.

It does not offer data portability, because §11 does not confer it. If you offer portability for commercial reasons, that is a product decision, not a statutory one.