Join the Waitlist
Guide · Running and Operating

How to Export an Audit Log for a Compliance Review

By DAVE by voolama5 stepsUpdated AUG 20265 min readAI

Summary

A step-by-step guide to filtering, scoping, and exporting DAVE's audit log as a CSV file ready for external auditors, compliance teams, or incident investigators.

The steps

  1. Navigate to the Audit Log

    Go to Admin, then Settings and select the Audit Log tab. The page displays a table of all recorded audit events for your tenant, sorted by most recent first.

    The Audit Log tab is only visible to users with admin:* or audit:read permissions. If you do not see the tab, your account does not have the required role. Ask an existing Admin to assign the appropriate role under Admin, then Settings, then Users and Roles.

    Do this
    • Open Admin, then Settings in the top navigation.
    • Click the Audit Log tab.
    • Confirm the event table loads with timestamped rows.
    Example

    You arrive at the Audit Log tab and see a table with columns for Time, Event Type, Actor, Entity Type, Method, Status, and Action. The most recent events appear at the top. If the table is empty, your tenant has no recorded events yet, or your retention period has purged them.

    Best practice

    Bookmark the Audit Log URL so you can reach it directly during a time-sensitive investigation or audit preparation session. Do not rely on navigating from the dashboard each time.

  2. Confirm compliance standards are active (SOC 2 or GDPR)

    Before exporting, confirm that the compliance standards relevant to your review are enabled. When SOC 2 or GDPR is active, events carry colored compliance badges (SOC2 in blue, GDPR in purple) and read-access events on sensitive endpoints are captured alongside mutations. An export from a tenant without compliance standards enabled will contain mutation events only and will not carry compliance tags.

    To check: navigate to Admin, then Settings, then General, then System Parameters, then the Audit Log section. The compliance checkboxes show which standards are currently active. If the standard you need is not enabled, enable it now. Note that existing events are not retroactively tagged: only events generated after enabling a standard will carry its compliance badge.

    Do this
    • Navigate to Admin, then Settings, then General, then System Parameters, then the Audit Log section.
    • Confirm the checkbox for SOC 2, GDPR, or both is checked, depending on your review requirements.
    • If a standard is not enabled, check it and save. The change takes effect immediately for new events.
    • Return to the Audit Log tab.
    • Confirm that compliance badges (blue SOC2 or purple GDPR) are visible on recent events.
    Example

    You are preparing evidence for a SOC 2 Type II audit. You navigate to System Parameters and confirm that the SOC 2 checkbox is checked. Back on the Audit Log tab, you can see blue SOC2 badges on events. You also filter by event type audit.compliance_changed and confirm there is an immutable record showing when SOC 2 was enabled and by whom.

    Best practice

    Enable compliance standards before your first production data processing, not after. Events generated before a standard is enabled will not carry its compliance tags and cannot be retroactively updated. If you are enabling a standard for the first time on an existing tenant, note the exact timestamp of the audit.compliance_changed event: this is the start of your compliant audit record.

  3. Set the date range to your review period

    Use the date range filter to scope the export to the specific time window your auditor or reviewer needs. The date range filter provides a From date picker and a To date picker. Set From to the first day of your audit observation period and To to the last day.

    For a SOC 2 Type II audit with a 12-month observation period, set the date range to cover that full 12 months. For a GDPR subject access request, set the date range to cover the period relevant to the data subject's request. For an incident investigation, set the date range to a window around the suspected incident time.

    Do this
    • On the Audit Log tab, locate the From and To date pickers in the filter bar.
    • Set From to the first day of your review period.
    • Set To to the last day of your review period.
    • Confirm the event count in the table updates to reflect the scoped period.
    Example

    Your SOC 2 observation period runs from 2025-09-01 to 2026-08-31. You set From to 2025-09-01 and To to 2026-08-31. The table now shows only events within that window. The row count at the bottom of the table tells you how many events fall within the period: this is the number of rows your CSV export will contain.

    Best practice

    Always set the date range before applying any other filters. This ensures you are working with the correct event population from the start. If you apply event type or entity type filters first, you may lose track of the total event count for the period and inadvertently export an incomplete dataset.

  4. Apply any additional filters needed for your review

    For most compliance exports, a date-scoped export with no additional filters is the right approach: the auditor receives the complete event record for the period, and the compliance badges on each event confirm which standards were active. However, some review scenarios call for targeted filtering before export.

    The available filters are:

    • Text search: searches across event types, actor email addresses, request paths, and entity IDs. Use this to find all events involving a specific user (search by email) or a specific object (search by entity ID).
    • Event Type: a dropdown of all distinct event types present in your logs. Use this to export only authentication events, only compliance configuration changes, or only a specific category of action.
    • Entity Type: a dropdown of all distinct entity types present in your logs. Use this to export only events affecting users, or only events affecting workflows.

    If your review does not require targeted filtering, skip to step 5 without applying additional filters. A full-period export with no additional filters is the safest default for a compliance submission.

    Do this
    • Decide whether your review requires targeted filtering or a full-period export.
    • For a full-period export: confirm no filters other than the date range are active. Check that the Event Type and Entity Type dropdowns show their default (all) values, and that the text search field is empty.
    • For a targeted export: apply the relevant Event Type, Entity Type, or text search filter. Note which filters are active, as these will scope your CSV output.
    • Confirm the event table reflects the intended scope before proceeding to export.
    Example

    A GDPR data subject access request requires you to produce a record of all access to a specific user's data. You set the date range to the relevant period, then use the text search to filter by the user's email address. The table now shows only events where that user was the actor or the affected entity. You export this filtered set as the evidence for the subject access request.

    Best practice

    Document which filters you applied before exporting. If an auditor questions the completeness of your export, you need to be able to demonstrate that the filters were intentional and appropriate for the review scope, not accidental omissions. A note in your compliance documentation stating the filter criteria used for each export is good practice.

  5. Export the filtered results as CSV

    With your date range and any additional filters set, click the download button in the Audit Log toolbar to export all currently filtered results as a CSV file. The export includes all event fields: timestamp, event type, actor, entity, HTTP context, IP address, user agent, details (sanitized), and compliance tags.

    The CSV file is suitable for direct submission to an external auditor, loading into a compliance management tool, or archival in your compliance documentation system. Sensitive values in the details field are already redacted at capture time: the exported file does not require a separate review step to strip credentials before sharing.

    If you need to share a single event rather than a full export, click the copy icon on any event row to copy that event's full details to your clipboard as formatted JSON. This is useful for sharing specific events during an investigation without exporting the entire dataset.

    Do this
    • Confirm your date range and filters are set correctly.
    • Click the download button in the Audit Log toolbar.
    • Save the CSV file with a descriptive filename that includes the date range and the compliance standard, for example dave-audit-soc2-2025-09-01-to-2026-08-31.csv.
    • Open the CSV in a spreadsheet application and spot-check that compliance tags are present on events within the period, confirming the standard was active.
    • Submit or archive the file according to your compliance documentation process.
    Example

    You click the download button. The browser downloads a CSV file. You rename it to dave-audit-soc2-2025-09-01-to-2026-08-31.csv and open it in a spreadsheet. The first few rows show recent events with SOC2 in the compliance tags column. You scroll to the oldest rows and confirm events from the start of the observation period are present. The export is complete and ready for submission.

    Best practice

    Store the exported CSV in a location that is itself access-controlled and auditable. An audit export that is emailed to an uncontrolled distribution list or stored in a public folder undermines the security posture the export is meant to demonstrate. Use your organisation's designated compliance document storage for all audit evidence files.

What this guide covers

This guide walks through the complete process of exporting DAVE's audit log as a CSV file for a compliance review, an external audit, or an incident investigation. It covers navigating to the Audit Log, confirming compliance standards are active, scoping the export to a specific time window, applying targeted filters where needed, and downloading the CSV.

The guide is written for Admin users. Only users with admin:* or audit:read permissions can access the Audit Log tab. If you do not have this access, ask an existing Admin to assign the appropriate role to your account.

The export process takes approximately five minutes for a straightforward compliance period export. More complex targeted exports, such as those scoped to a specific user or entity type, may require additional time to verify filter scope before downloading.

When to export your audit log

There are four common scenarios that call for an audit log export:

  • SOC 2 Type II audit preparation. Your auditor needs a date-scoped export covering the full observation period (typically 12 months), with SOC 2 compliance badges visible on events. The export demonstrates that the controls were operating as configured throughout the period.

  • GDPR subject access request. A data subject has requested a record of how their personal data has been accessed or processed. A filtered export scoped to events involving that data subject's user record provides the evidence needed to respond to the request under GDPR Article 15.

  • Security incident investigation. A suspected unauthorised access or configuration change needs to be investigated. A date-scoped export around the suspected incident time, filtered by the relevant actor email or entity type, provides the forensic record for the investigation.

  • Periodic compliance archival. Your organisation's retention policy requires archiving audit records before the platform's automatic retention cleanup would purge them. Export before the retention period expires for the events you need to keep.

In all four scenarios, the export process is the same. What varies is the date range and filters you apply before downloading.

Before you start: three things to check

Before beginning the export process, verify these three things to avoid producing an incomplete or non-compliant export.

  1. Compliance standards are enabled and have been active since before your review period started. Events generated before a compliance standard was enabled do not carry that standard's compliance tags. If SOC 2 was enabled six months into a 12-month observation period, the first six months of events will not have SOC 2 badges. Check the audit.compliance_changed event in your log to confirm when each standard was enabled. Navigate to Admin, then Settings, then General, then System Parameters, then the Audit Log section to verify current settings.

  2. Your retention period covers the review window. Events older than your configured retention period are permanently deleted by the platform's automatic cleanup task. If your review period extends further back than your retention setting allows, those events no longer exist and cannot be recovered. Navigate to Admin, then Settings, then General, then System Parameters, then Retention Policy to check your current retention setting. The default is 365 days. SOC 2 recommends at least 2,555 days (seven years): a warning is displayed in the UI if retention is set below this threshold when SOC 2 mode is active.

  3. You have Admin access. The Audit Log tab and the CSV export function are restricted to users with admin:* or audit:read permissions. If you cannot see the Audit Log tab, you do not have the required access. Ask an existing Admin to update your role assignment under Admin, then Settings, then Users and Roles.

What the exported CSV contains

The CSV export includes all event fields for every event that matches your current filter set at the time you click the download button. The columns in the exported file correspond directly to the eight fields captured on every audit event:

  • Timestamp: when the event occurred, to the second.
  • Event Type: the categorised label for the action, such as auth.login, users.create, or audit.compliance_changed.
  • Actor: the email address and user ID of the person who performed the action.
  • Entity: the type and ID of the object affected.
  • HTTP Context: the request method, path, and status code.
  • IP Address: the source IP of the request.
  • User Agent: the browser or client that made the request.
  • Details: the sanitized request body, with passwords, secrets, and tokens automatically redacted and large payloads truncated.

When compliance standards are active, the details column also includes the complianceTags array for each event, showing which standards the event satisfies. This is the field an auditor uses to confirm that compliance logging was active and that the event falls within the scope of the relevant standard.

One important note on export completeness: the CSV export includes only events that match the current filter set. If any filters other than the date range are active when you click the download button, the export will be scoped to those filters. Always verify your filter state before downloading. If you intend to export the complete event record for a period, click Clear filters first, then re-apply only the date range, then download.

Frequently asked questions

Can I export the audit log without Admin access?
No. The Audit Log tab and the CSV export function are restricted to users with admin:* or audit:read permissions. Ask an existing Admin to assign the appropriate role to your account.

Why are some events missing compliance badges in my export?
Events generated before a compliance standard was enabled do not carry that standard's compliance tags. Compliance tagging is applied at event capture time and cannot be added retroactively. Check the audit.compliance_changed event in your log to confirm when each standard was enabled, and note this in your compliance documentation if the observation period predates the standard's activation.

Why does my CSV export contain fewer events than I expected?
The CSV export is scoped to your current filter set. If Event Type, Entity Type, or text search filters are active, they will exclude events that do not match. Click Clear filters, re-apply only the date range, and re-export to get the full event record for the period.

Can I recover events that have been purged by the retention policy?
No. Events deleted by the automatic retention cleanup are permanently removed and cannot be recovered. If your review period extends beyond your retention window, those events no longer exist. To prevent this in future, increase your retention setting at Admin, then Settings, then General, then System Parameters, then Retention Policy, or set it to Forever for indefinite retention.

Is the exported CSV safe to share with an external auditor?
Yes. Sensitive values, specifically passwords, secrets, and tokens, are automatically redacted at capture time before events are written to the log. The exported CSV contains only sanitized data and does not require a separate review step to strip credentials before sharing. Note that other request body fields are captured as-is: review the details column for any business-sensitive content before sharing externally if your organisation's data handling policies require it.

Can I export a single event rather than the full filtered set?
Yes. Click the copy icon on any event row to copy that event's full details to your clipboard as formatted JSON. This is useful for sharing a specific event during an investigation without exporting the entire dataset.