DEV Community: Peesh Chopra

Your App Logs Can Become Legal Evidence: What Developers Should Preserve

Peesh Chopra — Tue, 08 Sep 2026 15:40:40 +0000

A production incident usually starts with a technical question.

What happened?

A legal dispute often starts with a different one:

Can you prove what happened?

For developers, those two questions are much closer than they appear.

A user claims that an account was accessed without permission. A customer disputes a transaction. A company investigates whether an employee downloaded confidential information. A security team discovers suspicious activity several weeks after it occurred.

The first place everyone looks is often the same: the logs.

But logs are not only useful for debugging and security investigations. In the right circumstances, digital records can become important evidence in a legal proceeding.

That creates a responsibility developers and engineering teams sometimes overlook.

The way your application creates, stores, and preserves logs can affect their usefulness later.

What Counts as an Application Log?

An application log can record events such as:

User login and logout activity
Password changes
API requests
Failed authentication attempts
Account modifications
File uploads and downloads
Administrative actions
Payment events
Changes to important records
Access to sensitive information

The exact contents depend on the application.

A simple timestamp and error message may be enough for debugging. For an investigation, however, the context surrounding that event can be much more important.

For example:

2026-09-08 10:41:12
user_id=4821
action=download
resource=customer_export.csv
ip=203.0.113.10

This tells us something happened.

But it may not tell us enough to establish who actually performed the action, whether the account was compromised, whether the log itself was altered, or whether the recorded time is reliable.

That distinction matters.

Why Developers Should Care About Evidence

Indian law recognises electronic records as a form of evidence, subject to the applicable legal requirements.

The Bharatiya Sakshya Adhiniyam, 2023 contains provisions dealing with electronic and digital records.

This does not mean that every log file automatically becomes conclusive proof in court.

The circumstances in which the record was created, stored, maintained, produced, and authenticated can matter.

For an engineering team, this means one thing:

Evidence quality begins before litigation begins.

By the time lawyers become involved, it may already be too late to recover deleted logs, establish missing timestamps, or determine whether an administrator modified a record.

The Difference Between Logging and Preserving

This is one of the most important distinctions.

A system may generate logs continuously, but that does not necessarily mean the organisation is preserving them properly.

Consider a startup that keeps authentication logs for seven days.

A suspicious account takeover happens on January 1.

The customer reports it on January 15.

The relevant logs have already been deleted.

The application technically had logging enabled. Yet the organisation may no longer have the information needed to investigate what happened.

Logging answers:

What did the system record?

Preservation asks:

Did we retain the relevant record long enough, and in a sufficiently reliable form, to use it later?

These are different engineering decisions.

What Should Developers Consider?

1. Accurate Timestamps

Timestamps should be consistent and properly managed.

If one server records an event in UTC while another records local time, investigators can struggle to reconstruct the sequence of events.

A consistent time standard makes incident reconstruction considerably easier.

2. Identity and Context

A log saying:

DELETE /customer/4821

may be technically useful but legally weak without additional context.

Where appropriate, organisations should consider recording information such as:

User or service identity
Relevant request or transaction identifier
Timestamp
Source information
Action performed
Resource affected
Authentication context

The exact information should depend on the application's security, privacy, and operational requirements.

More logging is not automatically better.

3. Protection Against Tampering

If an administrator can freely modify or delete the same logs used to investigate that administrator's actions, the reliability of those records can become questionable.

Sensitive logs should therefore be protected through appropriate access controls and retention mechanisms.

For critical systems, organisations may also consider append-only or otherwise tamper-evident storage.

4. Retention Policies

Keeping everything forever is not necessarily the answer.

Logs may contain personal information, identifiers, IP addresses, device information, or other sensitive data.

A sensible retention policy should balance:

Security requirements
Legal requirements
Business needs
Investigation requirements
Privacy obligations
Storage costs

The important point is to have a deliberate policy rather than allowing logs to disappear through an undocumented automated cleanup job.

What About IP Addresses?

IP addresses often appear in security logs.

They can be useful when investigating suspicious activity, but developers should avoid assuming that an IP address automatically identifies a particular person.

An IP address may correspond to:

A shared network
A corporate gateway
A mobile network
A VPN
A proxy
A public Wi-Fi connection

Therefore, an IP address can be an important investigative clue without necessarily proving who was physically using a device.

Context matters.

What Happens When an Incident Occurs?

Imagine a customer claims that ₹50,000 was transferred from an account without authorisation.

The engineering team investigates and finds:

A successful login
A password reset
A change to the registered device
A transaction request
An API response

If these events are recorded consistently, investigators can reconstruct a timeline.

But suppose the password reset event exists only in one application log, the transaction appears in another system, timestamps use different time zones, and the authentication logs were deleted after seven days.

The technical investigation becomes much harder.

The legal investigation may become harder too.

A Practical Logging Checklist

Engineering teams can ask a few basic questions before an incident happens:

Do we know what events need to be logged?

Are timestamps consistent across our systems?

Can we identify the relevant user, service, or administrator?

Can logs be modified without appropriate authorization?

How long are important logs retained?

Who can access them?

Are logs backed up appropriately?

Can we reconstruct a significant security event from the available records?

Do our retention practices align with our privacy and legal obligations?

These are not purely legal questions.

They are architecture questions with legal consequences.

Developers Should Not Become Lawyers

There is an important balance here.

Developers should not be expected to determine whether a particular log will ultimately be admissible in court. That is a legal question requiring analysis of the facts and applicable law.

But engineering teams should understand that technical design decisions can affect the quality of information available to investigators and legal professionals later.

A lawyer cannot recover a log that was permanently deleted six months earlier.

A security team cannot reconstruct an event that was never recorded.

And a company cannot easily demonstrate the integrity of a record if its preservation process was undocumented.

The Broader Lesson

Modern software systems create enormous quantities of digital information.

Some of it is temporary.

Some of it is operational.

Some of it may eventually become important evidence.

The challenge is not to turn every application into a surveillance system. It is to identify the records that genuinely matter, protect them appropriately, and establish sensible retention and access practices.

Good engineering therefore has a legal dimension that is easy to overlook.

The strongest evidence is often not created when a lawsuit begins.

It is created quietly, through ordinary system design, months or years before anyone expects a dispute.

Disclaimer: This article is intended for general legal and technical awareness and does not constitute legal advice. The treatment and evidentiary value of electronic records depend on the facts of each matter and the applicable law.

The DPDP Act Is "In Force." Here's What That Actually Means for Your Codebase

Peesh Chopra — Mon, 10 Aug 2026 16:53:54 +0000

A three-person startup ships an MVP. It stores user phone numbers, email addresses and rough location data in a shared Postgres instance. There is no consent banner, no data retention job, no documented breach process. When a co-founder raises the Digital Personal Data Protection Act, the answer from the team is: "relax, it's not even fully in force yet."

That answer is half right and half dangerous. Understanding which half applies to your product is the difference between a weekend of groundwork now and a scramble later.

The Core Question

India's Digital Personal Data Protection Act, 2023 received presidential assent in August 2023 but sat without operative rules for two years. On November 13, 2025, the Ministry of Electronics and Information Technology notified the Digital Personal Data Protection Rules, 2025, along with the establishment of the Data Protection Board of India. That single notification changed the Act from a law on paper to a law with a working timetable.

The question developers actually need answered is not "is the DPDP Act in force." It is: which obligations are live today, which are switched off until a later date, and what should get built into the product architecture in the meantime.

Applicable Legal Framework

Three documents matter here.

The Digital Personal Data Protection Act, 2023 is the parent statute. It defines core roles: the Data Fiduciary (the entity that decides how and why personal data is processed, meaning most product companies), the Data Processor (anyone processing data on the fiduciary's behalf, which can include your cloud vendor or analytics tool), and the Data Principal (the individual whose data it is).

The Digital Personal Data Protection Rules, 2025 operationalise the Act's provisions, filling in procedural detail the Act itself left to delegated legislation, things like exact breach notification timelines, consent notice content, and children's data verification.

The enforcement notification issued alongside the Rules sets a staggered timeline. Provisions establishing the Data Protection Board came into force immediately on notification. Rules relating to Consent Managers become operative from November 13, 2026. The bulk of the substantive obligations, including detailed consent requirements, data principal rights, and the full breach notification and penalty regime, become enforceable from May 13, 2027.

So as of today, the regulator exists, the rulebook is published, but most compliance obligations carry an eighteen-month runway rather than an immediate deadline.

Regulatory and Constitutional Position

It helps to know why this framework exists in the first place. In Justice K.S. Puttaswamy (Retd.) v. Union of India, (2017) 10 SCC 1, a nine-judge bench of the Supreme Court held that privacy is a fundamental right under Article 21 of the Constitution. That judgment is the constitutional foundation the DPDP Act was eventually built on, and it is why courts are likely to read the Act's provisions in favour of individual control over personal data where the statutory language leaves room for interpretation.

On the regulatory side, the Data Protection Board of India is now a functioning body, though independent commentary has noted a lag between its formal establishment in November 2025 and its Chairperson and Members being fully appointed, which happened only around mid-2026. Enforcement capacity is still being built even as the legal obligation exists. That gap between "law is in force" and "regulator is fully staffed and enforcing" is common for new regulatory regimes and is worth factoring into your risk assessment, not your compliance timeline.

Practical Examples for Developers

Consider four situations that come up in ordinary product work.

A signup form collects a phone number and email for OTP-based login. Once the relevant consent provisions are live, that form needs a notice, in clear language and not just legalese buried in a privacy policy link, describing what data is collected and why, at or before the point of collection.

A mobile app uses a third-party analytics SDK. Under the Act, that SDK vendor is likely a Data Processor. The Data Fiduciary, meaning the app's own company, remains accountable for how that processor handles the data, so vendor contracts need data protection clauses even if the vendor is a well-known name.

A gaming or edtech app has users who are, or might be, under 18. Rule provisions on children's data require verifiable parental consent before processing a minor's data, and the Rules set out specific mechanisms considered acceptable for that verification.

A production database is exposed by a misconfigured access control setting. Under Rule 7 of the DPDP Rules, once the organisation becomes aware of a personal data breach, it must intimate the Board without delay with an initial description, followed by a detailed report within 72 hours of becoming aware, and must notify affected individuals as well. This is one of the provisions scheduled to become fully enforceable in the later phase of rollout, but building the internal detection and escalation workflow now is far cheaper than building it under pressure after an incident.

Common Mistakes

Founders and engineering leads tend to make the same handful of errors. Treating "not yet fully enforced" as "does not apply to us" is the biggest one; the obligations exist in the statute now and will become enforceable on a fixed date, not on a date of the company's choosing. Assuming GDPR compliance automatically covers DPDP compliance is another; the two frameworks overlap conceptually but differ on specifics like the definition of significant data fiduciary, breach notification content, and children's data thresholds. Treating the privacy policy as a substitute for an actual data inventory is a third; without knowing what personal data lives where, in which database, in which log file, in which third-party tool, a company cannot honestly assess its own exposure.

Practical Steps to Take Now

Start with a data inventory: list every place personal data is collected, stored, or sent to a third party, including logs and backups. Map every third-party processor, from your email service to your customer support tool, and check whether their terms include data protection commitments. Draft a breach response runbook that assumes a 72-hour clock starting from the moment the team becomes aware of an incident, not from when the investigation concludes. Build consent capture into the product now, even ahead of the enforceable date, since retrofitting consent UI into an existing user base is far more disruptive than designing it in from the start. Finally, keep a compliance log, dated notes of what was built and when, because demonstrating good-faith preparation matters if the Board ever asks.

Conclusion

The DPDP Act's phased rollout is not a grace period to ignore the law. It is a runway to build the right architecture before the obligations become enforceable and the penalty schedule, which runs up to several hundred crore rupees for serious violations, becomes a live risk rather than a future one. Treat the current phase as free engineering time, not free legal exposure.

Disclaimer: This article is intended for general legal awareness and does not constitute legal advice. Readers should consult a qualified advocate for guidance specific to their organisation's data processing activities and compliance obligations under the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025.