Tamper-evident records auditors can verify offline.
Every major regulatory framework (SOX §404 internal controls, HIPAA §164.312(c) integrity, GDPR Article 32 'integrity and confidentiality,' FINRA 17a-4 non-rewriteable storage, MiFID II Article 16(7) recordkeeping) requires you to demonstrate that records have not been altered since acquisition. receipts.you stamps each record with an ECDSA P-256 signature and an externally-anchored OpenTimestamps proof — both verifiable by an auditor without any access to your infrastructure.
Workflows compliance actually run
- 01
Required disclosure capture.
A regulated process requires you to display a disclosure to a customer at a specific moment. Screenshot the disclosure-as-shown, seal it. The receipt's timestamp predates any subsequent customer dispute — and is independently verifiable. The regulator's audit becomes 'check the published key against the receipt' rather than 'trust your internal log.'
- 02
Internal control evidence (SOX §404).
Quarterly screenshots of control attestations, system configurations, segregation-of-duties matrices — all sealed at capture. Three years later, when the external auditor asks 'how do you know this control was in place on March 14th?', you produce the file + the receipt + the OpenTimestamps proof. The auditor verifies via openssl + the ots CLI. No trust required.
- 03
HIPAA / GDPR data access logs.
Screenshots of admin actions, PHI access events, consent screens — sealed. The integrity property required by HIPAA §164.312(c)(1) and GDPR Article 32(1)(b) is satisfied at the cryptographic primitive level. The image bytes never leave your environment (only the 32-byte hash is sent to us), so PHI / personal data exposure is structurally zero on our side.
- 04
Defense against retroactive log manipulation.
An insider tries to alter a system log after the fact to cover a breach. Without sealed receipts, the alteration is hard to prove. With sealed receipts: the original log screenshot has a receipt timestamp that predates the alteration; the altered log doesn't match. Cryptographically clean, no forensic dispute.
What it maps to in your world
- SOX §404 (internal controls over financial reporting): cryptographic hash + external timestamp is a defensible 'reliable evidence' standard.
- HIPAA §164.312(c)(1) Integrity: SHA-256 is the recommended integrity primitive in the underlying NIST SP 800-66 guidance.
- GDPR Article 32(1)(b) — 'integrity and confidentiality of processing': receipts.you provides the integrity guarantee; the image-bytes-never-leave-browser design provides the confidentiality.
- FINRA Rule 17a-4(f) non-rewriteable, non-erasable storage: sealed receipts are immutable by construction (signature + external anchor); deletion is impossible to do silently.
- MiFID II Article 16(7) recordkeeping (5 years, accessible, complete, tamper-evident): satisfied by the OpenTimestamps anchor that remains verifiable forever.
- ISO 27037 (digital evidence) + ISO 27001 (information security management) integration: the receipt is the digital-evidence-acquisition step's output, audit-trail-ready.
Questions this page answers
- “SOX 404 evidence retention cryptographic”
- “HIPAA integrity controls record hash”
- “GDPR Article 32 integrity record”
- “FINRA 17a-4 WORM tamper evident”
- “MiFID II Article 16 recordkeeping”
- “audit log cryptographic signature”
- “external timestamp regulatory compliance”
- “ISO 27037 compliance evidence”
- “non-repudiation document signing”
- “tamper evident screenshot compliance”
Specific answers
How does this satisfy 'non-rewriteable' storage requirements like FINRA 17a-4?
The receipt's signature cryptographically binds the timestamp to the hash. Altering the record breaks the signature — verification fails immediately. The OpenTimestamps anchor is in a public blockchain that cannot be retroactively edited even by us. So the record is non-rewriteable by mathematical construction, not just by access control.
Can the cryptography survive a 5-7 year retention requirement?
Yes. ECDSA P-256 is NIST-approved through at least 2030. OpenTimestamps proofs are verifiable indefinitely as long as the anchor blockchain (currently Bitcoin) exists. Our key may rotate, but historical receipts continue to verify against the kid in their envelope via the JWKS-shaped index at /.well-known/receipts-keys.json — historical keys remain addressable forever.
What if your service shuts down?
Sealed receipts remain independently verifiable. The OpenTimestamps proof verifies against blockchain headers using the open-source ots CLI. The signature verifies against the published public PEM using openssl. The full verification chain works offline, with no dependency on us continuing to operate.
Can we run this on-premise for sensitive workloads?
An on-premise build is in development for regulated workloads where the 'image bytes never reach Cloudflare' guarantee isn't sufficient (some PHI / classified workflows). Email [email protected] with your compliance bar — we can scope a self-hosted version.
How do we integrate with our SIEM / GRC tool?
REST API with bearer auth + webhook callback on verification events is available. Designed to drop into Splunk / ServiceNow GRC / Archer / OneTrust workflows. Email [email protected] for the API documentation.
Is the source code auditable?
Yes. All client + server code is published. The signing key is private. Read the methodology, run the test rig at /lab, confirm the claims against your compliance bar before adoption.
Records auditors can verify without trusting you.
Cryptographic integrity, external timestamp anchoring, image bytes never leave your browser. The audit trail is mathematics, not promises.