Questions to ask an e-signature vendor about security

Before relying on any e-signature vendor for real business documents, it's worth asking a specific set of questions rather than accepting a general "we take security seriously" statement at face value. This article covers what SOC 2 actually means, and the broader set of concrete questions worth asking, so you can evaluate any vendor's actual security posture rather than its marketing language.

What SOC 2 actually is

SOC 2 (System and Organization Controls 2) is an auditing standard, developed by the AICPA, that evaluates a service organization's controls around security, availability, processing integrity, confidentiality, and privacy. A SOC 2 report is produced by an independent auditor after reviewing a company's actual practices against these criteria — it's not a certification you simply claim, but a report based on an audit.

Why the specific wording matters

Vendors describe their SOC 2 status in different ways, and the wording isn't interchangeable:

"SOC 2 certified" or "SOC 2 Type II compliant" generally implies an actual completed, current audit report exists.
"SOC 2 Ready" typically means the company has aligned its internal practices with SOC 2's control framework but hasn't necessarily completed (or may be in the process of completing) an independent audit.
No mention at all doesn't necessarily mean a vendor is insecure, but it's worth asking directly rather than assuming.

If a specific audit report matters for your own compliance requirements, ask the vendor directly which of these applies and, if relevant, whether they can share the actual report (often available under an NDA) rather than relying on marketing language alone.

Questions worth asking any e-signature vendor directly

What encryption standards do you use, specifically, for data in transit and at rest? A vague "bank-level encryption" claim should be followed up with the actual standard names (TLS version, AES key length).
Is your audit trail tamper-evident, and how? Ask specifically whether entries are hash-chained, not just logged.
How are API keys stored and what happens if one is exposed? A vendor should be able to describe key hashing and immediate revocation capability.
What is your role with respect to our document content — do you analyze, use, or share it in any way? A vendor acting strictly as a processor of your content, without using it for other purposes, is the expected baseline.
What's your data retention and deletion policy? Especially relevant if you operate under GDPR or similar regulations.
Do you have a documented incident response process? How they'd handle and communicate an actual security incident matters as much as how they prevent one.
What compliance frameworks are you working toward or have completed, specifically? Push past a generic "we're compliant" answer to the specific framework and its actual current status.

Why this matters more for some businesses than others

If you're signing routine commercial contracts with no special regulatory requirements, a vendor meeting a reasonable general security baseline (strong encryption, a tamper-evident audit trail, clear data handling practices) is usually sufficient. If you operate in a regulated industry, or your own customers or auditors specifically require a vendor with a completed SOC 2 report, GDPR-specific contractual terms, or other formal certifications, it's worth confirming those specifics directly rather than assuming a general security page covers your particular requirement.

A good vendor should answer these questions clearly

A vendor that can answer these questions specifically and directly — rather than deflecting to generic statements — is generally a better sign than the specific answers themselves, since it suggests they actually understand their own security posture rather than reciting marketing copy.

Esignapi's current posture, stated plainly

Esignapi describes itself as "SOC 2 Ready" rather than claiming a completed independent audit, alongside stated GDPR compliance, AES-256 encryption at rest, TLS 1.3 in transit, a hash-chained audit trail, and HMAC-signed webhooks. If a completed SOC 2 report specifically is a hard requirement for your organization, confirm the current status directly rather than assuming "Ready" means the same thing as a completed audit.

Why asking the specific questions matters more than a checklist of certifications

It's tempting to look for a specific list of certification logos on a vendor's website and treat that as the full answer, but certifications are a proxy for the underlying practices, not a substitute for understanding them. A vendor that can clearly explain how it handles encryption, audit trail integrity, and incident response, even without every possible certification, is often a more trustworthy evaluation than one that lists certifications without being able to speak specifically to how its systems actually work. Treat certifications as one useful signal among several, not the entire evaluation.

Documenting the answers for your own records

If your organization has its own compliance or procurement process, it's worth documenting the answers you get from any vendor in writing — an email confirming specific claims, or a vendor's own published security page saved as a reference — rather than relying on a verbal conversation alone. This matters if your own organization is ever audited and needs to show how it evaluated a third-party vendor handling sensitive documents.

Revisiting vendor security periodically

A vendor's security posture isn't static — a company can achieve a new certification, update its encryption standards, or, less happily, have an incident that changes the picture. For an ongoing vendor relationship involving regular document volume, it's reasonable to revisit these questions periodically rather than relying on an evaluation done once at the very beginning of the relationship.

Ask the questions that matter for your situation

Esignapi's security page lays out its current security practices directly — use the questions above as a framework for your own evaluation of any vendor, including this one.

Frequently asked questions

Is "SOC 2 Ready" the same as being SOC 2 certified?

No — "Ready" generally means a company has aligned its practices with the SOC 2 framework without necessarily having completed an independent audit. If a completed audit report specifically matters for your compliance needs, ask directly about current status.

Do I need to worry about SOC 2 if I'm just a small business sending a few contracts a month?

Probably not as a hard requirement — SOC 2 matters most when your own customers, auditors, or industry regulations specifically require vendor compliance documentation. For routine business use, a reasonable general security baseline is usually sufficient.

Can a vendor refuse to answer specific security questions?

A vendor should be able to answer general questions about encryption standards and data handling practices without issue. If a vendor is unwilling to answer basic questions like these, that's worth treating as a signal in itself.

Is it reasonable to ask for a copy of a vendor's SOC 2 report?

Yes, this is a standard request in vendor security reviews — a vendor with a completed report should be able to provide it, often under an NDA, if your organization's compliance process requires reviewing it directly.

What's more important: encryption standards or audit trail design?

They address different risks and both matter — encryption protects confidentiality, while a solid, tamper-evident audit trail is what gives a signature evidentiary strength if it's ever disputed. Neither substitutes for the other.