Immutable ledgers and SOX IT general controls

Auditors expect a named list of identities that can post, reverse or change balances, each tied to a documented business role. Evidence comes from three sources: the identity provider and role assignments that gate access to the ledger API, the ledger's own audit trail of who submitted each transfer, and the privileged access records for the database and host underneath it. Keep the role matrix, the approval record for each grant and the exported logs for the audit period. Confirm with your ledger vendor or integrator whether the ledger itself records the calling identity on every transfer, or whether that identity must come from your API gateway logs.

A correction should be a new, linked entry that references the original transfer and carries its own reason code, approver and timestamp, while the original remains unchanged. Auditors will sample corrections and ask for both records side by side. Your evidence is the ledger record of the linked entries, the application ticket or workflow approval that authorized the correction, and the reconciliation report showing the balance effect. Retain the original and correcting entries, the approval and the period-end report. Confirm how your chosen ledger expresses linkage between entries, because the mechanism differs between products.

Posting logic is often the most significant automated control in a ledger, so auditors look for the same change management evidence they would expect for any financial application. Show the change request, the reviewer approval, the test results covering balance and rounding cases, and the deployment record that links the released version to that approval. The sources are your source control history, CI/CD pipeline logs and the change ticket. Separate duties so that the person who writes a change is not the only person who deploys it, and keep the pipeline logs for the audit period.

Completeness means every posted ledger movement reaches the general ledger, and nothing reaches it twice. Auditors typically ask for control totals, record counts and a reconciliation between the ledger's period balances and the GL batch imports. Evidence includes the interface job logs, the batch control totals, rejected-record queues and the signed reconciliation for each close. Retain the export files, the totals and the exception log. Ask your integrator how the interface handles retries, so that a failed batch cannot be silently duplicated.

Access reviews show that someone with authority periodically confirmed that each account still needed its access. Typical evidence is an export of users, roles and privileged accounts at the review date, the reviewer's signed attestation, and a record of every removal made as a result. Include operators with database or infrastructure rights, since they can change balances without passing through the ledger API. Set a review frequency in your control design, and retain each review package for the audit period.

SEC guidance in Release 33-8810 says management evaluates only the IT general controls needed for the consistent operation of controls that address financial reporting risks, and that the relevant areas depend on the company's facts. The guidance names program development, program changes, computer operations and access to programs and data as examples. For a ledger, that usually means access, change management, operations such as backup and job monitoring, and interfaces. Confirm the scope with your external auditor early, since they decide which controls they will rely on.

DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. In practice, a fixed-scope engagement can cover defining the control design, configuring access and logging, setting up the pipeline and retention, and writing the evidence procedures. Your auditors then test the controls. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope.

The main cost drivers are the scope of financial reporting the ledger feeds, the number of interfaces into the general ledger, the number of people and service accounts that can operate or change the ledger, and how mature your existing IT general controls already are. A ledger that feeds one consolidated general ledger with a small operator group is a smaller job than one that feeds several entities, multiple currencies and many automated posting paths. Organizations with documented access reviews, change tickets and log retention start from a stronger position than those building evidence from scratch. No public source gives a dollar figure for this work, so ask each provider for a written scope that lists these drivers separately.

The time to a first evidence package depends on how many controls are in scope, how quickly control owners can provide records, and whether the ledger's configuration, change history and access logs already exist in a usable form. Teams that need to design controls, instrument logging and collect a full period of evidence will take longer than teams that only need to document existing controls. Your external auditor sets the period they want to test, which often shapes the calendar more than the build itself. Ask any implementation partner for a timeline tied to specific deliverables and dependencies in writing, and confirm the testing period with your auditor before work starts.

Partners will need named control owners for financial reporting, read access to the general ledger and its interfaces, the change history for posting logic and infrastructure, and your current policies for access, change management, backup and incident handling. They also need the list of people and service accounts with operator rights, plus the systems that send entries into the ledger. Without these inputs, the partner cannot tell which controls matter for financial reporting or where the evidence sits. Build this list into the scope so that missing inputs appear as dependencies in the quote rather than as surprises mid-project.

Some internal teams can, particularly where they already run SOX programs for other systems and have engineers who understand the ledger's database, deployment and access model. The harder parts are usually independent testing of controls, mapping ledger activity to the general ledger, and producing evidence that an external auditor will accept without rework. Many teams split the work: internal control owners keep ownership of the controls and attestation, while a partner handles configuration, logging, hardening and evidence preparation. Decide early which parts you will own, and write that split into the scope.

The recurring work typically includes periodic access reviews for ledger operators and administrators, testing of a sample of changes to posting logic and infrastructure, checks that log retention and backups still work, and reconciliation of ledger balances to the general ledger. Management also needs to reassess its controls as the system and its people change. Under the SEC's evaluation approach in Release 33-8810, management evaluates the IT general controls that support reliable financial reporting, so the annual cycle should follow that scope. Ask any provider to price these recurring activities separately from the initial build, and to state who performs each one.

No. The SEC's 2020 estimate in Release 34-88365 covers the cost savings for an issuer that becomes newly exempt from the Section 404(b) auditor attestation requirement. It estimated about $210,000 per year on average, made up of roughly $110,000 in audit fees and $100,000 in other costs. It does not measure the cost of building or running a ledger, and it does not remove management's own obligation to assess internal control over financial reporting under Section 404(a). Use it only as context for how attestation costs are treated in the rules, and build your project budget from a written scope.

A usable quote lists each deliverable with its acceptance criteria, the systems and interfaces in scope, the controls mapped to each deliverable, and the roles and access the partner will need. It should separate one-time work such as design, configuration, logging, hardening and first-cycle evidence from recurring work such as reviews, change testing and retention checks. It should also state the assumptions about your inputs, the change control process for scope changes, and what the client must supply and by when. DeployOpen works from fixed-scope agreements where scope, deliverables and timelines are agreed in writing before work starts, and it does not publish a price list, so ask for the scope first and the quote second.

A partner prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications. Management remains responsible for its ICFR assessment under Section 404(a), and the external auditor, where one applies, performs its own testing under PCAOB standards. A partner also cannot decide which controls are relevant to your financial reporting risks on your behalf. Confirm these boundaries in the scope so that your auditor, control owners and the implementation team each know what they own.