The certificate is on the wall. SOC 2 Type II — clean opinion. ISO/IEC 27001:2022 — surveillance audit passed. The CISO has spent two years tightening identity, hardening endpoints, segmenting the network, and rolling out an e-signature platform that captures a notarised audit trail for every contract.
Then a customer's procurement team forwards an "executed MSA" with a different fee schedule than the one the CISO's company sent. The signatures look right. The audit trail in the e-signature platform shows the document was signed by the correct counterparties on the correct date. But the PDF in the customer's hand is not the PDF that left the e-signature vault.
Somewhere between signed and received, the document was modified. Nothing in the SOC 2 report or the ISO 27001 Statement of Applicability obliges the CISO to detect that modification. Nothing in the e-signature platform's audit trail surfaces it either, because the audit trail lives behind a login the customer will never visit.
This is the document-trust gap. It sits in the seam between the security framework's view of information at rest in your systems and the real world's view of a document moving through someone else's inbox, file share, and printer queue. This guide walks through where SOC 2 and ISO 27001 already speak to that gap, where they stop short, and how verifiable authenticity — hash-bound proof pages reachable from the document itself — extends the controls you have already built.
What "document trust" actually means in a controls vocabulary
Strip away the marketing layer and document trust decomposes into four properties an auditor can evaluate:
Authenticity. The document was issued by the party it claims to be issued by. This is the property forged invoices and impersonated supplier letters violate.
Integrity. The document has not been altered since issuance. This is the property modified contracts, edited bank statements, and tampered lab results violate.
Non-repudiation. The issuing party cannot credibly deny having issued the document. This is what e-signature platforms are designed to deliver for the signing event.
Verifiability. Any holder of the document — including parties who have no relationship with the issuing organisation and no access to its systems — can confirm the first three properties without taking the issuer's word for it.
Most security programs deliver authenticity and non-repudiation reasonably well inside the perimeter. They struggle with integrity once a document leaves the system of record, and they almost universally fail at verifiability. The frameworks acknowledge this. The implementations rarely do.
How SOC 2 frames document-related controls
SOC 2 reports against the AICPA's Trust Services Criteria. Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are scoped in based on customer commitments. Document handling shows up in several places:
CC6.1 — Logical access. Most CISOs think of this as "who can open the file." Auditors increasingly press on what happens after access is granted — including whether downstream copies inherit the access intent or escape it entirely.
CC6.7 — Transmission and disposal of information. This is the criterion under which encryption-in-transit and secure deletion live. It also covers the mechanisms an organisation uses to protect information being transmitted to external parties — which is where most document-integrity gaps surface. TLS to the recipient's mail server protects the bytes in flight; nothing about TLS protects the document the recipient downloads, edits, and forwards.
CC7.1 / CC7.2 — System monitoring and anomaly detection. Auditors expect monitoring for unauthorised changes to systems and data. For documents, this is typically scoped to documents inside the organisation's systems — DLP catches files leaving, file integrity monitoring watches the document repository. Once the document is delivered, the monitoring stops.
CC8.1 — Change management. Strong CISOs apply change management to code, infrastructure, and configurations. Few apply it to issued documents — yet a "v1.2" of a customer-facing certificate, with no link between the old and new versions and no way for a holder of v1.0 to discover v1.2 exists, is exactly the kind of uncontrolled change CC8.1 is designed to prevent.
PI1.4 / PI1.5 — Processing Integrity, output completeness and protection. These criteria, when in scope, explicitly cover the integrity of outputs delivered to users. A document is an output. PI1.5's language about output protection from "alteration, loss, [and] destruction" maps directly to the integrity property described above — and is the criterion most often misread as being satisfied by encryption alone.
Common thread. SOC 2 contains the language to require document integrity end-to-end. Most reports stop at the system boundary because that is where the auditor's evidence stops. Extending the evidence — by giving the document itself a verifiable proof — extends the controls.
How ISO/IEC 27001:2022 frames the same territory
ISO/IEC 27001:2022 restructured Annex A into four control themes (Organizational, People, Physical, Technological) and 93 controls. Several speak directly to document trust:
A.5.14 — Information transfer. The control objective covers transfer of information within the organisation and to external parties. The implementation guidance specifically calls out protection against interception, copying, modification, mis-routing, and destruction. "Modification" is the document-integrity case in plain language.
A.5.33 — Protection of records. Records (as distinct from information generally) are the documents the organisation must demonstrate authenticity, integrity, and retrievability for over time — contracts, certificates, regulatory submissions, financial records. This control most directly maps to the verifiable-authenticity use case.
A.5.34 — Privacy and PII. Where issued documents contain personal data (most do), A.5.34 layers privacy obligations on top of the integrity obligations.
A.8.10 — Information deletion. Often read narrowly as "secure deletion of files at end of life." A wider read covers revocation: when a document should no longer be considered valid, holders need a way to discover that. A revoked certificate that still verifies as authentic is a deletion-control failure.
A.8.12 — Data leakage prevention. DLP catches documents leaving. It does not catch documents changing once they have left.
A.8.24 — Use of cryptography. This is the control under which document hashing, digital signatures, and certificate-based identity sit. A.8.24 requires a policy on cryptographic use; it does not by itself require which documents must be cryptographically bound. Mature programs make that scoping decision deliberately and document it in the Statement of Applicability.
A.8.25 / A.8.28 — Secure development and secure coding. Where the organisation builds the systems that issue documents, these controls govern how cryptographic operations are implemented and tested.
The 2022 revision moved cryptography, records protection, and information transfer closer together precisely because the working group recognised that document integrity is a cross-cutting concern, not a niche application of cryptography.
Where e-signature is sufficient and where it isn't
E-signature platforms are excellent at one thing: capturing legally binding intent at the moment of signing, with sufficient audit trail to satisfy ESIGN/UETA in the United States and eIDAS in the EU. That covers a real and important slice of the document-trust problem.
What e-signature does well:
Authenticates signers via email, SMS, or knowledge-based authentication.
Captures consent to electronic signing under ESIGN/UETA.
Produces a tamper-evident audit trail of the signing event.
Stores the signed document in a controlled vault.
Supports advanced and qualified electronic signatures under eIDAS where higher assurance is required.
What e-signature does not do, by design:
Verify the authenticity of the document after it leaves the vault. The audit trail lives behind the platform's login; recipients rarely return to it.
Prove integrity of a copy received via email or downloaded and forwarded. The PDF in the recipient's inbox can be re-saved, edited, and re-sent with no signal to a downstream party that this happened.
Provide a verifier-side experience for parties who never had a relationship with the e-signature platform. A bank receiving a signed lease has no account on the e-sig platform and no incentive to create one to verify a single document.
Support documents that are issued rather than signed — diplomas, lab results, permits, certificates of insurance, audit reports. These have no second party to sign; they need a different trust model.
The honest framing for a CISO: e-signature satisfies CC6.x and parts of CC7.x for documents that are transactional and bilateral. It does not satisfy A.5.33 or PI1.5 for documents that are issued and circulated. Treating the two as the same control gives auditors a false sense of coverage and gives downstream recipients no defence against tampering.
How verifiable authenticity closes the gap
Verifiable authenticity — the model behind hosted proof pages and QR-bound certificates — adds three primitives to the document itself:
A cryptographic hash of the issued document, computed at issuance and stored on the issuing organisation's verification service.
A unique identifier embedded in the document, typically as a QR code linked to a stable URL. The URL resolves to a hosted proof page on a domain controlled by the issuer.
A proof page that displays the document's metadata (issuer, issuance date, current status, optional fields), shows the original document, and confirms — for any visitor — that the hash on file matches the document being held.
A holder verifies the document by scanning the QR code or visiting the URL. No login. No account on the issuer's platform. No need to call and ask. The verification is decoupled from the holder's relationship with the issuer, which is the property that makes verifiability work at scale.
Mapped back to the control frameworks:
ControlDocument-trust requirementWhere verifiable authenticity helpsSOC 2 CC6.7Protect information transmitted to external partiesDocument carries its own integrity proof; transmission channel no longer the only safeguardSOC 2 CC7.1/7.2Detect anomalies in data and systemsEach verification attempt produces a log entry; tampering attempts surface as hash mismatchesSOC 2 CC8.1Change managementReissuance creates a new hash; superseded documents are explicitly marked revoked or replacedSOC 2 PI1.5Protect outputs from alterationHash binding makes alteration detectable by any holderISO 27001 A.5.14Protect information in transfer from modificationSame — modification is detectable post-transferISO 27001 A.5.33Protect records' authenticity, integrity, reliabilityDirect mapping; this is the canonical use caseISO 27001 A.8.10Information deletion / revocationProof page status flips to revoked; future verifications surface thisISO 27001 A.8.24Use of cryptographyHashing and signing operations are subject to the cryptographic policy
None of this replaces the existing controls. It extends them past the boundary of the issuing system, to the document itself, in a form recipients can act on.
The audit evidence package
When verifiable authenticity is in scope for an audit, an auditor will typically ask for:
The cryptographic policy that governs hash algorithm selection, key lifecycle, and rotation cadence (A.8.24, CC6.1).
Issuance logs showing every document hashed, with timestamp, issuer identity, and document identifier (A.5.33, CC7.1).
Verification logs showing every proof-page lookup, with timestamp and outcome (CC7.2).
Revocation procedures and evidence that they have been exercised (A.8.10, CC8.1).
The hosted-proof-page domain's TLS certificate, DNS configuration, and access controls — the proof page itself is now a security asset (CC6.1, A.8.20).
Incident response runbooks for the case where a hash mismatch is reported by a holder (CC7.4, A.5.24).
Vendor security review of any third party operating the verification service (CC9.2, A.5.19/A.5.20/A.5.21).
Most of this evidence already exists for organisations using a managed verification platform. The work is mapping it to the control narrative and including it in the Statement of Applicability.
- Implementation playbook for CISOs
A practical sequence that has worked for organisations in regulated sectors:
Inventory documents by trust profile. Separate documents into transactional/bilateral (where e-signature suffices), issued/circulated (where verifiable authenticity is needed), and internal-only (where existing access controls suffice). Most organisations are surprised by how large the issued/circulated bucket is once they look — invoices, customer certificates, compliance attestations, training records, vendor onboarding documents.
Map the issued/circulated bucket to the framework. For SOC 2, identify which Trust Services Criteria the documents fall under (PI1.x is often newly in scope). For ISO 27001, identify whether A.5.33 currently has an "applicable" justification and whether the existing implementation is honest.
Pilot on the highest-risk document type. Customer-facing compliance certificates are a common starting point because the failure mode (counterfeit certificate used to win a contract) is concrete and the volume is manageable.
Bind verifiable authenticity into existing issuance workflows. The integration point is wherever the document PDF is finalised — contract management system, ERP, LIMS, internal portal. The hash should be computed once, at the moment of issuance, and the QR code embedded before the document is delivered.
Update the Statement of Applicability and the SOC 2 system description. Document the new control, the evidence sources, and the testing approach. Coordinate with the audit firm before the next interim or surveillance window so the change is scoped properly rather than as a finding.
Publish a verification page on the trust centre. A short page explaining how recipients verify documents — with screenshots and a sample document — reduces inbound support load and signals to security-buyer counterparts that the organisation takes document trust seriously.
- What to put in the SOC 2 system description
A defensible system description for verifiable authenticity reads roughly:
"The Service Organization issues [documents] to [parties] using a verifiable authenticity service. At the point of issuance, a SHA-256 cryptographic hash of the finalised document is computed and stored, together with issuance metadata, in the verification database. A QR code containing a unique identifier is embedded into the document; the QR code resolves to a hosted proof page operated by the Service Organization. Any holder of the document may verify its authenticity and current status by scanning the QR code or visiting the proof URL. Verification events, revocation events, and reissuance events are logged. The cryptographic policy, key management, and hash algorithm are subject to control A.8.24 of the Service Organization's ISO 27001 Statement of Applicability."
This language is concrete enough for the auditor and abstract enough not to bind the organisation to a single vendor.
Frequently asked questions
Does verifiable authenticity replace e-signature? No. They solve different problems. E-signature captures consent and intent at the signing event. Verifiable authenticity protects the document's integrity and authenticity afterward. Most mature programs use both.
Does this need to be in scope for SOC 2? Only if the documents in question are in scope for the audit and the relevant criteria (typically CC6, CC7, CC8, and PI1 if elected). For organisations whose customers rely on issued documents, scoping it in is usually the right call — but coordinate with the auditor first.
What hash algorithm should we use? SHA-256 is the current safe default. SHA-3 is also acceptable. Avoid SHA-1 and MD5; both have practical collision attacks. The cryptographic policy under A.8.24 should record the choice and the planned migration path.
How does this interact with eIDAS qualified electronic signatures? Verifiable authenticity is complementary. A QES proves who signed; the proof page proves the document the recipient holds matches what was signed. EU regulators have not opposed the combination; some sectoral guidance (e.g., for issued credentials under EUDI Wallet pilots) explicitly anticipates it.
What if our documents contain personal data — does GDPR cover the proof page? Yes. The proof page is a processing activity. The lawful basis is usually contract or legitimate interest; the data minimisation principle means proof pages should display the minimum metadata required for verification, with the underlying document accessible to authenticated parties only where necessary. A.5.34 (Privacy/PII) of ISO 27001:2022 covers this.
Who owns this control? Security or legal? Security operates it; legal scopes it. The cryptographic operations and the audit evidence are security's. The decision about which documents must be verifiable, and what verification represents legally, is legal's. Both should sign the SoA entry.
What happens if our verification provider goes out of business? This is a continuity-of-operations question (A.5.30 / CC9.2). Acceptable answers include: an open-standards data export (so hashes and metadata can be migrated), an escrow arrangement for the verification database, or a contractually guaranteed transition window. Insist on at least one before signing.
The control story, told end to end
A CISO who has built a strong SOC 2 and ISO 27001 program has already invested in identity, encryption, monitoring, change management, and secure development. Verifiable authenticity is not a new framework or a competing standard. It is the missing extension that lets those existing controls speak about a document after it has left the perimeter — to a customer, a regulator, a partner, or an auditor's auditor — without requiring any of those parties to log into a system they don't have access to.
The frameworks have always asked for output integrity and records protection. The implementation has historically stopped at the system boundary because that was the only place where evidence existed. Hash-bound proof pages move the evidence boundary out to the document itself. That is the change worth making, and it is the change worth telling your auditor about before they find it on their own.
