> ## Documentation Index
> Fetch the complete documentation index at: https://docs.auditrails.io/llms.txt
> Use this file to discover all available pages before exploring further.
# DSAR Delete — Right to Erasure (Right to Be Forgotten)
> Submit a Data Subject deletion request to erase all audit events for a given actor from AuditRails hot storage, in line with GDPR Article 17.
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](https://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
Go to [app.auditrails.io](https://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.
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.
Complete the following fields:
| Field | Required | Notes |
| ------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Actor ID** | Yes | Must exactly match the `actor_id` value used when the events were logged. A typo or case mismatch will result in no events being deleted. |
| **Type** | Yes | Select **Delete**. |
| **Requester email** | Yes | The email address of the data subject or their representative, for your internal records. |
| **Reason** | No | A free-text note for your internal records (e.g. "Erasure request received 2024-06-01 — subject withdrew consent"). |
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**.
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
| Status | Meaning |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pending` | The request has been accepted and is waiting in the processing queue. No action needed. |
| `processing` | AuditRails is actively deleting events from hot storage and applying logical deletion markers to cold-storage objects. |
| `complete` | Hot-storage deletion is confirmed and cold-storage logical deletion markers have been applied. |
| `failed` | Processing encountered an error. The row will display an error message. Contact [support@auditrails.io](mailto:support@auditrails.io) with the request ID shown in the table. |
***
## 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.