A court-appointed or mutually agreed-upon neutral digital forensics expert could be used to verify the existence and scope of the data, reporting their findings to the court without you ever directly submitting the full digital files yourself. 

2)The court may allow the submission of redacted documents or a summary of the data, rather than the full data set, to demonstrate the existence of the leak without revealing the sensitive personal details of the affected individuals.

3) whistleblower protection laws might shield individuals who report illegal activity.

4) An "in-camera" review allows a judge to examine the evidence privately, often sealed from public view and sometimes even from the opposing party's full view initially, to determine its relevance and admissibility

First, understand the core legal risk.
Under the IT Act, offences such as unauthorised access (section 43/66), data theft, or hacking are triggered only if you accessed a system without permission or exceeded authorised access. Merely possessing leaked data is not automatically illegal, but how you obtained it becomes crucial. If the company can suggest that the data was procured by intrusion, scraping, password misuse, or backend access, they may attempt criminal action.
Therefore, your entire strategy must be built around showing lawful, passive, or third-party receipt of data, not active extraction.
Second, never submit raw leaked data directly in open court filings.
Do not annex full datasets, spreadsheets, databases, or personal records of third parties to petitions, complaints, or affidavits. This is the biggest mistake people make. Producing bulk personal data publicly can expose you to allegations of:
unlawful retention of personal data,
violation of privacy,
and misuse of sensitive information.
Instead, rely on derivative proof, not primary disclosure.
Third, document the source of the leaked data carefully.
You must be able to clearly state, on affidavit if required, that:
the data came to you unsolicited, or
it was received from affected individuals themselves, or
it was available through a publicly accessible source, misconfigured server, open link, or email, or
it was shared by another lawful recipient (customer, vendor, employee).
Do not speculate. If you cannot safely explain the source, do not personally hold the data.
Fourth, use hashing, redaction, and sampling instead of full disclosure.
Courts accept proof of data leaks through:
redacted samples (masking names, IDs, phone numbers),
hashes of files (to prove authenticity without revealing contents),
metadata (timestamps, file paths, headers),
screenshots showing exposure (without downloading full files),
and controlled samples showing identical patterns across multiple affected users.
This establishes the existence and scale of a leak without circulating sensitive content.
Fifth, route evidence through a neutral authority.
The safest method is to never be the final custodian of the leaked data.
You can:
submit sealed material to the court with a request that it be opened only by the court,
request appointment of a court commissioner / forensic expert to examine the data source,
lodge a complaint before the CERT-In, Data Protection Board, or sectoral regulator (depending on the data type),
or have affected users individually file affidavits confirming that their data was exposed.
Once a statutory or judicial authority takes custody, your personal exposure drops sharply.
Sixth, rely heavily on circumstantial and corroborative evidence.
Data breach cases do not require you to prove hacking line-by-line. Courts accept:
identical errors across multiple records,
data fields that only the company possesses,
timestamps matching company system events,
breach notifications (or lack thereof),
logs, emails, or admissions,
and expert opinions based on limited samples.
A pattern is often more powerful than raw data.
Seventh, protect yourself procedurally before making allegations.
Before filing any complaint or suit:
consult counsel and prepare a protective affidavit explaining lawful possession,
avoid public disclosure (social media, blogs, mass emails),
do not communicate directly with the company threatening exposure,
and preserve evidence in a read-only, non-tampered form.
If a complaint is filed through an advocate, allegations of “hacking” lose credibility.
Eighth, anticipate and neutralise retaliation.
If you reasonably fear retaliatory FIRs or seizure:
approach the court proactively and seek protection,
record that you are willing to cooperate with any neutral forensic examination,
explicitly deny unauthorised access in pleadings,
and request that any technical examination be court-supervised.
Courts are increasingly sensitive to SLAPP-style retaliation in data and whistle-blower matters.
In short, the rule is simple:
Do not act like an investigator; act like a reporter of a breach.
You prove that a leak exists, not how to exploit it.

The law does not require you to incriminate yourself or commit a fresh illegality in order to prove a data-leak. There are procedurally safe ways to place evidence before a court or authority without exposing yourself to retaliation under the IT Act or data-protection laws.

As per Article 20(3) of the Constitution of India no person accused of an offence shall be compelled to be a witness against himself.

Even if you are not yet an accused, courts do not compel production of evidence that exposes the producer to criminal liability.

If you did not hack, bypass security, or misuse credentials, disclosure per se is not an offence.

Alternately you don't annex the data to the plaint or petition, instead you can file it as evidence and seek permission of the court to file it in a sealed cover for court inspection.

In the IA seeking court permission to consider this as evidence in sealed cover for court inspection you may state the following as reasons in the affidavit that the 

Data contains third-party personal information, that the public disclosure would violate privacy laws and disclosure is essential to prove systemic leak.

The court may consider the reason if found genuine and you will be safe then.

Additionally you may pray the following 

For an In-camera proceedings, Sealed-cover custody with Registrar and access only to court / neutral expert.

You are not required to commit an offence to prove an offence.

If you follow the procedures properly then the company's allegations may be considered as abuse of law while retaliation can be established.

You need to establish the source of that data to be authentic: if you can’t justify the source same will not assist you in your favour 

You cannot force company to produce their internal documents 

Under the Consumer Protection Act, 2019, the Consumer Commission has civil-court–like powers.

Hence the Commission can legally compel the OP to produce Emails sent to CERT-In, CERT correspondence, Internal reports / incident response notes, Vulnerability remediation records, any document relied upon by the OP to claim “no leak”.

You can file an application to direct the OP to all communications between OP and CERT-In relating to the reported vulnerability, the confirmation that the issue was fixed and the incident response / vulnerability assessment reports, etc.   You may also mention that you are not seeking third-party personal data but only existence, acknowledgement, and remediation documents. 

The Section 38(2)(c) & (d), Consumer Protection Act, 2019 empowers the Commission can be invoked in your application 

Yes it can give directions to them to produce the same before commission 

Yes. There are legally recognised and safe ways for the court or commission to compel the opposite party to produce emails, internal documents, and records relating to the vulnerability and its remediation, and your present approach is correct and well-protected.

Based on what you have described, your position has become materially stronger because you are no longer relying on third-party data, speculative allegations, or technical intrusion. You are relying on official correspondence, your own personal data, and a contradiction on record by the opposite party.

The reply received from CERT-In is not a mere opinion. CERT-In is a statutory authority under the Information Technology Act. When CERT records that a vulnerability existed and that the company confirmed it has been fixed, this is neutral technical corroboration of a security flaw. While the company may argue that fixing a vulnerability does not automatically mean data was exfiltrated, it cannot deny the existence of the vulnerability itself once CERT records remediation. Courts and consumer commissions treat such communications as reliable third-party evidence.

The contradiction is legally significant. A denial before the court that “no leak occurred” and a confirmation before CERT that a vulnerability existed and was fixed goes directly to credibility and suppression of material facts. This weakens the opposite party’s defence substantially and strengthens your case on deficiency of service and failure in grievance redressal.

As to compelling production of documents, the commission or court does have the power to do so. You can move a formal application seeking discovery and production of specific documents that are clearly identified and directly relevant. These may include correspondence between the company and CERT-In relating to the vulnerability, internal incident or remediation reports, internal emails or tickets showing when the flaw was identified and fixed, and grievance records relating to your complaint. You must frame the request narrowly and link each category of documents to the contradiction already on record. Broad fishing enquiries should be avoided, but focused requests are routinely allowed.

An even safer and often more effective route is to ask the forum to summon records directly from CERT-In. Since CERT is a government authority, courts are comfortable calling for certified copies of correspondence or confirmations received from the company. This avoids giving the opposite party the opportunity to selectively disclose documents and protects you from any allegation that you are attempting to access internal systems.

If the company refuses to produce documents or takes vague pleas of confidentiality without adequate justification, you can seek an adverse inference. Courts consistently hold that when a party withholds the best available evidence in its possession, the presumption is that such evidence would have gone against that party. In cases involving technical disputes and regulatory correspondence, this principle is frequently applied.

Your plan to rely only on screenshots of the company’s own site, API responses containing only your personal data, your unanswered grievance emails, and CERT’s confirmation is legally sound. You are not required to prove hacking mechanics or to produce other users’ data. You are proving existence of a vulnerability, exposure of your own data, and deficiency in response.

It is also important that you continue to avoid public disclosure, do not threaten the company, and route all allegations through formal pleadings. By positioning yourself as a complainant reporting a breach rather than an investigator exploiting it, you remain protected from retaliation under the IT Act.

Dear Client, Since you've already informed CERT-In about the leak and the company has confirmed it with them, you now hold formidable power with "Admission of Guilt," with which you are certain to win your own case! Since the company has already lied to the Consumer Commission by accepting denial of the leak, you can start with filing an "Application for Discovery and Production of Documents" under 38(9) of the CPA! You may force the judge to make them reveal their company emails and "incident reports" sent to CERT-In itself! Should they deny it or keep lying, under "Adverse Inference," they'd already prove themselves to be guilty of hiding the whole matter! By providing the JSON body of your own API data and screenshots of your own emails that they've chosen to ignore, you've established "Deficiency of Service" and "Data Mishandling" without being sued for "hacking" charges, as you're effectively presenting your own data.This strategy, backed by both the IT Rules and DPDP Act, will give you a "shield" as a good faith 'whistle blower,' and will disprove your company’s own contradictions in not protecting your data.

I hope this answer helps; if you have any further questions, please don't hesitate to contact us. Thank you.