Somebody asks for their data and a statutory clock starts, but nobody can list the systems it lives in. Here is the model behind a tracker, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A data subject request tracker is four parts: intake that starts the statutory clock on the day the request arrives, identity verification before disclosure, a searched system inventory, and evidence. The deadline is the part that makes it different from any other queue. It is set in law, it starts whether or not anybody noticed the request, and the only defence against missing it is a system inventory that already existed.
Subject requests
6
Open requests
1
Inside 5 days
18
Systems in the inventory
0
Completed late, 12 months
Request 2026-114
Access request · arrived 14 August · identity verified 15 August
What was searched, and what was found
You run privacy, legal or compliance. You already know your obligations. What you want is for the clock to start automatically, the search to be worked against a real list, and the evidence to exist without assembling it afterwards.
What happens from the moment a request arrives to the moment you can prove what you did.
Whatever channel it came through, including a reply to a marketing email. The deadline is derived from that date, not from today.
Proportionate to what is being asked for, recorded, and required before the workflow can reach disclosure.
From a maintained inventory of what holds personal data, assigned to each system's owner, rather than from anybody's memory.
A request cannot complete until each system has reported what it found or that it found nothing.
The specific exemption, per item. Withholding is often right; withholding without a reason is the finding.
What was sent, when, to whom, and a queue ordered by days remaining so nothing is missed quietly.
This is not a ticket queue with a due date. It is four parts, and the third one is what decides whether you can actually complete a request.
Every request logged with the date it arrived, whatever channel it came through, and the statutory deadline derived from that date rather than from when somebody noticed.
A recorded step before any data is disclosed, proportionate to what is being asked for. This protects the subject rather than the company.
The systems that hold personal data, what kind, who owns each, and how a search is performed there. The search is worked against this list, not from memory.
What was searched, what was found, what was disclosed, what was withheld and on what basis, when it was sent, and to whom.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Intake from any channel, with the deadline derived rather than typed.
In this Helix project, build me a data subject request tracker.
A request records: the subject's name and contact details, the date it
arrived, the channel it arrived through, the request type, what they
actually asked for in their own words, and who received it.
Request types to seed: access, deletion, rectification, portability,
restriction, objection, and a general question. Let me edit that list.
Now the important part. Derive the statutory deadline from the arrival
date and a period I configure per request type, and treat that derived
date as the thing the whole app is organised around. The clock starts when
the request arrives, not when somebody gets round to logging it, so let me
backdate the arrival date and have everything recalculate.
Support extending the deadline where the law allows it, with the reason
and the notification to the subject recorded, because an extension that
was never communicated is not an extension.
And accept requests from any channel. People send these by replying to a
marketing email or mentioning it in a support ticket, and an intake that
only accepts a form will miss those entirely.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Deriving the deadline from the arrival date rather than the logged date is the whole design. A request found in an inbox three weeks late has three weeks less, and the tracker should say so loudly.
Because the failure mode here is causing a breach while trying to comply.
Add identity verification as a required step before any data can be
disclosed.
Record what was checked, by whom, and when. Let me define what is
proportionate per request type: confirming a signed-in account may be
enough for one thing, and a deletion request from an unverified email
address needs more.
Do not let the workflow reach a disclosure state until verification is
recorded. Sending one person's data to somebody impersonating them is a
breach caused by trying to be compliant, and it is a well-documented
attack rather than a hypothetical one.
Handle requests made on somebody's behalf: a parent, a solicitor, an
authorised agent. Those need evidence of authority recorded as well as
identity, and they are the ones most likely to be got wrong.
Track the clock through verification. Time spent waiting for the subject
to verify usually does not count against you, but only if you recorded
when you asked.The inventory is what makes completion possible.
Build a system inventory, and make the search work against it.
Each system records: name, what categories of personal data it holds, a
named owner, how a search is performed there, whether deletion is possible
and what it means in that system, and any retention rule that overrides a
deletion request.
When a request is opened, generate a search task per relevant system,
assigned to that system's owner. Each task records what was searched for,
what was found, and what was done, or that nothing was found.
A request cannot be completed until every task is answered. Searching from
memory guarantees a system gets missed, and the missed system is always
the one nobody thinks of, like the backup, the analytics tool, or the
spreadsheet on somebody's laptop.
Flag any system in the inventory with no owner, and any system not
reviewed within a period I set. An inventory that has gone stale is worse
than an obviously incomplete one, because people trust it.Worth knowing. The inventory is the part that takes real work and the part that makes every subsequent request cheap. Build it once, maintain it, and the rest of this is administration.
What you did, and whether you are about to miss one.
Record the response: what was disclosed, in what format, when, and to whom.
Record what was withheld and the specific exemption relied on. Withholding
something without a stated basis is the finding, not the withholding.
Keep the outbound package itself, so what was actually sent is preserved
rather than reconstructed.
Then the views. A dashboard ordered by days remaining, not by date
received, with anything inside a threshold I set highlighted and anything
overdue at the top and impossible to miss. Notify the owner and their
manager as the deadline approaches.
And reporting: requests by type and month, median days to complete, how
often each exemption was relied on, which systems take longest to search,
and any request completed after its deadline with the reason. That last
list should be empty, and if it is not, it is the first thing to fix.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<every system in your inventory>. Search for the individual and record
what was found, or that nothing was. This is the work.
<Okta>. Authenticate the people handling requests and read the group that
says who is allowed to. This is personal data about identified
individuals, so the app should trust the group and nothing else.
<Google Drive>. Hold the response package, so what was sent is preserved
rather than reconstructed.
<Gmail>. Acknowledge the request and deliver the response, both
timestamped against the statutory clock.
<OneTrust>. If privacy operations already run somewhere, read requests
from there rather than running a second intake.
<Salesforce>. Search the CRM, which is almost always the largest single
store of personal data.
<Zendesk>. Search support history, which is where the most sensitive free
text usually is.
<Amplitude>. Search analytics, which is the system people forget holds
anything identifying.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This app handles personal data about identified individuals and produces regulatory evidence, so set Access Control tightly before anyone uses it.
This one searches every system that holds personal data, which is exactly why the inventory has to exist first.
Every system in your inventory
Search for the individual and record what was found, or that nothing was. This is the work.
Okta
Authenticate the people handling requests and read the group that says who is allowed to. This is personal data about identified individuals, so the app should trust the group and nothing else.
Google Drive
Hold the response package, so what was sent is preserved rather than reconstructed.
Gmail
Acknowledge the request and deliver the response, both timestamped against the statutory clock.
OneTrust
If privacy operations already run somewhere, read requests from there rather than running a second intake.
Salesforce
Search the CRM, which is almost always the largest single store of personal data.
Zendesk
Search support history, which is where the most sensitive free text usually is.
Amplitude
Search analytics, which is the system people forget holds anything identifying.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It handles personal data about identified individuals and produces evidence a regulator may ask for, so how it is run is the larger half of the job.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
This app holds personal data about identified individuals and the record of what was disclosed. SSO means every action is attributable, and access is scoped tightly to the people handling requests.
App Security
Searching the systems that hold personal data needs real access to each one. Granting it to the app rather than pasting keys into it means access is scoped, revocable, and itself auditable.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It logs each request on the date it arrived, derives the statutory deadline from that date, requires identity verification before disclosure, generates a search task per system holding personal data, and records what was found, disclosed and withheld.
When the request arrives, not when it is logged. A request sitting unnoticed in an inbox for three weeks has three weeks less remaining, so intake should let you backdate the arrival date and recalculate everything from it.
Because sending one person's data to somebody impersonating them is a breach caused by trying to comply. Verification should be proportionate to what is being asked for, recorded, and required before the workflow can reach a disclosure state.
Because the system that gets missed is always the one nobody thinks of: the backup, the analytics tool, the spreadsheet on a laptop. A maintained inventory of what holds personal data, with an owner per system, is what makes completion actually possible.
The specific exemption relied on, per item. Withholding something is often correct; withholding it without a stated basis is the finding. Keep the outbound package too, so what was sent is preserved rather than reconstructed later.
Yes for the app, and the prompts here are written for Claude Code, Codex or Cursor. The work that is not in the code is the system inventory, and that is also the part that makes every future request cheap.
Legal and Compliance
Version your policies, assign them to the right people, collect attestations with evidence, and produce the completion report an audit asks for. Prompts to build it, and what it takes to run it.
IT and Operations
Request access against a defined catalogue, route it to the system owner, grant it with an expiry, and produce the evidence an access review needs. Prompts to build it, and what it takes to run it.
Legal and Compliance
Tier vendors by the risk they actually carry, ask each tier only what it warrants, track findings to closure, and re-review on a schedule. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.