What Compliance Should an eSignature Vendor Give You?

When an enterprise buyer sends you a security questionnaire, your signing vendor becomes part of your answer whether you planned for that or not. The document layer touches signer identity, personal data, and the record of who agreed to what, so it shows up in diligence. What you want from that vendor is not a badge collection but four specific things: an attestation you can forward, an evidence package that returns to your system, identity assurance you control per document, and clarity about which framework covers which claim.

This is written for platform teams who get asked these questions, not for compliance officers writing the questionnaires.

What does SOC 2 actually prove, and what are the two types?

SOC 2 is an attestation engagement, which is why careful vendors write "attested" rather than "certified". An independent auditor examines a set of controls and reports on them.

Type I reports on whether controls are suitably designed as of a point in time. Type II additionally reports on whether they operated effectively across a period, usually several months. Type II is the more demanding of the two, and the distinction is worth knowing because questionnaires often ask for one and accept either.

Verdocs holds a SOC 2 Type I attestation, and the report is available on request under a mutual NDA. That request-the-report pattern matters more than the badge: a vendor that will not share the report under NDA is offering you a logo rather than evidence you can pass along.

Verdocs is also HIPAA compliant, which becomes relevant the moment a workflow touches health information, including insurance claims and underwriting adjacent to medical records.

Which framework covers legal validity, as opposed to security?

These are separate questions that diligence often merges, and separating them saves an argument.

Security frameworks like SOC 2 speak to how a vendor protects data. Legal validity of a signature is governed elsewhere: the ESIGN Act and UETA in the United States, and eIDAS in the European Union. Verdocs signatures are ESIGN and UETA compliant, with eIDAS Simple Electronic Signature and Advanced Electronic Signature support, and Qualified Electronic Signature available through qualified trust service provider partnerships. They are legally valid in 50+ countries and 60+ jurisdictions.

A vendor holding a SOC 2 report has told you nothing about whether the signature holds up, and a vendor citing ESIGN has told you nothing about how they store your data. Ask both.

What evidence should come back with a completed document?

This is the part that survives the vendor relationship, and the part most evaluations skip.

Every completed Verdocs document carries a PKI digital signature backed by public and private certificates, a tamper-evident seal so alteration after signing is detectable, a signed certificate recording when and where the document was signed and by whom, and a full event history including opens, declines, and the authentication each party cleared. Documents are encrypted at rest with 2048-bit RSA private keys held in Hardware Security Modules, so no unauthorized party can read them, including Verdocs developers. Infrastructure runs on AWS and Azure.

The test that matters: does all of that return through the API into your system, or does it live in the vendor's dashboard? Evidence you cannot retrieve programmatically is evidence you do not really have, and you will discover that during an audit or a migration rather than before one.

Can you control identity assurance per document?

You should be able to, because a flat setting is either too weak for your riskiest document or too expensive for your most routine one.

Verdocs supports an ascending ladder: creator link, in-person link, guest email, PIN code, verified user, MFA or SMS, knowledge-based authentication, and live ID scan. Each step a signer clears is recorded in the same audit trail as the signature, so the record reflects the assurance level actually applied rather than the policy you intended. Knowledge-based authentication and ID scan are per-transaction add-ons.

For a platform, the important property is that the level becomes a field on the document type in your own data model, configured once per workflow.

What about data processing terms and subprocessors?

Ask for the data processing agreement, not a summary of it. Verdocs publishes its DPA and its privacy policy as pages you can read before signing anything, which is faster than requesting them and lets your counsel review on their own schedule.

Two questions worth asking any vendor in this category: what subprocessors touch the data, and whether the agreement prohibits training AI models on customer content. The second one is newly load-bearing and frequently unaddressed.

The questionnaire answers you actually need from a vendor

If you are assembling responses, these are the items worth having on hand before someone asks:

1. The attestation, with type and report date, plus whether it is shareable under NDA.
2. The legal-validity frameworks, named separately from the security ones.
3. The encryption posture, including key storage and who can access keys.
4. The evidence package contents, and confirmation it is API-retrievable.
5. The identity assurance options, and whether you control them per document.
6. The DPA and subprocessor list, in writing.

A vendor that can produce all six quickly is a vendor whose own diligence is in order. One that takes three weeks to answer item one is telling you how the next questionnaire will go.

What if a buyer demands Type II and your vendor has Type I?

This comes up, and the useful response is neither to bluff nor to concede the deal.

Separate the requirement from its proxy. A buyer asking for Type II usually wants assurance that controls work over time, and the report is the conventional way to evidence that. Where a vendor holds Type I, the substantive answer is the controls themselves: what encryption is in use, where keys live, who can access them, what the audit trail records, and what independent examination has covered so far. Those are inspectable claims, and on any signing platform you can verify several of them yourself on a test envelope in a sandbox.

Say plainly which type the vendor holds and when it was issued. A buyer who has been told "SOC 2 compliant" and later discovers it meant Type I has a trust problem with you, not with your vendor. The precision costs nothing at the start and quite a lot retroactively.

Where this leaves you

Compliance in the signing layer is not a badge you inherit; it is a set of artifacts you can forward and a set of controls you can describe accurately. The useful test is whether you could answer an enterprise questionnaire about your signing vendor today, from documents you already hold.

Fuller detail on the compliance surface, including how to request the SOC 2 report under NDA, lives on the legal compliance page. For a worked example of diligence running the other way, where a regulator names the obligations and your customer inherits them, see who is responsible when eSignature is embedded in tax software.