What GDPR Mode Actually Changes in DAVE

GDPR mode is a compliance standard toggle, not a separate product tier or a support request. It is configured at Admin, then Settings, then General, then System Parameters, then the Audit Log section. The section presents three compliance standards as checkboxes:

• Standardalways on, cannot be disabled. Covers base audit logging: all mutations, authentication events, and system changes.
• SOC 2off by default, independently enabled.
• GDPRoff by default, independently enabled.

SOC 2 and GDPR can be enabled together or separately. Enabling one does not require enabling the other. Each standard adds its own scope of logging on top of the Standard baseline.

Only users with the Admin role can access the Settings page and change compliance standards. Of the six default tenant roles, Admin is the only one with access to this section. The change takes effect immediately: the next event captured after saving will carry GDPR compliance tags if GDPR is enabled.

One important timing note: existing audit events are not retroactively tagged when GDPR mode is enabled. Events generated before you enable GDPR will not gain GDPR compliance badges after the fact. If you are preparing for a compliance review that requires GDPR-tagged evidence from a specific date, enable GDPR mode before that date, not after.

The most significant operational change GDPR mode makes is extending audit logging from mutations to reads. Without any compliance standard beyond the always-on Standard baseline, DAVE logs only mutating requests: POST, PUT, PATCH, and DELETE. This means that if an admin views a list of users, reads a role configuration, or pulls a report, that access is not recorded.

When GDPR mode is enabled, GET requests to the following sensitive endpoints are also captured in the audit log:

• Users
• Roles
• Secrets
• API Clients
• OAuth Providers
• Reports

Each of these read-access events is recorded with the same eight fields as any other audit event: timestamp, event type, actor (email and user ID), entity type and ID, HTTP context (method, path, status code), IP address, user agent, and sanitized request details. The event details also include a complianceTriggered: true flag, which distinguishes read-access events captured because of a compliance standard from standard mutation events.

This matters for GDPR specifically because the regulation's right-of-access provisions (Article 15) and records-of-processing obligations (Article 30) require that you can demonstrate not just what data was changed, but who accessed it and when. A mutation-only log cannot satisfy that requirement. A log that captures reads on user data endpoints can.

The six endpoint categories above are the specific ones DAVE captures under GDPR mode. If a GET request is made to an endpoint not in this list, it is not captured as a read-access event even when GDPR mode is active. This is a deliberate scope decision: logging every GET request across the entire API would generate an unmanageable volume of events. The six categories represent the endpoints where personal and sensitive data is most likely to be accessed.

DAVE's GDPR compliance standard is mapped to five specific Articles of the General Data Protection Regulation. These are the Articles that the audit logging controls are designed to support evidence for. They are not the only Articles that apply to an organisation processing personal data, but they are the ones that the audit trail directly addresses.

• Article 5 - Lawfulness of Processing. Requires that personal data is processed lawfully, fairly, and transparently, and that processing is limited to what is necessary. The audit log's record of who accessed and modified user data supports demonstration of processing accountability.

• Article 15 - Right of Access. Gives data subjects the right to know whether their personal data is being processed and to obtain a copy. The read-access logging activated by GDPR mode creates a record of when user data was accessed, by whom, and from where, which supports responding to subject access requests with evidence of access history.

• Article 17 - Right to Erasure. Gives data subjects the right to have their personal data deleted under certain conditions. Deletion events (DELETE requests to user data endpoints) are captured in the audit log under the Standard baseline. GDPR mode adds the read context that shows what data was accessed before deletion.

• Article 30 - Records of Processing Activities. Requires controllers and processors to maintain records of processing activities. The audit log, with GDPR mode enabled, provides a continuous, immutable record of processing activity across user data endpoints, suitable for inclusion in or reference from a Records of Processing Activities document.

• Article 33 - Breach Notification. Requires notification of personal data breaches to the supervisory authority within 72 hours of becoming aware. The audit log's timestamped, actor-identified records of access to user data endpoints support the forensic analysis needed to determine the scope and timing of a breach, which is a prerequisite for an accurate breach notification.

These five Articles represent the compliance surface that GDPR mode's logging controls are designed to support. They do not represent DAVE's complete GDPR posture: data minimisation, consent management, data subject request workflows, and processor agreements are organisational and contractual matters that sit outside the scope of audit logging controls.

When GDPR mode is active, every qualifying audit event carries a complianceTags array in its detail payload. For an event that satisfies GDPR requirements, this array includes "gdpr". For an event that satisfies both SOC 2 and GDPR (if both are enabled), the array includes both tags, for example ["standard", "soc2", "gdpr"]. The Standard tag is always present.

In the audit log UI at Admin, then Settings, then Audit Log, compliance tags are displayed as colored badges next to the event type label:

• SOC2 badge: blue
• GDPR badge: purple

These badges make it visually immediate which events are in scope for which standard. When you are preparing a date-scoped export for a compliance review, you can confirm at a glance that GDPR badges are present on events within the review period, which confirms that GDPR mode was active during that time.

The act of enabling GDPR mode is itself recorded as a special audit.compliance_changed event. This event captures the before state (which standards were active before the change), the after state (which standards are active after the change), and exactly what was added or removed. This means you can produce an immutable record of when GDPR mode was enabled, by which admin, and whether it was ever subsequently disabled. Filter the audit log by event type audit.compliance_changed to see the full timeline of compliance standard changes for your tenant.

This compliance change record is significant for auditors and data protection officers. A system that claims GDPR logging was active during a given period but cannot show when the standard was enabled, or whether it was disabled and re-enabled, cannot provide the level of assurance that a serious compliance review requires. The audit.compliance_changed event closes that gap.

Enabling GDPR mode is a one-click action in the System Parameters section. The operational preparation around it matters more than the click itself. Here are four things to verify before enabling GDPR mode in a production tenant.

1. Check your audit log retention setting. Navigate to Admin, then Settings, then General, then System Parameters, then Retention Policy. The Retain Audit Logs field accepts 30, 60, 90, 180, 365, or 730 days, or Forever. The default is 365 days. GDPR does not specify a single mandatory retention period, but Article 30 records-of-processing obligations and the practical requirements of breach investigation under Article 33 typically require retention well beyond one year. Review your retention setting against your organisation's legal advice before going live. If you need indefinite retention, set the field to Forever, but note that this increases storage over time.

2. Confirm that the Admin role is assigned to the right people. Only Admin users can view the audit log, export it, and change compliance settings. Navigate to Admin, then Settings, then Users and Roles to verify that the users who need audit log access have the Admin role, and that users who should not have it do not. This is itself a GDPR-relevant control: limiting access to the records of processing activities to authorised personnel.

3. Enable GDPR mode before your first production data processing, not after. Existing events are not retroactively tagged. If personal data has already been processed in your tenant before GDPR mode is enabled, those events will not carry GDPR compliance badges. For a clean compliance record, enable GDPR mode before any personal data enters the system.

4. Export the compliance_changed event immediately after enabling. Once you have enabled GDPR mode and saved, navigate to the Audit Log tab, filter by event type audit.compliance_changed, and export the result as CSV. This gives you an immediate, timestamped record of when GDPR mode was activated and by whom. Store this export in your compliance documentation alongside your Records of Processing Activities. It is the foundational evidence that your GDPR logging controls were in place from a specific date.

GDPR mode and SOC 2 mode share a mechanism: both activate read-access logging on the same six sensitive endpoint categories (Users, Roles, Secrets, API Clients, OAuth Providers, Reports), and both add compliance tags to qualifying events. If both are enabled simultaneously, events that satisfy both standards carry both tags.

Where they differ is in the framework they reference and the specific controls they are designed to support evidence for.

• SOC 2 mode maps to three Trust Services Criteria: CC6 (Logical and Physical Access), CC7 (System Operations), and CC8 (Change Management). It also triggers a warning in the UI if audit log retention is set below 2,555 days (seven years), which is the SOC 2 recommended minimum.
• GDPR mode maps to five GDPR Articles: 5 (Lawfulness of Processing), 15 (Right of Access), 17 (Right to Erasure), 30 (Records of Processing Activities), and 33 (Breach Notification). It does not trigger a specific retention warning, because GDPR does not prescribe a single mandatory retention period in the same way SOC 2 guidance does.

For organisations subject to both frameworks, enabling both standards simultaneously is the correct configuration. The two standards complement rather than duplicate each other: SOC 2 focuses on operational security controls and change management; GDPR focuses on the lawfulness and accountability of personal data processing. Both produce the same type of evidence (timestamped, actor-identified, compliance-tagged audit events) but frame that evidence against different regulatory requirements.

If your organisation is subject to GDPR but not currently pursuing SOC 2 attestation, enabling GDPR mode alone is sufficient to activate the compliance logging controls described in this article. You do not need to enable SOC 2 mode to get GDPR read-access logging.