Operations & Compliance package

GDPR data subject requests

Handle access, erasure and other privacy requests: statutory deadline, identity check, search of CRM, billing and support, erasure, and a DPO-approved reply.

Starts from a formAdvanced~30 min setupv1.0.0
Download .utpkg 22 KBHow to install

About this package

What it does

GDPR data subject requests takes a privacy request from receipt to response inside the statutory deadline. The privacy team (or your web form posting to the API) fills in the start form: who is asking, their email, the request type (access, erasure, rectification, portability, objection), the jurisdiction and the date it arrived.

The Statutory deadlines decision table sets the response deadline and whether it can be extended (one month under EU and UK GDPR, 45 days under CCPA, 15 days for a CCPA opt-out) and the run gets an SLA to match. The request is added to the DSAR register and nothing is searched until the privacy team has verified the requester's identity; they can ask for more information or reject the request. Once verified, the CRM, billing system and support desk are searched by email, and for erasure requests an erasure is requested in each system, with any records kept by law listed.

The DPO reviews a drafted response with everything found, edits and approves it or sends it back, and the approved response is emailed to the requester and the register row closed. Adapt the deadline rules to your legal advice and the three system references to the systems that hold personal data.

Starts from a form

Starts from a form: the privacy team fills in the request from the Run dialog, or your privacy web form posts it to the start API or an inbound webhook.

Someone fills in a form to start it: the workflow inputs are the start form (Run dialog in the app, or your own portal posting to the API), and people complete User Task forms along the way.

The flow

Step by step

  1. 1

    Request received

    The start form records the requester, email, request type, jurisdiction, details and received date; the request gets a DSAR reference.

  2. 2

    Set the statutory deadline

    The Statutory deadlines decision table gives the deadline and extension rule; the run SLA and the DSAR register row use it.

  3. 3

    Verify identity

    The privacy officer confirms the requester is the data subject, asks for more information (emailed to the requester) or rejects the request.

  4. 4

    Search the systems

    The CRM, billing system and support desk are searched by email and the matches summarised.

  5. 5

    Erase where asked

    For erasure requests an erasure is requested in each system; records kept by law are listed in the response.

  6. 6

    DPO approval

    The DPO edits and approves the drafted response, or sends it back to the privacy officer to revise.

  7. 7

    Respond and close

    The approved response is emailed to the requester and the DSAR register row is closed.

Data subject request — A data subject request from the privacy team or a web form: sets the statutory deadline, verifies identity, searches the CRM, billing and support systems, erases where asked, and sends a DPO-approved response. The same canvas you get in the designer after installing.

Forms

The start form and the task forms

The workflow inputs are the start form: the Run dialog renders them, and your own portal can post the same fields. User Tasks show their fields and outcome buttons to the assignee.

Start form

Data subject request

Filled in by whoever starts the process

Requester name * requester_name · textFull name of the data subject
Requester email * requester_email · emailname@company.comEmail the request came from (used to search the systems)
Request type * request_type · select
accesserasurerectificationportabilityobjection
What the requester is asking for
Jurisdiction * jurisdiction · select
EU-GDPRUK-GDPRCCPAother
Which law applies (sets the deadline)
Details details · textThe request in the requester's words, and anything that helps identify them
Received date received_date · dateYYYY-MM-DDWhen the request was received (the deadline runs from here). Empty = today.
Privacy officer (user id) privacy_officer_id · textOptional: user id of the privacy team member handling it (otherwise the one chosen on install)
DPO (user id) dpo_id · textOptional: user id of the DPO who approves the response (otherwise the one chosen on install)

User Task

Verify identity

Verify identity: {{requester_name}} ({{request_type}}, due {{due_date}})

How was identity checked? * verification_method · choice
Email on file confirmedAccount login matchedID document checkedOther
Notes (sent to the requester if more info is needed or the request is rejected) verification_notes · text
VerifiedNeed more infoReject

User Task

DPO review

Approve DSAR response {{reference}} ({{request_type}}, due {{due_date}})

Response to the requester * response_summary · textPrefilled: {{response_summary}}
Notes for the privacy team dpo_notes · text
Approve responseSend back

User Task

Revise response

Revise DSAR response {{reference}}

Response to the requester * response_summary · textPrefilled: {{task_data.response_summary}}
Resubmit

From your code

Start a run over the API

Every workflow can be started over REST, MCP or the CLI, whatever its trigger, with the sample input below. Runs start straight away on the published version; replace <workflow id> with the id the install created.

REST

shell
curl -X POST "$USERTASKS_URL/api/v1/workflows/start" \
  -H "Authorization: Bearer $USERTASKS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"workflow_id":"<workflow id>","variables":{"requester_name":"Robin James","requester_email":"robin.james@example.com","request_type":"erasure","jurisdiction":"EU-GDPR","details":"Please delete all my data. I closed my account in September; my customer number was CUS-20417.","received_date":"2026-10-26"}}'

CLI

shell
usertasks workflows inputs <workflow id>          # the start form: keys, types, required
usertasks workflows run <workflow id> --input requester_name="Robin James" --input requester_email=robin.james@example.com --input request_type=erasure --input jurisdiction=EU-GDPR … --wait

Inbound webhook

shell
usertasks webhooks create <workflow id>          # prints the hook slug and secret once
curl -X POST "$USERTASKS_URL/api/webhooks/inbound?hook=<slug>" \
  -H "Authorization: Bearer <webhook secret>" -H "Content-Type: application/json" \
  -d '{"requester_name":"Robin James","requester_email":"robin.james@example.com","request_type":"erasure","jurisdiction":"EU-GDPR","details":"Please delete all my data. I closed my account in September; my customer number was CUS-20417.","received_date":"2026-10-26"}'

What's included

15 assets, ready to adapt

TypeNameDetails
Email templateDSAR identity checkAsks the requester for more information to confirm their identity.
Email templateDSAR not verifiedTells the requester the request cannot proceed because their identity could not be confirmed.
Email templateDSAR responseThe final response to the requester, approved by the DPO.
Data tableDSAR registerRegister of data subject requests: who asked, what for, the statutory deadline, systems searched and the outcome. Keep it as your record of processing for requests.
IntegrationBilling system
IntegrationCRM
IntegrationSupport desk
API referenceFind billing customerGET /customers — Billing accounts, invoices and payment methods held for the subject's email.
API referenceFind CRM subjectGET /subjects — Contacts and leads in the CRM that match the data subject's email.
API referenceFind support contactGET /contacts — Support desk contact and ticket history for the subject's email.
API referenceRequest billing erasurePOST /erasure-requests — Removes personal data from the billing account; invoices are kept for the statutory retention period with the name pseudonymised.
API referenceRequest CRM erasurePOST /erasure-requests — Queues erasure (or anonymisation where records must be kept) of the subject in the CRM.
API referenceRequest support erasurePOST /erasure-requests — Deletes the contact and redacts their tickets and attachments in the support desk.
Decision tableStatutory deadlines5 rules — Response deadline by jurisdiction and request type, whether it can be extended, and the legal basis to quote. First matching rule wins. Check these against your own legal advice.
WorkflowData subject request34 steps — A data subject request from the privacy team or a web form: sets the statutory deadline, verifies identity, searches the CRM, billing and support systems, erases where asked, and sends a DPO-approved response.

DSAR register · schema only

ReferenceRequesterEmailRequest typeJurisdictionReceivedDueStatusSystems with dataErasure referencesOutcomeClosed

Requirements

What you connect it to

Credentials never travel in a package. The install wizard asks for what your environment must provide, or installs it incomplete until you finish setup.

Needs

  • REST API — A REST API integration: set its base URL and credentials on install.
  • Assignees — People in your workspace to receive the User Tasks (picked on install).
  • Email — Email delivery configured for the instance (EMAIL_PROVIDER), used for notifications.
  • Inbound webhook (optional) — An inbound webhook created for the workflow, so other systems can start it.

After installing

  1. CRM, Billing system and Support desk integrations: set each base URL and API token. Each has a search reference (GET with ?email=) and an erasure reference (POST /erasure-requests); adjust paths and response models to your systems in Integrations, or remove a system you do not use.
  2. Assignees: pick the privacy officer who verifies identity and revises responses, and the DPO who approves them (runs can pass privacy_officer_id and dpo_id).
  3. Review the Statutory deadlines rules with your legal team; add rows for other jurisdictions you serve.
  4. Optional: create an inbound webhook for the workflow so your privacy web form can submit requests directly.
  5. Email: configure EMAIL_PROVIDER on the instance so requesters receive the identity request and the response (the steps continue on error).

Asked for on install

  • Integration “Billing system”Required

    • Tokenconfig.auth_config.token
    • Base urlconfig.base_urldefault https://billing.example.com/api· optional

  • Integration “CRM”Required

    • Tokenconfig.auth_config.token
    • Base urlconfig.base_urldefault https://crm.example.com/api· optional

  • Integration “Support desk”Required

    • Tokenconfig.auth_config.token
    • Base urlconfig.base_urldefault https://support.example.com/api· optional

  • Workflow “Data subject request” assigneesRequired

    • User for step “Verify identity”nodes.8.config.assignee_id
    • User for step “DPO review”nodes.27.config.assignee_id
    • User for step “Revise response”nodes.28.config.assignee_id

Install

Install it in your workspace

Works on UserTasks cloud and on any self-hosted instance. Installing creates the assets above; nothing runs until you complete setup and start it.

In the app

  1. Download gdpr-dsar-handling-1.0.0.utpkg.
  2. Open Automations → Packages and drag the file onto the page (or choose Import package). Browse gallery there lists every gallery package without downloading by hand.
  3. Pick the file. The wizard verifies the checksum, every file hash and the signature, and shows the readme.
  4. Review the changes (what is created) and the data rows.
  5. Fill in the requirements, or tick Keep incomplete and finish later with Complete setup.
  6. Done: the workflow is published and active once setup is complete.

With the CLI

shell
curl -fLO https://usertasks.com/gallery/gdpr-dsar-handling-1.0.0.utpkg
usertasks packages inspect gdpr-dsar-handling-1.0.0.utpkg       # offline: checksum, hashes, signature
usertasks packages install gdpr-dsar-handling-1.0.0.utpkg --dry-run
usertasks packages install gdpr-dsar-handling-1.0.0.utpkg       # prompts for each requirement
usertasks packages install gdpr-dsar-handling-1.0.0.utpkg --keep-incomplete --yes   # in CI; finish with:
usertasks packages complete gdpr-dsar-handling -f values.yaml

Verify the download

File SHA-256
7d789a2ecf3841a7facfe198420e611b89ef1052d074c38405fa6d0fb3574f9f
Package checksum (what is signed)
sha256:d59a260ddc88b480636f94659e2dedb29f776b76d14e0578cd9bd46a3aa746e5
Signer
Unsigned preview build — compare the SHA-256 above

shasum -a 256 gdpr-dsar-handling-1.0.0.utpkg should print the file SHA-256. How gallery packages are signed.

Versions

Version 1.0.0

  1. v1.0.02026-10-26First release.

Installing a newer version upgrades in place: local credentials and requirement values are kept, and changes you made are flagged first. How packages work

More packages

Related

Browse the whole gallery