Activity Log & Audit Trail

Every create, update, and delete action in TATER is automatically recorded in the Activity Log. This tamper-evident audit trail captures who did what, when, and exactly what changed — providing the evidence auditors need to verify that your compliance program is operating as documented.

Accessing the Activity Log

Navigate to Admin > Activity Log in the sidebar. This page is accessible to users with the Admin (OrgAdmin) role or higher within the current organization. Auditor-level users can view the log but cannot filter by user or export raw records.

What Gets Logged

Every API write operation in TATER is automatically logged. The following entity types generate audit records:

Understanding a Log Entry

Each Activity Log entry contains the following fields:

Delta Records (Before/After Changes)

When a record is updated, the Activity Log computes and stores the exact set of fields that changed, along with the old and new values. This delta is displayed inline in the log entry as a side-by-side comparison.

Example: If an Override's expiry date is extended from 2026-06-01 to 2026-12-31 and its justification is updated, the delta shows:

{
  "expiryDate": {
    "before": "2026-06-01",
    "after": "2026-12-31"
  },
  "justification": {
    "before": "Vendor patch delayed.",
    "after": "Vendor patch delayed. Compensating control: additional monitoring enabled."
  }
}

Sensitive fields such as API key secrets, client secrets, and encrypted credentials are never included in delta records, even partially. Only the field name is recorded for these, noting that a change occurred.

Filtering and Searching

The Activity Log provides several ways to narrow results:

Filter by Entity Type

Use the Entity Type dropdown to show only records for a specific type of record (e.g., show only Override changes, or only Scan events). The dropdown lists all entity types that have at least one log entry for the current organization.

Filter by Action

Use the Action dropdown to filter to Create, Update, or Delete operations independently. Selecting "Delete" is useful for accountability reviews — you can quickly see what records have been removed and by whom.

Filter by User

Type a partial name, email address, or user OID in the User field to show only activity from a specific actor. This is useful during a security investigation or to review a specific team member's recent activity.

Filter by Date Range

Set a Start Date and/or End Date to limit results to a specific time window. For example, use a date range to show all activity during the period covered by an audit (e.g., January 1 – March 31). Dates are interpreted in your browser's local timezone.

Free Text Search

The search bar performs a full-text match against entity IDs, user names, and action types. Use this to locate a specific record by its ID (e.g., paste an override ID to find when it was created and last modified).

Stacking Filters

All filters stack — you can combine entity type, action, user, and date range simultaneously. For example: Entity Type = Override, Action = Update, Date = last 90 days shows all risk acceptance modifications in the past quarter.

AI-Tagged and Automated Records

TATER distinguishes between actions taken by human users and those performed by automated processes.

AI Analyst Records

When the AI Compliance Analyst creates a risk acceptance, adds an evidence comment, or assigns a control, the resulting Activity Log entry is tagged with source: "ai-analyst". The actor field shows the authenticated user who initiated the AI session, but the source tag makes clear that the specific action was performed by the AI on the user's behalf.

This distinction matters for audits: if an auditor questions whether a risk acceptance was thoroughly reviewed by a human, you can point to the timestamp of the AI action and confirm whether human review followed.

Evidence Agent Records

When the Evidence Agent automatically collects screenshots and posts them as control evidence comments, those records are tagged with source: "evidence-agent". This lets auditors distinguish machine-collected evidence from human-written evidence notes.

Runbook Records

When Azure Automation runbooks upload scan results or update remediation job status via API key authentication, the actor field shows the API key prefix (e.g., apikey:abc12345) rather than a user's name. This confirms that the action was performed by an automated system, not a human user.

SIEM Forwarding

Audit events can be forwarded in real-time to your SIEM or log aggregation platform as they are created. TATER supports two forwarding methods:

Syslog (CEF Format)

TATER sends audit events over syslog using RFC 5424 format with a CEF (Common Event Format) payload. This is compatible with Splunk, Microsoft Sentinel, IBM QRadar, and most other enterprise SIEMs.

Configure syslog forwarding in Settings > SIEM:

Webhook (HMAC-Signed JSON)

TATER can POST audit events as JSON payloads to a webhook URL. Each request is signed with an HMAC-SHA256 signature in the X-TATER-Signature: sha256=... header so your receiver can verify authenticity.

Configure webhook forwarding in Settings > SIEM:

To verify the HMAC signature in your webhook receiver:

const crypto = require('crypto');

function verifyTaterSignature(payload, secret, signatureHeader) {
    const expected = 'sha256=' + crypto
        .createHmac('sha256', secret)
        .update(payload, 'utf8')
        .digest('hex');
    return crypto.timingSafeEqual(
        Buffer.from(expected),
        Buffer.from(signatureHeader)
    );
}

Testing SIEM Configuration

After configuring either syslog or webhook forwarding, click Send Test Event in Settings > SIEM. TATER sends a sample audit event immediately. Check your SIEM or webhook receiver to confirm it arrived and was parsed correctly before relying on production forwarding.

Using the Activity Log During Audits

The Activity Log is most valuable when you need to demonstrate to an auditor that a specific compliance-related action was taken, by an authorized person, at a specific time.

Risk Acceptance Evidence

When a control is marked as an accepted risk (Override), the auditor may want to know:

• Who created the risk acceptance and when?
• Was the justification entered at the time of creation, or added later?
• Has the acceptance been modified since it was first created?
• Who approved the risk acceptance?

Filter the Activity Log by Entity Type = Override, Entity ID = [the override's ID] to see the complete lifecycle of a specific risk acceptance — creation, any updates to the justification or expiry, and the identity of whoever made each change.

Remediation Evidence

When a failing control has been remediated, auditors need to verify that the remediation was performed and by whom. Filter by Entity Type = Remediation to see all triggered remediations, including the actor who triggered them, the timestamp, and the runbook callback status updates.

Assignment Evidence

Control assignments (linking a control to a team member with a due date) appear in the log as Assignment Create and Update events. Use these to demonstrate that accountability was formally assigned for each failing control.

Exporting Records for Auditors

The Activity Log does not currently offer a one-click CSV export from the UI. To provide audit evidence, use one of these approaches:

• SIEM export: If SIEM forwarding was configured, query your SIEM for the relevant date range and entity types and export from there. This is the recommended path for formal audit packages.
• Screenshot the filtered view: For individual records, filter the log and use the browser's print dialog (Ctrl+P) to produce a PDF of the filtered results.
• API access: Authenticated API requests to GET /api/audit-log return JSON records that can be piped into a reporting script. Pass query parameters: entityType, action, actorEmail, startDate, endDate.

Retention and Storage

Activity Log entries are stored in the AuditLog Cosmos DB container. Unlike Usage Telemetry (which auto-expires after 90 days), audit log entries have no automatic expiry (TTL). Records are retained indefinitely unless manually deleted by a SuperAdmin with direct Cosmos DB access.

For long-term retention strategies, consider:

• SIEM forwarding: Forward events in real-time to a SIEM with configurable retention (e.g., Microsoft Sentinel, Splunk). The SIEM becomes the authoritative long-term store for audit records.
• Cosmos DB continuous backup: Azure Cosmos DB supports point-in-time restore for up to 30 days on accounts with continuous backup enabled. For longer retention, configure periodic exports to Azure Storage.
• Cosmos DB analytical store: Enable the Cosmos analytical store and query via Azure Synapse for historical reporting without impacting transactional performance.

Troubleshooting