E-signature security checklist
A secure e-signature platform needs to protect a document in three distinct ways: while it's being transmitted, while it's sitting in storage, and in the record of what happened to it during signing. This checklist walks through what to actually verify on any platform you're evaluating, rather than taking a generic "we're secure" claim at face value.
Encryption in transit
Every connection between a signer's browser and the platform — opening the document, submitting a signature, downloading a completed file — should be encrypted using a current TLS version. TLS 1.3 is the current standard worth looking for specifically; an older version isn't inherently broken, but a platform still relying only on outdated protocols is a signal worth noticing. See AES-256 and TLS 1.3 explained for document signing for what each of these actually protects.
Encryption at rest
Once a document is stored on the platform's servers, it should be encrypted using a strong standard — AES-256 is the common benchmark across reputable platforms. This matters because a storage breach, however unlikely, shouldn't expose readable document content if encryption at rest is properly implemented.
A tamper-evident audit trail
Beyond encryption, check whether the platform's record of who did what and when is itself tamper-evident — ideally through a hash chain, where each logged event includes a hash of the previous one, making a later edit to the record detectable. A plain, unprotected log is weaker evidence than a chained one. See What an e-signature audit trail contains and How tamper-evident signed PDFs work for the details.
Document integrity verification
The platform should compute and store a cryptographic hash of the final signed document, so any later alteration to the file is detectable by comparing its current hash against the one recorded at signing time.
Independent timestamping
Look for a timestamp conforming to a recognized standard like RFC 3161, which certifies when something happened independent of the platform's own internal clock — this matters more if a signature's timing is ever disputed. See RFC 3161 timestamps explained for how this actually works.
Access control for signers
Each signer should access the document through a unique, individually addressed link rather than a shared one anyone could use — this is what ties a specific signature to a specific identified person rather than to "whoever had the link."
API key and credential handling
If you're integrating via API, check how API keys are generated, stored, and revoked — a key should be hashed on the server side (not stored or retrievable in plain text after creation) and revocable immediately if it's ever exposed. See API keys and authentication for e-signature APIs for what good key handling looks like.
Webhook signature verification
If the platform supports webhooks, check that deliveries are signed (commonly with HMAC) so your own endpoint can verify a payload actually came from the platform rather than from an attacker sending a fake event.
Data handling and privacy posture
Check how the platform describes its role with respect to your documents — ideally acting strictly as a processor of your content, without analyzing, selling, or sharing it with third parties, and encrypting documents such that even the platform's own staff can't casually read them outside of legitimate operational need.
Questions worth asking any vendor directly
Beyond what's published on a security page, it's worth asking a vendor directly about independent audits or certifications relevant to your situation, data retention and deletion practices, and incident response — see Questions to ask an e-signature vendor about security for a fuller list.
Where Esignapi stands on this checklist
Esignapi encrypts documents at rest with AES-256 and all communications in transit with TLS 1.3, computes a document hash and RFC 3161 timestamp for every signature, maintains a hash-chained audit trail, and signs webhook payloads with HMAC-SHA256. See Esignapi's security page for the full current posture, including compliance framework coverage.
Physical and infrastructure security
Beyond the application-level measures covered above, it's worth knowing generally where and how a platform's underlying infrastructure is hosted — most legitimate platforms run on established cloud infrastructure providers that themselves maintain significant physical and network security, rather than operating their own data centers. This is less something to interrogate in detail yourself and more something to confirm is reasonable: a platform relying on established, reputable cloud infrastructure is generally a safer bet than one that's vague about where documents are actually stored.
How often to re-run this checklist
Security isn't a one-time evaluation — standards evolve (an older TLS version becomes deprecated, a new compliance framework becomes industry-standard), and a platform's own practices can change over time, for better or worse. Revisiting this checklist periodically, especially before a significant increase in your document volume or before using a platform for a new, more sensitive category of document, is a reasonable habit rather than something to check once and never again.
Treating this as a starting point, not a final answer
This checklist covers the baseline worth checking across any platform, but your own specific situation — industry, regulatory environment, document sensitivity — may call for additional scrutiny beyond what's listed here. Treat it as a floor to start from, not a ceiling that guarantees a platform is right for your particular use case.
Keeping a copy of this checklist for your own records
It's worth keeping a dated copy of whatever security evaluation you do for a given vendor, including the specific answers you received, as part of your own internal records — useful both if your organization is later audited, and as a baseline to compare against if you revisit the same vendor's security posture again in the future.
Sharing this checklist with a colleague
If someone else on your team is responsible for actually choosing or managing your e-signature platform, sharing a checklist like this one with them directly is a simple way to make sure the same questions get asked consistently, rather than relying on any one person's memory of what to check.
Review your own checklist
Esignapi's security page covers each of these points directly, so you can verify them against this checklist for your own evaluation.
Frequently asked questions
It's the current recommended standard rather than a strict universal legal requirement — a platform using it demonstrates it's keeping pace with current best practice rather than relying on older, weaker protocols.
What's the difference between a document hash and an audit trail hash chain?
A document hash protects the signed file itself (detecting if its content changes), while an audit trail hash chain protects the sequence of logged events (detecting if the record of what happened is altered). Both matter for different reasons.
Does encryption alone make a signature legally valid?
No — encryption protects confidentiality and integrity, but legal validity under laws like the ESIGN Act and UETA depends on identification, intent, and a retrievable record, which is a separate (though related) set of requirements.
How do I verify a platform's security claims rather than just trusting its marketing page?
Ask for specifics (which encryption standards, whether audit trails are hash-chained, how API keys are stored) rather than accepting a generic "bank-level security" claim, and compare the answer against what's actually documented, not just asserted.
Not automatically — relevant certifications vary by industry and jurisdiction. It's worth asking directly what's relevant to your specific use case rather than assuming every certification applies to every business.