Audit Log Template for Product Planning

What This Template Is For

An audit log records who did what, when, and to which resource. It is the single most requested enterprise feature that product teams underestimate. Building an audit log looks simple on the surface: capture events, store them, display them. In practice, getting the event taxonomy right, ensuring immutability, handling retention across compliance regimes, and making logs actually searchable requires deliberate upfront design.

This template walks you through specifying an audit log system that satisfies security reviews, compliance audits, and customer admin needs. It covers the event taxonomy, log schema, storage architecture, search interface, retention policies, and export/integration capabilities.

If your product handles sensitive data, the HIPAA Compliance Checklist and Fintech Compliance Checklist provide domain-specific requirements that feed into your audit log design. For the broader admin experience that the audit log sits within, see the Admin Console Template. The Product Strategy Handbook covers how to sequence compliance investments for enterprise readiness.

How to Use This Template

1. Start by cataloging every user and system action that modifies data or accesses sensitive resources. This is your raw event list.
2. Group events into categories (authentication, user management, data access, configuration, billing). This hierarchy makes filtering usable.
3. Define the log schema. Every event needs a timestamp, actor, action, resource, and result. Add a structured changes field for mutation events.
4. Decide on storage. Append-only writes to a separate datastore (not your main application database) ensure immutability and prevent accidental deletion.
5. Specify retention periods per compliance regime. SOC 2 requires 1 year. HIPAA requires 6 years. GDPR requires you to delete personal data, which conflicts with audit retention. Document how you handle each.
6. Design the search interface. Audit logs are useless if nobody can find anything. Time range, actor, action, and resource are the minimum filter dimensions.
7. Review with your security team, legal counsel, and at least two enterprise customers.

The Template

Audit Log Overview

Purpose. [Why this product needs an audit log. Which customer segments require it. What compliance certifications depend on it.]

Event Taxonomy

Event categories.

Event naming convention. [resource].[action].[result]

• Resource: lowercase, singular (user, project, api_key)
• Action: past tense verb (created, updated, deleted, viewed, exported)
• Result (optional): success, failed, denied

Full event catalog.

Log Entry Schema

Required fields.

Actor schema.

{
  "id": "usr_456",
  "type": "user",
  "email": "[email protected]",
  "name": "Jane Smith",
  "role": "admin",
  "ip_address": "203.0.113.42"
}

Actor types: user, admin, api_key, system, support_agent

Resource schema.

{
  "type": "user",
  "id": "usr_789",
  "name": "John Doe",
  "url": "/admin/users/usr_789"
}

Changes schema (for mutations).

{
  "changes": [
    {
      "field": "role",
      "old_value": "member",
      "new_value": "admin"
    },
    {
      "field": "team_id",
      "old_value": null,
      "new_value": "team_456"
    }
  ]
}

Context schema.

{
  "request_id": "req_abc123",
  "session_id": "ses_def456",
  "user_agent": "Mozilla/5.0...",
  "ip_address": "203.0.113.42",
  "geo": {
    "country": "US",
    "region": "CA",
    "city": "San Francisco"
  },
  "source": "web_app"
}

Source types: web_app, mobile_app, api, cli, system, admin_console

Storage Architecture

Immutability guarantees.

• ☐ Application code has no DELETE or UPDATE permissions on audit log tables
• ☐ Database user for audit writes has INSERT-only privileges
• ☐ Log entries are cryptographically signed or hash-chained to detect tampering
• ☐ Infrastructure access to audit storage is logged separately (meta-audit)
• ☐ Backup deletion requires approval from two authorized personnel

Retention and Lifecycle

GDPR and audit log conflict resolution. When a user exercises their right to erasure (Article 17), the audit log must retain the event record for compliance but anonymize personally identifiable information. Replace actor email, name, and IP with anonymized placeholders. Keep the actor ID as a pseudonymized reference. Document this approach in your privacy policy.

Storage tiers.

Search and Filtering Interface

Filter dimensions.

Search capabilities.

Export and Integration

Export formats.

SIEM integration.

Filled Example: B2B Project Management SaaS

Event Taxonomy

Estimated total volume: ~59,000 events/day across 2,400 organizations.

Storage Architecture

Search Interface

The admin console displays audit logs with these default columns: Timestamp, Actor (name + avatar), Action (color-coded badge), Resource (linked), Result (green/red), and an expand button for full context.

Filter presets for common workflows:

• "Failed logins (last 24h)": category=auth, action=user.login.failed, time=24h
• "Admin actions": actor.role=admin, time=7d
• "Data exports": action=data.exported, time=30d
• "Security events": severity=critical, time=7d

SIEM Integration

Supports Splunk HEC, Datadog Log Intake, and generic webhook. Events are streamed in real-time via a dedicated SQS queue per integration. Each event includes a HMAC-SHA256 signature header for webhook verification. Customers configure integrations in the admin console under Settings, Integrations. Each integration can filter by event category to reduce noise.

Common Mistakes to Avoid

• Logging too little. If your audit log only captures CRUD operations on primary resources, you will miss authentication events, configuration changes, and data access events that security teams need for incident investigation.
• Logging too much without structure. Dumping application logs into the audit log makes it unsearchable. Every event must follow the schema and taxonomy. Unstructured text fields are not audit events.
• Storing audit logs in the application database. When a malicious actor compromises the application, they can delete their tracks if audit logs are in the same database. Use a separate datastore with restricted access.
• Forgetting the GDPR/audit conflict. You need audit logs for compliance, but GDPR requires you to delete personal data on request. Solve this upfront with the anonymization approach, not during your first data deletion request.
• Building search as an afterthought. An audit log that nobody can query is the same as no audit log. Invest in the search interface alongside the logging infrastructure.

Key Takeaways

• Define your event taxonomy before writing any logging code. Consistent naming makes search usable.
• Store audit logs in a separate, append-only datastore with restricted access.
• Plan for the GDPR/audit conflict. Anonymize PII in log entries when users are deleted, but keep the event metadata.
• Build the search interface alongside the logging infrastructure. Unsearchable logs are useless.
• Design retention policies per compliance regime and use tiered storage to manage cost.

About This Template

Created by: Tim Adair

Last Updated: 3/5/2026

Version: 1.0.0

License: Free for personal and commercial use