How to implement a DSAR portal in a Next.js app (GDPR Articles 15, 17, 20)

GDPR Articles 15, 17, and 20 give data subjects the right to know what data you hold about them (access), receive a machine-readable copy (portability), and have their data deleted (erasure). Controllers must respond within 30 days. For most web apps, this means building a dedicated portal: a form where users can submit a request, an identity verification step (to prevent spoofing), a pipeline that collects data from every data store your app uses, a packaging step that creates a downloadable export, an erasure pipeline that removes personal data without breaking referential integrity, and a dashboard for tracking outstanding requests and their deadlines. Failing to respond within 30 days can result in regulatory action.

The compliance-eu module generates a complete DSAR portal into every Alleex Cloud app that processes personal data. The generated portal includes: a request intake page at `/dsar` where the user selects the request type (access, portability, or erasure); an email-token verification step that confirms the request before processing begins; a background job (`compliance/dsar.ts`) that calls a `dsarHandler` registered by each installed module — for example, the auth module contributes user profile data, the booking module contributes booking records; an erasure handler that marks records as anonymised or deletes them depending on the module's retention rules; a 30-day deadline tracker surfaced in the app's admin dashboard; and a consent receipt system (Ed25519-signed, verifiable offline) for consent-related requests. Every step in the DSAR lifecycle is written to the hash-chained audit log, so the entire fulfilment chain is tamper-evidently recorded.

1. 1

   Define your data inventory

   Before building the portal, map every table and service that stores personal data. For each: what data is stored, what the retention period is, and what the erasure rule is (hard delete vs. anonymisation). This inventory drives the DSAR pipeline.

2. 2

   Build the request intake and verification

   Create a Next.js route (`/dsar`) with a form that accepts the user's email and request type. On submission, generate a signed verification token and send it to the email. Only proceed after the token is verified — this prevents spoofed requests.

3. 3

   Implement a dsarHandler per data module

   For each module that holds personal data, implement a `dsarHandler(userId: string): Promise<DsarPayload>` function that returns the user's data in a structured format. Register each handler so the DSAR pipeline can invoke them in sequence. For erasure, implement an `eraseUser(userId: string): Promise<void>` that respects retention rules.

4. 4

   Package the access/portability export

   Collect the output of all `dsarHandler` calls and package them into a JSON or ZIP file. Generate a time-limited signed URL for the user to download. Log the export event with a hash in the audit log.

5. 5

   Track deadlines and notify

   Record the request date and the 30-day deadline in a `dsar_requests` table. Run a daily cron job that flags overdue requests in the admin dashboard and sends a reminder to the responsible team member.

6. 6

   Use Alleex Cloud to skip steps 1–5

   If you are building with Alleex Cloud, include compliance-eu in your module plan. The portal, verification, dsarHandler registration, export pipeline, erasure pipeline, and deadline tracker are generated automatically. Each module you add automatically registers its dsarHandler.

Do I have to build a DSAR portal, or can I handle requests by email?

GDPR does not mandate a self-serve portal — you can handle requests by email. However, a self-serve portal reduces support load, creates an auditable record of each request and its fulfilment, and makes the 30-day deadline easier to track at scale. Regulators also look favourably on systematic DSAR processes.

How do I verify identity without storing a copy of an ID document?

Email-token verification is the most practical approach for consumer apps: send a time-limited signed token to the email on record, and only process the request if the token is clicked. This is not proof of legal identity, but it confirms control of the account email — sufficient for most consumer DSAR scenarios. High-risk contexts (financial, medical) may require additional steps; consult your DPO.

What is the difference between Article 17 erasure and anonymisation?

Article 17 requires that personal data be erased when there is no longer a lawful basis to retain it. Hard deletion removes the row. Anonymisation replaces identifying fields with pseudonyms or nulls so the record no longer refers to a natural person — this can satisfy Article 17 while preserving aggregate statistics or audit records. The right approach depends on your retention obligations (e.g., accounting records may have a legal retention period that overrides erasure).

Do third-party services your app uses also need to process the DSAR?

Yes. If your app sends personal data to a third-party processor (e.g., a payment provider, email service, or analytics tool), your DSAR pipeline needs to trigger erasure/export requests to those processors as well — or document that the processor handles DSARs under a separate subprocessor agreement. Alleex Cloud-generated apps document subprocessors in the generated privacy policy.