The data subject request handling checklist: the clock, the identity check, the export and delete paths in your app, and the test that proves them

The ICO’s and the EDPB’s guidance on data subject requests sets the rules: one month under GDPR Article 12, no set form, no copy of a passport by default. The EDPB’s own example puts access in the app: a “Download your personal data” option in the user’s account. A data subject request handling checklist for a small SaaS has 10 lines, and four are code you build and test.

The data subject request handling checklist: ten lines from the email to the evidence

A data subject request handling checklist has 10 lines: log the request, write the deadline date, name the right, check identity in proportion, find the person in every system, run the export path, run the delete path, send the deletion to each vendor, record what was kept and reply, and re-run the seeded-user test.

It covers the EU GDPR and the UK GDPR from the controller’s side. If your SaaS is a processor for a business customer, the customer is the controller and you assist it, which EU GDPR Article 28(3)(e) asks of a processor “taking into account the nature of the processing” and “insofar as this is possible”; which role you hold is worked out in GDPR for a small SaaS. The checklist is one part of how to manage SaaS data compliance as a whole, and it is an engineering checklist, not legal advice. Article numbers refer to the GDPR’s text on EUR-Lex, with UK differences named where they change what you do.

A data subject under GDPR is the “identified or identifiable natural person” the personal data relates to, in the words of EU GDPR Article 4(1): in a SaaS, that is a user, a trial signup, a person named in someone else’s workspace or a support contact. For an erasure request, the same ten lines work as a GDPR account deletion checklist.

1. 01 Recognize the request on any channel and log it the same day: the receipt time and channel go on the register row, with the original wording and the owner's name kept beside it. Evidence: the register row.
2. 02 Write the deadline date on the row, one month from receipt. Evidence: the deadline date column.
3. 03 Name the right being used: access (Article 15), portability (Article 20), erasure (Article 17), rectification (Article 16), restriction (Article 18) or objection (Article 21). Evidence: the right requested column.
4. 04 Check identity in proportion: a signed-in session first, more information only where there are reasonable doubts, and a copy of an identity document only where that is necessary, suitable and in line with national law. Evidence: the identity check column.
5. 05 Find the person in every system, using the data map. Evidence: the systems touched column.
6. 06 Run the export path. Evidence: the job's own register entry and the delivery record.
7. 07 Run the delete path. Evidence: the row counts after the job.
8. 08 Send the deletion to every vendor that holds the person and keep each receipt. Evidence: the vendor receipts column.
9. 09 Record what was kept and why, reply in plain words with what was done, and close the row. Evidence: the exceptions and replied-at columns.
10. 10 Re-run the seeded-user test, so both paths still work when the next request arrives. Evidence: the dated test output.

Lines 6, 7, 8 and 10 are code, and they are the build sections below. Line 5 runs on a GDPR data map: one list of systems, which both paths walk. When a user asked to delete their account data, the work starts at line 1, not at the database. The decision rules behind an erasure (whether a ground applies, the preview, shared records, backups) belong to the GDPR delete request runbook for a small SaaS; its steps cover deletion only, while this list covers every right and ends in the code.

In the Production Hardening Sprint, this is deliverable 12.2, Data export and deletion paths.

What is SAR GDPR: the deadline, the identity check, and the letter the requester sent you

A SAR under GDPR is a subject access request: a person asking for a copy of the personal data you hold about them, under Article 15. It needs no set form and no article number, it can in general arrive on any channel you provide, and the reply is due without undue delay and within one month at the latest.

SAR is the everyday UK name. The ICO writes “The right of access, commonly referred to as subject access”, and defines the request itself: “A SAR is a request made by or on behalf of a person for the information they are entitled to ask for under article 15 of the UK GDPR”. DSAR, data subject access request, is the same thing under a longer name. Banks file SARs too (suspicious activity reports), and rescue teams run SAR operations; neither is this one.

GDPR access to data is EU GDPR Article 15: confirmation of whether the person’s data is being processed, “a copy of the personal data undergoing processing”, and context the article lists, among them the purposes, the recipients, where possible the storage period, and the source where the data was not collected from the person. Under the UK GDPR the list also names two complaint routes, to the controller and to the Information Commission (Article 15(1)(ea) and (f)).

Making a GDPR request takes no set form and no named legal basis (the EDPB’s guidelines, paragraphs 52 and 47), and a request sent through a channel you provide, even one other than the one you prefer, is “in general” effective (paragraph 53). A support chat you run counts as such a channel, in my reading. The EDPB’s limit is narrow: a controller that has provided an appropriate channel is not obliged to act on a request sent to a random address or a channel clearly not meant for requests (paragraph 54). The ICO’s UK guidance is wider: a person can make a SAR “verbally or in writing, including by social media”, and to “any part of your organisation”. That is why line 1 trains whoever reads the inbox, not only the founder.

GDPR time to respond: one month, and how the month is counted

The GDPR time to respond is without undue delay and in any event within one month of receipt, under EU GDPR Article 12(3), and the same clock runs for access, erasure and every other right in Articles 15 to 22. Write the deadline date on the register row the day the request arrives.

Under the UK GDPR, Article 12A (in force since 5 February 2026) starts the month at the latest of three moments: receipt of the request, receipt of identity information asked for under Article 12(6), and payment of any fee; and the days spent waiting for information needed to identify what an access request covers do not count.

For the UK GDPR, the ICO counts the SAR response time from “the actual date you receive the request” forward “to the end of the same date in the following month”; when that date does not exist, it uses “the last day of that month instead”, and a deadline on a weekend or public holiday “moves to the end of the next working day”. For the EU GDPR, the EDPB counts the DSAR response time under Regulation 1182/71: a request received on 5 March is due “until and including 5 April”, one received on 31 August is due on 30 September, and a last day on a weekend or public holiday moves to the next working day. The GDPR request time limit is therefore not a fixed number of days; in the ICO’s words it “varies, depending on the month in which you receive the request”, and the ICO’s right of access guidance allows “a 28-day period” for teams that need one fixed number.

Good practice, and my working rule rather than anything the law asks: the register computes the deadline date on entry, and a reminder fires around day 20, which leaves time to chase a slow vendor.

The identity check: a signed-in session before any document

An identity check for a data subject request starts with what the account already proves: a signed-in session or a reply from the verified email address. EU GDPR Article 12(6) lets a controller with reasonable doubts request additional information necessary to confirm identity, so my working rule is no identity document for a request made from inside the account.

The UK GDPR’s Article 12(6)(b) adds that the controller may “delay dealing with the request until the identity is confirmed”. The EDPB’s guidelines on the right of access set the limit from the other side: the controller must make sure “it does not collect more personal data than is necessary to enable authentication” (paragraph 70), the log-in credentials may serve (paragraph 72), and “it is disproportionate to require a copy of an identity document in the event where the data subject making a request is already authenticated by the controller” (paragraph 73). The ICO says the same in UK terms: “You can use verification measures that you already have in place (eg an existing username and password)”.

The check column below is my working rule, built on those two sources; the record column follows the ICO’s note of what to keep instead of a copy of an ID document.

The fresh sign-in or code before a deletion is the first step of an account deletion feature. For a third party, the ICO is plain: “If you have no evidence that a third party is authorised to act on a person’s behalf, you cannot comply with the SAR until you receive the appropriate authority.”

The ICO’s reason for any check is to avoid personal information “being sent to someone else, either accidentally or as a result of deception”. The risk runs both ways. EU GDPR Article 4(12) defines a personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data”, and the EDPB notes that making personal data available to someone not entitled to it “can amount to a personal data breach” (paragraph 80). If an export that reaches the wrong person is one, the next steps are those of a GDPR breach.

GDPR subject access request template: what to do when the letter arrives

A GDPR subject access request template is a tool for the person asking, not for you. The ICO’s public page offers requesters one for deletion and says “There are no specific words that you must use”. Consumer sites publish their own; datarequests.org, for one, offers a sample letter for access requests under Article 15.

What matters on your side is that the letter is a request either way. The ICO’s rule for access is “There are no formal requirements for a valid request”, so a letter copied from a GDPR data deletion request template gets the same register row as a two-line email. A letter built on a data protection letter template may ask for two rights at once, a copy and then erasure; the ICO says to “deal with each request separately”, so the register gets two lines and the export runs before the delete.

The long list in a GDPR request for information template (purposes, recipients, retention, source) is answered from the data map and a privacy policy for a SaaS, not written fresh for each letter.

Your reply is short: what was done, and what was kept under which exception. Where you do not take action on a request, EU GDPR Article 12(4) requires the reasons and “the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy”. Under the UK GDPR, Article 12(4) names a complaint to the controller under section 164A of the Data Protection Act 2018, a complaint to the Information Commission under section 165, and a judicial remedy. The ICO’s page for people asking for deletion is worth reading once, because it shows the letter from the requester’s side.

What goes wrong without it

Each of these five failures sits in the gap between the request process and the code, and each has a checklist line that stops it.

The third row is the one I’d fix first. In my June and July 2026 audits, 7 of the 21 third-party apps had confirmed cross-user or cross-tenant authorization failures, where a logged-in user could read or write another customer’s data. At least 5 of the 21 third-party apps exposed PII or PHI. Those 21 are a selected set of apps I audited, not a random sample and not a rate for AI-built apps in general. An export endpoint with the same failure hands one person’s whole file to any signed-in user who asks for it. The control behind it is server-side authorization, and its absence has a name: broken access control.

The fifth row turns on what soft delete is: a flag that hides a row from the app while every column of it stays stored, which is fine for an undo window and wrong for an erasure reply.

How to build the export and delete paths in your own app

Both paths are authenticated product features. They read the same list of systems (the data map), take the person’s id from the session or from a register row an owner approved, run as background jobs, and write their result to the register. The deletion runbook puts the legal bar plainly: “A reviewed manual workflow meets the right, provided it runs inside the response deadline and reaches every system holding a copy”. A self-serve button is one way to meet the right, not an obligation; the point of the build below is that the reviewed path and the button run the same code.

How to build a data export feature: the self-serve path

A data export feature is 7 steps: a control in account settings behind a recent sign-in, the user id taken from the session, a queued job, one archive built from the data map, a link that opens a signed-in download, a request limit, and a register row written by the job.

1. 01 A Download my data control in account settings, behind a recent sign-in.
2. 02 The server takes the user id from the session, never from a request parameter.
3. 03 It queues a job and returns at once; the job id can be read back only through the same user's session.
4. 04 The job walks every system on the data map and writes one archive.
5. 05 Delivery goes through a controlled channel: the email carries a link to a signed-in page, and the one-time download happens there.
6. 06 A limit on how often one person can request an export, so the job cannot be used to load the database.
7. 07 The job writes the register row itself, so self-serve requests are counted like emailed ones.

Steps 1 and 5 lean on how to export user data from a SaaS, whose build section covers the recent sign-in, the least-privilege worker, the private archive and the controlled link; what goes in the file (portability against access, the manifest, formats, other people’s data) is that article’s job too. Step 5 sends a link to a signed-in page instead of the file itself for one reason: some mail providers’ security features “prefetch URL links from incoming emails”, and Supabase’s auth docs note that a confirmation link is then “consumed instantly”. The size of the step 6 limit is a product choice, so I give no number for it.

A download button does not finish an access request on its own. The EDPB says self-service tools “should never limit the scope of personal data received”, and information the tool cannot give “needs to be provided in a different manner”; the purposes, recipients and retention periods still go in the reply. Data portability is the EU GDPR Article 20 right to receive the data a person provided “in a structured, commonly used and machine-readable format”, and it applies where the processing is based on consent or on a contract and is carried out by automated means; the export article defines it in full.

How to fully delete user account data: one job behind three doors

Fully deleting a user’s account data means one deletion job behind three doors: the in-app button, the support tool and the emailed request all call the same steps, so a request handled by support deletes exactly what the button deletes.

Article 17 applies only where one of its grounds does, and Article 17(3) lists when it does not; whether a ground applies is the runbook’s decision, made before the job runs. The build rule is one job. Hand-written SQL in a database console is never a door, because it deletes whatever the person typing it remembers. The job itself (the order of operations, related records, stored files, the auth user last, safe to run twice) is the account deletion feature named under the identity check. “Fully” means every system on the data map, which is the next section.

If the app ships on the App Store and supports account creation, the App Store pre-submit pass quotes Apple’s rule that such apps must let users start deletion of their account within the app, and covers the submission side. Rectification (Article 16) rides the same doors: an edit form the person can reach, and a support path for the fields they cannot edit.

Delete user data across third party services: the propagation table

Deleting user data across third party services means one call or ticket per vendor that holds the person, across 6 vendor types: payments, product analytics, web analytics, email tools, error tracking and the support desk. Each response id goes on the register row, which stays open until every vendor has accepted the request and, where it documents one, confirmed completion.

Stripe’s delete-a-customer API reference adds that deleted customers “can still be retrieved through the API in order to be able to track their history”, so a deleted customer is a record marked deleted, not an absent one. PostHog states that “User deletion requests are not immediate, but processed asynchronously”, and that while most data is deleted instantly, event data is cleared “during non-peak usage times (weekends on PostHog Cloud)”. PostHog’s data deletion docs say to add delete_events=true to delete the person’s events and delete_recordings=true to also delete their session recordings, so a job that calls the delete without them is not deleting everything the person left there.

Google replaced the legacy User Deletion API (v3), sunset with Universal Analytics, with Google Analytics’ SubmitUserDeletion method in the Admin API, which takes one of the identifiers in the table’s row, so the job has to know which one the app sent. Google’s Help page gives timings (data stops displaying “within 24 hours” and is “permanently removed within the next 63 days”) only for a deletion made in the User explorer report, not for the API method.

For each row, call the API from the deletion job where one exists, open a ticket where none does, and store the response id or ticket number on the register row. A failed vendor call is retried, and the row stays open until it succeeds. The rows to fill come from your processor list, the same vendors your business customers know as sub-processors, and what a sub-processor is decides which vendors belong on it. Each vendor’s duty to help sits in its contract, under the same Article 28(3)(e) assistance clause the scope paragraph at the top quotes with its limits, and that clause is the part of what a DPA agreement is that matters most here. Article 19, telling recipients about an erasure, has conditions of its own, and the runbook’s processors section handles it.

Retention exceptions and backups: what stays, written down

The delete path never deletes everything, and the reply says so. Invoices you keep for tax records, a minimal abuse marker, the register row itself and anything under a legal hold all stay, each with its reason written on the row. The exceptions table and its Article 17(3) grounds are built into the account deletion feature, and the periods come from a data retention schedule for a small SaaS.

Backups are the second thing that stays for a while. How long a copy lives is set by your database backup checklist for startups, and what the law expects of backup copies, and how to re-apply a deletion after a restore, is the runbook’s backup section. I state no period here, because the right one depends on your schedule and your jurisdiction.

The request register: one row per request

The register’s ten columns are my working rule, good practice rather than a legal list. The example column is an example row, invented, with no real person, date or id.

Each row also keeps the person’s internal user id, the original wording and the owner’s name, and never the exported data or an identity document. It lives in a table in the app’s own database or a spreadsheet with restricted access. It is also the evidence a business customer’s questionnaire asks for when it asks how you handle data subject requests, which is one of the questions in how a small team answers a customer’s questionnaire. Each deletion is also written to the audit log, following audit logging best practices.

How to verify it

Verifying the export and delete paths takes a seeded user and 8 checks. Test the data export request end to end: it arrives, it is complete, another user cannot get it, the link expires. Then verify deleted user data is really gone: no rows or files left, every vendor confirmed, exceptions as recorded, and the support path matching the button.

Seed one user in staging, or in a clearly named test tenant, who touches every system on the data map: a profile, rows in each related table, uploaded files, a payment customer in the provider’s test mode, an analytics profile and an email contact. Give that user values you can search for: a unique email address, a unique name and a marker string in a free-text field. Seed a second user, B, the same way, and record both ids and the storage keys of the seeded files. Do the seeding and checks 1, 2, 4 and 8 through the app’s own settings page and the vendors’ dashboards before any script; checks 3, 5 and 6 need direct calls, a database query and the vendors’ APIs.

The export article’s fixture-user checks cover the file’s contents. This test adds the delete path, the vendors, the doors and the cross-user refusal; checks 2 and 4 overlap that list because the delete path cannot be tested without them. Together, the eight checks work as a self-audit checklist for both paths.

1. 01 Request the export as the seeded user through the button. Pass: the archive arrives by the verified channel. Evidence: the register row.
2. 02 Completeness: open the archive next to the data map and tick every system. Pass: each system marked include appears once. Evidence: the ticked map.
3. 03 Authorization: as user B, call the export endpoint with the seeded user's id, call it again with no session, and fetch the seeded user's export job or archive by its id. Pass: B gets only B's own data, the call with no session is refused with nothing queued, and the fetch by id is refused or not found with nothing returned. Evidence: the three responses.
4. 04 The download: open the seeded user's link once (it works), open it again, and open user B's link (from B's own export in check 3) after it expires. Pass: the second open and the expired link are both refused. Evidence: the two refusals.
5. 05 Run the delete through the button, then search every table for the seeded ids and the ids of rows seeded under them, search the text columns for the seeded email, name and marker string, and list the recorded storage keys. Pass: nothing is left except what the register row's exceptions column records. Evidence: the query output and the storage listing, dated.
6. 06 Vendors: read each vendor's own completion signal. Pass: Stripe returns the customer with deleted set to true, PostHog's deletion status shows a verified time, Google Analytics returned a deletion request time, and every other vendor shows the contact gone or suppressed. Evidence: each receipt on the register row.
7. 07 Exceptions: compare what remains with the register row's exceptions column. Pass: they match, and nothing more remains. Evidence: the remaining rows beside the exceptions column.
8. 08 The doors: delete user B through the support path. Pass: the same result as the button gave in checks 5 to 7. Evidence: the second register row.

Check 5 counts rows instead of trusting the schema, and it searches for more than the user id because a project’s media rows carry the project’s id, not the user’s, and a copied email address carries no id at all. An AI content system I audited ran on SQLite and never turned on foreign_keys = ON for its connection, so every declared ON DELETE CASCADE was inert, and deleting a project or user left orphaned rows forever, including media rows still holding live object-storage keys. The take I draw from it: a delete path is proven by counting what is left for the seeded user in every table and bucket, never by reading the cascade rules in the schema. The row-count query itself lives with the account deletion feature.

Check 6 does not pass on a dashboard looking empty. A PostHog deletion whose delete_verified_at is still null keeps the row open. Google’s method returns only the time the request was received and its page states no completion time, so that row closes on the deletionRequestTime.

Keep the test in the suite and re-run it about once a month, and after any change that adds a table or a vendor; that is my working rule. Give the seeded users rows in every new table, so a table the delete path misses shows up as leftovers in check 5, and put a new vendor on the data map before it holds anyone’s data: checks 2 and 6 read the map, so they cannot catch what it lacks. “Really gone” has one limit. Backups and vendor-side logs age out on their own retention periods, and the reply says that instead of claiming otherwise.

In the Production Hardening Sprint, deliverable 12.2 is verified this way: “Export and delete a seeded user’s data; verify completeness, authorization, and recorded exceptions.”

Where the sprint does this

In the sprint, deliverable 12.2 in the published scope implements authenticated export and deletion workflows covering related systems and documented retention exceptions, verified by the line quoted above. Beside it, 12.1 documents what personal data is stored, where it lives, why it is collected, and who can access it, and 1.8 builds the account deletion flow, covering related records and stored assets under the documented retention rules. The result for every scope item, the work completed and its verification evidence go into the production readiness report, deliverable 13.1. We include only the supporting interfaces the listed controls need, such as session management, account deletion and billing self-service; new features that change the product’s core capabilities are separate work. Legal advice and certification are separate services: the sprint implements and documents the technical data-handling controls. Hosting, paid tools, and API usage remain in your accounts.

Common questions about data subject requests

What happens if SAR is late?

The person can complain to a supervisory authority under EU GDPR Article 77, and failures on data subjects’ rights under Articles 12 to 22 fall in the Article 83(5) fine tier: up to 20,000,000 EUR or, for an undertaking, up to 4 % of total worldwide annual turnover of the preceding financial year, whichever is higher. In the UK, Article 77 was omitted from 19 June 2026; the person complains to the controller under section 164A of the Data Protection Act 2018, which the controller must acknowledge within 30 days, or to the Information Commission under section 165, and the UK GDPR’s Article 83(5) tier is up to £17,500,000 or 4 %, covering Articles 12 to 21. The practical step is the same in both places: reply now, say why it is late, and record the reason on the register row.

Can I extend the SAR deadline?

Yes, by two further months where necessary, taking into account the complexity and number of the requests, under EU GDPR Article 12(3), provided you tell the person within one month of receipt, together with the reasons for the delay. Under the UK GDPR, Article 12A(3) and (4) allow the same two months, by notice with reasons given within one month of the relevant time. For UK requests the ICO adds how to count it: “You must calculate the extension as three months from the original start date”, so a request received on 7 August and extended runs until the end of 7 November.

What can be excluded from a DSAR?

Three things can limit a DSAR under the EU GDPR: other people’s rights (Article 15(4) says the copy “shall not adversely affect the rights and freedoms of others”), manifestly unfounded or excessive requests under Article 12(5), where you may charge a reasonable fee or refuse and carry the burden of showing why, and restrictions set by Union or member state law under Article 23, which need counsel. In the UK, the ICO lists a set of exemptions from the right of access, to be weighed “on a case-by-case basis”, and UK GDPR Article 15(1A) limits the person to what the controller can provide “based on a reasonable and proportionate search”.

What is the difference between GDPR and DSAR?

GDPR is the regulation; a DSAR is a request made under it, using the Article 15 right of access. The person does not have to name either: the ICO says a requester does not have to include the phrases “subject access request”, “right of access” or “article 15 of the UK GDPR”, and “It just needs to be clear that they are asking for their personal information.”

What is a data subject example?

A newsletter subscriber, a job applicant and a person named in a file a customer uploads are all data subjects under Article 4(1), because each is an identified or identifiable natural person the data relates to. A company is not one: the definition covers natural persons only.

Does the US have a GDPR equivalent?

Not a single federal one. The Congressional Research Service’s report Preemption and Privacy Law (August 29, 2025) says: “Rather than adopting a single comprehensive consumer privacy law, Congress has enacted various privacy statutes that apply to particular industries and subcategories of data.” It also counts at least 19 states that have adopted comprehensive consumer privacy laws. California’s law, the CCPA, gives rights to know and delete; the California Privacy Protection Agency’s FAQ says businesses “must substantively respond to your request to delete, correct, or know your personal information within 45 calendar days” and can extend “by another 45 days (90 days total) if they notify you”. It applies to for-profit businesses that collect consumers’ personal information, determine why and how it will be processed, do business in California, and meet any of its thresholds. The same export and delete paths serve both laws.