AI Audit Logging and Retention for SOC 2

What this control should accomplish

Material AI activity and decisions can be reconstructed from protected, searchable records retained for the intended operational and review period.

How to implement AI Audit Logging and Retention

1. 1

   Define material events

   List workflow starts, model calls, context retrieval, tool actions, configuration changes, approvals, outputs, failures, and exceptions that require records.

   You should end up with: AI event and field logging specification

2. 2

   Correlate the activity

   Use stable request, workflow, tenant, version, and actor identifiers across application, gateway, tool, and approval records.

   You should end up with: End-to-end correlated event trail

3. 3

   Protect retained records

   Limit access, minimize sensitive fields, detect alteration, set retention, and document deletion or archival behavior.

   You should end up with: Logging access and retention configuration

4. 4

   Verify completeness

   Generate representative events, confirm arrival and searchability, reconcile source counts, and investigate logging gaps.

   You should end up with: Logging health and retrieval test

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Which records should you prepare for the audit?

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: Material AI activity and decisions can be reconstructed from protected, searchable records retained for the intended operational and review period.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (AI Workflow Owner / CISO / Engineering), then compare dated records with the stated cadence: Per workflow/change; review at least annually.

• Establish the complete audit record set

  Reconcile event counts and correlation IDs from workflow, gateway, retrieval, approval, and tool sources to the central log platform; investigate sequence gaps, delayed ingestion, missing sources, and scheduled tests not completed. Separately reconcile every annual review due date to a completed no-change or configuration-change decision, a documented missed review, or a rescheduled review that preserves the original and new due dates.

• Prepare the as-of-date evidence for a Type 1 engagement

  Retain current event and retention specifications, active logging configuration, the latest scheduled annual logging and retention review and disposition, and a recent end-to-end execution and older-record retrieval test on the selected date.

• Prepare period evidence for a Type 2 engagement

  Account for every expected material runtime event produced by all scoped workflows during the period—including model calls, retrievals, approvals, tool actions, failures, and exceptions—plus every logging configuration change, health test, retention test, identified gap, and scheduled annual logging and retention review, including no-change completions, missed reviews, and rescheduled reviews.

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect review records

    For each selected record, confirm it demonstrates A qualified owner reviewed logging completeness, searchability, access, retention, and identified gaps with follow-up.

    • Review ID and date
    • Scoped workflows and sources
    • Reviewer
    • Checks performed
    • Findings
    • Actions and status

  • Inspect exception register

    For each selected record, confirm it demonstrates Known missing, delayed, sensitive, or reduced logging is risk-assessed, approved, bounded, and tracked to closure.

    • Exception ID
    • Affected events and workflow
    • Cause and risk
    • Approver
    • Compensating monitoring
    • Expiry and status

• Inspect the operating / technical evidence

  Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.

  • Inspect AI activity logs

    For each selected record, confirm it demonstrates Material runtime requests, retrievals, model calls, approvals, tool actions, and outcomes are attributable and correlated.

    • Event and execution IDs
    • Workflow version
    • Actor and tenant
    • Event type
    • Timestamp
    • Outcome or linked event

  • Inspect configuration snapshots

    For each selected record, confirm it demonstrates The exact logging, workflow, model, tool, and retention settings effective at a point in time can be reconstructed.

    • Snapshot ID
    • Workflow and environment
    • Configuration version
    • Captured time
    • Logging destinations
    • Retention settings

  • Inspect retention evidence

    For each selected record, confirm it demonstrates Required AI records remain protected, searchable, and retrievable across the configured period and are disposed of as designed.

    • Log source
    • Storage tier
    • Retention period
    • Access policy
    • Oldest retrievable event
    • Test date and result

• Trace the control from design to operation

  Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

• Logs show a model call but omit workflow version, actor, tenant, or resulting action.
• Full prompts and outputs create an unnecessary sensitive-data store.
• Provider logs and application decisions cannot be correlated.
• Retention is configured but retrieval has not been tested for older records.

Before you call this control ready

• Can a sampled action be reconstructed across request, approval, tool, and outcome?
• Would monitoring detect if a workflow stopped emitting required events?
• Are sensitive log fields minimized and accessible only to approved roles?
• Can records from the earliest in-scope period still be found and exported?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

• CC7.2
• CC7.3
• CC5.3

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.

Related controls to review next