Skip to main content
When a data subject exercises their right to erasure under GDPR, you can action that request directly from the AuditRails dashboard. DSAR Delete 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 — Article 17. Article 17 grants data subjects the right to request erasure of their personal data without undue delay where one of several grounds applies — for example, the data is no longer necessary for the purpose it was collected, or the subject withdraws consent. GDPR Article 17(3)(e) provides a counterbalancing exception: retention remains lawful where it is necessary for the establishment, exercise, or defence of legal claims, and where regulatory frameworks mandate the preservation of immutable audit trails. AuditRails’s architecture reflects this balance, as described below.

​
How to submit a deletion 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. You will see it appear in the DSAR history table with a status of pending.
5

Confirm completion

Monitor the DSAR history table. Once the status changes to complete, hot-storage deletion is confirmed. Read the cold-storage section below for the important limitations that apply to WORM-archived events.

​
How the deletion works

After you submit a request, AuditRails carries out the following steps automatically:
  1. Queues and validates the request. The actor ID is verified against your organisation and the request enters the processing queue.
  2. Deletes from hot storage. All events where actor_id exactly matches the supplied value are permanently deleted from the active hot store. These events immediately stop appearing in dashboard searches, queries, and API reads.
  3. Handles cold storage (S3 WORM) with a logical deletion. See the critical limitation below.

​
S3 WORM cold storage — critical limitation

Events in S3 WORM cold storage cannot be physically deleted before their retention period expires — not even by AuditRails staff or AWS root account users.AuditRails archives events to Amazon S3 with Object Lock in COMPLIANCE mode. This means the retention lock is enforced at the AWS infrastructure level and is legally immutable for the duration of the configured retention period. No policy override, support request, or elevated privilege can remove or shorten a COMPLIANCE-mode lock before it expires.When a DSAR Delete request reaches complete, AuditRails applies a logical deletion marker to all matching cold-storage events. Logically deleted events are:
  • Excluded from all future exports, including DSAR Export runs.
  • Excluded from all dashboard reads and API queries.
  • Not returned in any search, report, or data feed.
The underlying S3 objects will be physically deleted automatically once their retention period expires. To find out your organisation’s exact retention periods by plan and compliance framework, go to Settings → Organisation.
This design is intentional and reflects a deliberate balance between GDPR Article 17 erasure obligations and Article 17(3)(e), which permits continued retention where it is required for legal proceedings or where regulatory frameworks mandate immutable audit records. By logically deleting events immediately and physically deleting them at the earliest lawful moment, AuditRails provides a defensible, compliance-ready erasure posture.

​
Request statuses

​
Constraints and limits

  • One active request per actor at a time. If a deletion 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.
  • Hot-storage deletion is immediate and irreversible. Once events are removed from hot storage they cannot be recovered. Ensure you have completed any required DSAR Export before submitting a deletion request if you need to provide the data subject with a copy first.
  • Cold-storage physical deletion follows your retention schedule. The exact retention period varies by your AuditRails plan and the compliance framework applied to your organisation. Check Settings → Organisation for your specific values.
  • No API equivalent. DSAR Delete cannot be triggered via the bearer-token REST API. All erasure requests must be submitted through the dashboard by an Org Admin.