Skip to main content
When a data subject exercises their right of access or data portability under GDPR, you can fulfill that request directly from the AuditRails dashboard. DSAR Export is a dashboard-only workflow — there is no bearer-token API endpoint for this feature. Only organisation admins can submit and view DSAR requests, and all submissions are authenticated by your existing logged-in session at app.auditrails.io.
GDPR legal basis — Articles 15 & 20. Article 15 grants data subjects the right to obtain confirmation of whether their personal data is being processed and to receive a copy of that data. Article 20 extends this by allowing them to receive data in a structured, machine-readable format and to transmit it to another controller. The DSAR Export workflow in AuditRails is designed to satisfy both obligations within your audit log infrastructure.

​
How to submit an export request

1

Sign in as an organisation admin

Go to app.auditrails.io and sign in with an account that holds the Org Admin role. DSAR features are restricted to admins — member-level accounts will not see the DSAR section.
2

Open the DSAR panel

Navigate to Settings → DSAR in the left-hand sidebar. You will see a submission form and a history table of all past and in-progress requests for your organisation.
3

Fill in the request form

Complete the following fields:
4

Submit the request

Click Submit. The request is immediately queued and processed asynchronously in the background. You will see it appear in the DSAR history table with a status of pending.
5

Download the export when complete

Refresh the DSAR history table to monitor progress. Once the status changes to complete, a Download link appears in the row. Click it to retrieve the export file containing all matched audit events.

​
How the export works

After you submit a request, AuditRails carries out the following steps automatically:
  1. Scans hot storage. All events in your active, searchable log store where actor_id exactly matches the value you supplied are identified across the full retention period for your plan.
  2. Scans cold storage. AuditRails also searches your S3 WORM archive for matching events. Cold-storage objects are opened read-only — the originals are never modified or moved as part of this process.
  3. Compiles the export file. Matching events from both storage tiers are merged, deduplicated, and compiled into a single downloadable file.
  4. Makes the download available. The status in the DSAR history table updates to complete and a Download link appears. The link is scoped to your organisation and accessible only to Org Admins.

​
Request statuses

​
Constraints and limits

  • One active request per actor at a time. If an export request for a given actor_id is already in pending or processing state, submitting a second request for the same actor will be rejected. Wait for the in-flight request to reach complete or failed before resubmitting.
  • Actor ID must be an exact match. The lookup is case-sensitive and matches the literal string stored in the actor_id field at event ingestion time. There is no fuzzy matching or alias resolution.
  • Retention scope. The export covers all events within your plan’s configured retention period. Events that have already aged out of both hot and cold storage are not recoverable and will not appear in the export. To check your retention period, go to Settings → Organisation.
  • WORM originals are untouched. Exporting events from cold storage is a read-only operation. S3 Object Lock COMPLIANCE mode prevents any modification — AuditRails reads the data without altering or unlocking the underlying objects.