Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Data request handler series ~6 min read

A data request handler on AWS for a few dollars a month

A subject access request rarely arrives labelled as one. It arrives as an angry email that ends “and send me everything you have on me”, in an inbox that gets forty messages a day, and it sits there. Three weeks later somebody notices, and a thirty-day statutory window has nine days left in it and nobody has started gathering anything. This post walks through a small system whose most valuable single feature is noticing on day zero.

man driving motor scooter delivering goods
Photo by Lucian Alexe on Unsplash

Key takeaways

  • The clock starts on arrival. Recognising a request the same day is most of the value.
  • Requests arrive worded as complaints, not as legal notices, and both count.
  • Gathering is per system and each system is asked once, with a record of what it returned.
  • A person reviews every package before it leaves, and executes every deletion.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: a request recognised, data gathered, a package reviewedThree boxes across the top sit outside the AWS account. On the left, An ordinary inbox where requests arrive. In the middle, Your systems, each holding something. On the right, Whoever handles it: the person who reviews and sends. Each connects by an arrow to the AWS account container below. Messages flow down into the account. Each system reports what it holds. A package to review goes back out. Inside the AWS account are three components in a row. On the left, the Recogniser, which asks whether this is a request and starts the clock. In the middle, the Gatherer, which asks every system and records what came back. On the right, the Reviewer, which produces a package checked before it goes. A note at the bottom says nothing is released or deleted without a person; the system prepares and a person acts.AWS ACCOUNTAn ordinary inboxwhere requests arriveYour systemseach holding somethingWhoever handles itreviews and sendsRecogniseris this a request?start the clockGathererask every system,record what came backReviewera package, checkedbefore it goesmessageswhat each holdsa package toreviewNothing is released or deleted without a person. The system prepares; a person acts.
Fig 1. Three things outside the account, three pieces inside it. The recogniser is doing the highest-value work, because everything downstream is only useful if it starts on time.
  • Database
  • App integration
  • Analytics
  • People

The clock starts on arrival

This is the fact the whole design turns on. Response deadlines run from when the request was received, not from when it was recognised, opened or forwarded to the right person. A request that sits unread for three weeks has already consumed most of its window.

So the most valuable thing this system does is notice, on the day, in an inbox where nobody was looking for one. Everything after that — the gathering, the package, the review — is useful and would be manageable by hand if somebody had three weeks. The three weeks is what gets lost.

What runs (the inside)

  • The recogniser. Reads inbound mail and asks one narrow question: is somebody asking for their data, or asking for it to be deleted? Part 2 covers the wording it has to catch and the wording it must not over-catch.
  • The gatherer. Asks each system what it holds about this person, records the answer including “nothing”, and assembles it. Part 3 is about the systems that cannot be asked programmatically, which is most of them.
  • The reviewer. Presents the package with everything that would be sent, highlights what needs redacting, and requires a person to release it. Part 4.

One request, end to end

One data request from arrival to sent package, in five stagesA horizontal row of five boxes joined by arrows. Arrives: worded as a complaint. Recognised: the clock starts on day zero. Verified: proportionately. Gathered: every system asked. Reviewed and sent: by a person. A note says the second box is worth more than the other four put together.ONE REQUEST, END TO ENDArrivesworded as a complaintRecognisedclock starts, day zeroVerifiedproportionatelyGatheredevery system askedReviewed and sentby a personThe second box is worth more than the other four put together.
Fig 2. The same system as one line. Recognition on day zero is what turns a panicked scramble into an ordinary task with weeks of margin.
  • App integration
  • Security & identity
  • Management
  • Analytics
  • People

In plain words

An email arrives on the 8th complaining about a delivery, and the last line says “please also send me a copy of all the personal data you hold about me and then delete my account”. That is two requests in a sentence at the end of a complaint, and in an ordinary inbox it is genuinely easy to miss.

The recogniser catches both, records the arrival date as day zero, and tells whoever handles these within the hour. Verification is straightforward: the email came from the address on the account. The gatherer asks the six systems that hold anything, five answer within seconds, and the sixth — a booking tool with no export API — becomes a task for a person with three days on it.

By the 11th the package is assembled: the order history, the messages, the account record, the support tickets, and a note that the marketing tool holds only an email address and a subscription state. Somebody spends twenty minutes reviewing it, redacts two lines of an internal note that mention another customer, and sends it on the 12th — four days in, with the deletion scheduled separately once the access request is satisfied.

Design rules that shaped every decision

  • The clock starts on arrival. Everything is measured from that date, not from recognition.
  • Recognise generously and confirm cheaply. A false positive costs one clarifying question.
  • Ask every system, and record “nothing” as an answer. An unasked system is not the same as an empty one.
  • Verify proportionately. Over-verification is a recognised way of obstructing a request.
  • A person reviews and releases. Nothing leaves and nothing is deleted automatically.
  • Deletion is a plan a person executes, with the record of what was deleted kept.

Why this shape

Businesses that get these wrong almost never do so out of unwillingness. They do it because a request arrived worded as something else, went unnoticed, and by the time somebody was looking at it the remaining time was not enough to ask six systems and review the answers properly.

So the design spends its effort on the two places time is lost: recognition, which is one model call on inbound mail, and gathering, which is a fan-out that would otherwise be somebody emailing colleagues. The review is deliberately manual because it is the part where judgement is genuinely required and where an error is expensive.

The next four posts walk through each piece: how a request is recognised, how the requester is verified, how the data is gathered, and how the package is reviewed and delivered. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts