Data request handler
A small system that spots a subject access or deletion request in an ordinary inbox, records the statutory clock, verifies who is asking, gathers what every system holds, and puts a package in front of a person to check before anything is sent. It never releases or deletes anything unreviewed. Seven posts on the same system — one diagram at a time — with a cost breakdown and an engineering reference at the end.
- 01
A data request handler on AWS for a few dollars a month
The whole system on one page — a recogniser, a gatherer and a reviewer — built around the fact that the deadline runs from arrival.
- 02
How a data request gets recognised
What wording counts as a request, why generous recognition with a cheap confirmation is the right trade, the requests that are not requests, and the channels other than email.
- 03
How a requester gets verified
What proportionate verification means, the three tiers of confidence, why over-verification is itself a failure, and how third-party requests are handled.
- 04
How the data gets gathered
Why every system is asked rather than the obvious ones, why “nothing” is recorded as an answer, the register that makes this possible, and the systems that need a person.
- 05
How a package gets reviewed
What has to be redacted before a package leaves, why deletion is a plan a person executes, what the response letter says, and the numbers worth watching.
- 06
What the data request handler costs
About $18 a month. One Bedrock read per message screened is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.
- 07
Engineering reference: the data request handler architecture
Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the schemas and the exact model id.
Frequently asked questions
- What is a data request handler?
- A small serverless system that recognises a data subject request in an ordinary inbox, starts the statutory clock, verifies the requester, gathers what each system holds, and presents a package for a person to review. A person sends it; the system never does.
- Why does recognising it matter so much?
- Because the clock starts when the request arrives, not when somebody notices it. A request worded as an ordinary complaint that sits unread for three weeks has consumed most of the response period before anybody has started.
- Does it delete data automatically?
- No. It produces a deletion plan naming every record in every system, and a person executes it. Automatic deletion across systems on the basis of an email is not a risk worth taking.
- How does it verify who is asking?
- Proportionately. An email from the address already on the account is usually sufficient; a request from an unknown address for somebody else’s data needs more. Over-verifying is itself a way of obstructing a request.
- What does it cost to run?
- A couple of dollars a month. Request volume is low even where it feels high. See part six.