Section 65: When Code Becomes Crime—Understanding Source Document Tampering
Published on January 3, 2026 • 12 min read
Picture this: A senior developer at a fintech startup, frustrated after being denied a promotion, decides to "get even" before resigning. Late one night, he modifies a critical authentication module in the company's payment gateway. The change is subtle—a single line that creates a backdoor, allowing transactions to bypass fraud detection under specific conditions. He commits the code, wipes his tracks, and walks out.
Three months later, the company discovers ₹2.3 crore in fraudulent transactions exploiting this exact vulnerability. The developer is long gone, working at a competitor. Can the company take legal action? Absolutely. Under Section 65 of the Information Technology Act, 2000, this isn't just a breach of employment contract—it's a criminal offense.
What is Section 65? The Statutory Text
Section 65 of the IT Act is titled "Tampering with Computer Source Documents." The bare text reads:
At first glance, this might seem like a niche provision affecting only government systems. In reality, it's one of the most critical IP protection tools for India's ₹7.4 trillion IT sector.
Breaking Down the Elements: What Constitutes an Offense?
For a violation of Section 65 to be established, four key elements must be present:
1. The Act: Concealment, Destruction, or Alteration
- Concealment: Hiding source code that must be disclosed (e.g., during audits, regulatory inspections, or legal discovery).
- Destruction: Permanently deleting code repositories, version control history, or documentation.
- Alteration: Modifying source code in a way that changes its functionality or obscures its original purpose.
2. The Target: Computer Source Code
"Source code" means human-readable instructions written in programming languages (Python, Java, C++, etc.) as opposed to compiled binaries. This includes:
- Application code, algorithms, and scripts
- Database schemas and stored procedures
- Configuration files with business logic
- Version control metadata (Git commits, change logs)
3. The Intent: Knowledge or Intentionality
This is the critical mens rea element. The act must be knowingly or intentionally done. Accidental deletion, honest mistakes, or bugs introduced during development are not covered. The prosecution must prove:
- The accused was aware the code existed and was legally protected.
- The tampering was deliberate, not negligent.
4. The Legal Obligation: Required by Law
This is where Section 65 becomes nuanced. The source code must be "required to be kept or maintained by law." This includes:
- Banking & Finance: RBI mandates source code escrow for core banking systems (Master Direction on IT Framework).
- E-Governance: Government procurement contracts often require source code deposits.
- Legal Discovery: When under investigation or litigation, courts can order source code preservation.
- SEBI-Registered Entities: Algorithmic trading platforms must maintain auditable code.
Real-World Applications: When Does Section 65 Apply?
Case Study 1: The Disgruntled Developer
A SaaS company discovers that a terminated employee deleted the entire Git repository of their proprietary CRM tool before leaving. The deletion was intentional (proven via Slack messages saying "they'll regret firing me"). The company had contractual obligations to maintain the code for client audits.
Outcome: Section 65 was invoked successfully. The key was proving (a) intentional destruction, and (b) the code was legally required under client contracts.
Case Study 2: Source Code Escrow Violation
A fintech partnered with a bank, agreeing to deposit source code in escrow as per RBI guidelines. The fintech submitted obfuscated code that was functionally useless. When audited, this was deemed "concealment."
Legal Issue: Was obfuscation "concealment"? Courts have held that if the intent is to prevent scrutiny while technically complying, it violates Section 65's spirit.
Case Study 3: Open Source Relicensing
A company built software using GPL-licensed code, then altered copyright headers and relicensed it proprietary. When the original authors sued, the company tried to destroy evidence by wiping commit history.
Result: Beyond copyright infringement, destruction of version control during pending litigation triggered Section 65.
Penalties: What's at Stake?
Section 65 is a cognizable (police can arrest without warrant) and bailable offense. Penalties include:
- Imprisonment: Up to 3 years
- Fine: Up to ₹2 lakh
- Or Both
While the statutory fine seems modest, civil damages in parallel IP litigation can run into crores. Additionally, corporate reputation damage in the tech industry is immeasurable.
Defense Strategies: Challenging Section 65 Allegations
If accused under Section 65, here are the primary defense avenues:
1. Lack of Intent
Argue that the alteration was accidental, part of routine maintenance, or due to system failures. Digital forensics can establish automated deletions vs. manual ones.
2. No Legal Obligation
Prove that the source code in question was not "required to be maintained by law." Proprietary internal tools with no regulatory or contractual mandates don't qualify.
3. Ownership Dispute
If the code was independently developed or open-sourced, the accused might argue they had rights to modify/delete it.
4. Procedural Flaws
Challenge the investigation: Was digital evidence collected properly? Was chain of custody maintained? Many Section 65 cases collapse due to poor cyber forensics.
Practical Compliance: Protecting Your Organization
For companies, compliance with Section 65 isn't just about avoiding prosecution—it's about safeguarding your most valuable asset: code.
For Tech Companies
- Version Control Discipline: Use Git/SVN with access logging. Never allow force pushes that rewrite history.
- Code Escrow Agreements: If contractually obligated, ensure deposits are current and verified.
- Employee Exit Protocols: Immediately revoke repository access. Conduct exit code audits for high-risk roles.
- Litigation Hold Procedures: When legal action is anticipated, institute automatic locks on all source code modifications.
For Developers
- Understand your employment IP assignment clauses. Code you write on company time isn't yours.
- Never alter code maliciously, even if leaving on bad terms. Section 65 has a 3-year imprisonment clause.
- If asked to destroy code during discovery, consult legal counsel immediately—compliance is a crime.
The Intersection with Other Laws
Section 65 doesn't operate in isolation. It overlaps with:
- Copyright Act, 1957: Software code is protected as "literary work." Destruction can be copyright infringement.
- Indian Penal Code Section 425 (Mischief): If tampering causes property damage.
- Trade Secrets Law: Altering code to hide misappropriation is both Section 65 and trade secret theft.
Prosecutors often charge multiple sections simultaneously to strengthen the case.
Conclusion: Code is Crown Jewel, Section 65 is the Guard
In the knowledge economy, source code is intellectual property's most liquid form. A single leaked or tampered algorithm can make or break billion-dollar valuations. Section 65 of the IT Act recognizes this reality, creating a criminal deterrent for those who would weaponize access to code.
For businesses, understanding Section 65 isn't optional—it's existential. For developers, it's a reminder that code, once written under contract, carries legal weight far beyond the repository.
The law is clear: your code may be digital, but the consequences of tampering with it are very, very real.
Facing allegations of source code tampering or need to secure your software IP? Our team combines deep technical understanding with cyber law expertise. From drafting source code escrow agreements to defending Section 65 prosecutions, we protect innovation. Contact Our IP & Cyber Law Practice.