Hash-only
Docseal stores the sealed hash, issuer metadata, status and receipt metadata. Sensitive document content can remain outside Docseal.
Security & Trust for regulated document flows.
Docseal is designed for pilot-first evaluation by institutions that need to verify official documents without unnecessarily exposing sensitive content.
Data handling modes
The issuer decides how much document information is exposed to Docseal and to third-party verifiers.
Restricted-visible reference
Reference data can be shown only under issuer-defined rules, for example to authorized verifiers or controlled workflows.
Visible reference
For lower-sensitivity documents, the reference document or selected metadata can be visible on the verification page.
Hash-only data flow
In hash-only mode, Docseal does not need to store or read the document content. Verification is performed by comparing file hashes.
Issuer system
The official document is produced by the issuer.
Local hash
The file hash is computed before or during sealing.
Docseal Registry
Docseal records Seal ID, hash, issuer, status and visibility policy.
Verifier hashes file
The received file is uploaded or hashed locally.
Hash comparison
The received hash is compared with the sealed reference hash.
Result
The verifier receives Authentic, Tampered, Revoked, Replaced, Expired or Unknown.
Pilot controls
Access policy
Define who can issue, revoke, replace and verify records during the pilot.
Audit trail
Define what events are logged and what proof records are exportable.
Data retention
Define retention for metadata, receipts and verification events.
Incident contact
Define support windows, incident escalation and pilot owner responsibilities.
Production review topics
DPA / GDPR review
Define roles, data categories, retention and processing scope before regulated production.
DORA-aligned ICT review
Prepare ICT risk, resilience, third-party and operational continuity topics for financial institutions.
SLA and support
Define availability, response times, maintenance windows and escalation model.
Reversibility
Define receipt export, evidence export, fallback verification and offboarding requirements.
Security testing
Production scope can include SDLC review, penetration test planning and vulnerability handling.
Hosting and locality
Define hosting region, network boundaries and local hashing or gateway requirements.
Security, privacy and operational FAQ
Does Docseal store document content?
Not necessarily. In hash-only mode, Docseal stores the hash and metadata needed for verification, while the document content remains outside Docseal.
Can verification happen without exposing the file to Docseal?
Yes. A pilot can be scoped around local hashing or gateway workflows so the verification compares hashes without storing sensitive content.
What happens if Docseal is unavailable?
Production scope should define fallback, receipt export, evidence export and reversibility. These points should be included before regulated deployment.
Is Docseal a qualified trust service or electronic signature?
No. Docseal is a document authenticity and file-integrity verification layer. It can coexist with electronic signatures and qualified trust services.
What data is stored in hash-only mode?
Typically Seal ID, issuer metadata, document type, registry status, file hash, receipt metadata and verification metadata.
Is a DPA available?
A DPA and privacy pack should be prepared for regulated pilots or production deployments. Hash-only mode helps minimize data exposure.
What SLA is available?
SLA commitments are defined at production scope. A pilot should define availability expectations, support windows and escalation contacts.
Can the issuer revoke or replace a document?
Yes. Registry status can represent valid, revoked, replaced, expired or other issuer-defined states.
For banking teams
Evaluate Docseal on one high-risk banking document flow: statements, proof of funds, bank certificates or mortgage-file verification.
A banking pilot can start with one issuer, one document type and controlled authentic / tampered scenarios.Prepare a controlled security review.
A bank-grade pilot should define data handling mode, evidence export, reversibility, support, incident escalation and production review requirements before launch.
Post-quantum readiness and crypto-agility
The current DocSeal demo profile uses a classical document-integrity proof model. For banking and long-retention deployments, DocSeal is designed to support a crypto-agile evidence model that can be extended with a hybrid post-quantum signature layer.
Current demo profileClassical document integrity
Hash profileSHA-256
Post-quantum statusCrypto-agile ready
Hybrid target profileClassical + ML-DSA
Migration approachSecondary signature layer
Long-term validationPeriodic resealing supported
DocSeal does not claim that this demo profile is post-quantum protected end-to-end. The current claim is crypto-agility: the proof architecture can be extended toward a hybrid signature profile without changing the document workflow.