Episode 41 · Module 9 · Audit & Logging

Audit Log Design

19 May 2026 · 8:49 · Security for Legal SaaS

8:49 8:49

Welcome to Module 9 — Audit, Logging, and Provenance. Every security control we've discussed across 40 episodes depends on one thing: a reliable record of what happened. If you can't prove a human reviewed that AI-generated filing (Episode 37), if you can't show that a prompt was redacted before reaching the cloud (Episode 39), if you can't demonstrate that API key access was properly scoped (Episode 38) — then those controls exist only in theory.

Today’s Lesson

Security for Legal SaaS — Episode 41: Audit Log Design

An Audit Log Is Not a Debug Log

This episode is about designing audit logs that serve their purpose: telling you who did what, when, from where, and to which resource. Done well, audit logs are the evidence trail that compliance officers, regulators, courts, and incident responders rely on. Done poorly, they are noise.

Audit Logs vs. Application Logs vs. Debug Logs

The first design decision is understanding that these are three different things with different purposes, retention requirements, and access controls.¹

Log Type	Purpose	Audience	Retention	Sensitivity
Debug logs	Troubleshoot code behaviour	Developers	Days to weeks	Low (may contain stack traces)
Application logs	Track system operations (requests, errors, performance)	DevOps, SRE	Weeks to months	Medium
Audit logs	Record security-relevant human and system actions	Compliance, legal, security, courts	Years (often 7+)	High (who did what)

Mixing these together — writing audit events to the same log file as debug output — is a common and dangerous mistake. Debug logs get rotated, truncated, or deleted for disk space. Application logs get filtered for noise. Audit logs must be preserved intact, with controlled access, for the duration required by your regulatory obligations.²

NIST SP 800-92 (Guide to Computer Security Log Management) establishes the federal standard for log management: "Organizations should establish policies and procedures for log management because they ensure a consistent approach throughout the organization as well as ensuring that laws and regulatory requirements are being met."³

What to Log: The Six W's

Every audit log entry should answer six questions:⁴

Field	Question	Example
Who	Which authenticated identity performed the action?	`user: "sarah.chen@firm.com"`
What	What action was performed?	`action: "document.classify"`
When	When did the action occur?	`timestamp: "2026-05-18T14:23:07.442Z"`
Where	From what location/device/IP?	`source_ip: "203.0.113.42", device_id: "laptop-SC-2024"`
Which	Which resource was affected?	`resource: "matter/2026-0142/doc/brief-v3.docx"`
Outcome	Did the action succeed or fail?	`outcome: "success"` or `outcome: "denied: insufficient_permission"`

For legal SaaS, additional fields are critical:

Matter ID: Which client matter does this action relate to?
AI involvement: Was AI used in this action? Which model, which version?
Approval chain: For governed writes (EP37), who approved the action?
Data classification: What sensitivity level was the affected data?

Structured Logging: JSON, Not Plaintext

Audit logs must be machine-parseable. Unstructured plaintext — `"Sarah updated the document at 2:23 PM"` — is usable by humans reading individual entries but useless for automated analysis, alerting, correlation, and legal discovery across millions of records.⁵

Structured JSON logging with a consistent schema is the industry standard:

json

{
  "timestamp": "2026-05-18T14:23:07.442Z",
  "event_type": "document.classify",
  "actor": {
    "user_id": "sarah.chen@firm.com",
    "role": "associate",
    "auth_method": "sso_mfa"
  },
  "resource": {
    "type": "document",
    "id": "doc-a3f2c1",
    "matter_id": "2026-0142",
    "classification": "attorney_client_privileged"
  },
  "action": {
    "type": "classify",
    "ai_assisted": true,
    "model": "privilege-classifier-v2.1",
    "confidence": 0.94,
    "human_approved": true,
    "approver": "james.wong@firm.com"
  },
  "outcome": "success",
  "source": {
    "ip": "203.0.113.42",
    "user_agent": "Chrome/125.0",
    "session_id": "sess-8f2a1b3c"
  }
}

Every field follows a consistent schema documented and versioned alongside your application. When the schema changes — new fields, renamed fields, changed types — the version number increments, and old entries remain readable under their original schema.⁶

Log Integrity: Append-Only and Access-Controlled

An audit log that can be edited is not an audit log — it is a story that can be rewritten. Integrity requires three properties:⁷

1. Append-Only Storage

Audit logs should be written to append-only storage. New entries can be added; existing entries cannot be modified or deleted. Options include:

Append-only file systems with immutable flags (`chattr +a` on Linux)
Cloud object storage with object lock (S3 Object Lock, GCS retention policies)
Write-once databases (append-only tables with no UPDATE or DELETE permissions)
Dedicated ledger databases (AWS QLDB — covered in Episode 42)

2. Access Controls

Who can read audit logs? Who can write to them? The answers should be different from who runs the application.

Role	Read	Write	Delete
Application service account	No	Yes (append only)	No
Developers	No (unless investigating with approval)	No	No
Security team	Yes	No	No
Compliance/Legal	Yes	No	No
System administrators	Controlled (audit of the audit)	No	No

The principle: the people who could benefit from modifying audit logs (developers, system administrators) should not have the ability to do so. Separation of duties applies to log access the same way it applies to financial controls.⁸

3. Tamper Detection

Even with append-only storage and access controls, you need a mechanism to detect if tampering occurred — because controls can be bypassed. Hash chains (Episode 42) provide this. Each entry's integrity hash includes the previous entry's hash, creating a mathematical chain where any modification to any entry breaks the chain for all subsequent entries.

Legal Admissibility: What Makes a Log Trustworthy Evidence

In litigation, regulatory investigations, and e-discovery, audit logs may need to serve as evidence. For a log to be admissible and persuasive, it should demonstrate:⁹

Contemporaneous recording: Entries were created at or near the time of the event, not reconstructed later
Systematic process: The logging system operates automatically and consistently, not at the discretion of individuals
Integrity controls: Demonstrable protections against tampering (append-only, hash chains, access controls)
Chain of custody: A documented trail of who had access to the logs and when
Completeness: Evidence that the logging system captures all relevant events, not a selective subset

Key insight: Courts assess the reliability of digital evidence based on the controls surrounding its creation and preservation. A log that can be shown to be append-only, hash-chained, and access-controlled is substantially more persuasive than one stored in a regular database table that any administrator could modify.¹⁰

What to Log in Legal SaaS: A Checklist

Category	Events to Log
Authentication	Login success/failure, MFA events, session creation/destruction, password changes
Authorization	Permission grants/revocations, role changes, access denials
Data access	Document views, downloads, searches, exports (especially across matter boundaries)
Data modification	Document edits, classification changes, metadata updates
AI operations	Model invocations, prompt content (may need redaction), response summaries, confidence scores
Governed writes	AI draft creation, human review events, approval/rejection with reviewer identity
Administrative	User provisioning/deprovisioning, system configuration changes, key rotations
Security events	Failed access attempts, anomalous patterns, privilege escalation attempts

Retention Requirements

Framework	Minimum Retention
SOC 2	1 year minimum; varies by trust service criteria
HIPAA	6 years from creation date
GDPR	As long as necessary for the purpose; must justify retention period
SEC Rule 17a-4	6 years for broker-dealers (relevant for financial litigation support)
ABA Model Rules	As long as the matter is active, plus jurisdictional record retention requirements
PCI DSS	1 year immediately available; longer for investigations

For legal SaaS, a default retention of 7 years — aligned with the longest common regulatory requirement — is a reasonable starting point, with the ability to extend retention for specific matters under legal hold.¹¹

Common Mistakes

Logging too little: Capturing only errors, not successful operations. You need both — an access denial is interesting, but knowing who successfully accessed what is equally important for investigations.
Logging too much: Including full document content in audit entries. Log the action and the resource identifier, not the resource itself. This keeps log volumes manageable and avoids creating a second copy of sensitive data in the log store.
Inconsistent schemas: Different services logging in different formats. Establish a firm-wide audit log schema and enforce it.
No log integrity: Storing audit logs in a regular database table that DBAs can modify. Use append-only storage.
Mixing log types: Combining debug, application, and audit logs in the same stream. Separate them.

What's Next

Episode 42 covers Hash-Chained Immutable Logs — the specific technique for making audit logs tamper-evident, ensuring that if anyone modifies a single entry, the tampering is mathematically detectable.

Sources & Further Reading

Sources & references

Sonar, Audit Logging Best Practices, Components & Challenges.
Fortra, Audit Log Best Practices for Security & Compliance.
NIST, SP 800-92: Guide to Computer Security Log Management.
UC Berkeley Information Security Office, Security Audit Logging Guideline.
Pangea, Understanding Audit Logs: What It Is & How to Build One.
Orca Security, Audit Logs: Complete Guide to Cloud Security Monitoring.
Mattermost, Compliance by Design: 18 Tips to Implement Tamper-Proof Audit Logs.
Kiteworks, Audit Log: What Is an Audit Log, Audit Logs & Audit Logging.
CX Today, How to Build AI Audit Trails That Stand Up to Regulatory Scrutiny.
Huntress, Audit Logs Explained: Security & Compliance Simplified.
NIST, SP 800-92 Rev. 1 (Draft): Cybersecurity Log Management Planning Guide.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 41 — and we're starting a new module. Module 9, Audit and Logging. Alice, we've spent forty episodes building security controls. Now we're talking about proving those controls actually work?

Alice: Exactly. An audit log is how you answer the question: what happened? Not what the code did — that's a debug log. Not what the server handled — that's an application log. An audit log tells you what humans and systems did to your data. Who accessed this document. Who approved that AI-generated filing. Who changed a user's permissions. When, from where, and whether it succeeded or failed. And critically — audit logs can hold up in court. Debug logs can't.

Dan: Mm. So the first thing is separating these from your regular application logs?

Alice: That's the most important design decision, and the one most teams get wrong. Debug logs, application logs, and audit logs serve different purposes, have different audiences, and need different retention. Debug logs are for developers and last days to weeks. Application logs are for operations teams and last weeks to months. Audit logs are for compliance, legal, security, and potentially courts — and they need to last years. Seven years is a common default because it covers most regulatory requirements. If you're mixing all three into the same log file, your audit events get rotated out with your debug noise, and your evidence disappears.

Dan: Right. What goes into an audit log entry? What's the minimum?

Alice: Six questions, every entry. Who — which authenticated user or system performed the action. What — what action was performed, like "document.view" or "privilege.classify" or "user.create." When — a precise timestamp with timezone. Where — the IP address, device, session identifier. Which — which specific resource was affected, down to the document ID and matter number. And outcome — did the action succeed or fail, and if it failed, why.

Dan: Hmm. And for legal SaaS specifically, there are extra fields?

Alice: Several. Matter ID — which client matter does this action relate to, because you need to be able to pull all activity on a specific matter for e-discovery or compliance. AI involvement — was AI used, which model, which version. For the governed writes pattern from Episode 37, you need the full approval chain — who the AI drafted it for, who reviewed it, who approved it, and the specific version they approved. And data classification — was this a privileged document, a confidential document, or a public one.

Dan: Yeah. And I'm guessing these need to be in a structured format, not just free text?

Alice: JSON, with a consistent schema. Every audit event follows the same structure, documented and versioned. The reason is simple — you will eventually need to search across millions of entries. "Show me every document Sarah Chen accessed in matter 2026-0142 between January and March" is a query you can run against structured JSON. Against free-text log lines that say "Sarah updated the document at 2:23 PM," you're doing string matching and praying.

Dan: Mm. Let's talk about integrity. If someone can edit the audit log, you don't really have an audit log.

Alice: <sigh> Exactly. And this is where most systems fail. The audit log sits in a regular database table. The database administrator has full access. A developer with production access can run an UPDATE query. The moment someone can modify or delete entries, the entire log is suspect. An audit log must be append-only. New entries can be added. Existing entries cannot be modified or deleted. Period.

Dan: Mm-hmm. How do you enforce that technically?

Alice: Several options. Append-only file systems — on Linux, you can set an immutable append flag on a file so that even root can only add to it, not modify existing content. Cloud object storage with object lock — Amazon S3 and Google Cloud Storage both support retention policies that prevent deletion. Write-once database tables where the application's service account has INSERT permissions but not UPDATE or DELETE. And dedicated ledger databases like AWS QLDB, which we'll cover in detail next episode.

Dan: Right. And the access control around the logs matters too?

Alice: Separation of duties. The application writes to the log — it has append-only access. Developers should not be able to read audit logs during normal operations. The security team reads the logs for monitoring and investigation. Compliance and legal read the logs for regulatory purposes. And here's the key — the people who would benefit most from modifying audit logs are the ones who should have the least access. A system administrator who made an unauthorised change would want to delete the audit entry that recorded it. That's exactly why they can't have delete access.

Dan: Hmm. What about legal admissibility? You said these logs can hold up in court. What makes them admissible?

Alice: Five things. First, contemporaneous recording — entries were created at the time of the event, not reconstructed later. Timestamps prove this. Second, systematic process — the logging runs automatically and consistently, not at someone's discretion. Third, integrity controls — you can demonstrate the logs haven't been tampered with. Append-only storage, hash chains, access controls. Fourth, chain of custody — you can document who had access to the logs and when. And fifth, completeness — evidence that the system captures all relevant events, not just the ones someone chose to log.

Dan: Yeah. That "completeness" one is interesting. How do you prove you're logging everything?

Alice: It's the hardest one. You can demonstrate it through your schema documentation — "here are the event types we capture, here is the code that generates each event type, here is our test coverage proving each event type is emitted." And you can point to the absence of gaps in the log — sequential identifiers, consistent timestamps with no unexplained jumps. It's not perfect proof, but it's substantially more persuasive than no documentation at all.

Dan: Mm. What are the biggest mistakes you see teams make with audit logs?

Alice: Five common ones. Logging too little — only capturing errors, not successful operations. Knowing that a document access was denied is useful, but knowing who successfully accessed a document is equally important. Logging too much — including full document content in audit entries. You want the action and the resource identifier, not a copy of the document itself. That bloats your logs and creates a second copy of sensitive data. Inconsistent schemas across services. Storing logs in a regular database that admins can modify. And the original sin — mixing debug, application, and audit logs in one stream.

Dan: Right. For someone building a legal SaaS product today, what's the minimum viable audit log?

Alice: Structured JSON entries with the six W's. Append-only storage — even just S3 with object lock is a solid start. Separate from your application and debug logs. Access controls that enforce separation of duties. A documented schema. And a retention policy of at least seven years. That gets you to compliance-ready. Next episode, we'll add hash chains to make it tamper-evident — which takes you from "we believe the logs haven't been modified" to "we can mathematically prove it."

Dan: Next episode — Hash-Chained Immutable Logs. Making audit logs provably tamper-proof.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.