GDPR requests workflow: export, correction, deletion blueprint

What problem this workflow solves

A GDPR requests workflow is the difference between handling privacy requests calmly and scrambling every time an email arrives. People can ask you to export their personal data (access), fix it (rectification), or delete it (erasure). These requests are normal for any app that stores profiles, messages, orders, support tickets, or analytics identifiers.

Ad hoc handling breaks down fast. A request lands in someone’s inbox, gets forwarded around, and turns into manual database checks and screenshots. Deadlines get missed, the wrong person’s data can be exported by mistake, and teams forget data that lives outside the main app database (like email tools, payment providers, or logs). The biggest gap is usually the same: no clear audit trail that proves what you did and when.

A well-designed workflow makes requests predictable and repeatable. It should deliver three outcomes: speed (the request routes to the right owners with due dates and reminders), accuracy (the export, correction, or deletion is complete across the right systems), and evidence (you can show proof-of-completion records with approvals, timestamps, and what data was affected).

Scope matters. The workflow should cover data inside your app (your database, files, and internal admin tools) and connected systems your app uses (payments, messaging, CRM, analytics, backups, and cloud storage). A simple example: a user asks for deletion, but their email still exists in your support tool and their customer ID remains in Stripe. Without a defined scope, you will “complete” the request but still keep personal data.

If you’re building this in a platform like AppMaster, the goal is to map every request type to a consistent set of steps, roles, and recorded outcomes, so compliance doesn’t depend on who happens to be on duty.

Key GDPR request types and what they mean in practice

A GDPR request is when a person asks you to do something with their personal data. Personal data is any information that can identify someone directly or indirectly, like a name, email, device ID, or support ticket history.

In simple terms, you might be a controller (you decide why and how data is used) or a processor (you handle data for someone else). Many apps act as both depending on the feature, so your workflow should record which role applies for each request.

The most common request types are access (export), rectification (correction), and erasure (deletion). Treat these as different paths, because each one has different risks and different proof you need to keep.

Time expectations: why you need a clock

Most requests have a response deadline, and the timer usually starts when you receive the request, not when it becomes convenient. Your workflow should make dates visible: received, verified, scoped, and completed. That helps you avoid missed deadlines and gives you a clean audit trail if someone later asks what happened.

What you need to act (without collecting extra data)

You want enough information to find the right records, but not so much that you create new privacy risk. Typically you need to know who is making the request (and how you’ll verify them), what action they want (export, correction, deletion), what account or identifier to search, and where to deliver the response (a secure channel).

If the request is vague, ask clarifying questions instead of guessing.

When requests may be refused or limited (general)

Sometimes you may limit or refuse a request, for example if you can’t verify identity, the request is repetitive, or laws require you to keep certain records (like invoices). Even then, record what you decided, why, and what you did instead, such as partial deletion or a limited export.

Roles and responsibilities (who does what)

A GDPR requests workflow runs faster and safer when each step has a named owner. The goal is simple: one person approves, a different person executes, and you can prove what happened later.

Start with a small set of roles that match how your company already works. In smaller teams, the same person may cover multiple roles, but permissions should still stay separated.

A practical RACI-style split looks like this:

• Requester (data subject): initiates the request and completes identity checks. Informed on progress and outcome.
• Support agent: handles intake, captures details, and keeps the requester updated. Pulls in privacy and security when needed.
• Privacy lead (DPO or privacy owner): accountable for decisions, scope, and deadlines. Approves edge cases and documents the legal basis.
• Approver (manager or privacy lead): approves higher-risk actions like deletion when there are dependencies or disputes.
• Engineer (or ops/admin): executes export, correction, or deletion across systems, then records what was done.

Security is typically consulted rather than executing every step. They help define identity checks, review unusual patterns (like repeated requests), and confirm that exported data is delivered safely.

Separation of duties matters most for deletion. The person who can press the delete button shouldn’t be the only person who can decide deletion is allowed. That reduces mistakes and lowers the risk of abuse.

To avoid stalled requests, plan coverage and handoffs upfront: set a primary and backup owner for each role (vacations happen), define an escalation point when deadlines are at risk, require status notes at each handoff, and keep a single case record with timestamps and approvals.

If you build this as an internal tool (for example, in AppMaster), model roles as permissioned actions: who can approve, who can execute, and who can only view. That structure makes the workflow auditable by default.

Intake: how requests enter the system

Intake is where GDPR work succeeds or fails. If requests arrive in different places and get handled ad hoc, you lose time and you lose a clean record of what happened. The goal is one tracked case per request, with a clear owner, timestamps, and a repeatable path forward.

Accept requests through a small set of channels, but route them to the same queue. Many teams use an in-app request form (fast and structured), a privacy email inbox, a support ticket portal, and phone or chat follow-up that an agent logs (never handle a request only by voice).

Whether the request starts in-app or by email, capture the same core fields. Keep the form short, but specific enough that your team can find the right account and understand what the person is asking for. Useful intake fields include request type (export/access, correction, deletion), account identifiers (user ID, email, phone, customer number), delivery destination (in-app download, verified email reply, postal address if truly needed), identity signals you already have (last login date, recent order ID, last 4 digits of a saved payment token, and so on), and free-text details.

Create a case the moment you receive the request. Use a rule like “one request = one case” so you can audit it later. Give it a unique case ID (for example, GDPR-2026-00128), and log the channel, intake time, requester details, and who owns the next step.

Send an acknowledgement quickly, even if you can’t act yet. Keep it factual: confirm the case ID, say you’ll verify identity, and set a realistic timeline. Avoid promises like “we’ll delete everything immediately.” Say what happens next, what you need from them (if anything), and how you’ll confirm completion when the case is closed.

Verify identity without creating new privacy risks

Identity checks should be proportional. If someone is asking for a simple copy of their profile data from a logged-in account, you usually don’t need the same level of verification as you would for a deletion request that could affect orders, invoices, or team workspaces.

A good rule: verify using signals you already have, not by collecting new sensitive documents.

Keep verification minimal and risk-based

Start with the safest option: confirm the requester controls the account you already know.

• If the request comes from inside an authenticated session, require a re-login or a one-time code.
• If it comes by email, respond only through the email on file (not the email the request came from).
• If a phone number is on file, use a one-time code to that number.
• For higher-risk actions (like deletion), add a second factor (for example, email plus in-app confirmation).
• Avoid collecting ID scans unless you truly have no other way. If you must, make it time-bound and delete it after verification.

This keeps you from creating a new pile of sensitive identity documents that now needs protection, retention rules, and breach response.

Authorized agents: what proof to ask for

Sometimes a request comes from a lawyer, parent, or another authorized agent. Ask for two things: proof of the data subject’s identity (using the same minimal approach as above) and proof of authority.

In practice, that usually means a signed authorization from the data subject plus a way to confirm it (for example, replying from the account email on file). If the agent is part of the same organization (like an admin acting for an employee), document the internal policy and limit what the admin can request.

If you can’t verify identity, don’t process the request yet. Ask for the minimum extra detail needed, pause the workflow, and log every step (what you asked for, when you asked, and what you received). Delete any verification artifacts once the check is complete.

Triage and scoping before you touch data

Before anyone exports, edits, or deletes data, you need a triage step. This is where most problems are prevented: missed systems, the wrong request type, or work started before you know what’s actually being asked.

Write down the scope in plain language. Answer three questions: what data, where it’s stored, and what time period is relevant. Also check whether anything requires you to pause or limit action, like an active dispute, fraud investigation, or legal hold.

A simple triage checklist covers: what the person is asking for (access/export, correction, deletion, or a mix), which systems might contain their data (app database, support inbox, billing, analytics), which identifiers you’ll use to find records (email, user ID, phone, order number), what timeframe applies (all time vs. a specific period), and any constraints (legal hold, shared account, or data that affects another person).

Classify mixed requests early. “Send me my data and then delete my account” should become two tracked outputs: a data package plus a deletion action, each with its own approval and proof.

Decide if manual review is required. Triggers include sensitive data, shared accounts (family or team logins), records that mention other people, or anything that could expose internal notes. In those cases, add a reviewer step before sending or deleting anything.

Set internal deadlines and escalation points. GDPR timelines are tight, so aim for a short internal target (for example, triage within 2 business days) and define who gets notified if the case stalls.

Example: a user requests deletion, but triage finds open invoices in billing and support tickets that mention other customers. You can still proceed, but you’ll likely need partial deletion, retention of finance records, and a documented reviewer sign-off. In tools like AppMaster, this is easier to manage when status changes, approvers, and completion notes are captured in one place.

Step-by-step: data export (access request) workflow

A good access request flow isn’t about “dump all data.” It’s about being able to explain, later, exactly what you searched, what you delivered, and why.

Start by building (and keeping current) a simple user data map. For one user, list where their data can live: core profile tables, orders and invoices, support tickets, chat messages, uploaded files, audit events, and any logs you’ve decided are in scope. Include third-party systems too (for example, payment provider records) so you don’t forget them during a rush.

Then run the export as a predictable sequence:

• Identify the user record(s) and all linked identifiers (user ID, email, customer number, device IDs).
• Generate an export package in common formats (often JSON or CSV), plus a short human-readable summary that explains what each file contains.
• Review for completeness and privacy: remove other people’s data (for example, messages that include another customer’s email) and document any lawful exclusions.
• Deliver securely with expiration: a one-time download, a password-protected archive shared out-of-band, or a secure portal inbox. Set a clear expiry date and limit who can access it.
• Capture proof of completion: timestamp, requester identity check result, operator name, systems searched, files generated (names and counts), and delivery method.

Example: a customer asks for their export, but your support notes mention another customer by name. Include the note with that other person’s identifiers removed, and log that redaction happened and why.

If you build this inside a tool like AppMaster, treat export generation and approval to send as separate steps. That makes it easier to add a second pair of eyes, and it creates cleaner records if you ever need to show what was delivered and when.

Step-by-step: correction (rectification) workflow

A rectification request means a person says some data about them is wrong and wants it fixed. The goal is to correct what should be corrected, without quietly rewriting records that must stay as historical evidence.

Decide what “correction” covers in your app. Common examples are profile fields (name, email, address), account settings, and preferences. It can also include user-generated content (like a display name on a comment) and some transactional metadata (like an incorrect shipping phone number). Treat financial and audit records with extra care.

Process steps (simple, repeatable)

1. Log the request and scope the exact fields or items claimed to be inaccurate.
2. Pull the current values and capture the requester’s proposed correct values and proof (if needed).
3. Apply approval rules, then update the data (or add a note when data can’t be overwritten).
4. Notify the requester of what changed, what didn’t, and why.
5. Store proof-of-completion records for auditing.

Approval rules keep support fast but safe. A practical split is that support can correct low-risk profile fields (typos, formatting) after basic checks, a data owner (or privacy lead) approves changes to identity fields or anything tied to billing and access, and engineering reviews corrections that affect core transactional tables or integrations.

Your audit trail should capture the old value, new value, reason, who changed it, when, and which request it belonged to. If you use AppMaster, you can model this as a dedicated “Rectification Log” table in the Data Designer and enforce approvals in the Business Process Editor.

Edge cases to handle

If there’s a dispute over accuracy, record both positions and pause the change while you investigate. Also avoid rewriting historical records that must remain intact (invoices, security logs). Instead, append a correcting entry or annotation so history stays truthful while current data becomes accurate.

Step-by-step: deletion workflow (with dependencies)

A GDPR deletion request sounds simple until you hit dependencies: invoices you must keep, fraud signals you shouldn’t erase blindly, or support tickets that reference other people. Treat deletion as a controlled job with clear decision points and a paper trail.

1) Decide what “delete” means for this case

Start by choosing one of three outcomes based on what you store and what you must keep:

• Full deletion: remove personal data everywhere it exists.
• Anonymization: keep the record for reporting or integrity, but irreversibly remove identifiers.
• Account deactivation: stop processing and access, but don’t erase yet (often a temporary step while you check retention rules).

Write the reason in the case file, especially if you can’t fully delete due to legal obligations.

2) Check dependencies before you touch data

Map the user’s data to systems that might block or change the approach: payments and invoices, fraud prevention flags, support history, product analytics, email and SMS logs, and file uploads.

If a payment record must remain, you can often delete or anonymize the user profile while keeping an invoice with minimal fields. For support history, consider redacting names and emails while keeping the conversation for quality.

3) Execute deletion as a tracked job

Keep the steps consistent so you can prove completion later.

1. Freeze changes: lock the account to avoid new data during the job.
2. Delete or anonymize in the primary database first (your source of truth).
3. Purge secondary stores: queues, files or object storage, caches, and search indexes.
4. Remove derived data: analytics events, email marketing profiles, and exports.
5. Verify: run a targeted search for identifiers (email, user ID) across stores.

If you build this in AppMaster, treat the deletion as a Business Process with explicit states, approvals, and retryable tasks.

4) Notify downstream processors and close the case

Send deletion instructions to third parties (payments, messaging, analytics) and log their confirmations. Store proof of completion: job run logs, timestamps, the operator or automation ID, and a closure note listing what was deleted, anonymized, or retained and why.

Common mistakes and traps to avoid

Most compliance failures aren’t about bad intent. They happen because work gets scattered across email threads, chat messages, and quick fixes.

The first trap is having no single case ID. Without one case record, you can’t show who requested what, when you verified identity, what you did, and when you finished.

A close second is missing approvals. If the same person can approve and execute a request, a mistake can slip through unnoticed. Even a light two-person check helps, especially for deletion and exports.

Deletion fails in two directions. Over-deleting is removing data you still need for security, fraud prevention, or legal and accounting records, without review. Under-deleting is more common: teams delete the main database row but forget attachments, logs, analytics events, full-text search indexes, caches, and background jobs that may recreate the data later.

Exports can be risky too. Pulling data from many places means small join mistakes can include another user’s data. Internal notes are another frequent problem: comments like “suspected fraud” or “VIP discount” can end up in the export even if they were meant only for staff.

Example: a support agent exports “all tickets” for one customer, but the export query also includes messages from a shared inbox or a merged contact record. That’s a privacy incident created by a “helpful” shortcut.

Guardrails that prevent most of these issues are simple: create one case ID and log every action under it, separate roles across intake, approval, and execution, maintain a data map (tables, files, logs, search, caches, async jobs), use scoped export templates and test with dummy accounts, and record completion evidence (what was changed or deleted, by whom, and when).

If you build this in AppMaster, treat the case as a first-class object and have each workflow step write an audit entry automatically.

Quick checklist and next steps to implement in your app

A good GDPR requests workflow is easy to run on a busy day and easy to prove later. If you can answer two questions quickly - what did we do, and when did we do it - you’re in good shape.

Use a consistent checklist for every case (access, correction, or deletion): log intake and assign a case ID, owner, and due date; verify identity using a safe method and record how you verified it; scope the request (products, accounts, time range, data sources); get the right approvals (privacy lead, legal, and system owner when needed); execute, confirm to the requester, and save proof-of-completion records.

For proof, you don’t need to store more personal data. You do need reliable metadata. At minimum, keep the case ID, request type, identity verification method (not the raw documents), timestamps for each step, approver names or roles, actions taken, and a reference to the deliverable (for example, export file ID, ticket number, or deletion job ID).

To reduce mistakes and speed up responses, template the key messages so every requester gets clear, consistent updates. Keep three ready: acknowledgement (what you received, expected timeline, and how you’ll verify identity), info request (what’s missing and how to provide it), and completion (what you delivered or changed, what you couldn’t do and why, and how to appeal).

Next steps: implement the workflow inside your app so it doesn’t live in scattered emails. Model the case as a record with status steps, attach evidence references, and add role-based approvals plus audit logs.

Teams often build this kind of internal GDPR case tool in AppMaster (appmaster.io) because you can define the case table in the Data Designer, set up approvals and execution steps in the Business Process Editor, and keep the audit trail tied to each status change. Done well, the workflow becomes repeatable, measurable, and defensible.