The server of record is disappearing. The control objectives endure — but the audit approach and control-implementation guidance must adapt. A control-objective map for a serverless, local-first, hash-chained ERP ledger, against COSO (2013), SOX / PCAOB AS 2201, and ISO/IEC 27001:2022.
The direction of travel. Enterprise software is moving off the central server of record. Local-first and offline-first architectures place the authoritative copy of data on the user’s own device — syncing peer-to-peer or through stateless relays rather than a cloud database that owns the truth[14]; conflict-free replicated data types (CRDTs) have made multi-device convergence a solved primitive[15]; and data-sovereignty regulation pushes the authoritative record toward the edge, not the centre[16]. The assurance frameworks that govern financial reporting — SOX/PCAOB, COSO, ISO/IEC 27001 — were written for the opposite world: a single locked database behind a corporate firewall.
The claim — objectives endure, the approach must adapt. This is not an argument to weaken control. The control objectives do not change — completeness, existence/occurrence, authorisation, segregation of duties, retention. What must change is the audit approach and control-implementation guidance: where each objective is satisfied, and how it is tested, when no server owns the record. The profession has already taken the first step — the PCAOB holds that on-chain proof is “not sufficient appropriate audit evidence”[7], and COSO frames blockchain risk inside the unchanged 2013 framework[5]. Below is a control-objective framework to apply: per objective, where cryptographic assurance is strengthened, where the control relocates and must be designed, where it stays open, and where the limit is invariant to any ledger. It is a control map, not a certification.
Strengthened — trusted-custodian → independently verifiable·Relocated — objective intact, control moves layer·Open — compensating control required·Invariant — no ledger removes it
1 The shift is the locus of trust, not the control objective
Traditional internal control over financial reporting (ICFR) locates assurance in a central server of record: a database whose integrity is trusted because privileged access, change management, and backup are controlled (the IT general controls, ITGC, tested under PCAOB AS 2201[3]). Remove that server and the control objectives are unchanged — completeness, existence/occurrence, authorisation, segregation of duties, retention — but the mechanism of assurance moves. Integrity is no longer asserted by a custodian; it is verifiable by any party against a signed, hash-chained log (the same tamper-evidence primitive as RFC 6962 Certificate Transparency[11] and RFC 3161 trusted timestamping[12]). In exchange, a new crown-jewel risk appears — signing-key custody (NIST SP 800-57[10]) — and a new completeness question — proving that every device’s shard has reported. This paper is that trade, made explicit, objective by objective.
2 Control-objective map — central server vs. local-first hash-chain
Control objective
Central server-of-record — assured by
Local-first hash-chain — assured by / relocated to
State
Record integritySOX §802; ISO A.8.15
Trust in DBA / privileged-access & change-management ITGC over the database
Signed SHA-256 hash chain; any post-hoc alteration breaks the chain and is detectable by any verifier — trust becomes verification
▲ Strengthened
Audit trail & loggingISO A.8.15; AS 2201
Application/DB audit logs — a side-artefact that can be disabled or diverge from the data
The signed op-log is the system of record; there is no separate log to disable — the trail and the data are one object
▲ Strengthened
Re-performanceAS 2201 evidence
Auditor re-computes on a sample; full re-computation is cost-prohibitive against a live server
Financial statements re-derive deterministically from the log — 100% re-performance, not a sample, at near-zero cost
▲ Strengthened
Access control / authorisationSOX §404; ISO A.5,A.8
Server-enforced role-based access control (RBAC) against a central identity store
No server to enforce RBAC; authorisation must be enforced at the op-gate and by key possession — present but relocated to client + key custody
◆ Relocated
Non-repudiation / identityISO A.8; eIDAS
Server-side authenticated session bound to a directory identity
A signature binds a key, not a person; requires key→identity binding, lifecycle and revocation (a PKI / KYC discipline)
◆ Relocated
Records retention & availabilitySOX §802; ISO A.8.13
Centrally-administered backup and 7-year retention
A ledger on an edge device needs an explicit retention-relay / replica policy to meet retention and availability — a designed control, not a default
◆ Relocated
Completeness (across the estate)Assertion: completeness
One database holds all rows; completeness is structural
State is sharded across devices; completeness requires proving all shards reported (quorum / attestation). See §4 evidence — a silent-loss defect was found and closed; cross-shard action attribution remains open
● Open
Segregation of duties (SoD)SOX §404; COSO CA
Server enforces that originator ≠ approver ≠ settler by role
A single device + single key can originate, approve and settle; SoD is not inherent — it must be imposed by multi-party / quorum signing on high-risk op-classes (a designed compensating control)
● Open
Validity / occurrence of the entryAssertion; PCAOB
Not solved by the server either — requires substantive audit procedures
Not solved by the chain. A signed false entry is notarised as faithfully as a true one — integrity ≠ veracity. Substantive procedures still required[5][7]
An inherent limitation of internal control (COSO)[4]
Unchanged — collusion and override survive any cryptographic ledger
■ Invariant
3 The map read through COSO’s five components[4][5]
▲ Strengthened — Control Activities · Information & Communication
What the cryptography earns
Assurance that previously rested on trusting a custodian becomes independently verifiable.
Integrity & audit trail unified — the hash-chained op-log is simultaneously the data and its tamper-evident trail; there is no separable log to disable or backdate. ISO/IEC 27001:2022 A.8.15 · SOX §802 [8][1]
Total, not sampled, re-performance — because reported state is a deterministic fold of the log, an auditor can re-derive the financial statements in full rather than test a sample — a qualitative change in evidence sufficiency under AS 2201. PCAOB AS 2201 [3]
Trust → verification — the same tamper-evidence lineage as Certificate Transparency (Merkle proofs) and RFC 3161 timestamping; a third party verifies the math, it is not asserted by the preparer. RFC 6962 · RFC 3161 [11][12]
◆ Relocated — Control Environment · Risk Assessment
Controls that must be designed, not inherited
The objective is untouched; removing the server moves the control to a new layer.
Authorisation → op-gate + key custody — with no server RBAC, authorisation is enforced client-side at the write gate and by key possession; key management becomes a primary control (the ISACA control area). ISACA Blockchain Framework · NIST SP 800-57 [9][10]
Identity binding — signatures must bind to real, revocable identities (PKI / KYC), or non-repudiation is nominal. ISO/IEC 27001:2022 A.5, A.8 [8]
Retention & availability → replica policy — a designed retention-relay replaces central backup for §802 retention and availability. SOX §802 · ISO A.8.13 [1][8]
● Open — Control Activities · Monitoring
Objectives not yet met — disclosed, not resolved
Named honestly; each requires a compensating control before reliance.
Segregation of duties — a single key-holder can originate, approve and settle. Compensating control: multi-party / quorum signing on high-value op-classes (designed, not yet enforced by default). SOX §404 · COSO Control Activities [1][4]
Completeness across the estate — assurance that every device’s shard is present requires quorum attestation; a withheld shard is a completeness risk. Assertion: completeness
Cross-device action attribution — per-step, per-person attribution of workflow actions across devices is not yet cryptographically preserved on merge (see §4). Non-repudiation of approvals
■ Invariant — the profession’s own boundary
What no ledger design removes
These are limits of internal control itself, not gaps to engineer away.
Validity / occurrence (“garbage-in”) — a chain proves a record was not altered, never that it was true when made. On-chain proof is “not sufficient appropriate audit evidence.” PCAOB Crypto Spotlight · COSO [7][5]
Management override & collusion — a named inherent limitation of internal control under COSO. COSO 2013 [4]
Professional judgment & materiality — the auditor’s judgment does not move onto the chain. AICPA/CPA Canada [6]
4 Empirical grounding — the “Open” column is evidenced, not asserted
The credibility of a control map rests on disclosing its failures. Two are material and are stated with their test evidence:
Completeness — a silent-loss defect, found and closed. Concurrent edits on the same record could be lost at the storage layer while the interface reported success — a completeness failure. It was reproduced (two writers → 50% loss; ten writers → 90% loss), root-caused, and closed by an append-only op-store with a cross-writer commit lock. Re-tested: 10 of 10 concurrent edits survive, hash-chain intact (witness W-OPLOG-APPEND). This is offered as evidence that the architecture’s completeness assertion is tested, and that failures are disclosed and remediated rather than assumed away.
Cross-device attribution — open, and stated as open. When two devices’ logs merge, field edits converge to one identical signed history (witness W-N-CONVERGE: 10 devices → one signed tip, 0 lost), but multi-step document actions (Complete / Void / Close) are re-signed under the merging device’s key — per-person attribution of those approval steps across devices is not yet preserved. The compensating direction is opt-in per-step signing. Until wired, cross-device approval trails are a disclosed control gap.
5 What changes for the auditor
The engagement re-weights rather than disappears. ITGC testing shifts from privileged-access / change-management / backup over a central database to three concerns: (i) verification of the chain and the deterministic fold — cheaper and now total rather than sampled (AS 2201 evidence[3]); (ii) key-management controls — custody, rotation, revocation, and quorum policy become the crown-jewel ITGC (NIST SP 800-57[10]; ISACA key-management control area[9]); and (iii) completeness-of-estate — attestation that all shards reported. Substantive procedures over validity/occurrence are unchanged: the chain notarises, it does not adjudicate. This is consistent with the PCAOB’s stance that DLT can raise evidence reliability for what it records while leaving sufficiency for the entry’s validity to substantive work[7], and with COSO’s treatment of blockchain risk within the unchanged 2013 framework[5].
Scope & disclaimer. This is a control-mapping position paper for a professional assurance audience. It is not legal, audit, or compliance advice, not an assertion that the described system is SOX-, SOC-, or ISO-certified, and not a substitute for an independent examination (e.g. SSAE 18 / SOC 2[2]). Control objectives are cited from the frameworks named; their application here is the authors’ analysis. Open items in §3–§4 are disclosed limitations, not resolved claims.
References
Sarbanes–Oxley Act of 2002, Pub. L. 107-204 — §302 (corporate responsibility for financial reports), §404 (management assessment of internal control over financial reporting), §802 (retention of records; criminal penalties for altering documents), §906.
PCAOB Auditing Standard AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with an Audit of Financial Statements (formerly Auditing Standard No. 5).
COSO, Internal Control — Integrated Framework (2013) — five components (Control Environment, Risk Assessment, Control Activities, Information & Communication, Monitoring Activities) and 17 principles; management override cited as an inherent limitation of internal control.
COSO, Blockchain and Internal Control: The COSO Perspective (2020), sponsored by Deloitte & Touche LLP (Burns, Steele, Cohen, Ramamoorti) — applying the 2013 framework to blockchain-related financial-reporting risk.
CPA Canada & AICPA, Blockchain Technology and Its Potential Impact on the Audit and Assurance Profession (2017).
PCAOB, Audit Considerations Related to Crypto Assets — Staff Spotlight (June 2023); and PCAOB staff guidance, Insights for Auditors Evaluating the Relevance and Reliability of Audit Evidence Obtained from External Sources.
ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements; Annex A controls, incl. A.8.15 (logging), A.8.13 (information backup), A.5/A.8 families. See also ISO/IEC 27002:2022 for control guidance.
ISACA, Blockchain Framework and Guidance and the Blockchain Framework Audit Program — control areas: governance, infrastructure, data management, key management, and smart contracts.
NIST, Special Publication 800-57, Recommendation for Key Management.
IETF RFC 6962, Certificate Transparency — Merkle-tree, append-only tamper-evident log (prior art for verifiable-log assurance).
ISO/TC 307, Blockchain and distributed ledger technologies — ISO 22739 (vocabulary) and ISO 23257:2022 (reference architecture).
M. Kleppmann, A. Wiggins, P. van Hardenberg, M. McGranaghan, Local-First Software: You Own Your Data, in Spite of the Cloud, Ink & Switch (2019).
M. Shapiro, N. Preguiça, C. Baquero, M. Zawirski, Conflict-Free Replicated Data Types, INRIA / SSS 2011 — convergent multi-replica state without a central coordinator.
Regulation (EU) 2016/679 (GDPR) and comparable data-sovereignty / data-residency regimes — pressure toward edge-resident authoritative records.