SEC recordkeeping requirements in your application

For years, the practical reading of SEC Rule 17a-4 was that electronic records had to sit in write-once, read-many storage. That constraint shaped financial software for many years, usually by pushing records into a separate archival system that the application wrote to and nobody else touched.

The 2022 amendments changed the options. The rule now permits an audit-trail alternative alongside the WORM approach, and for most modern applications the audit-trail route is both a better architectural fit and, read carefully, a more demanding engineering requirement.

What the rule actually says

The operative language is worth reading rather than paraphrasing. An electronic recordkeeping system must preserve a record for the duration of its retention period in a manner that maintains a complete time-stamped audit trail that includes all modifications to and deletions of the record or any part thereof, the date and time of actions that create, modify, or delete the record, if applicable the identity of the individual creating, modifying, or deleting the record, and any other information needed to maintain an audit trail in a way that maintains security, signatures, and data to ensure the authenticity and reliability of the record and will permit re-creation of the original record if it is modified or deleted [1].

The alternative is to preserve records exclusively in a non-rewriteable, non-erasable format [1], which is the older WORM option and remains available.

Two further requirements come with it and are often missed. The system must verify automatically the completeness and accuracy of the processes for storing and retaining records electronically. And it must have the capacity to readily download and transfer copies of a record and its audit trail in both a human readable format and in a reasonably usable electronic format [1].

The four assertions in one sentence

Converted into engineering requirements, that paragraph produces a short list, and the difficulty is unevenly distributed across it.

Every create, modify, and delete produces an entry. Straightforward. Most teams have this, usually through database triggers or an application-level audit table.

Every entry carries a timestamp. Also straightforward, with one risk: the timestamp needs to be unambiguous. A local-time timestamp with no zone, or one that shifts under daylight saving, is a real problem in a reconstruction three years later.

Every entry names the individual. This is where the first genuine failures appear, and there are three common ones. Background jobs write as a service account, which is correct but only if the entry also records what triggered the job and on whose behalf. Bulk operations record one actor for a thousand rows, which is usually fine, but only if the trail links them. And administrative impersonation, where a support user acts as a customer, often records the customer as the actor. That last one is not a small defect. It means the trail asserts that a customer did something a member of staff did, which is worse than no entry at all, because it is confidently wrong.

The original is recoverable. This is the hard one, and it is the requirement that separates systems that pass from systems that look like they pass.

Why re-creation is the requirement that fails

Most audit implementations record that a change happened. Far fewer record enough to reconstruct what the record was before it.

The typical pattern is an audit table with an action, a timestamp, an actor, and a record identifier. That satisfies three of the four assertions and fails the fourth completely, because knowing that customer record 4471 was modified at a given time by a given user does not let you reconstruct its prior state. To do that you need either the prior values, the changed values plus enough history to replay, or an append-only design where nothing is ever overwritten in the first place.

Soft deletes deserve specific attention here, because teams treat them as the compliant option and they are not automatically compliant. A soft delete that sets a deleted flag and leaves the row otherwise intact preserves re-creation. A soft delete that sets the flag and also blanks or anonymises the fields, which many do for privacy reasons, destroys it. The two look nearly identical in the code and behave completely differently under the rule.

There is a genuine tension here worth naming, because pretending it does not exist helps nobody. Recordkeeping obligations push towards preserving everything, and privacy obligations push towards deleting on request. They are resolved by retention periods and by scoping which records are covered, not by picking one and ignoring the other, and that resolution is a legal question rather than an engineering one. What engineering must contribute to the discussion is an accurate account of what the system currently does, which is frequently different from what the team believes.

How to check it, properly

The re-creation requirement cannot be verified by inspection. Reading the schema tells you what could be reconstructed in principle. It does not tell you what actually can be, because the answer depends on application behaviour that the schema does not capture.

The check that works is a full cycle test, run as an automated test:

Create a covered record with known values. Modify several fields, including at least one that the application treats specially, such as an encrypted field or one that triggers a downstream sync. Delete it, by whatever mechanism the application actually offers users. Then, using only the audit trail, reconstruct the record as it stood before each change, and assert that the reconstruction matches what you created.

Run that for every covered record type rather than one representative example. The failures are almost never uniform. A system will handle its core entity correctly and fail on the three peripheral ones that were added later by a different team under time pressure, and those peripheral ones are exactly the ones nobody thinks to test manually.

Then add the export requirement to the same suite: assert that the record and its trail can be produced in a human-readable form and in a reasonably usable electronic form [1]. Teams often satisfy this with an ad hoc database query run by an engineer, which works right up until the examination arrives and the engineer who knew the query has left.

The retention side

Preserving the trail for the duration of the applicable retention period is part of the same requirement, and retention is its own source of unnoticed failures.

The common pattern is that retention is enforced somewhere other than where data actually leaves. A policy says records are kept for the required period and then disposed of, and the implementation is a scheduled job over the primary table. Meanwhile the analytics replica, the backup snapshots, the log aggregator, and the export bucket each have their own lifecycle, usually set by whoever configured them, usually not aligned with the policy. Records that should have been disposed of survive in three places, and records that should have been preserved get deleted from a backup tier on a ninety-day default.

Both directions are failures. Checking them means enumerating every place a covered record can be stored, which is a discovery exercise before it is an engineering one, and which is covered on how to audit an existing financial application.

Rules change and this page is a starting point for engineering work, not legal advice about which records are covered in your business. Get that scoping from counsel, then bring it here and turn it into checks. If you want help doing that, get in touch.