Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Data request handler series ~5 min read

How a data request gets recognised

Nobody writes “I am exercising my right of access under Article 15”. They write “what information do you actually have about me”, usually while annoyed about something else, and a system that only recognises the formal wording will recognise almost nothing.

Key takeaways

  • No formal wording is required, and almost nobody uses it.
  • Recognise generously; a false positive costs one clarifying question.
  • Four kinds: access, deletion, correction, and objection to processing.
  • “Delete my account” is usually not a deletion request, and asking is how you find out.
  • Requests arrive by post, by phone and in person, and those need a manual entry path.

What counts

What somebody writesWhat it isRecognised?
“Send me all the data you hold on me”An access requestYes
“What information do you have about me?”An access requestYes
“Delete everything you have about me”A deletion requestYes
“Please close my account”Probably not a deletion requestAsk
“Stop emailing me”A marketing withdrawal, not a data requestNo
“Why do you have my phone number?”Possibly an access requestAsk

The fourth and sixth rows are why the system asks rather than deciding. Closing an account and erasing all personal data are different things with very different consequences, and a substantial proportion of people who say the first do not mean the second. One clarifying question resolves it and takes a day off nothing.

Recognise generously

How an inbound message is recognised as a data requestA vertical chain of five steps entered by a box labelled Inbound message, from any inbox. Step one applies cheap filters first for auto-replies and bulk mail; a hit exits to Ignore with no model call. Step two asks whether this could be a request, with a single Bedrock call; no exits to Not a request, which is most messages. Step three asks which kind: access, delete, correct or object; unclear exits to Ambiguous, which asks one question. Step four records day zero as the arrival timestamp in a requests table where the clock lives. Step five tells whoever handles it within the hour. A note says day zero is the arrival timestamp and not the recognition timestamp, always.AWS ACCOUNTInbound messageany inboxCheap filters firstauto-reply, bulkIgnoreno model callyesCould this be a request?one Bedrock callNot a requestmost messagesnoWhich kind?access, delete, correct,objectAmbiguousask one questionunclearRecord day zerothe arrival timestampRequests tablethe clock lives hereTell whoever handles itwithin the hourDay zero is the arrival timestamp, not the recognition timestamp. Always.
Fig 1. How a request is recognised. The distinction in the note is the one that matters legally and is the easiest to get wrong in a schema.
  • Database
  • App integration
  • Machine learning
  • Security & identity
  • Management
  • Analytics
  • Front-end & mobile

Why generous

The two errors are not symmetric. A false positive means somebody asks a customer “just to check — are you asking for a copy of your data?” and gets told no, which costs one email and reads as attentive. A false negative means a statutory deadline passes without anybody knowing there was one.

So the threshold is set low and the confirmation is cheap. In practice the system flags perhaps three messages a month in a small business, one of which is a genuine request and two of which are resolved by asking.

Day zero versus recognition

Two timestamps, and a schema with only one of them is a schema that will eventually report a deadline wrongly. The arrival timestamp is what the deadline runs from. The recognition timestamp is how you measure whether the recogniser is working.

Keeping both also produces the single most useful operational number in the system: the gap between them. A median gap of under an hour means the recogniser is doing its job; a gap of eleven days on one request means something arrived in an inbox that is not being watched.

The channels that are not email

Five channels a data request can arrive throughA horizontal row of five boxes. Email: recognised automatically. Web form: explicit and easiest. By post: somebody types it in. By phone: logged with the date. In person: the same manual path. A note says the manual path exists so the clock is recorded correctly rather than so it is convenient.A REQUEST DOES NOT HAVE TO ARRIVE BY EMAILEmailrecognised automaticallyWeb formexplicit, easiestBy postsomebody types it inBy phonelogged, with the dateIn personsame manual pathThe manual path exists so the clock is recorded correctly, not so it is convenient.
Fig 2. The channels a request can arrive through. The manual entry path is not a convenience feature; it exists so that a request made by phone gets the same clock as one made by email.
  • App integration
  • Front-end & mobile
  • People

The manual entry form asks for one thing that is easy to get wrong: the date the request was made, not the date it was entered. Somebody typing up a letter that arrived on Tuesday on the following Monday must record Tuesday, and the form defaults to today with a prompt rather than silently accepting it.

Next: verifying who is asking.

All posts