Audit Logs Are Not Evidence
TL;DR: If your evidence lives in the same database as the system it's supposed to audit, it's not evidence. It's a story. Real evidence is ECDSA-signed, hash-chained, stored on infrastructure you control, and verifiable offline without trusting the vendor. SidantiX produces a signed receipt for every governance decision — grant, certify, revoke, deny — and ships it to your S3 bucket with your KMS keys.
The audit log illusion
I spent years building identity governance products. Every one of them had an "audit trail" feature. Every sales deck said "complete audit trail." Every RFP response checked the box.
Here is what that audit trail actually is: rows in a database table. Usually the same database that runs the application. Managed by the same admins who manage the application. Protected by the same credentials that protect the application.
An admin with database access can UPDATE a timestamp. Can DELETE a row. Can INSERT a backdated approval that never happened. The application logs will show nothing, because the change happened below the application layer.
This is not a theoretical concern. In SOX audits, I have watched auditors accept application-generated reports as evidence of control effectiveness — reports generated by the system being audited, from data stored in the system being audited, accessed through credentials managed by the system being audited. The circularity is total.
When a breach investigation requires proving what actually happened — not what the logs say happened — this architecture falls apart. The logs are assertions, not evidence. They are the defendant's testimony, not the forensic record.
What real evidence looks like
Evidence has four properties that audit logs lack:
- Tamper-evidence. You can detect if someone changed it after the fact.
- Non-repudiation. The system that produced it cannot deny producing it.
- Independence. It does not live in the system it describes.
- Offline verifiability. You can verify it without trusting the vendor, without network access, without a license.
In SidantiX, every governance decision — every grant, every certification, every revocation, every denial — produces a signed receipt. Here is what happens at the moment of decision:
- The decision payload is serialized to canonical JSON (RFC 8785). This includes the actor, the target, the action, the policy that matched, the timestamp, and the decision outcome.
- The payload is signed with ECDSA P-256 using a key that the application holds in memory, loaded from your HSM or KMS at startup. The signing key never touches disk in plaintext.
- The signed receipt is hash-chained to the previous receipt using SHA-256. Each receipt includes the hash of its predecessor, creating a tamper-evident sequence. Insert a record, delete a record, or modify a record, and the chain breaks.
- The receipt is packaged into an evidence pack — a self-contained ZIP containing the signed receipt, the public key needed to verify it, the chain-verification metadata, and a standalone verifier binary (no dependencies, no license, runs on any Linux/macOS/Windows machine).
- The evidence pack is written to your S3 bucket, encrypted with your KMS key. Not our bucket. Not our key. Your infrastructure, your access controls, your retention policy.
The result: a forensic record that your auditor can download, air-gap, and verify with a single command. No vendor login. No API call. No trust relationship.
Why this matters for SOX and regulatory compliance
SOX Section 404 requires management to assess the effectiveness of internal controls over financial reporting. Access controls are internal controls. Every access certification, every role assignment, every privileged access grant is a control activity that auditors evaluate.
When an auditor asks "prove that this access review was completed by the deadline," the standard IGA answer is: here is a screenshot from our application. Or: here is a CSV export from our database.
A signed receipt answers the same question differently: here is a cryptographic proof that this decision was made at this time by this person under this policy, and you can verify it yourself without trusting us.
The difference is not academic. PCAOB inspections increasingly scrutinize the reliability of audit evidence. An assertion from the system under audit is weaker evidence than an independently verifiable cryptographic proof stored on infrastructure the auditor can inspect directly.
For HIPAA, the logic is identical: access to PHI must be logged and auditable. For GDPR Article 30, processing records must be accurate and demonstrable. For the EU AI Act, high-risk AI system decisions must be traceable. In every case, "we have logs" is weaker than "we have signed, hash-chained, independently verifiable proof."
Why this matters for cyber insurance
Cyber insurance carriers are getting specific about what they want to see. After a breach, the claims process requires proving the state of controls at the time of the incident — not now, but then.
If your evidence is database records that an attacker with admin credentials could have modified during the breach window, the carrier's forensic team will question it. Reasonably. The same credentials that were compromised in the breach are the credentials that protect the audit trail that's supposed to prove the controls were in place.
Hash-chained, signed receipts stored on separate infrastructure with separate credentials break that circularity. The evidence is either intact and verifiable, or the chain is broken and you know exactly where. There is no ambiguity. There is no "we think the logs are accurate." The math either checks or it doesn't.
Several carriers we've spoken with have indicated that cryptographic evidence of control state would materially strengthen a claim. One told us directly: "We want to see proof that doesn't depend on the system that got breached."
What to ask your current IGA vendor
Five questions. The answers will tell you whether you have evidence or a story.
- Where are audit records stored? Same database as the application? Same infrastructure? Same admin credentials?
- Are records signed? With what algorithm? Where is the signing key stored?
- Are records hash-chained? Can I detect if a single record was inserted, modified, or deleted?
- Can I verify records offline, on my own machine, without your software or your API?
- Can I store records on my own infrastructure with my own encryption keys?
If the answer to any of these is "no" — you have audit logs. You do not have evidence.
What SidantiX ships
Every SidantiX deployment produces signed, hash-chained evidence packs for every governance decision. The evidence is stored on your infrastructure. The verifier is a standalone binary you can run offline. The format is documented and open.
This is not a roadmap item. It is shipping in production today. You can download a sample evidence pack and verify it yourself in under sixty seconds.
If you are evaluating IGA platforms and want to see how this works against your compliance requirements, request a scoped proof. We will generate evidence packs against your scenarios, hand you the verifier, and let the math speak.
About the author: SidantiX is founded by an identity governance veteran with over two decades of experience building identity and access governance products at major enterprise software companies. SidantiX delivers autonomous IGA across humans, non-human identities, and AI agents — with cryptographic proof on every decision.