> ## 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.

# GDPR Compliance Guide: DPA, DSARs, Data Residency, and PII

> Set up AuditRails as a GDPR-compliant data processor: sign your DPA, handle DSARs, anonymise IPs, apply redaction rules, and configure data residency.

Under GDPR, AuditRails acts as your **data processor** — it processes personal data on your behalf according to your instructions. You remain the **data controller**, responsible for determining the purpose and means of processing. This guide walks you through signing your Data Processing Agreement, handling Data Subject Access Requests, minimising PII in your logs, and configuring data residency.

## Data Processing Agreement (DPA)

Before processing any personal data through AuditRails, you must have a signed DPA in place. The DPA is available directly in your dashboard — no back-and-forth with a sales team required.

<Steps>
  <Step title="Navigate to Legal settings">
    Go to **Dashboard → Settings → Legal**.
  </Step>

  <Step title="Review the DPA">
    Read through the agreement. The DPA covers the nature and purpose of processing, categories of personal data and data subjects, the list of sub-processors, EU Standard Contractual Clauses (SCCs), and breach notification obligations.
  </Step>

  <Step title="Sign and download">
    Click **Sign DPA** to apply your electronic signature. Download the signed PDF and store it with your compliance records.
  </Step>
</Steps>

The DPA renews automatically. You will receive **30 days' notice** before any material changes, giving you time to review and object before renewal takes effect.

### Sub-Processors

AuditRails uses the following sub-processors:

| Sub-processor | Service                     | Region    |
| ------------- | --------------------------- | --------- |
| AWS (S3, SQS) | Storage and message queuing | US and EU |
| Stripe        | Payment processing          | US        |
| MaxMind       | Geo-IP enrichment           | US        |

You will receive **30 days' notice** before any new sub-processor is added. If you object to a new sub-processor, contact support before the notice period expires.

***

## Compliance Checklist

The GDPR compliance checklist gives you a live view of your status against the key GDPR obligations. Open it at **Dashboard → Compliance → GDPR**.

The checklist tracks:

| Category                   | Items tracked                                               |
| -------------------------- | ----------------------------------------------------------- |
| Data protection principles | Art.5 accountability, purpose limitation, data minimisation |
| Lawful basis               | Consent logging, legitimate interest records                |
| DSAR procedures            | Export and deletion workflows configured                    |
| DPO appointment            | Data Protection Officer designation (if required)           |
| DPIA                       | Data Protection Impact Assessment completion                |
| Breach notification        | Breach event types configured, 48-hour notification         |
| International transfers    | SCCs in DPA, sub-processor regions                          |
| Security measures          | Hash chaining, WORM, encryption, access controls            |

***

## Data Subject Access Requests (DSARs)

GDPR Articles 15–20 give individuals the right to access, export, and delete their personal data. AuditRails provides a built-in DSAR workflow. Only **admin users** can submit DSAR requests.

### DSAR Export (Art.15 / Art.20)

<Steps>
  <Step title="Open the DSAR panel">
    Navigate to **Dashboard → Settings → DSAR** and click **New Request**.
  </Step>

  <Step title="Enter the actor ID">
    Enter the `actor_id` that corresponds to the data subject. This is the identifier you use when logging events (for example, `user_123`).
  </Step>

  <Step title="Select Export type">
    Choose **Export** as the request type.
  </Step>

  <Step title="Download the export">
    AuditRails compiles all events associated with that `actor_id` into a ZIP file containing a CSV. Download it and provide it to the data subject.
  </Step>
</Steps>

### DSAR Delete (Art.17)

<Steps>
  <Step title="Open the DSAR panel">
    Navigate to **Dashboard → Settings → DSAR** and click **New Request**.
  </Step>

  <Step title="Enter the actor ID">
    Enter the `actor_id` of the data subject requesting erasure.
  </Step>

  <Step title="Select Delete type">
    Choose **Delete** as the request type and confirm.
  </Step>
</Steps>

<Warning>
  **Hot storage records are deleted immediately.** S3 WORM (cold storage) records **cannot be physically deleted** before the retention period expires — they are S3 Object Lock COMPLIANCE objects, which are immutable by design. Records in WORM storage are **logically marked as deleted** and excluded from all reads, API responses, and exports immediately upon the request being processed. Physical deletion occurs automatically when the Object Lock expires.

  This behaviour is permitted under **GDPR Art.17(3)(e)**, which allows retention of data necessary for the establishment, exercise, or defence of legal claims. Your DPA documents this legal basis.
</Warning>

**CCPA note:** If you are also subject to CCPA/CPRA, deletion requests must be actioned within **45 days**. The DSAR workflow logs a `data.deleted` event with a timestamp so you can demonstrate compliance with this deadline.

***

## PII Best Practices

Minimising personal data in your audit logs is the most effective way to reduce GDPR risk. The less PII you log, the less you need to manage.

### Use Identifiers, Not PII

<CodeGroup>
  ```javascript Good — log an identifier theme={null}
  auditRails.log({
    action: 'document.viewed',
    actorId: 'user_123',        // internal ID, not PII
    resource: 'document/456',
  });
  ```

  ```javascript Bad — logs PII directly theme={null}
  auditRails.log({
    action: 'document.viewed',
    actorId: 'john@example.com',  // ❌ email address is PII
    resource: 'document/456',
  });
  ```
</CodeGroup>

### Log Field Names, Not Values

When recording what changed, log the names of changed fields — not their new values.

<CodeGroup>
  ```javascript Good — field names only theme={null}
  auditRails.log({
    action: 'profile.updated',
    actorId: 'user_123',
    metadata: {
      fields_changed: ['name', 'email'],  // ✅ names only
    },
  });
  ```

  ```javascript Bad — logs PII values theme={null}
  auditRails.log({
    action: 'profile.updated',
    actorId: 'user_123',
    metadata: {
      new_email: 'john@example.com',  // ❌ PII value
      new_name: 'John Smith',         // ❌ PII value
    },
  });
  ```
</CodeGroup>

### Never Log Sensitive Data

Avoid logging any of the following in event metadata:

* Passwords or password hashes
* Social Security Numbers (SSNs) or national ID numbers
* Full payment card numbers (PANs)
* Biometric data
* Health or medical information
* Unmasked API keys or secrets

### IP Anonymization

If you process EU user IP addresses, consider enabling IP anonymization to truncate the last octet before storage.

<Steps>
  <Step title="Navigate to Privacy settings">
    Go to **Dashboard → Settings → Privacy**.
  </Step>

  <Step title="Enable IP Anonymization">
    Toggle **IP Anonymization** on. AuditRails will truncate the last octet of every IP address going forward.

    **Example:** `203.0.113.45` → `203.0.113.0`
  </Step>
</Steps>

<Info>
  IP anonymization applies to **future events only**. Events already stored retain their original IP addresses. If you need to anonymise historical data, contact support.
</Info>

### Metadata Redaction Rules

Redaction rules automatically strip known PII field names from event metadata before storage, replacing their values with `[REDACTED]`.

<Steps>
  <Step title="Navigate to Redaction Rules">
    Go to **Dashboard → Settings → Privacy → Redaction Rules**.
  </Step>

  <Step title="Configure field names to redact">
    AuditRails pre-populates common PII field names: `email`, `phone`, `ssn`. Add any additional field names that may appear in your metadata.
  </Step>

  <Step title="Verify redaction">
    Log a test event containing a redacted field name and confirm the value appears as `[REDACTED]` in the dashboard.
  </Step>
</Steps>

<Tip>
  Redaction rules are a safety net — not a substitute for good instrumentation. Design your logging to avoid PII in the first place; use redaction rules to catch anything that slips through.
</Tip>

***

## Data Residency

All plans currently store data in a single AWS region — `us-east-1` (Northern Virginia, USA). There is no EU-only storage option available today, regardless of plan.

<Info>
  If your GDPR obligations require that personal data not leave the EU, talk to us before signing up — see the DPA (available at **Dashboard → Settings → Legal**) for how AuditRails safeguards this cross-border transfer, and reach out to support if you need to discuss your specific residency requirements.
</Info>

***

## Breach Notification

If AuditRails becomes aware of a security incident affecting your data, we will notify you **within 48 hours** of becoming aware of the breach. This supports your own 72-hour notification obligation to your supervisory authority under GDPR Art.33.

To log breach-related events from your own application:

```javascript theme={null}
auditRails.log({
  action: 'breach.detected',
  actorId: 'system',
  resource: 'security/incident-2024-001',
  metadata: {
    affected_systems: ['auth-service'],
    detected_at: new Date().toISOString(),
  },
});
```

Log `breach.notified` when you notify your supervisory authority, and `breach.resolved` when the incident is closed. These events are tracked by the GDPR compliance checklist and satisfy Art.33 documentation requirements.