Is Your AI Workflow Tool SOC 2 Ready? What to Look For

SOC 2 is a framework, not a checkbox. The Trust Services Criteria it defines require that a system can demonstrate, with evidence, that it controls access, monitors activity, and retains records of both. For an AI workflow tool, that means the system must be able to answer three questions an auditor will ask:

1. Who did what, and when?
2. Did anyone read sensitive data, and if so, who and when?
3. How long are those records kept, and can you prove they have not been tampered with?

A tool that can answer all three with a filterable, exportable log is SOC 2 ready in the operational sense. A tool that answers none of them, or answers them only partially, creates audit risk for every customer who runs it in a production environment.

The distinction matters more for AI workflow tools than for conventional SaaS because AI tools handle a wider surface area of sensitive data: API keys for external AI providers, content generated from proprietary inputs, human review decisions on sensitive material, and agent interactions that may touch personal or regulated data. Each of those surfaces needs to be in scope for the audit log, not just the authentication layer.

It is also worth being precise about what SOC 2 readiness is not. A vendor claiming SOC 2 readiness is not the same as a vendor holding a SOC 2 Type II attestation from an independent auditor. Readiness means the controls are in place and can be demonstrated. Certification means an auditor has independently verified them over an observation period. Both matter, but they are different claims, and a vendor who conflates them is worth scrutinising.

The non-negotiable starting point for SOC 2 readiness is an immutable audit log that captures every significant action in the system. Immutable means the log cannot be edited or deleted by any user, including administrators. Significant means the log covers not just authentication events but the full lifecycle of every object in the system: creation, modification, deletion, and, when compliance mode is active, read access.

In DAVE, the audit log is accessible at Admin, then Settings, then the Audit Log tab. Every event in the log captures eight fields that map directly to what a SOC 2 auditor needs:

• Timestamp: when the event occurred, to the second.
• Event Type: a categorised label for the action, such as auth.login, users.create, tenant.update, 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.

The sanitization point is important. A log that captures raw request bodies including API keys or passwords is itself a security liability. DAVE redacts known sensitive fields automatically, so the log is useful for auditors without being a new attack surface.

Access to the audit log is restricted to users with admin:* or audit:read permissions. Of the six default tenant roles, only the Admin role can view, filter, search, and export audit data. This access control is itself logged: any attempt to access the audit log is an auditable event.

A log that captures events is necessary but not sufficient for SOC 2. Auditors need to be able to identify which events are in scope for the standard, and they need evidence that the system was configured to capture compliance-relevant activity during the audit period. DAVE addresses this through a compliance mode that is explicitly enabled and recorded.

When SOC 2 compliance is enabled in Admin, then Settings, then General, then System Parameters, then the Audit Log section, two things change:

1. Compliance tags are added to events. Each event's complianceTags array is populated with the applicable standards, such as ["standard", "soc2"]. These tags are stored in the event payload and displayed in the audit log UI as colored compliance badges: blue for SOC2, purple for GDPR. Events may carry one or both badges depending on which standards they satisfy.
2. Read-access logging is activated. Without compliance mode, only mutating requests (POST, PUT, PATCH, DELETE) are logged. With SOC 2 or GDPR enabled, GET requests to sensitive endpoints are also captured. The sensitive endpoints covered are: Users, Roles, Secrets, API Clients, OAuth Providers, and Reports. These read-access events include a complianceTriggered: true flag in their details, distinguishing them from standard mutation events.

The act of enabling or disabling compliance mode is itself recorded as a special audit.compliance_changed event. This event captures the before state, the after state, and exactly what was added or removed. This means an auditor can verify not just that compliance mode was active during the audit period, but precisely when it was turned on, by whom, and whether it was ever turned off.

This is a meaningful control. A system that claims SOC 2 readiness but has no record of when its compliance logging was enabled, or whether it was disabled and re-enabled during the audit period, cannot satisfy an auditor who asks for that evidence.

SOC 2 auditors typically require evidence covering a defined observation period, often twelve months for a Type II audit. But the underlying Trust Services Criteria, and the practical requirements of most enterprise security programmes, push retention requirements significantly longer. DAVE's audit log documentation notes that the SOC 2 recommendation is at least 2,555 days, which is seven years, and the system displays a warning if retention is set below that threshold when SOC 2 mode is active.

Retention is configured in Admin, then Settings, then General, then System Parameters, then the Retention Policy section. The default retention period is 365 days. Three practical settings are available:

• A specific number of days: events older than the configured period are automatically purged by a scheduled background task. If SOC 2 mode is active and the configured period is below 2,555 days, the UI displays a warning.
• Forever (set retention to 0): audit logs are never automatically deleted. Use this when compliance or legal requirements demand indefinite retention, but note that retaining all events indefinitely increases storage over time.

The most common mistake teams make is connecting an AI workflow tool to production data before configuring retention. Events generated before retention is set to a compliant value are not retroactively affected by a later change: they will be purged according to whatever policy was active when they were created. If you enable SOC 2 mode on day one but leave retention at the 365-day default, you will have a gap in your audit evidence at the twelve-month mark.

The practical sequence is: enable SOC 2 compliance mode first, set retention to at least 2,555 days (or to Forever if your legal team requires it), then begin production use. This ensures every event generated in production is captured under the correct retention policy from the start.

Configuring the right controls is necessary. Being able to produce the evidence when an auditor asks for it is equally important. DAVE's audit log provides two export mechanisms designed for exactly this use case.

The first is row-level copy: click the copy icon on any event row to copy that event's full details to the clipboard as formatted JSON. This is useful for sharing specific events during an investigation or for spot-checking individual records.

The second is CSV export: click the download button to export all events that match the current filter set as a CSV file. The exported data includes all event fields, making it suitable for submission to an external auditor or for loading into a compliance management tool.

The filtering controls are designed to produce audit-period-scoped exports without manual post-processing. The available filters are:

• Text search: searches across actions, email addresses, paths, and entity IDs. Type an email address to find all actions by a specific user.
• Event Type: a dropdown of all distinct event types present in the log. Filter to audit.compliance_changed to produce a timeline of when compliance standards were modified.
• Entity Type: a dropdown of all distinct entity types present in the log.
• Date range: from and to date pickers to scope events to a specific time window, such as the audit observation period.

A practical audit export workflow: set the date range to the observation period, confirm that compliance badges are visible on events (confirming SOC 2 mode was active during that period), clear any other filters, and export the full CSV. The resulting file contains the timestamped, actor-identified, compliance-tagged evidence an auditor needs to verify the controls were operating as configured.

One important note on export completeness: the CSV export includes only events that match the current filter set. If filters are active when you click the download button, the export will be scoped to those filters. Always click Clear filters before a full-period export, or verify that your active filters are intentional.

Whether you are evaluating DAVE or any other AI workflow platform, these five questions will quickly separate tools with genuine compliance controls from tools with compliance marketing.

1. Does your audit log capture read access to sensitive endpoints, or only mutations? A log that only records writes misses a significant category of SOC 2 evidence: who read what. The answer should be that read-access logging is available, ideally activated automatically when a compliance mode is enabled, and that it covers the specific endpoints where sensitive data lives.

2. Is the act of enabling or disabling compliance mode itself logged? If a vendor cannot show you an immutable record of when their compliance controls were turned on, you cannot verify that the controls were active during the audit period. The answer should be yes, with a specific event type for compliance configuration changes.

3. What is the default retention period, and what is the SOC 2 recommended minimum? A vendor whose default retention is 30 or 90 days is not designed for compliance use cases. The answer should include a specific recommended minimum (seven years is the common SOC 2 guidance) and a warning mechanism if the configured retention falls below it.

4. Are sensitive values in the audit log automatically redacted? A log that captures raw API keys, passwords, or tokens in event details is a security liability. The answer should be that known sensitive fields are redacted at capture time, not at display time, and that the redaction covers secrets, tokens, and passwords at minimum.

5. Can I export audit evidence scoped to a specific date range, filtered by compliance standard, as a file I can hand to an auditor? If the answer requires a custom data extract, a support ticket, or a professional services engagement, the tool is not operationally ready for a SOC 2 audit. The answer should be yes, available in the product UI, in a standard format such as CSV.

DAVE's audit log is designed to answer all five questions affirmatively. The controls described in this article are product features, not aspirational claims: they are configurable in the Admin panel today. What DAVE does not claim is SOC 2 Type II certification, which requires independent third-party attestation over an observation period. If your procurement process requires a certified vendor, that is a separate evaluation. If your goal is to operate a compliant AI workflow environment with the controls in place to support a future audit, the features described here are where to start.