How to Enable SOC 2 or GDPR Mode in DAVE

Summary

The steps

1. 1

   Navigate to the compliance settings panel

   Compliance standards are configured in a specific sub-section of Admin Settings. The path has three levels: the Settings page, the General tab, and the System Parameters section within it. Getting to the right panel before making any changes avoids confusion with other settings on the same page.

   The Audit Log tab (also at Admin, then Settings) is where you view audit events. The System Parameters section is where you configure compliance standards. These are two different places on the same Settings page.

   Do this

   • In the sidebar, click Admin.
   • Click Settings.
   • Confirm the Settings page loads. You will see tabs at the top: General, Access, and Audit Log.
   • Stay on the General tab (it is the default).
   • Scroll down to the System Parameters section.
   • Within System Parameters, locate the Audit Log sub-section. This contains the compliance standard checkboxes.

   Example

   If the Settings page does not appear in your sidebar, your account does not have the Admin role. Ask an existing Admin to assign it at Admin, then Settings, then Users and Roles. Only users with admin:* or audit:read permissions can view the Audit Log tab; only Admin role holders can modify compliance settings.

   Best practice

   Before enabling either compliance standard, decide on your retention policy first (covered in Step 3). Enabling SOC 2 without addressing retention will trigger a warning about the 7-year recommendation. It is cleaner to set retention before enabling the standard than to address the warning after.

2. 2

   Enable SOC 2 and/or GDPR compliance standards

   The Audit Log sub-section within System Parameters contains three compliance standard controls:

   • Standard: Always enabled and cannot be disabled. This is the baseline audit trail that every tenant has by default. It captures all mutations (create, update, delete), authentication events, and system changes.
   • SOC 2: Off by default. A checkbox you enable when your organisation operates under SOC 2 requirements.
   • GDPR: Off by default. A checkbox you enable when your organisation processes personal data of EU residents or wants read-access logging for user data endpoints.

   The two standards are independent. You can enable one, both, or neither (beyond the always-on Standard baseline). Most organisations that need both will enable both at the same time.

   What SOC 2 mode adds: Read-access logging for sensitive endpoints, covering GET requests to: Users, Roles, Secrets, API Clients, OAuth Providers, and Reports. These events would not be logged without SOC 2 or GDPR enabled. SOC 2 mode covers trust service criteria CC6 (Logical and Physical Access), CC7 (System Operations), and CC8 (Change Management).

   What GDPR mode adds: Read-access logging for user data endpoints, covering GET requests to the same sensitive endpoint list. GDPR mode covers Articles 5 (Lawfulness of Processing), 15 (Right of Access), 17 (Right to Erasure), 30 (Records of Processing Activities), and 33 (Breach Notification).

   What both modes share: Every read-access event logged under either standard includes a complianceTriggered: true flag in its details, distinguishing it from standard mutation events. Every audit event includes a complianceTags array showing which standards it satisfies. Events may carry one or both tags depending on which standards they satisfy.

   Critical: existing events are not retroactively tagged. Enabling a compliance standard does not add compliance tags to events that were recorded before the standard was enabled. New events from the moment of enablement onward will carry the appropriate tags. If you need a complete tagged audit trail from day one, enable compliance standards before the team starts using the platform.

   Do this

   • In the System Parameters Audit Log sub-section, locate the SOC 2 checkbox and check it if your organisation requires SOC 2 compliance.
   • Locate the GDPR checkbox and check it if your organisation processes EU personal data or requires GDPR-aligned audit logging.
   • Do not uncheck Standard: it is greyed out and cannot be disabled.
   • Click Save Settings at the bottom of the form.
   • Confirm the green success banner appears.

   Example

   A SaaS company preparing for a SOC 2 Type II audit enables SOC 2 mode at the start of their audit observation period. From that point, every read of a user record, role assignment, secret, or API client is logged alongside all mutations. The auditor receives a date-filtered CSV export covering the full observation period, with SOC2 compliance badges visible on every relevant event.

   Best practice

   Enable compliance standards at the start of a new audit period, not partway through. Partial-period coverage is harder to explain to auditors than full-period coverage. If you are enabling compliance standards for the first time on an existing tenant, note the enablement date and document it: the audit.compliance_changed event in the audit log records this automatically, but having it in your internal documentation as well avoids questions later.

3. 3

   Set audit log retention to match your compliance requirements

   Enabling a compliance standard without addressing retention is an incomplete configuration. The audit log retention setting controls how long events are kept before automatic, permanent deletion. If retention is shorter than your compliance requirement, events will be purged before you need them.

   Retention is configured at Admin, then Settings, then General, then System Parameters, then Retention Policy. The Retain Audit Logs field has the following options: 30, 60, 90, 180, 365, or 730 days, or Forever (set retention to 0 to never delete audit logs).

   The default is 365 days (1 year).

   SOC 2 retention guidance: SOC 2 recommends at least 2,555 days (7 years) of audit log retention. If your Retain Audit Logs setting is below this threshold, DAVE displays a warning. The maximum dropdown option is 730 days (2 years). If your SOC 2 requirements specify the full 7-year period, set retention to Forever and manage archival manually, or export audit logs as CSV before they are purged if you use a shorter retention window.

   GDPR retention guidance: GDPR does not specify a fixed retention period for audit logs, but Article 30 (Records of Processing Activities) requires that processing records be maintained for as long as processing activities continue. A minimum of 3 years is a common practical baseline. Set retention to at least 365 days and review annually.

   Cleanup runs automatically via a scheduled background task. Expired events are permanently deleted and cannot be recovered. Reducing retention below the current setting may cause existing events to be purged in the next cleanup cycle.

   Do this

   • In the System Parameters section, locate Retention Policy.
   • Find the Retain Audit Logs dropdown.
   • If SOC 2 is enabled: select Forever if your requirements specify 7-year retention, or select 730 days and plan for regular CSV exports.
   • If GDPR is enabled: select at least 365 days, and consider 730 days for a comfortable compliance margin.
   • Click Save Settings.
   • Confirm the green success banner.
   • If SOC 2 is enabled and retention is below 2,555 days, note the warning DAVE displays and document your export plan.

   Example

   A team that enables SOC 2 mode sets Retain Audit Logs to Forever and schedules a quarterly calendar reminder to export the previous quarter's audit log as CSV and store it in their compliance archive. This gives them indefinite retention in the platform and a portable archive outside it.

   Best practice

   Do not reduce retention settings without first exporting the data you need. Cleanup is automatic and irreversible. If you are unsure between two options, always choose the longer retention period. Use Forever sparingly on large tenants with high event volume, as it prevents automatic cleanup entirely. If your compliance requirement is exactly 7 years and you cannot use Forever, set retention to 730 days and export quarterly.

4. 4

   Verify the compliance change was recorded

   Every change to compliance standards generates an automatic audit.compliance_changed event in the audit log. Verifying this event exists confirms that the change was saved, recorded, and timestamped correctly. It is also the first piece of compliance evidence you can point to: an immutable record of when the standard was enabled and by whom.

   The audit.compliance_changed event records four things: the Before state (which standards were active before the change), the After state (which standards are active now), Added (which standards were enabled), and Removed (which standards were disabled). The event is displayed with an amber color code in the audit log table.

   Do this

   • Navigate to Admin, then Settings and click the Audit Log tab.
   • The most recent event at the top of the table should be an audit.compliance_changed event with an amber color indicator.
   • Click the row to expand it and view the full event details.
   • Confirm the After field shows the compliance standards you just enabled.
   • Confirm the Actor field shows your email address and user ID.
   • Confirm the Timestamp matches the time of your change.
   • Optionally, click the copy icon on the row to copy the event details to your clipboard, or use the CSV export button to export the event for your compliance records.

   Example

   An Admin enables SOC 2 mode on 2026-08-30. They navigate to the Audit Log tab and find an audit.compliance_changed event at the top of the list, timestamped to the minute. Expanding the row shows Before: ["standard"], After: ["standard", "soc2"], Added: ["soc2"], Removed: []. They export this event as part of their SOC 2 audit preparation package.

   Best practice

   Export the audit.compliance_changed event immediately after enabling compliance standards and store it in your compliance documentation. This event is the proof that compliance logging was enabled at a specific point in time. SOC 2 auditors and GDPR supervisory authorities may ask for this evidence. Having it in your external archive means you are not dependent on the platform's retention policy to produce it.

5. 5

   Confirm read-access logging is active

   The most practical way to confirm that compliance logging is working is to trigger a read-access event and verify it appears in the audit log. Without compliance standards enabled, GET requests to sensitive endpoints are not logged. With SOC 2 or GDPR enabled, they are.

   The sensitive endpoints that generate read-access events when compliance is enabled are: Users, Roles, Secrets, API Clients, OAuth Providers, and Reports. Navigating to any of these pages in the Admin section will trigger a GET request that should now appear in the audit log.

   Do this

   • Navigate to Admin, then Settings, then Users and Roles. This triggers a GET request to the Users endpoint.
   • Return to Admin, then Settings and click the Audit Log tab.
   • Use the Event Type filter dropdown to filter for users.list or a similar read event type.
   • Confirm a read-access event appears for the navigation you just performed.
   • Click the row to expand it and confirm the Details section includes complianceTriggered: true.
   • Confirm the event carries the appropriate compliance badge: blue for SOC2, purple for GDPR, or both.

   Example

   After enabling SOC 2 mode, an Admin navigates to the Users list and then checks the Audit Log. They find a users.list event with a blue SOC2 badge and complianceTriggered: true in the details. This confirms that read-access logging is active and working correctly.

   Best practice

   Run this verification step immediately after enabling compliance standards, not days later. If read-access events are not appearing, the most likely cause is that the compliance standard was not saved correctly. Return to System Parameters and confirm the SOC 2 or GDPR checkbox is checked and that the save completed with a green success banner. If the Audit Log tab is not visible, your account needs admin:* or audit:read permissions.

What SOC 2 mode and GDPR mode each do

What enabling compliance mode does not change

Who can see and export the audit log

Frequently asked questions