How Do I Set the Audit Log Retention Policy in Dave by voolama?

The retention policy in Dave by voolama (hellodave.ai) is configured at Admin, then Settings, then General, then System Parameters, then Retention Policy. Before changing the Retain Audit Logs field, make these four decisions. Each is grounded in the audit-logs help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30, and in NIST SP 800-53 Rev 5 AU-11.

1. Decision 1: What compliance framework applies to this tenant?

   Three scenarios, each with a specific retention implication:

   • SOC 2 active: the audit-logs help documentation states that Dave by voolama displays a warning if retention is set below 2,555 days (7 years) when SOC 2 compliance mode is enabled. Set retention to at least 2,555 days. The warning appears in the Audit Log settings section and is visible to any Admin who opens System Parameters. SOC 2 CC7.2 (System Monitoring) requires that organisations monitor system components for anomalies and events: an audit trail with gaps caused by premature deletion is evidence of a CC7.2 control failure.
   • GDPR active: GDPR Article 5(1)(e) (storage limitation) requires that personal data be kept for no longer than necessary for the purposes for which it is processed. For audit logs, the purpose is accountability and incident investigation. Retain for as long as your legal counsel determines is necessary. GDPR does not prescribe a fixed number of days.
   • No compliance framework: the default 365 days is appropriate for operational troubleshooting. Increase it if your organisation's incident response policy requires a longer lookback window than 12 months.

2. Decision 2: What is the longest lookback window any auditor or investigator will ever need?

   NIST SP 800-53 Rev 5 control AU-11 requires organisations to retain audit records for an organisation-defined time period to support after-the-fact investigations of security incidents. Set retention to the longer of: your compliance framework's minimum (2,555 days for SOC 2) or your incident response policy's required lookback window. For most organisations, 7 years covers both. Document this decision: AU-11 requires that the organisation-defined period be recorded, and the Retain Audit Logs field value is that record.

3. Decision 3: Do I need to export logs before reducing retention?

   The audit-logs help documentation states directly: "When the retention period expires for an event, it is permanently removed during the next cleanup cycle." If you are reducing the retention period, events older than the new threshold will be deleted during the next cleanup cycle. The best practices section of the same document states: "Export before retention cleanup: If your retention policy is shorter than your archival requirements, export audit logs as CSV before they are automatically purged." Export any events you need as CSV before reducing the retention period. There is no recovery path after deletion.

4. Decision 4: Is indefinite retention appropriate for this tenant?

   The audit-logs help documentation states: "Set retention to 0 to never delete audit logs." It also cautions: "Use Forever retention sparingly: retaining all audit logs indefinitely increases storage costs. Only use this when compliance or legal requirements demand it." Use the forever option only when a specific compliance or legal requirement mandates indefinite retention.

All steps require the Admin role (admin:* permission). Sourced from the audit-logs help documentation, DEV v0.11.0, confirmed 2026-08-30.

1. Navigate to System Parameters. Go to Admin, then Settings, then General, then System Parameters, then Retention Policy. The Retention Policy section contains the Retain Audit Logs field.

2. Set the Retain Audit Logs value. Enter the number of days to retain audit log events. Three reference values from the audit-logs help documentation:

   • 365 days: the default. Suitable for operational troubleshooting with no compliance framework requirement.
   • 2,555 days (7 years): the SOC 2 recommended minimum. Dave by voolama displays a warning if retention is set below this threshold when SOC 2 compliance mode is enabled.
   • 0: retain forever. Events are never deleted by the automatic cleanup task.

3. Save the setting. Click Save. The new retention period takes effect for the next cleanup cycle. If you have reduced the retention period, events older than the new threshold will be deleted during the next cleanup cycle.

4. Verify the SOC 2 retention warning is resolved (if applicable). If your tenant has SOC 2 compliance mode enabled, return to Admin, then Settings, then Audit Log. Confirm that no retention warning is displayed. If the warning persists, the retention value was not saved correctly: repeat steps 2 and 3.

5. Confirm the change appears in the audit log. Navigate to Admin, then Settings, then Audit Log and filter by the current date. Confirm that a mutation event appears recording the retention policy change, with your Admin identity as the Actor. This event is itself evidence that the retention policy was deliberately set and by whom, satisfying NIST SP 800-53 Rev 5 AU-11's requirement for an organisation-defined and documented retention decision.

Known limitation, sourced from the audit-logs help documentation, DEV v0.11.0: the exact schedule of the background cleanup task is not specified in the audit-logs help documentation. Treat any reduction in retention as taking effect imminently: export any events you need before reducing the retention period, not after.

Two retention configuration mistakes produce unrecoverable outcomes. Both are documented in or directly derivable from the audit-logs help documentation at DEV v0.11.0, confirmed 2026-08-30. Each is described with cause, symptom, the exact documentation statement, and prevention.

Failure 1: Retention set too short before events are needed

Cause: the Admin leaves retention at the default 365 days. An auditor, regulator, or incident investigator requests records from 18 months ago. Events older than 365 days have been permanently deleted.

Symptom: the Audit Log table shows no events before the cutoff date. The gap cannot be recovered.

Documentation statement: "When the retention period expires for an event, it is permanently removed during the next cleanup cycle."

SOC 2 consequence: SOC 2 CC7.2 (System Monitoring) requires that organisations monitor system components for anomalies and events. A gap in the audit trail caused by premature deletion is a CC7.2 control deficiency, not merely a missing record. If a SOC 2 auditor finds that events were deleted before the 7-year minimum, the finding is a control failure.

Prevention: set retention to at least 2,555 days for SOC 2-scoped tenants before the audit period begins. For tenants without a compliance framework, set retention to the longest lookback window any investigator will realistically need, plus a safety margin.

Mitigation if already occurred: none for deleted events. Increase retention immediately to prevent further deletions, and export remaining events as CSV before the next cleanup cycle removes more.

Failure 2: Reducing retention without exporting first

Cause: the Admin reduces the retention period (for example, from 2,555 days to 365 days) without first exporting the events that will fall outside the new threshold.

Symptom: events between day 366 and day 2,555 are deleted during the next cleanup cycle. If those events were needed for a compliance submission or investigation, they are gone.

Documentation best practice: "Export before retention cleanup: If your retention policy is shorter than your archival requirements, export audit logs as CSV before they are automatically purged."

Prevention: always export the full audit log as CSV before reducing the retention period. Use the date-range filter to scope the export to the events that will be deleted, then export. Only reduce the retention period after confirming the export is complete and stored in a durable location.