Tamper-evident audit trails for SEC 17a-4 recordkeeping
The SEC's audit-trail alternative to WORM storage requires a complete, time-stamped record of every modification and deletion, attributable to individuals, able to re-create original records. Sigilbase provides the integrity layer that makes such a trail defensible: every event hash-chained, sealed into signed checkpoints, and verifiable by an examiner without trusting the firm or us.
Since October 2022, Rule 17a-4 permits an audit-trail alternative to WORM, but the entire compliance claim then rests on the trail's own integrity.
An audit trail stored as ordinary database rows can be rewritten by anyone with sufficient access, and nothing would detect it.
Examiners ask the sharp question: prove the trail is complete and unaltered, not just that one exists.
The Sigilbase event model, applied to a record amendment.
Record lifecycle events post to a Sigilbase stream as they happen. Each entry captures the individual, the action, the time, and the hashes that make prior states re-creatable.
{
"actor": "user:jmorton",
"action": "record.amended",
"occurred_at": "2026-07-10T14:31:02.418260Z",
"resource": "record:acct-4471/kyc-form",
"payload": {
"reason": "address correction",
"prior_version_hash": "9c4e1ab27fd0…",
"new_version_hash": "5b02c9e4d811…"
}
}
Sigilbase hashes every event with SHA-256 and chains it to the one before it, so modifying, deleting or reordering any historical entry breaks the chain at that exact sequence.
Sigilbase seals recent events into Merkle checkpoints signed with Ed25519 every few minutes, and the standalone verifier recomputes the chain and signatures offline, so a break is detected by recomputation rather than by trust.
A log records events. Sigilbase makes them provable.
| Question | Ordinary audit table | WORM archive | Sigilbase trail |
|---|---|---|---|
| Operator can silently rewrite history | Yes | No, for archived copies | No, detectable at the exact record |
| Captures who, what, when per change | If the application remembers to | For what reaches the archive | Enforced per event, attributed and timestamped |
| Original record re-creatable after changes | Rarely | Yes, as frozen copies | Yes, prior states referenced by hash in the trail |
| Third party can verify integrity independently | No | No, trust in the platform | Yes, offline, with an open-source verifier |
| Survives the vendor disappearing | No | Partially | Yes, exported bundles verify without Sigilbase |
Built for the audit-trail alternative's four requirements.
Rule 17a-4(f)(2)(ii)(A) asks four things of an audit trail. How each maps:
Streams are append-only by construction, enforced at the database layer, so every change to a record is a new attributed event and no code path exists to alter history. The absence of a delete path is a property, not a policy.
Every event carries the acting identity and microsecond UTC timestamps from synchronised clocks, the fields an examiner samples first.
Hash chains link every event to its predecessors; checkpoints seal batches under Ed25519 signatures every few minutes; nightly verification confirms the chains end to end and alerts on the first broken sequence.
Prior-state hashes in the trail bind each version of a record to its history, and evidence bundles export the full sequence, so the original of any amended record is identifiable and demonstrable, not merely asserted.
Sigilbase is the integrity layer of an audit-trail-alternative architecture, the part that makes the trail itself defensible to an examiner. Communications archiving, record classification and retention scheduling remain the firm's wider system; Sigilbase makes the change history of that system provable.
Questions about SEC 17a-4 audit trails.
Does the SEC still require WORM storage?
No, not exclusively. The October 2022 amendments to Rule 17a-4 kept WORM as one option and added an audit-trail alternative. A firm's electronic recordkeeping system must satisfy one of the two.
What must a 17a-4 audit trail contain?
A complete time-stamped record of all modifications and deletions, the date, time and individuals behind each action, and whatever else is needed to maintain the record's authenticity and permit re-creation of the original if it is altered or erased.
How does Sigilbase keep the audit trail itself from being tampered with?
Every event is hash-chained to the previous one and batches are sealed into signed checkpoints. Changing any historical entry breaks the chain detectably at that sequence. Verification runs nightly, and exported evidence verifies offline with an open-source verifier, so the check does not depend on trusting Sigilbase.
Is Sigilbase a complete 17a-4 compliance solution?
No. Sigilbase provides the tamper-evident audit trail within a firm's recordkeeping architecture. Communications capture, record classification, retention schedules and regulatory undertakings are separate parts of the rule that remain the firm's responsibility.
Can an SEC examiner verify the records without a Sigilbase account?
Yes. Evidence bundles export the events, hashes, checkpoints and signatures, and the standalone verifier checks them offline in three commands. A failed check names the exact sequence that does not verify.
Join the waitlist
Building now. Early access for firms modernising 17a-4 recordkeeping.
Could not save your email. Try again or write to [email protected].
No spam, one email when it opens.