Audit Log Policy

Origin & evolution

The discipline grew from accounting's audit trail and hardened as security standards made logging a named requirement. ISO 27001 and SOC 2 both expect a documented logging and retention policy, and examiners look for logs that are immutable, so that once a record is written it cannot be changed or deleted, even by an account with super-admin privileges (techclass).

Two parameters define a mature policy. Retention sets how long records survive; one year satisfies common standards like SOC 2, while SOX or HIPAA can demand five years or more (optro). Tamper-evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → sets how alteration is detected or prevented. Best-in-class architectures enforce immutability through Write Once, Read Many storage or by streaming logs to an external server beyond the reach of local admins, and NIST recommends message digests and digital signatures so any modification is detectable (Mattermost). The field's centre of gravity moved from "do you log?" to "can you prove the log was not touched?"

How it works in practice

A healthcare platform writes its policy to satisfy both SOC 2 and HIPAA. It logs every access to patient records: who, what record, when, from where. Records stream in real time to append-only WORM storage, each entry carrying a timestamp and a cryptographic hash chained to the entry before it, so deleting one record breaks the chain visibly. Retention is set to six years to meet the strictest applicable rule. Two events test the design. A SOC 2 Type II auditor samples a week and the immutable log produces the evidence on demand. Months later, an employee accesses a record they should not have; the forensic trail shows the exact access, and because the log is tamper-evident, the employee cannot have erased it. The policy did both jobs🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → from the same records.

Audit log policy vs. its neighbours

• Compliance framework🏟️Compliance FrameworkComplianceA compliance framework (SOC 2, GDPR, etc.)View reference → sets the requirement that a logging policy exist and names the retention floor. The policy is the organisation's specific answer: what it logs, for how long, protected how. The framework demands the trail; the policy designs it.
• Event schema🔠Event SchemaData & AnalyticsAn event schema for trackingView reference → defines the shape of each logged record: the fields, their types, their meaning. The policy decides which events to capture and keep; the schema decides what each captured event looks like. Policy chooses; schema structures.
• Data classification🍃Data ClassificationSecurityA data classification levelView reference → drives the policy's stringency. Records touching sensitive data attract longer retention and stricter tamper-evidence. Classification sets the sensitivity; the policy translates it into logging rules.

In the graph

In the Unified Product Graph, an audit log policy sits in the compliance region as the rule set over the trail. The product connects through product_audited_via_audit_log_policyProductaudited viaAudit Log Policyhierarchy, making auditability a stated property of the system. The policy answers upward to standards through compliance_framework_requires_audit_log_policyCompliance FrameworkrequiresAudit Log Policyhierarchy, recording that a framework is the reason the policy exists, and downward to structure through audit_log_policy_tracks_event_schemaAudit Log PolicytracksEvent Schemacross-domain, tying the rules to the shape of the events they govern. That places the policy at the junction of why logging is required and how each event is formed, so a framework demanding a trail with no policy to satisfy it becomes a visible gap.