Sigilbase writing

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

2026-07-10T00:00:00+00:00

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	ISO 27001:2022	PCI DSS v4
Nature	Criteria-based (Trust Services Criteria)	Risk-based controls (Annex A)	Prescriptive requirements (Requirement 10)
What to log	Not prescribed; whatever evidences your controls (access, changes, incidents)	8.15: user IDs, system activities, dates and times, device identity, network addresses	10.2.1: an explicit event list including all admin actions, access to cardholder data, access to logs, auth failures
Integrity protection	Implied by the criteria; auditors test whether records are reliable	8.15 requires logs to be protected against tampering and unauthorised access	10.3: read access restricted, modification protected, prompt backup, change detection on the logs themselves
Retention	Not prescribed; must cover the audit period, driven by policy	Not prescribed; set by risk assessment and legal obligations	10.5.1: 12 months minimum, most recent 3 months immediately available
Review	Monitoring criteria (CC7 series) expect anomaly detection and evaluation	8.16 requires monitoring and analysis of logs	10.4: daily review of critical logs, using automated mechanisms
Clock sync	Expected in practice	8.17: clocks synchronised to approved time sources	10.6: time synchronisation across systems

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:

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.
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.
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.

SEC Rule 17a-4: WORM storage vs the audit-trail alternative

2026-07-10T00:00:00+00:00

SEC Rule 17a-4 governs how broker-dealers preserve their books and records, and since October 2022 it offers two paths for electronic records: the traditional WORM standard, or an audit-trail alternative under which a system may allow changes provided it keeps a complete, time-stamped, tamper-evident trail of every change and can re-create the original record. Understanding what the alternative actually demands is the difference between modernising your recordkeeping and failing an examination with newer technology.

This guide covers what changed in 2022, what the audit-trail alternative requires in engineering terms, and how to evaluate a recordkeeping system against either path. It is written for the people who build and buy these systems rather than for securities lawyers, though the primary sources are linked throughout and nothing here substitutes for counsel.

What Rule 17a-4 covers

Rule 17a-4 is the Securities Exchange Act rule requiring broker-dealers to preserve specified books and records, including communications sent and received, trade and order records, and customer account documents, for defined periods and in a form regulators can promptly obtain.

The rule has three practical dimensions. Scope: what counts as a record, which is broad, famously including business communications on any channel, the provision behind the roughly $289 million in penalties the SEC imposed on eleven firms in August 2023 over unarchived messaging-app communications. Retention: how long each record class is kept, commonly three years, with central books and customer account records generally at six, and the first two years of any required record in an easily accessible place. Form: the requirements an electronic recordkeeping system must meet, which is where WORM and the audit-trail alternative live, in Rule 17a-4(f).

For decades the form requirement had one answer. Records had to be preserved exclusively in a non-rewriteable, non-erasable format, the WORM standard, written in an era of optical disks and carried forward into compliant disk arrays and object-storage retention locks. WORM is conceptually simple and remains fully valid. It is also rigid: it forces a separate compliance-only storage estate, makes legitimate corrections awkward, and describes how storage media behaves rather than what actually makes a record trustworthy.

What the 2022 amendments changed

On 12 October 2022 the SEC adopted amendments to Rule 17a-4 (Release No. 34-96034) that kept the WORM standard as an option and added an audit-trail alternative, alongside related changes including the removal of the requirement to notify a firm's designated examining authority before using an electronic recordkeeping system, and more flexible undertakings for third-party recordkeeping arrangements. The Commission's stated aim was to modernise requirements that predated two decades of technological change.

The audit-trail alternative, set out in Rule 17a-4(f)(2)(ii)(A), requires an electronic recordkeeping system that preserves records in a manner maintaining a complete time-stamped audit trail including:

all modifications to and deletions of a record or any part of it;
the date and time of operator entries and actions that create, modify or delete the record;
the individual or individuals creating, modifying or deleting the record; and
any other information needed to maintain an audit trail of each distinct record in a way that maintains the record's security, signatures and data to ensure its authenticity and reliability, and that permits re-creation of the original record if it is modified or deleted.

Read as an engineering specification, that is: capture every write as an attributed, timestamped event; never lose a prior state; and be able to prove both the sequence and the content of what happened. A firm electing the alternative must meet all of it, and the retention periods, accessibility requirements and prompt-production obligations of the wider rule apply unchanged.

WORM vs audit trail: how to think about the choice

	WORM	Audit-trail alternative
Core idea	Records cannot be changed, by construction of the storage	Records can change, but every change is captured and the original is re-creatable
Where integrity lives	In the storage medium's write-once property	In the completeness and trustworthiness of the trail
Corrections and lifecycle	Awkward; corrections become new records beside immutable originals	Natural; amendments are events in the trail
Typical implementation	Object-lock storage, compliant archive platforms	Event-sourced or versioned systems with attributed change capture
The hard question an examiner asks	Is every in-scope record actually landing in the WORM store?	Could the trail itself have been altered without detection?

The last row is the one that matters. WORM's weakness is coverage: the storage is trustworthy, but only for what reaches it, and the gap between a record's creation and its archival is where problems live. The audit-trail alternative's weakness is circularity: it proves record history by reference to a trail, so the entire compliance claim now rests on the integrity of the trail itself. An audit trail held as ordinary rows in a database that administrators can quietly rewrite does not "maintain security... to ensure the authenticity and reliability of the record". It merely relocates the original problem.

What makes an audit trail trustworthy

An audit trail can carry the weight the alternative places on it only if it is tamper-evident: constructed so that any alteration, deletion or reordering of trail entries is detectable after the fact.

A tamper-evident audit trail is one in which each entry is cryptographically linked to its predecessors, typically by hash chaining, and batches of entries are sealed under digital signatures, so that recomputation reveals any change to historical entries.

The engineering ladder runs from access controls (necessary, insufficient, because someone always holds the higher privilege), through write-once storage of the trail (which quietly reintroduces WORM one layer down, and still leaves verification as an act of trust in the operator), to cryptographic tamper-evidence, where the trail's integrity is a property anyone can check by computation. The strongest version makes that check independently runnable: an examiner, an auditor or a counterparty verifies the trail's completeness and the re-creatability of original records without trusting the firm or its vendor. This is the design Sigilbase implements for application-level records and events: every entry is hash-chained on write, sealed into signed checkpoints, and exportable as an evidence bundle that verifies offline with an open-source verifier, so "the trail is intact" is a demonstrable fact rather than an assertion.

The honest boundary matters here: an event-integrity layer of this kind is a component of an audit-trail-alternative architecture, the part that makes the trail itself defensible, not a turnkey books-and-records platform. Communications archiving, record classification, retention scheduling and the rule's undertaking arrangements are their own problems, and a firm's overall system is what an examiner evaluates.

Evaluating a system against the alternative

Whether building or buying, the questions that map directly to the rule's four elements:

Completeness. Does every create, modify and delete of an in-scope record produce a trail entry, enforced at the system level rather than by application discipline? Can anything write to the record store without writing to the trail?

Attribution and time. Does each entry carry the acting individual (not a shared service identity) and a timestamp from synchronised clocks? Cross-system timelines fail at exactly the moment an examination needs them.

Re-creation. Given any record and any point in its history, can the system reproduce the original content, not merely report that a change occurred? Deltas without recoverable originals fail the plain text of the requirement.

Trail integrity. If someone with the highest level of access had altered a trail entry last year, what would detect it? This is the question that separates an audit trail from a log table, and the one worth asking every vendor whose brochure says "17a-4 compliant".

Production. Can records and their trails be extracted, for a regulator, promptly and in a usable form, with their integrity demonstrable outside the system that produced them?

Where this is heading

The 2022 amendments describe trustworthy records by their properties rather than their storage media, and that framing is spreading: examiners increasingly ask how any record system, WORM or not, would evidence its own integrity. Firms replatforming their recordkeeping have a rare alignment available, where the architecture that satisfies the regulator, event-sourced records with a cryptographically verifiable trail, is also simply better engineering than a compliance-only archive bolted alongside production systems.

Primary sources: the SEC's adopting release and summary of the amendments, the text of Rule 17a-4, and FINRA Rule 4511. For the broader question of what makes audit logs defensible across frameworks, see our guide to audit log requirements.

How to prepare audit evidence for SOC 2: an engineer's guide

2026-07-10T00:00:00+00:00

SOC 2 evidence is the documentation and system records proving your security controls existed and operated during the audit period. Preparing it well comes down to three moves: map each control to the system that evidences it, collect that evidence continuously rather than quarterly, and make the records trustworthy enough that an auditor can rely on them. This guide covers all three from the engineering side.

The audience is the technical lead a few months out from a first audit, staring at an evidence request list that seems to want everything the company has ever done. It is more tractable than it looks, and most of the pain is self-inflicted by treating evidence as something you gather at the end rather than something your systems produce as they run.

What counts as evidence in a SOC 2 audit?

Audit evidence is the set of records an auditor examines to conclude that your controls were suitably designed and operated effectively: documents, system-generated records, configurations, and the outputs of the controls themselves.

Evidence takes three broad shapes. Configurations and screenshots capture how something is set: the MFA policy, the firewall rule, the S3 bucket permissions. Documents capture what you committed to: policies, procedures, risk assessments, vendor reviews. System records capture what actually happened: audit logs, access reviews, deployment records, tickets, alerts. The first two are gathered; the third is generated, and it is where audits are won or lost.

The Type 1 versus Type 2 distinction determines how much the third category matters. A Type 1 report assesses whether controls were suitably designed at a point in time. A Type 2 report assesses whether they operated effectively across a period, commonly three to twelve months, and it is the report your customers will actually ask for. Type 2 is what makes record-keeping the hard part: a control that ran for eleven months but has records for nine is, to an auditor, a control with a two-month hole in it, and holes cannot be backfilled honestly after the fact.

What evidence do auditors actually request?

Auditors request evidence per control, grouped by the Trust Services Criteria areas, and the requests are more predictable than first-timers expect. A realistic tour of the recurring items:

Access control (the CC6 series). User access reviews with sign-off, showing each system's accounts were reviewed and exceptions acted on. Provisioning records tying each new account to an approval. Deprovisioning records showing leavers lost access promptly, with the leaver list cross-checked against HR. MFA configuration and its enforcement. Privileged access lists and the justification for each entry. The deprovisioning cross-check is a perennial finding: the auditor samples leavers and asks for the timestamped removal record, and "we definitely did it" is not a record.

Change management (CC8). Evidence that changes were reviewed, approved, and tested before production: pull request approvals, CI results, deployment logs tying the deploy to the approved change. Auditors sample changes from the period and walk each one end to end, so the chain from ticket to approval to deploy needs to be reconstructable for any given change, not just describable in general.

Incident response (CC7). Incident tickets with timelines, severity, and resolution; post-incident reviews for the significant ones; evidence the response procedure was followed rather than improvised. If you had no incidents, expect to evidence that monitoring existed and would have caught one.

Monitoring and logging (CC7). Alert configurations, samples of alerts firing and being handled, and audit logs from the systems in scope. The logs themselves get sampled: the auditor picks events and asks who did this, when, and how do you know this record is accurate.

The pattern across all four areas: auditors sample, then trace. They rarely read everything; they pick items from the period and follow each one through your records. Evidence preparation is therefore about traceability per item, not volume in aggregate.

How to collect evidence without a fire drill

Continuous collection beats the quarterly scramble on every axis: less effort, fewer gaps, better evidence. The method is unglamorous. For each control, decide the single system of record that evidences it, and write the mapping down: access reviews live in this tool, change approvals are pull requests in this repo, incidents are tickets in this project, admin actions are in this audit log. Ambiguity about where evidence lives is how gaps happen, because everyone assumes another system caught it.

Then automate the exports. Anything that requires a human to remember monthly will develop holes; anything scheduled will not. Timestamp everything at generation, in UTC, from synchronised clocks, because evidence with vague or conflicting times invites exactly the scepticism you are trying to avoid. Assign an owner per control, since evidence without an owner is evidence nobody notices has stopped.

A word on compliance automation platforms, because most first-time SOC 2 journeys involve one. They are genuinely good at the workflow: mapping controls, chasing tasks, integrating with your stack to pull configurations, and keeping the programme organised. Use one if it helps. Be clear-eyed about what they collect, though: ordinary records from ordinary systems. The platform proves collection happened; it does not make the underlying records more trustworthy than the systems that produced them. That question, the reliability of the records themselves, is a separate one.

Can your evidence survive scrutiny?

The uncomfortable question underneath all evidence preparation is whether the records could have been altered, because most of them could. The access review lives in a spreadsheet anyone can edit. The audit log is a database table the application, and every administrator, can UPDATE. Screenshots prove a moment and are trivially remade. For most first audits this passes, because auditors work within the norms of what organisations can produce. The norms are shifting, and for period-based controls the better auditors have started asking the sharper question: how do you know these records are the records?

Tamper-evident evidence is evidence stored such that any alteration after the fact is detectable, typically through append-only storage, cryptographic hash chains linking each record to its predecessor, and digital signatures sealing batches of records.

The escalation ladder for record integrity runs from restricted write permissions, through write-once storage, to cryptographic tamper-evidence, and each rung strengthens what you can claim. The top rung changes the conversation with an auditor in kind rather than degree: instead of describing controls that should have prevented edits, you hand over records whose integrity can be checked by computation. This is the problem Sigilbase exists to solve: applications write audit events into hash-chained, checkpoint-sealed streams, and evidence exports verify offline with an open-source verifier, so an auditor can confirm for themselves that nothing was modified, deleted, or reordered, without taking anyone's word for it, including ours.

You do not need the top rung for every record in a first audit. You do need to know which of your evidence sources would survive the sharper question, because the systems that evidence your most sensitive controls, admin actions, access changes, production data access, are exactly where it will land first.

A 90-day preparation plan

Ninety days is enough runway for a first Type 2 audit if the period is already underway and the controls broadly exist. The plan, deliberately boring:

Days	Focus	Concretely
1 to 30	Scope and map	Agree the audit period and scope with your auditor. Map every control to its system of record and an owner. List the gaps where no system currently produces the evidence.
31 to 60	Close and automate	Close the gaps: stand up the missing records, fix deprovisioning traceability, enable the audit logging that was off. Automate the recurring exports. Dry-run one control end to end, sample-and-trace style, as the auditor will.
61 to 90	Review and freeze	Internal evidence review against the request list. Fix what the dry run exposed. Auditor kickoff. Freeze changes to the evidence process itself for the remainder of the period, since changing how records are produced mid-period creates its own questions.

The single highest-value hour in the whole plan is the dry run: pick a control, sample five items from the period, and trace each to its records as a stranger would. Whatever you cannot trace, the auditor will not be able to either, and you have just found it first.

The mindset that makes audits cheap

Companies that find SOC 2 painful treat evidence as a deliverable assembled before the audit. Companies that find it routine treat evidence as a property of how their systems run: actions produce records, records are owned, protected, and traceable, and the audit becomes an export rather than a project. Every improvement above, systems of record, automation, integrity protection, moves you from the first category to the second, and each is worth having even if no auditor ever asked.

Primary sources: the AICPA Trust Services Criteria define what auditors assess. For the logging side in depth, including what SOC 2, ISO 27001 and PCI DSS each require from audit logs, see our companion guide to audit log requirements.