Audit log requirements for SOC 2, ISO 27001 and PCI DSS

Every major compliance framework requires roughly the same four things from audit logs: record security-relevant events, protect those records from alteration, retain them for a defined period, and review them. The details differ. PCI DSS is prescriptive down to individual fields, ISO 27001 is risk-based, and SOC 2 is criteria-based. The requirement most implementations fail is not the recording. It is the protection.

This guide covers what each framework actually asks for, where the common core sits, and how to build one logging design that satisfies all three. It is written from the engineering side of compliance work, where the question is never "should we log" but "what exactly, for how long, and how do we prove nobody touched it".

What is an audit log?

An audit log is a chronological record of security-relevant events in a system, capturing who did what, to which resource, when, and with what outcome, kept for the purpose of accountability and investigation.

The definition matters because audit logs get conflated with two neighbours. Application logs exist for debugging: they are verbose, unstructured, and nobody minds if they rotate away after a fortnight. Metrics exist for operations: they aggregate away the individual actions entirely. An audit log is different in intent. Each entry is a small assertion of fact about a human or system actor, and the collection is expected to stand up as evidence months or years later. That evidential intent is what drives every requirement below.

What each framework requires

The three frameworks approach logging from different philosophies. PCI DSS tells you what to do. ISO 27001 tells you to decide what to do and prove you did it. SOC 2 tells you the outcomes your controls must achieve and lets the auditor judge whether your logging achieves them.

SOC 2

SOC 2 never says "you must keep an audit log". The Trust Services Criteria published by the AICPA describe outcomes: the CC6 series covers logical access controls, and the CC7 series covers monitoring, anomaly detection, and the evaluation of security events. What makes logging unavoidable is the Type 2 report, which attests that controls operated effectively across a period, typically three to twelve months. An auditor testing whether access reviews happened, whether changes were approved, and whether incidents were handled needs records spanning that whole window. In practice those records are audit logs, tickets, and approval trails, and the auditor's real question is whether they can be relied upon. A criteria-based framework does not lower the bar for log quality. It moves the judgement to the auditor, which makes the trustworthiness of your records the deciding factor rather than a checkbox.

ISO 27001

ISO 27001:2022 addresses logging in three adjacent Annex A controls. Control 8.15 (logging) requires that logs recording activities, exceptions, faults and other relevant events are produced, stored, protected and analysed, and its guidance lists the contents: user IDs, system activities, dates and times of events, device identity, and network addresses and protocols. Control 8.16 (monitoring activities) requires the logs to actually be watched, with anomalous behaviour detected and evaluated rather than archived unread. Control 8.17 (clock synchronisation) exists because correlation across systems is impossible when their clocks disagree; it requires synchronisation to approved time sources. ISO deliberately avoids fixed retention periods. The standard expects you to set retention from your own risk assessment and legal obligations, then demonstrate you follow your own policy, which is a subtler test than a number: an auditor will check that the policy exists, that it was reasoned, and that reality matches it.

PCI DSS

PCI DSS is the most prescriptive of the three, and Requirement 10 is effectively a specification for an audit logging system. Requirement 10.2.1 enumerates the events that must be captured, including every individual access to cardholder data, all actions by anyone with administrative privileges, all access to the audit logs themselves, invalid access attempts, changes to authentication mechanisms, and the starting or stopping of logging. Requirement 10.2.2 specifies the fields per event: user identification, event type, date and time, success or failure, origin, and the identity of the affected data or resource.

The integrity requirements are where PCI shows its teeth. Requirement 10.3 restricts read access to logs to those with a need, protects log files from modification, requires prompt backup to a centralised location, and, in 10.3.4, requires file integrity monitoring or change-detection mechanisms on the logs themselves, so that existing log data cannot be changed without generating alerts. Requirement 10.5.1 sets retention at a minimum of 12 months with the most recent three months immediately available for analysis. Requirement 10.4 mandates review of critical logs at least daily, and version 4 requires that review to be performed with automated mechanisms rather than a human scrolling a file. Requirement 10.6 mandates time synchronisation. If you design for PCI's Requirement 10, you have almost certainly satisfied the logging expectations of the other two frameworks along the way.

The common core: one design for all three

A single logging design satisfies all three frameworks if it captures the right fields, covers the right events, and treats time seriously. Per event, record the actor (a user, service, or API identity), the action, the resource affected, the outcome, a timestamp in UTC from a synchronised clock, and the origin (address or system). That field set satisfies PCI 10.2.2 verbatim and gives ISO 8.15 and any SOC 2 auditor everything they ask of an individual record.

Coverage is a checklist rather than a philosophy: authentication events including failures, privilege and role changes, access to the sensitive data your frameworks care about, configuration and system changes, administrative actions of any kind, and access to or management of the logs themselves. That last item is easy to miss and explicit in PCI: the audit trail of the audit trail.

Two structural decisions round out the core. Centralise the logs away from the systems that produce them, because a log that lives only on the machine that generated it disappears with the machine. And synchronise every clock to the same source, because the first thing any investigation does is build a timeline, and the first thing that breaks a timeline is two systems that disagree about when.

How do you protect audit logs from tampering?

Protecting logs from alteration is the requirement that most implementations quietly fail, because the default implementation is a table the application can rewrite. Every framework contains a version of this clause. ISO 8.15 requires protection against tampering. PCI 10.3.2 and 10.3.4 require modification protection and change detection. SOC 2 auditors, asked to rely on records, must first believe the records. Yet the standard audit log in most software is a row in the same database, written by the same application, administered by the same team whose actions it records. Anyone with production database access can rewrite history with one statement, and nothing would notice.

There is an escalation ladder for closing that gap, and each rung is a real improvement:

1. Restricted permissions. The application's runtime database role gets INSERT but not UPDATE or DELETE on log tables, and humans do not hold standing write access. Necessary, cheap, and insufficient alone, because someone always holds the higher privilege.
2. Write-once storage. Shipping logs to WORM or object-lock storage removes the easy rewrite. It protects the copies, though the window between write and shipment remains, and verifying the archive matches what was originally written still requires trust.
3. Hash chains and signed checkpoints. Cryptography makes the log itself tamper-evident rather than merely access-controlled.

A hash chain is a structure in which each record includes a cryptographic hash of the record before it, so the entries form a linked sequence. Changing, removing, or reordering any historical record changes its hash, which breaks every link after it, making the alteration detectable by recomputation.

Hash chaining, combined with periodically sealing batches of records under a digital signature, changes the nature of the claim you can make to an auditor. Instead of "we have controls that should have prevented edits", the claim becomes "here is a computation you can run that proves no edits occurred". The strongest version of the pattern makes that computation independently runnable, so an auditor or counterparty can verify the records without trusting the operator of the logging system at all. This is the approach Sigilbase takes: events are hash-chained on write, sealed into signed checkpoints, and exportable as evidence bundles that verify offline with an open-source verifier, so the integrity claim does not rest on trusting us either.

Whichever rung you build to, the test an auditor will apply is the same: if someone with the highest level of access had quietly changed a record last year, what would have noticed?

Retention and review without drowning

Retention is the easiest requirement to satisfy on paper and the easiest to break in practice. The workable posture across frameworks: keep everything for at least 12 months (PCI's floor, and a sensible default for the others), keep the most recent three months hot and queryable, and archive the remainder to cheap storage that you have actually tested restoring from. The untested archive is a classic audit finding, because retention configured is not retention demonstrated. Where ISO and SOC 2 leave the number to you, write the number down in policy first, since the auditor tests you against your own document.

Review requirements sound worse than they are. PCI's daily review of critical logs explicitly expects automated mechanisms in version 4, and ISO 8.16 and SOC 2's monitoring criteria are equally satisfied by alerting: define the classes of event that matter (authentication anomalies, privilege escalations, logging stopping, integrity check failures), alert on them, and keep records of the alerts and their handling. Nobody expects a human reading log lines each morning, and a documented alerting pipeline is stronger evidence than a signature on a daily checklist claiming somebody did.

Common failures auditors flag

The recurring findings in this area are rarely exotic. The log table is editable by anyone with database access, and nothing detects changes. Clocks are unsynchronised, so cross-system timelines cannot be built. Logging silently stopped during an incident, precisely when it mattered, and no alert fired on the stoppage (an explicit PCI event category for that reason). Retention is configured but the archive has never been restored. Events record that something happened but not who did it, because the application logged the action under a service account rather than the acting user. Each of these is cheap to fix before an assessment and expensive to discover during one.

Where to start

If you are building or fixing audit logging for a compliance programme, the order that works: define the event catalogue and field set against the table above, centralise and clock-sync, lock down write access and add change detection, then decide how far up the integrity ladder your evidence needs to go. PCI environments should treat Requirement 10 as the specification. Everyone else inherits a design that clears their bar with room to spare.

Primary sources worth reading directly: the PCI DSS standard (Requirement 10), ISO/IEC 27001:2022 (Annex A 8.15 to 8.17), and the AICPA Trust Services Criteria. For the evidence-preparation side of a SOC 2 audit specifically, see our guide to preparing SOC 2 audit evidence.