The eSignature Vendor Security Checklist: What to Ask Before You Sign

When a procurement team asks about eSign vendor security, the first answer they usually get is a badge: "We are SOC 2 Type II certified." That is a reasonable starting point — it tells you the vendor ran their controls past an auditor at a point in time. It does not tell you what those controls actually cover, how tight they are, or whether your specific signing flow falls within the audit scope.

Any eSignature vendor security checklist worth using needs to cover four layers that SOC 2 typically does not address directly: authentication modes, document integrity levels, audit trail evidence quality, and whether your signed documents remain verifiable once you leave. This guide covers all four, with specific questions and the answers that should concern you.

In India, the stakes run higher than in many markets. Aadhaar-based eSign flows touch UIDAI infrastructure and are governed by the IT Act and the Aadhaar Act. A vendor can hold a SOC 2 certificate and still produce a signing flow that would not hold up under Section 3A in a dispute.

The four layers that matter in an eSign security review

eSign security stacks across four distinct concerns:

• Authentication: How does the vendor verify that the person signing is who they claim to be?
• Document integrity: What proves the document was not altered after signing?
• Audit trails: What evidence can the vendor produce if the signature is challenged?
• Infrastructure and access control: What happens when the vendor's systems are attacked or compromised?

Most vendor security pages address only the fourth layer. The first three are what actually matter when a signature is disputed.

Authentication: what the signing flow actually verifies

Three main authentication modes appear in Indian eSign deployments, and they are not equivalent:

• OTP to registered mobile or email: Confirms access to a communication channel. It does not verify identity.
• Aadhaar OTP or biometric eSign: Verifies identity against UIDAI's database. Requires a CCA-licensed Authentication Service Agency or eSign Service Provider. The vendor must hold this licence directly or integrate with one that does.
• Digital Signature Certificate (DSC): Hardware or cloud-based. Identity is verified during DSC issuance, not at signing time.

Questions to ask:

• What authentication modes do you support for signers?
• For Aadhaar eSign: which CCA-licensed ESP does your integration use, and can you provide the licence number?
• If Aadhaar eSign fails due to UIDAI downtime, what is the documented fallback authentication mode?
• Is the OTP sent to a channel the signer provided, or one already verified in your system?

A vendor who cannot name their ESP is using a third-party integration they do not fully control.

Document integrity: beyond "encrypted at rest"

Every vendor says documents are encrypted at rest and in transit. That is baseline hygiene — it tells you a passive network observer cannot read the file. It says nothing about whether the document can be altered after signing.

What actually proves a document was not altered is a cryptographic signature embedded in the PDF — specifically a PAdES (PDF Advanced Electronic Signature) signature. It covers a defined byte range of the file. If any byte in that range changes after signing, the signature breaks. The PAdES level determines what else is embedded alongside the signature:

For most enterprise contracts, B-LT is the right target. B-LTA is for documents with legal retention requirements of ten years or more, where the signing algorithm itself may eventually be deprecated.

Questions to ask:

• What PAdES level do your signed PDFs meet by default?
• Which TSA do you use for timestamps? Is it a recognised, accredited authority?
• Can a signed PDF be verified offline, without calling your API?

That last question is the most revealing. A vendor whose verification depends on their own API is building in lock-in — and breaking verifiability the day they shut down.

Audit trails: the difference between a log and evidence

A database row that says "signed at 14:32" is not an audit trail. An audit trail is a sequence of timestamped, tamper-evident records that can reconstruct who did what, with which document, using what authentication, and in what order.

Under Section 3A of the IT Act, a reliable authentication technique must produce records that support this reconstruction. The specific fields that matter:

• Signer identity: email, phone, or Aadhaar token — whichever authentication method produced it.
• Authentication event: type, timestamp, and success or failure.
• Document hash: SHA-256 of the document at the time of signing, so any post-signing alteration is detectable.
• IP address and user agent: circumstantial, but required for envelope-level forensics.
• Every state transition: draft, sent, viewed, signed, completed — with timestamps on each.

"Viewed" is the underrated one. Clicking agree without opening the document is a common dispute point. A defensible audit trail logs the timestamp when the signer first opened the signing view, separately from when they submitted the signature.

Questions to ask:

• What events and fields does your audit trail capture?
• Is the audit trail cryptographically signed or chained?
• Can I export audit trail data independently of the signed PDF?
• What is your audit trail retention period, and is there a charge beyond that?

Aadhaar eSign: the compliance layer unique to India

If you are deploying Aadhaar-based eSign, there is an additional set of questions that goes beyond standard security posture:

• CCA licence: Is the vendor's integration with a CCA-licensed ESP? The CCA maintains a public list of licensed providers. Ask for the ESP name and verify it against that list before signing a contract.
• Data retention under the Aadhaar Act: Neither the vendor nor the integrator is permitted to store biometric data. OTP transaction references may be retained for audit purposes; the OTP itself may not. Ask what Aadhaar-related data the vendor retains, for how long, and under which legal basis.
• Fallback when UIDAI is down: UIDAI's e-KYC services have documented downtime windows. A vendor with no answer here will break your signing flow without warning. The right answer is a documented fallback — OTP-based or DSC-based signing — with the failed Aadhaar attempt logged as an authentication event.

UIDAI downtime is a government infrastructure issue, not a vendor fault. But a vendor who has not planned for it is passing that risk entirely to you.

Infrastructure and access control

This is where the SOC 2 report is actually useful. Request Type II (covers a period of time, not a point-in-time snapshot) and look specifically at:

• Change management: Is there a process that prevents an engineer from pushing a change to production that mutates or deletes signed documents?
• Access control: Can support staff access raw document bytes? Under what conditions, and is that access logged?
• Data residency: Where are signing servers and document storage located? For India-regulated workflows, is storage within India?
• Incident response: What is the vendor's SLA for notifying you of a breach? The DPDP Act sets a 72-hour standard for reporting to the Data Protection Board.

Questions to ask:

• Can you share your SOC 2 Type II report? What period does it cover?
• Where is document storage located? Is it within India?
• Under what conditions can support staff access signed document content?
• What is your breach notification SLA to customers?

The eSignature vendor security checklist

Use these verbatim in your vendor evaluation. A vendor who can answer all of them clearly, in writing, is worth evaluating seriously. One who deflects more than two to marketing materials is not ready.

Authentication

• What signing authentication modes do you support?
• For Aadhaar eSign: which CCA-licensed ESP does your integration use?
• Is Aadhaar biometric data retained anywhere in your systems?
• What is the documented fallback if Aadhaar eSign is unavailable?

Document integrity

• What PAdES level do your signed PDFs meet?
• Which TSA do you use for timestamps?
• Can signatures be verified offline, without your API?

Audit trails

• What events and fields does your audit trail capture?
• Is the audit trail cryptographically signed or chained?
• Can I export audit trail data independently of the signed PDF?
• What is the retention period, and what is the cost beyond that?

Infrastructure

• SOC 2 Type II report available? What period does it cover?
• Where is document storage located? Is it within India?
• Under what conditions can support staff access signed document content?
• What is your breach notification SLA?

Portability and exit

• Can I export all signed documents and audit trails if I leave?
• Will PAdES signatures remain independently verifiable after export?
• What is your data deletion policy and timeline after account closure?

A vendor who cannot answer these in writing is asking you to take their security posture on faith. That is not a posture you want to inherit.