The intake end of a rights request, where most of them go wrong

A published URL, because Rule 14 requires the means to be published

Rule 14 obliges you to publish, on your website or app, the means by which a data principal makes a request to exercise their rights, and the particulars they will need to give. That is a publication requirement, not just a process requirement — the route has to be findable by somebody who has never dealt with you before and has no account.

Each organisation gets a public request URL carrying its own slug. It is a real page with a real form, not a mailto link. The operator dashboard renders it as a copyable link and a QR code, which matters for the organisations whose principals arrive through a printed notice or a branch counter rather than a website footer.

One small behaviour worth knowing: an unknown slug returns a genuine 404 with a suggestion if something close exists. An earlier version returned a fake success page for any slug, which felt tidy and was a transparency failure — a person who submits a request to a URL with a typo and sees "thank you" believes they have exercised a right they have not.

Verifying a person without collecting more data than you need

The form takes an identifier — an email address or a phone number — and the verification channel follows from the type rather than being chosen. Give an email, get an emailed code; give a phone number, get an SMS. There is no separate identity-document step at intake, because requiring one would mean collecting sensitive data from everybody in order to serve the minority of requests where it is genuinely needed.

The constants: six digits, valid fifteen minutes, five verification attempts per code, at most ten codes in any rolling twenty-four hours, thirty seconds between resends, and thirty failed attempts over the life of a request before the person has to file a new one. The code is stored as a hash and compared in constant time; the raw value never exists in a table. Requests arriving through an authenticated integration skip verification entirely, on the basis that the calling system has already established who the person is.

Verification returns eleven distinct error codes rather than a generic failure — expired, consumed, attempts exceeded, cooldown, resend limit, wrong format, no recipient on file, already verified, not required. That granularity is not fastidiousness; it is what lets the portal tell somebody why their code did not work, which is the difference between a person retrying and a person emailing your support desk instead.

The clock starts at verification, not at submission

This is the single most consequential detail on the page and it is almost never stated. The response deadline is set when the identity is verified, not when the form is submitted. A request sitting unverified is not a request yet.

The reason is practical. Anyone can type your customer's email into a public form. If submission started the clock, a single script could put a thousand unverifiable requests on your books and each one would be running down a deadline you cannot meet because you cannot lawfully act on any of them. Starting at verification means the clock only runs against requests you can actually work.

The window itself is a tenant setting with a thirty-day default, and an extension mechanism that requires the new date to be in the future, to stay within the configured maximum, and to carry a written reason — which is emailed to the person rather than recorded internally. Requests that are never verified are cleaned up after a day rather than accumulating.

Keeping the queue clean before a human sees it

A public form on the internet attracts everything a public form on the internet attracts. Four controls run before anything reaches the queue.

• A honeypot field. Filled in, and the response is an ordinary success page while nothing is persisted. Telling a bot it failed only teaches it to try differently.
• Per-identifier rate limiting — three submissions an hour for the same email or phone against the same organisation.
• Per-address rate limiting — ten an hour from one IP across all tenants, which catches the script that is working through a list.
• Route-level limits on the public and verification endpoints, tighter on the code-issuing ones than on the form.

Routing, and what it does when it does not know

Assignment runs on an ordered rule list, first match wins, lowest priority number first. A rule matches on the request type, the domain part of the identifier, the identifier type, the grievance category or a substring of the description, using equals, not-equals, contains or in.

The identifier domain condition is the one that earns its keep in practice: requests from a particular corporate domain route to the person who handles that account. And a rule with no conditions matches everything, which makes it a clean final catch-all to the data protection officer rather than a special case in the code.

Two behaviours are worth stating because they are deliberate. An unrecognised field or operator fails closed — no assignment, rather than a guess. And the router as a whole fails open: if it errors, the request lands unassigned for human triage and public submission is never broken by a bad rule. Those are opposite defaults for opposite risks, and both are the right way round.

The link the person keeps

Every request gets a signed token, and the link built from it is what goes in every email to the principal. They use it to check status, add an attachment, withdraw the request, and download whatever you send back — without an account, because requiring one would mean creating an identity for somebody who came to you about identity.

The token is long-lived, stored only as a hash, and re-signed on every material transition — acknowledgement, extension, fulfilment, rejection, escalation. Rotating on transition means the most recent email always carries a current link and a leaked older one is worth less.

What the portal shows is a deliberately narrow projection of the record. Where per-vendor fulfilment tasks exist, the person sees the party name, the action, its status and its deadline; internal notes and evidence URLs are stripped server-side rather than hidden with CSS.

What intake cannot fix

It cannot capture requests that never reach it. The most common gap in a rights programme is not a broken portal, it is a portal plus four other doors — a support inbox, a sales rep, a WhatsApp number, a branch. Publishing the portal is the easy half; routing everything else into it is the half that takes a quarter.

It also cannot tell you whether the person is your data principal at all. Verification proves control of an email address. Whether the holder of that address is somebody whose personal data you process is a lookup in your systems, and "not a data principal of this fiduciary" is one of the recorded refusal reasons precisely because it is a real and frequent answer.