> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zenoo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Do I Read the Audit Trail?

> View immutable audit logs for every action in Case Management — filter by event type, actor, and date, and export for regulatory reporting.

# How Do I Read the Audit Trail?

Every action in Zenoo Case Management is logged immutably. The audit trail provides a complete record of who did what, when, and why — essential for regulatory examinations, internal compliance reviews, and dispute resolution.

## What you'll learn

* Where to find the audit trail
* What events are logged
* How to filter and search audit entries
* How to export data for regulatory reporting
* What the maker-checker audit pattern looks like

## Where is the audit trail?

The audit trail is accessible in two places:

1. **On a specific case or alert** — scroll to the **Audit Trail** section in the detail view to see all events for that record
2. **Global audit trail** — available from the main navigation for compliance officers and administrators who need to search across all records

## What events are logged?

The audit trail captures 32 event types across seven categories:

<Accordion title="Case events">
  | Event                  | When it fires                                                             |
  | ---------------------- | ------------------------------------------------------------------------- |
  | **Case Created**       | A new case is created (manually or from a verification flow)              |
  | **Case Status Change** | Case status transitions (New to In Progress, In Progress to Closed, etc.) |
  | **Case Assignment**    | Case is assigned or reassigned to an analyst                              |
  | **Case Escalation**    | Case is escalated to a manager or senior reviewer                         |
  | **Case Closure**       | Case is closed with resolution notes                                      |
</Accordion>

<Accordion title="Alert events">
  | Event                      | When it fires                                 |
  | -------------------------- | --------------------------------------------- |
  | **Alert Created**          | A new alert is generated from a check result  |
  | **Alert Acknowledged**     | An analyst acknowledges an open alert         |
  | **Alert Resolved**         | An alert is resolved with an action and notes |
  | **Alert False Positive**   | An alert is marked as a false positive        |
  | **Alert Escalated**        | An alert is escalated to a senior reviewer    |
  | **Alert Assignment**       | An alert is assigned to a specific analyst    |
  | **Alert Auto-Disposition** | An alert is auto-resolved by the AI system    |
</Accordion>

<Accordion title="Risk events">
  | Event                        | When it fires                                 |
  | ---------------------------- | --------------------------------------------- |
  | **Risk Assessment Created**  | A new risk assessment is generated            |
  | **Risk Score Calculated**    | Dimension scores are calculated               |
  | **Risk Tier Override**       | An analyst overrides the calculated risk tier |
  | **Risk Assessment Approved** | A risk assessment is formally approved        |
</Accordion>

<Accordion title="Check and document events">
  | Event                   | When it fires                                   |
  | ----------------------- | ----------------------------------------------- |
  | **Check Status Change** | A check transitions between statuses            |
  | **Check Waived**        | A check is waived with a documented reason      |
  | **Check Rejected**      | A check result is rejected                      |
  | **Check Completed**     | A check finishes with a result                  |
  | **Document Uploaded**   | A document is uploaded for a requirement        |
  | **Document Reviewed**   | A document is reviewed and accepted or declined |
</Accordion>

<Accordion title="Collaboration events">
  | Event                 | When it fires                                  |
  | --------------------- | ---------------------------------------------- |
  | **Reviewer Added**    | A reviewer is added to a case or alert         |
  | **Reviewer Removed**  | A reviewer is removed                          |
  | **Reviewer Response** | A reviewer approves or rejects                 |
  | **Comment Added**     | A comment is posted on a case, alert, or check |
</Accordion>

<Accordion title="Entity and system events">
  | Event               | When it fires                                            |
  | ------------------- | -------------------------------------------------------- |
  | **Entity Added**    | An entity is added to a case                             |
  | **Entity Removed**  | An entity is removed from a case                         |
  | **Auto Escalation** | A case is auto-escalated due to SLA breach               |
  | **SLA Breach**      | A case breaches its SLA deadline                         |
  | **Bulk Operation**  | A bulk action is performed (e.g., bulk alert assignment) |
  | **AI Analysis**     | AI research is run on an alert                           |
</Accordion>

## How do I filter audit entries?

The audit trail panel provides filters to narrow your search:

<Steps>
  <Step title="Filter by event type">
    Select one or more event types from the dropdown (e.g., show only "Case Escalation" and "Risk Tier Override" events).
  </Step>

  <Step title="Filter by date range">
    Set a start and end date to view events within a specific period. Useful for regulatory examinations that cover a defined timeframe.
  </Step>

  <Step title="Filter by actor">
    Search for events performed by a specific user. The audit trail stores both the user ID and their name at the time of the event — so even if a user is deactivated, their name is preserved.
  </Step>

  <Step title="Search by keyword">
    Use the search bar to find events containing specific text in their description, old value, new value, or reason fields.
  </Step>
</Steps>

## What does an audit entry show?

Each audit entry contains:

| Field           | Description                                                          |
| --------------- | -------------------------------------------------------------------- |
| **Timestamp**   | When the event occurred (date and time to the second)                |
| **Event type**  | The category and specific event (e.g., "Alert Resolved")             |
| **Actor**       | Who performed the action (name and user ID)                          |
| **Record**      | Which case, alert, or check the event relates to                     |
| **Description** | Human-readable description of what happened                          |
| **Old value**   | The previous state (e.g., "Open")                                    |
| **New value**   | The new state (e.g., "Resolved")                                     |
| **Reason**      | The justification provided (e.g., resolution notes, override reason) |
| **Severity**    | Info, Warning, or Critical                                           |

<Info>
  Audit entries are immutable. Once created, they cannot be edited or deleted — not even by administrators. This is enforced by a validation rule at the database level.
</Info>

## How do I export for regulatory reporting?

Click the **Export CSV** button at the top of the audit trail panel. The export includes:

* All visible entries (respecting your current filters)
* All fields in a flat CSV format
* Timestamps in ISO 8601 format for easy processing
* UTF-8 encoding

The CSV can be provided directly to regulatory examiners or imported into your organization's compliance reporting system.

<Tip>
  Before a regulatory examination, use date range filters to export only the relevant period. Include all event types unless the examiner requests specific categories.
</Tip>

## What is the maker-checker pattern?

The audit trail supports the **four-eyes principle** (maker-checker) used in regulated environments:

* **Maker** — the analyst who performs an action (e.g., resolves an alert, overrides a risk tier)
* **Checker** — the approver who validates the action (e.g., a senior reviewer who approves the case)

The audit trail links these events with approved-by and approved-date fields, providing a clear chain of accountability that satisfies regulatory requirements for dual authorization.

## What's next?

<Columns cols={2}>
  <Card title="Resolve a Case" icon="circle-check" href="/guides/case-management/resolve-a-case">
    See how case lifecycle events appear in the audit trail.
  </Card>

  <Card title="Track SLA Compliance" icon="clock" href="/guides/case-management/track-sla">
    SLA breaches and auto-escalations are logged for review.
  </Card>

  <Card title="Understand Risk Scores" icon="gauge-high" href="/guides/case-management/understand-risk-scores">
    Risk overrides are fully audited.
  </Card>

  <Card title="Collaborate With Your Team" icon="users" href="/guides/case-management/collaborate-with-team">
    Comments and reviewer actions appear in the audit trail.
  </Card>
</Columns>