Section 65B is gone. What the BSA's Section 63 requires from your digital evidence.

On 1 July 2024, the Bharatiya Sakshya Adhiniyam, 2023 (BSA) replaced the Indian Evidence Act, 1872. India's rules for digital evidence in court changed with it. The transition was covered in legal publications and then largely forgotten by engineering and compliance teams. That forgetting has a practical cost. Section 65B, which governed how electronic records are produced as evidence in Indian courts, no longer exists. Its replacement, Section 63, requires something Section 65B never did: a hash value of the document you are producing. Most Indian businesses have not built that into their document workflows yet.

What Section 65B required

Under Section 65B of the Indian Evidence Act, electronic records could be admitted as secondary evidence if accompanied by a certificate from a responsible official. The certificate had four components: the output was produced from a computer, that computer was in regular use during the relevant period, the information was stored in the ordinary course of the computer's activities, and the computer was operating properly when it did so.

The certificate was straightforward. A senior IT or operations officer signed it. It established that the computer system worked and that the data was produced in the normal course of business. It said nothing about whether the specific file being produced in court was byte-for-byte identical to the file that was created or received on a specific date.

Courts applied this framework to bank transaction logs, email chains, WhatsApp messages, and signed contracts. The common failure mode: a party would produce a printout from their system, get an officer to sign a Section 65B certificate, and consider the task complete. Whether the printout matched what was actually sent or received was often not examined closely. The certificate did not require that level of proof.

What Section 63 now requires

Section 63 of the BSA carries forward the basic structure of Section 65B: a certificate from a responsible official attesting to the provenance of an electronic record. But it adds two things that change the operational picture considerably.

First: hash values. The certificate under Section 63(4)(c) must now state the hash value of the electronic record being produced. A hash value is a fixed-length string representing the exact contents of a file. SHA-256 is the standard you should use. Change a single character anywhere in the document and the hash is completely different. Including a hash in the certificate lets a court verify that the file being produced matches the file as it existed at a specific earlier point, provided that hash was recorded when that point occurred.

Second: a two-part certificate. Part A is completed by the responsible official (the person who controls the device or system) and covers device details, ordinary use, and the hash value. Part B, optionally completed by an independent technical expert, provides a second verification of the hash. The Ministry of Electronics and Information Technology has published a prescribed format for both.

Third, and this is often missed: Section 57(4) of the BSA states: "An electronic or digital record stored in an electronic form shall also be primary evidence." Electronic records are no longer secondary evidence that needs a certificate to be valid at all. They are primary evidence whose authenticity can be challenged. The Section 63 certificate is how you establish that authenticity.

Why hash values require a process change, not just new paperwork

This is where most businesses have a gap. Recording a hash value of a document is not something you can do retrospectively with the same evidentiary force as recording it at the time of creation or receipt.

A concrete scenario: a vendor sends you a signed contract by email. Your accounts team downloads the PDF and uploads it to cloud storage. The cloud storage system strips some metadata. When a dispute arrives two years later, you compute the hash of the file sitting in your storage. That hash reflects the file as it now exists, after metadata stripping, possibly after some automated process altered the file bytes. It is not necessarily the hash of the file that arrived in the original email.

To serve a Section 63 certificate well, the hash should be recorded at receipt. That means your document intake process needs to compute and store a hash at the moment a legally significant document enters your systems, separately from the file itself, so that neither can be altered without creating a detectable inconsistency.

This is a standard practice in digital forensics. It is new in Indian business operations, and most teams have not built it into document workflows that were designed around email and cloud storage rather than court admissibility.

Who is the responsible official?

Section 63 requires the Part A certificate to be signed by "a person occupying a responsible official position in relation to the operation of the relevant device or the management of the relevant activities."

In practice, for corporate entities, this is the CTO, CISO, Head of IT, or a designated records officer. For smaller companies, the founder or a senior technical officer suffices. The key is that this person should be able to speak credibly (under oath if necessary) about how the document management system operates, how access is controlled, how hash values are computed, and how the specific record came to be produced in court.

Designate this role before a dispute, not during one. A responsible official named in your company's records retention policy is more defensible than one named for the first time in a certificate during litigation.

What needs to change in your document workflow

For most Indian businesses, the gap is not in drafting or signing. It is in storage, intake, and retrieval. Six practical steps:

1. Choose SHA-256 as your hash function and document it in your records retention policy. MD5 and SHA-1 are cryptographically broken. Avoid them for any evidentiary purpose.
2. Compute and record hash values at intake for legally significant documents: contracts, signed agreements, board resolutions, regulatory filings, statutory notices. At the moment of receipt or creation, compute the hash and log it in a tamper-evident record.
3. Store hash values separately from the documents themselves. If your hash registry lives in the same database as your files, someone who modifies a document can potentially modify its hash record too. Use a separate log. At minimum, different tables with different access controls; better, an append-only ledger or an external audit service.
4. Designate a responsible official and record the designation in your compliance documentation.
5. Draft your Part A certificate template now. The MEITY-prescribed format is publicly available. Fill in your organisation's boilerplate: device architecture, system description, usual operating conditions. You should not be writing this for the first time during a dispute.
6. Review what your document and signing platforms already record. Signing platforms that manage the signing workflow typically record the document hash at each stage. FlowVerify's audit trail, for instance, records the document hash at send, view, sign, and complete, meaning the integrity proof is built into the workflow rather than retrofitted later. If you are routing contracts through such a platform, verify that the output format is suitable for a Section 63 certificate and identify who your responsible official is for that system.

Documents created before 1 July 2024

Electronic records created and stored before the BSA came into force should be produced under Section 65B of the Indian Evidence Act. Courts apply the law in force at the time a document was created or stored, not the law at the time of proceedings. If a document is post-July 2024, Section 63 applies.

If you are handling a dispute that spans the transition, you may need to produce certificates under both regimes: Section 65B for older records, Section 63 for newer ones. Check the dates carefully before deciding which procedure applies to each document.

How India courts are applying the new digital evidence rules

Disputes involving digital evidence are already being decided under the BSA framework. Indian courts have cited Section 63 in electronic evidence rulings since early 2025. Deficiencies in hash values or certificate structure that might have been overlooked under old Section 65B practice are receiving closer scrutiny.

The practical risk is specific: a contract that is valid, was genuinely agreed by both parties, and is properly stored in your systems might be inadmissible as evidence if you cannot produce a Section 63-compliant certificate. The underlying agreement does not change. Your ability to prove it in court does.

Every Indian business that relies on contracts (which is every Indian business) has a checklist item here. The law is not new anymore. The adjustment is overdue.