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

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.

Navigate to Legal settings

Go to Dashboard → Settings → Legal.

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.

Sign and download

Click Sign DPA to apply your electronic signature. Download the signed PDF and store it with your compliance records.

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)

Open the DSAR panel

Navigate to Dashboard → Settings → DSAR and click New Request.

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

Select Export type

Choose Export as the request type.

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.

DSAR Delete (Art.17)

Open the DSAR panel

Navigate to Dashboard → Settings → DSAR and click New Request.

Enter the actor ID

Enter the actor_id of the data subject requesting erasure.

Select Delete type

Choose Delete as the request type and confirm.

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.

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

auditRails.log({
  action: 'document.viewed',
  actorId: 'user_123',        // internal ID, not PII
  resource: 'document/456',
});

auditRails.log({
  action: 'document.viewed',
  actorId: 'john@example.com',  // ❌ email address is PII
  resource: 'document/456',
});

Log Field Names, Not Values

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

auditRails.log({
  action: 'profile.updated',
  actorId: 'user_123',
  metadata: {
    fields_changed: ['name', 'email'],  // ✅ names only
  },
});

auditRails.log({
  action: 'profile.updated',
  actorId: 'user_123',
  metadata: {
    new_email: 'john@example.com',  // ❌ PII value
    new_name: 'John Smith',         // ❌ PII value
  },
});

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.

Navigate to Privacy settings

Go to Dashboard → Settings → Privacy.

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

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

Metadata Redaction Rules

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

Navigate to Redaction Rules

Go to Dashboard → Settings → Privacy → Redaction Rules.

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.

Verify redaction

Log a test event containing a redacted field name and confirm the value appears as [REDACTED] in the dashboard.

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.

Data Residency

Plan	Storage region
Starter Trails	`us-east-1` (Northern Virginia, USA)
Framework Trails	`us-east-1` (Northern Virginia, USA)
Compliance Trails	`us-east-1` or `eu-west-1` (Ireland, EU)

If your GDPR obligations require that personal data not leave the EU, you need a Compliance Trails plan with EU storage (eu-west-1) enabled. Contact your account manager to configure EU-only storage.

AWS eu-west-1 (Ireland) is an EU jurisdiction for GDPR purposes. Data stored there does not transfer outside the EU/EEA under normal operation. The DPA’s EU SCCs cover the residual transfer risk associated with US-based sub-processors (Stripe, MaxMind) that do not store audit event data.

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:

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.

Getting Started

Guides

Reference

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

Data Processing Agreement (DPA)

Sub-Processors

Compliance Checklist

Data Subject Access Requests (DSARs)

DSAR Export (Art.15 / Art.20)

DSAR Delete (Art.17)

PII Best Practices

Use Identifiers, Not PII

Log Field Names, Not Values

Never Log Sensitive Data

IP Anonymization

Metadata Redaction Rules

Data Residency

Breach Notification

​Data Processing Agreement (DPA)

​Sub-Processors

​Compliance Checklist

​Data Subject Access Requests (DSARs)

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

​DSAR Delete (Art.17)

​PII Best Practices

​Use Identifiers, Not PII

​Log Field Names, Not Values

​Never Log Sensitive Data

​IP Anonymization

​Metadata Redaction Rules

​Data Residency

​Breach Notification

Data Processing Agreement (DPA)

Sub-Processors

Compliance Checklist

Data Subject Access Requests (DSARs)

DSAR Export (Art.15 / Art.20)

DSAR Delete (Art.17)

PII Best Practices

Use Identifiers, Not PII

Log Field Names, Not Values

Never Log Sensitive Data

IP Anonymization

Metadata Redaction Rules

Data Residency

Breach Notification