eSign admissibility in India: why your audit trail is only half the evidence

The question of eSign admissibility in India surfaces in two contexts: during vendor evaluation, when legal teams ask whether eSign is "legally valid"; and during an actual dispute, when the question becomes urgent. Most teams only engage with it seriously in the second context, which is the wrong time.

The standard vendor answer, "yes, eSign is valid under the IT Act", addresses only one of the two requirements. Signature validity and record admissibility are different legal questions, governed by different statutes. Your eSign platform's audit trail covers the first. The second requires something no platform can issue on your behalf.

Two separate questions, one document

When a signed contract reaches a court or arbitration tribunal in India, two distinct questions arise.

First: was the signature valid? Did the right person sign with appropriate authentication? This is governed by the IT Act 2000, specifically Section 3A for Aadhaar eSign and Section 3 for DSC-based signatures.

Second: is the electronic record itself admissible? Can this PDF be presented to the court as evidence at all? This is governed by the Bharatiya Sakshya Adhiniyam (BSA) 2023, which replaced the Indian Evidence Act from 1 July 2023. The relevant provision is Section 63, successor to the old Section 65B of the Evidence Act.

Most eSign vendor documentation addresses the first question at length and treats the second as a footnote or omits it entirely. The omission creates a real gap in contract workflows where disputes are plausible.

What the Bharatiya Sakshya Adhiniyam 2023 requires

BSA Section 63 sets out the conditions under which an electronic record is admissible as evidence. The record must be accompanied by a certificate from a person in a responsible official position, typically the custodian of the computer or device that produced or stored the record, confirming:

• That the record was produced by a computer in regular use at the relevant time.
• That the device was functioning correctly, or that any malfunction did not affect the record's integrity.
• That the record was produced from information supplied to the computer in the ordinary course of its activity.
• The manner in which the record was produced or stored.

The Supreme Court, in Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal (2020) and confirmed in subsequent rulings through 2024-25, has held this certificate is mandatory. It is not a technical formality a court can waive in the interest of expedience.

The BSA 2023 retained this requirement, renumbered it, and integrated electronic records more explicitly throughout the evidentiary framework. The certificate requirement survived the legislative transition intact.

The certificate your eSign platform doesn't issue

Your eSign platform produces a comprehensive audit trail. For each signed document, FlowVerify logs the identities of all invited signers, the authentication method used (Aadhaar OTP, Aadhaar biometric, email OTP, or DSC), a timestamped record of every action taken, the document hash at each step, and a final sealed PDF with embedded cryptographic signatures.

That trail proves the signing event. A court-appointed forensic examiner can verify the embedded signatures independently. Aadhaar eSign records are countersigned by the UIDAI-issued certificate, making the authentication record independently verifiable.

The Section 63 certificate is different. It certifies the computer system: your organisation's mail infrastructure, internal tools, CRM, or whatever system sent and received the document. It does not certify the signing event. A person in a responsible position at your organisation must attest that the system was operating correctly and generating records in the ordinary course of business.

Your eSign vendor cannot issue this certificate for your internal systems. For their own platform, a vendor could theoretically issue one, but courts have generally expected the certificate to come from the party presenting the evidence, in relation to their own systems. The certificate is your team's responsibility.

Three workflow gaps that affect eSign admissibility in India

Three specific gaps appear repeatedly in workflows that have not planned for this:

Nobody owns the certificate process. Teams select an eSign vendor, configure templates, train users, and go live. The question of who produces the Section 63 certificate, and what records they need to keep access to, is never formally assigned. Litigation feels hypothetical. When a dispute arrives three years later, the IT team may have changed, system logs may have been purged, and the person who operated the sending infrastructure may no longer be at the company.

Audit logs aren't exported at signing time. Your eSign vendor retains the audit trail on their platform. If you terminate the subscription, the vendor changes their retention policy, or the vendor shuts down, access may be lost. The signed PDF might remain in your document management system; the audit trail lives in a system you don't control.

The sending infrastructure isn't documented. If the document was dispatched from a work email account on your company's mail server, someone needs to be able to certify that server. If it was sent from a shared inbox through an external tool, the chain of custody becomes harder to establish. For the signing event itself, the vendor's platform acts as the collection system; for the dispatch event, your infrastructure is in scope.

Three things to prepare before a dispute arrives

This does not require new technology. It requires three organisational decisions:

Designate a document custodian. Assign a specific role, not a named individual (since people leave), that is responsible for producing Section 63 certificates for electronically executed contracts above a defined materiality threshold. Document who fills this role and what records they are responsible for maintaining access to. This is an HR and governance question.

Export and retain audit logs at signing time. Establish a policy to export signed-document audit logs from your eSign platform as part of the contract execution process, or on a scheduled basis for active high-value contracts. Store them alongside the signed PDF in your document management or legal storage. Having a certified export in your own records is a stronger position than relying on vendor access.

Ask your vendor specific questions now. What records does your eSign platform retain, and for how long? Can you obtain a certified export in a format suitable for court proceedings? What does "audit log" mean to them: a PDF summary, a JSON event stream, a hash-verified file? These questions are worth answering before a dispute makes them urgent.

What FlowVerify's audit trail covers and what it doesn't

FlowVerify's audit trail is designed to answer the signature question: who signed, when, with what authentication, and whether the document was altered between steps. The sealed PDF carries embedded cryptographic signatures that a forensic examiner can verify independently. Aadhaar eSign events include the UIDAI-countersigned authentication record, making the authentication verifiable without reference to FlowVerify's servers.

What FlowVerify does not produce: a Section 63 BSA certificate for your organisation's computer systems. That is, by design and by law, the responsibility of the organisation presenting the record as evidence.

For contracts where litigation is a realistic possibility (vendor agreements above a material threshold, employment terms, financing documents, and regulatory filings), treat the audit trail as one side of the evidence question and Section 63 preparation as the other. Both are necessary. Only one requires a vendor.