How Do I Use Dave by voolama Task Decisions as an Audit Trail for SOC 2 and GDPR?

Summary

The steps

1. 1

   Understand what the audit log captures for each task type

   Dave by voolama (hellodave.ai) has four task types: user_interaction, human_review, agent_review, and safety_check. The audit log captures the same four fields for all four types. Sourced from the tasks help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30.

   Audit field	What is recorded	SOC 2 CC6.1 mapping	GDPR Article 30 mapping
   Acting user	The user ID of the person who submitted the decision	Identifies the authorised user who performed the access action	Identifies the natural person responsible for the processing activity
   Decision	Approve, Reject, or Request Changes	Records the specific action taken, not just that access occurred	Records the nature of the processing activity
   Timestamp	The date and time the decision was submitted	Enables time-bound access review	Enables chronological reconstruction of processing activities
   Submitted result JSON	The full submitted result, with sensitive fields redacted	Provides the evidentiary record of what was approved or rejected	Records the output of the processing activity without exposing personal data values

   Task assignment changes are also logged separately. If a task is reassigned from one user to another, the reassignment event records the original assignee, the new assignee, and the timestamp. This maps to SOC 2 CC6.1's requirement to record changes to access rights, not just access events.

   Do this

   • Navigate to Admin, then Settings, then Audit Log.
   • Filter by event type: task_completed.
   • Open any task_completed event. Confirm it shows the acting user, the decision, the timestamp, and the submitted result JSON.
   • Filter by event type: task_assigned. Confirm assignment changes are present.
   • No vendor trust required: the audit log is independently readable in the UI.

   Example

   You open a task_completed audit event. The event record shows: acting_user: user-id-0042, decision: Reject, timestamp: 2026-10-24T14:32:11Z, submitted_result: {decision: 'reject', comment: 'Claim in paragraph 2 is inaccurate.', sensitive_field: '[REDACTED]'}. The sensitive_field value is replaced with [REDACTED] automatically. The comment is preserved in full. Verify: open the same task in the Task Inbox. The Submitted Result section shows the same JSON. No vendor trust required.

   Best practice

   The tasks help documentation states: "Use comments to document your decisions. Even a brief note explaining why you rejected or requested changes helps workflow owners and other reviewers understand the history." A comment on a Reject or Request Changes decision is the difference between an audit record that says 'user X rejected this' and one that says 'user X rejected this because the claim in paragraph 2 is inaccurate.' The second record is more useful to a compliance auditor reviewing the decision chain.

2. 2

   Verify the SOC 2 CC6.1 role boundary independently

   SOC 2 Trust Services Criteria CC6.1 requires that logical access to systems and data is restricted to authorised users. In Dave by voolama (hellodave.ai), the task access boundary is enforced on the server by role. Only Admin and Use roles can view and complete tasks. All other roles return a 403 Forbidden error on direct URL access. Sourced from the tasks help documentation, DEV v0.11.0, confirmed 2026-08-30.

   Dave by voolama has six default roles: Admin, Create, Curate, Use, Reporting, and Financial. Roles are editable. The role-to-task-access mapping:

   Role	View Task Inbox	View task detail	Submit a decision	Add a comment
   Admin	Yes	Yes	Yes	Yes
   Create	No (403)	No (403)	No	No
   Curate	No (403)	No (403)	No	No
   Use	Yes	Yes	Yes	Yes
   Reporting	No (403)	No (403)	No	No
   Financial	No (403)	No (403)	No	No

   The 403 response is independently verifiable. A compliance auditor can confirm the boundary by attempting to access the Task Inbox URL with a Reporting-role account and observing the 403 response.

   Do this

   • Create a test user with only the Reporting role at Admin, then Settings, then Users and Roles.
   • Log in as that user. Confirm the Tasks link is absent from the sidebar.
   • Navigate directly to the Task Inbox URL. Confirm the response is 403 Forbidden.
   • Log back in as an Admin or Use-role user. Confirm the Tasks link is present and the Task Inbox loads.
   • Document the test result. This is the CC6.1 access control verification evidence.

   Example

   A compliance auditor asks for evidence that task access is restricted to authorised users. You create a Reporting-role test account, log in, and navigate to the Task Inbox URL. The browser shows a 403 Forbidden error. You screenshot the response. You log in as a Use-role account and navigate to the same URL. The Task Inbox loads. Both screenshots together constitute the CC6.1 access control evidence. No vendor trust required.

   Best practice

   Assign the minimum roles each person needs. A compliance reviewer who only needs to read reports should have the Reporting role, not the Use role. Giving a compliance reviewer the Use role to access the audit log is unnecessary and conflicts with NIST SP 800-53 Rev 5 AC-6 section 6a (least privilege). The Reporting role grants audit log access without task access, which is the correct assignment for a compliance reviewer who does not participate in workflow execution.

3. 3

   Enable compliance modes and verify audit tags

   SOC 2 and GDPR compliance modes in Dave by voolama (hellodave.ai) add compliance tags to audit events. Both are disabled by default. Sourced from the tasks help documentation, DEV v0.11.0, confirmed 2026-08-30.

   Enable at Admin, then Settings, then General, then System Parameters, then Audit Log. Only the Admin role can enable compliance modes.

   Mode	What it adds to task audit events	Standard	Verify independently
   SOC 2 mode	CC6.1 compliance tag on task_completed and task_assigned events	AICPA Trust Services Criteria CC6.1: logical access controls	Enable SOC 2 mode. Complete a task. Navigate to Audit Log. The task_completed event shows a SOC 2 compliance badge with a CC6.1 tag. No vendor trust required.
   GDPR mode	Article 30 compliance tag on task_completed events. Data-subject tracking on tasks involving personal data.	GDPR Article 30: records of processing activities (Regulation EU 2016/679)	Enable GDPR mode. Complete a task. Navigate to Audit Log. The task_completed event shows a GDPR compliance badge with an Article 30 tag. No vendor trust required.

   The two modes are independent and additive. Enabling both adds both CC6.1 and Article 30 tags to the same audit event. Whether enabling these modes satisfies a specific contractual or regulatory obligation is a legal question requiring a third-party compliance assessment.

   Do this

   • Navigate to Admin, then Settings, then General, then System Parameters, then Audit Log.
   • Enable SOC 2 mode. Save.
   • Navigate to Tasks. Complete any pending task.
   • Navigate to Admin, then Settings, then Audit Log. Find the task_completed event.
   • Confirm the event shows a SOC 2 compliance badge with a CC6.1 tag.
   • Repeat with GDPR mode enabled. Confirm the Article 30 tag appears on the same event.

   Example

   You enable both SOC 2 and GDPR modes. You complete a human_review task by clicking Approve. You navigate to the Audit Log and open the task_completed event. The event record shows: compliance_tags: ['soc2_cc6.1', 'gdpr_art30'], acting_user: user-id-0042, decision: Approve, timestamp: 2026-10-25T09:14:33Z. Both compliance tags are present on the same event. Verify: the compliance_tags array is visible in the event payload in the Audit Log UI. No vendor trust required.

   Best practice

   Enable compliance modes before your team starts using the platform in production. Audit events generated before a compliance mode is enabled do not retroactively receive compliance tags. If you enable SOC 2 mode after 100 instances have already completed, the first 100 instances' task events will not carry CC6.1 tags. The compliance record starts from the moment the mode is enabled.

4. 4

   Present the task audit trail to a compliance auditor

   A compliance auditor reviewing SOC 2 CC6.1 or GDPR Article 30 for Dave by voolama (hellodave.ai) needs three categories of evidence from the task audit trail. All three are independently verifiable in the UI. Sourced from the tasks help documentation, DEV v0.11.0, confirmed 2026-08-30.

   Evidence category	What to show	Where to find it
   Access control boundary	Proof that only authorised roles can access tasks	403 Forbidden response for a Reporting-role user navigating to the Task Inbox URL (see step 2)
   Decision records	Attributable, timestamped records of every task decision	Audit Log filtered by task_completed, showing acting_user, decision, timestamp, and submitted_result for each event
   Assignment records	Records of task assignment changes	Audit Log filtered by task_assigned, showing original assignee, new assignee, and timestamp for each change

   Sensitive fields in the submitted result JSON are automatically redacted before the audit record is written. The tasks help documentation states: "Submission data is captured with sensitive fields redacted." The audit record is safe to export and share with an external auditor without additional data masking.

   Do this

   • Navigate to Admin, then Settings, then Audit Log.
   • Filter by event type: task_completed. Export or screenshot the filtered list for the audit period under review.
   • Filter by event type: task_assigned. Export or screenshot the filtered list for the same period.
   • Prepare the 403 Forbidden evidence from step 2.
   • Present all three categories to the auditor. No additional data masking is required: sensitive fields are already redacted.

   Example

   A SOC 2 auditor requests evidence for CC6.1 covering 2026-09-01 to 2026-10-25. You navigate to the Audit Log, filter by task_completed, and set the date range. The filtered list shows 847 task_completed events, each with acting_user, decision, timestamp, and submitted_result (sensitive fields redacted). You export the list. You also provide the 403 Forbidden screenshot from step 2. The auditor confirms the two pieces of evidence together address CC6.1: access is restricted to authorised roles (403 evidence) and every access action is recorded with attribution (audit log evidence). No vendor trust required.

   Best practice

   The tasks help documentation states: "Task completion, task assignment, and submission data are all captured for compliance and accountability." Keep the audit log retention period set to at least the duration required by your compliance framework. SOC 2 typically requires 12 months of audit records. GDPR Article 30 requires records to be maintained as long as the processing activity continues. Review the retention setting at Admin, then Settings, then Audit Log before your first production workflow run.

What this guide does not cover