Audit log retention starts with a record that lets a team answer five questions after a sensitive action: who acted, what they did, which object changed, when it happened and whether it succeeded. The log also needs enough context to connect related events without copying passwords, access tokens or whole request bodies into a new store of sensitive data.
There is no universal retention period. Keep each class of log for as long as its security, operational, contractual or legal purpose requires, then delete it through a documented policy. “Keep everything forever” raises cost and privacy risk without making the record more trustworthy.
Start with the decision the log must support
The right event list comes from the system’s risks, not from a generic checklist. The OWASP Logging Cheat Sheet recommends defining security monitoring during requirements and design, with the level of detail proportionate to the risk.
For a typical product, the first audit events include:
- sign-in success, failure and account lockout;
- changes to roles, permissions and authentication methods;
- creation, update, deletion and export of important records;
- access to high-risk data or administrative tools;
- configuration, billing and integration changes;
- key, token and credential lifecycle actions;
- security-control failures and attempts to bypass validation;
- starts and stops of the logging system itself.
Operational, transaction and security logs can overlap, but their purposes differ. A payment ledger may need exact financial reconstruction. A security log needs to show suspicious access and control changes. Keeping them logically separate makes permissions, retention and investigations easier to manage.
What each audit event should contain
OWASP groups useful event data under “when, where, who and what.” In practice, an audit record often needs these fields:
| Field | What it should answer |
|---|---|
| Event time | When the system says the event happened, with timezone |
| Recorded time | When the collector received or stored it |
| Actor | Stable user, service or workload identifier |
| Authentication context | Session or credential type, without the secret itself |
| Action | The normalized operation attempted |
| Target | Resource type and stable identifier |
| Outcome | Success, failure, denial or partial completion |
| Reason | Safe error or policy reason |
| Origin | Service, host, tenant, region and source address where appropriate |
| Correlation ID | Which request, job or workflow the event belongs to |
| Change summary | Which fields changed, using redaction for sensitive values |
| Log schema version | Which event definition produced the record |
A display name is useful for people, but it should not replace a stable identifier. Names and email addresses change. The immutable ID is what lets an investigator follow one actor through a long timeline.
A correlation ID is equally important in distributed systems. It connects an API request to a queue job, database update and webhook delivery without pretending that one timestamp proves causation. The same identifier can also help analyze duplicate API operations and webhook replay protection.
Do not turn the log into a secrets archive
Logs are widely copied, indexed and shared during incidents. That makes careless logging a high-impact leak.
OWASP advises excluding or masking data such as passwords, access tokens, session identifiers, encryption keys, sensitive personal data and payment-card information. Request and response bodies deserve particular suspicion because they can contain all of those at once.
Safer patterns include:
- log the credential type and a non-secret key identifier, not the credential;
- log that a protected field changed, not its old and new values;
- store a truncated or keyed fingerprint only when matching is necessary;
- allowlist safe fields rather than trying to redact every dangerous field later;
- sanitize line breaks and delimiters so untrusted input cannot forge new log entries.
Error logs need the same discipline. A stack trace can help debugging, but it may contain file paths, query values or headers that do not belong in the main audit stream.
Retention should be a table, not a slogan
The NIST Guide to Computer Security Log Management treats retention as part of log-management policy. A workable policy separates fast, searchable access from cheaper archives and maps both to a purpose.
| Log class | Example purpose | Retention decision |
|---|---|---|
| Administrative changes | Investigate privilege abuse | Long enough to cover the investigation and review cycle |
| Authentication events | Detect account attacks | Long enough for baselines, alerts and incident discovery |
| Application diagnostics | Debug recent failures | Short operational window unless tied to an incident |
| Financial audit trail | Reconstruct transactions | Contractual, accounting and regulatory requirement |
| Security incident evidence | Support the case record | Preserved under incident and legal-hold procedures |
Write the decision in units the storage system can enforce: days in the searchable tier, days or months in archive, and a deletion date. Record exceptions such as an active legal hold separately. Otherwise “retain for one year” becomes an aspiration that nobody can verify.
Retention also begins at different moments. A raw event may age from collection time, while an incident case may age from closure. Make that start point explicit.
Protect logs from the people and systems they describe
A log is weak evidence when the same administrator can perform an action and silently erase its record. Send high-value events to a separate collection system with tightly scoped write access. Application accounts should append records, not browse or delete them.
Useful controls include:
- encrypted transport to the collector;
- restrictive read roles and recorded access to the log store;
- append-only or immutable storage for high-risk events;
- integrity checks, signed batches or hash chains where the threat model warrants them;
- time synchronization and an explicit clock-confidence field when devices can drift;
- alerts when collection stops or event volume changes unexpectedly;
- tested export and restoration procedures.
Immutability is not the same as indefinite retention. A store can prevent alteration during the approved window and still delete records automatically when that window ends.
Can audit logs be deleted?
Yes, but deletion should happen through policy, not ad hoc cleanup. The retention service can remove expired records while producing its own administrative event: which dataset, policy version, date range and volume were deleted, and who approved an exception.
Individual users usually should not be able to erase audit events that describe their actions. Privacy requests also need careful handling. If an event is legally required or necessary for security, a team may need to retain it while limiting access or pseudonymizing fields. The correct answer depends on the applicable law and the stated purpose, not on a blanket technical rule.
Test the log before an incident
Choose one sensitive workflow and reconstruct it from the stored events. Can you tell who changed the permission, what object changed, whether the attempt succeeded and which downstream job ran? Then test the failure cases: collector unavailable, clock wrong, malformed input, oversized event and redaction rule broken.
Also rotate credentials and disconnect integrations to confirm that the audit trail captures the lifecycle. Our guide to OAuth refresh-token revocation explains why “disconnect” may leave several credentials or sessions to account for.
