A database log is evidence you control. A Merkle chain is evidence the regulator controls. The difference is the audit defensibility argument.
Every regulator's enforcement playbook begins with the same question: can the company produce evidence that the records of record haven't been altered? For a long time, "we have a database log" was an acceptable answer. After a decade of cases where the company's audit evidence turned out to be self-attested, the standard moved.
The current standard is cryptographic. The audit log is anchored to a Merkle hash chain. The chain root is published to an external timestamp authority. Any modification to any event invalidates the chain — and the invalidation is mathematically detectable by a third party.
That's tamper-evident audit. It's the foundation of every other defensibility argument the regulator will ask for. TeamSync was built on it from day one.
Talk to the security solutions team · See the CISO + Audit Committee page · Read the regulator-by-regulator coverage
What's actually anchored.
Every event in the platform writes to the audit chain at the moment it happens. Not at the end of the day. Not on a batch cycle. Every event, at write time, with the cryptographic hash that becomes part of the chain.
| Event category | What's anchored |
|---|---|
| Document lifecycle | Upload, edit, version, archive, delete |
| Permissions | Grant, revoke, role change, ABAC rule change |
| Identity | Login, MFA, session events, key rotation |
| AI | Retrieval, generation, citation, agent action |
| Signatures | Signature ceremony, witness, validation event |
| Holds and discovery | Hold creation, custodian notification, collection, production |
| Workflow | Step execution, approval, escalation, completion |
| Configuration | Rule change, overlay activation, retention policy update |
A regulator looking at a specific document can ask: what's the complete history of every event involving this document? The answer is a chain segment. The chain segment is verifiable. The verification is independent.
How the chain stays defensible.
The chain's defensibility depends on 2 architectural choices that most platforms don't make.
Continuous external anchoring.
The chain's root hash is published to an external timestamp authority on a continuous cadence. This is what makes the chain third-party verifiable. The timestamp authority's records are independent of TeamSync — a regulator can verify the chain's integrity without depending on TeamSync's attestation.
Per-tenant chain isolation.
Each tenant has its own chain. A regulator examining one customer's chain doesn't see other customers' chain data. The cryptographic isolation is enforced at the platform level, not by application logic.
The result: the audit defensibility argument is structural, not procedural. The CISO doesn't have to defend the audit log's integrity by appealing to operational controls. The math defends it.
What the regulator's verification actually looks like.
The audit committee's question — "can the regulator verify this independently?" — has a concrete answer.
| Step | What happens |
|---|---|
| 1. The regulator's auditor receives a chain segment from TeamSync (or directly from the customer) | A signed, timestamped, third-party-verifiable artifact |
| 2. The auditor's tooling computes the hash of the events | Using standard cryptographic primitives — no proprietary algorithms |
| 3. The tooling compares against the published anchor | A binary outcome — verifies or doesn't |
| 4. If the chain verifies, the audit defensibility is proven | Cryptographically, not procedurally |
| 5. If the chain doesn't verify, the modification is detected | And the modification's location in the chain is identifiable |
The audit defensibility argument moves from "trust our controls" to "verify the math."
The regulators that already accept this.
The cryptographic audit standard isn't theoretical. The regulators below have published guidance accepting it:
- FINRA / SEC Rule 17a-4 — the 2022 audit-trail amendment explicitly accepts cryptographically verified audit evidence as an alternative to WORM media
- FDA 21 CFR Part 11 — accepts cryptographic audit evidence for electronic records and signatures
- DORA — cryptographic audit is contemplated under Article 9 (ICT systems integrity)
- EU AI Act — Article 12 logging requirements are met by cryptographic audit
- Basel III / IV operational risk — cryptographic audit accepted as evidence of control integrity
For the per-regulator detail, see the compliance overlays.
What changes for the security and compliance teams.
| Activity | Before tamper-evident audit | With TeamSync |
|---|---|---|
| Quarterly audit-evidence assembly | Multi-week project | Generated artifact |
| Regulator inquiry response | 14–21 days | Hours |
| Audit-log integrity verification | Manual, periodic | Continuous, API-callable |
| Defending audit defensibility | Procedural argument | Cryptographic proof |
| Cross-overlay evidence reuse | Manual | Native |
Read further.
- CISO + Audit Committee page — the executive conversation
- Why TeamSync — permissions-aware AI — what the chain enables for AI defensibility
- Why TeamSync — defensible eDiscovery — what the chain enables for litigation
- Compliance overlays — the regulator-by-regulator pack
- Audit prep panic — the use case — the conversation in the week before an inspection