How to build data subject request automation

What matters here

• Search from an inventory, not from memory. The system somebody forgets is the one that makes the response wrong.
• Verify identity before disclosing anything. Handing a data export to an impersonator is a worse breach than a late response.
• Start the clock at receipt. Statutory deadlines do not wait for somebody to notice the request.
• Record the systems that held nothing. A negative result is evidence and it is the half people never keep.
• Deletion needs a legal-hold and retention check first. Some records cannot be deleted and saying so is the correct answer.

Who this is for

You run privacy operations, legal or data protection. Requests arrive by several routes, the search is manual, and the evidence that it was done properly is an email thread.

How it works in practice

The sequence, from a request arriving to a defensible response going out.

1. 1

   Requests are taken from every route they arrive on

   A form, the privacy inbox, support, and sometimes a letter. All of them start the clock.

2. 2

   Identity is verified before anything is searched

   Proportionate to what is being asked for, and always before disclosure.

3. 3

   The inventory drives the search

   Every system on the register is searched, including the ones that will hold nothing.

4. 4

   Results are assembled with their source

   What was found, where, and what was excluded under an exemption with the reason.

5. 5

   Legal reviews before anything is disclosed

   Third-party data, privileged material and exemptions are judgements rather than rules.

6. 6

   The response is delivered and the whole thing recorded

   Including the systems that held nothing, because a negative result is evidence.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then build the system inventory first

   The inventory is the control. Everything else is mechanism.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Salesforce, Zendesk,
   Marketo, Snowflake, Google Drive, Gmail and Jira, or whatever we run
   in those seats. Before you plan anything, tell me which of them are
   already authenticated in the workspace, because I do not want a
   connector stubbed that I have not authenticated.
   
   Then build the personal data inventory as a table: system, what personal
   data it holds, how to search it by email and by name, whether search is
   automated or manual, an owner, and a retention rule.
   
   This table is the control. Anything not on it will not be searched, and a
   response that omits data we hold is a failure of the response, not 
   a gap in it.
   
   Flag any system with no automated search route. Those become tracked
   manual tasks with a deadline, not something somebody remembers.

   The inventory needs re-reviewing on a schedule. A new system adopted six months ago and never added is exactly how a response ends up incomplete.

2. 2

   Take requests from everywhere, start the clock at receipt

   The deadline does not wait for somebody to notice.

   Headless skills build-workflow

   Copy

   Use build-workflow. Accept requests from every route: the privacy form,
   the privacy inbox, a support ticket flagged as a rights request, and a
   manual entry for anything arriving by post.
   
   Start the statutory clock at receipt, not at triage. A request sitting
   unread in an inbox for four days has consumed four days of the deadline.
   
   Classify the type: access, deletion, rectification, portability,
   restriction or objection. Each has a different path and a different
   answer.
   
   Record the jurisdiction, because the deadline and the exemptions differ,
   and a workflow that assumes one regime will be wrong for the other.

3. 3

   Verify identity before disclosing anything

   Disclosing to an impersonator is worse than being late.

   Copy

   Verify before any search result is disclosed, proportionate to the
   request:
   
     A logged-in account holder confirming from the account is often
     sufficient
     An email-only requester needs a verification step
     Anything high risk, such as bulk export or deletion, needs stronger
     verification
     A request made on somebody else's behalf needs evidence of authority
   
   Verify before disclosure, and record how it was verified.
   
   Never disclose personal data to somebody who has only asserted an
   identity. A late response is a compliance problem; a disclosure to an
   impersonator is a breach, and one of those is considerably worse than the
   other.

4. 4

   Search everything on the inventory, including the empties

   A negative result is evidence, and it is the half nobody keeps.

   Headless skills tray-gotchas tray-patterns

   Copy

   Use tray-gotchas, then search every system on the inventory, not the ones
   somebody remembers.
   
   Search on email, then on name, then on any other identifier we hold, such
   as a customer id or a phone number. People appear under a personal
   address in one system and a work address in another.
   
   Record a result for every system including the ones that found nothing.
   Searched and found nothing is evidence. Not searched is a gap, and after
   the fact the two are indistinguishable unless you wrote it down.
   
   Handle: a system that is down, which retries and then escalates rather
   than being silently skipped; a match that is a different person with the
   same name, which needs a human; and free text fields such as support
   notes, where personal data hides in a paragraph instead of a field.

5. 5

   Handle deletion carefully, and track the clock

   Some records cannot be deleted, and saying so is the right answer.

   Copy

   For a deletion request, check before deleting anything:
   
     A legal hold, which overrides the request entirely
     A retention obligation, such as financial records that must be kept
     A contract still in force
     A legitimate interest that has been assessed and documented
   
   Where data cannot be deleted, respond saying so with the reason. That is
   a correct response, not a failure, and the reason is what makes it
   defensible.
   
   Where it can, delete and verify, including in backups per the documented
   policy, and record what was deleted and when.
   
   Then track the clock: days remaining on every open request, anything
   inside a week of its deadline, and an extension only where the regime
   allows one with the justification recorded.

6. 6

   Validate it, then hand the inventory to privacy

   Because the inventory is never finished.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Test with a request for somebody who exists in
   several systems under different addresses, which is the case that finds
   the gaps.
   
   Then open the same workflow in Tray Build so the privacy team can
   maintain the system inventory, the retention rules and the verification
   thresholds in the visual canvas. New systems are adopted constantly and
   an unmaintained inventory is the failure mode.

What it connects to

Personal data is everywhere, which is why the inventory instead of the integrations is the control.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides