Hacking with computer systems, Data Alteration - Sec.66 (IT Act)

Section 66 of the IT Act (often explained as hacking) focuses on intentional acts that cause wrongful loss or damage by destroying, deleting, or altering data in a computer resource.

May 21, 2012

Section 66 of the Information Technology Act, 2000 is frequently explained through the idea of "hacking". The core concept in the commonly cited text is simple: if someone intentionally destroys, deletes, or alters information in a computer resource in a way that causes wrongful loss or damage, it can attract criminal liability.

Section 66 (IT Act): hacking with computer system, in plain English

The widely circulated wording describes hacking as destroying, deleting, or altering information residing in a computer resource (or otherwise diminishing its value or utility) with intent to cause, or knowledge of likely causing, wrongful loss or damage to the public or any person.

The same text sets out a punishment of imprisonment up to three years, or a fine up to two lakh rupees, or both.

What "wrongful loss or damage" looks like in practice

  • Business data deleted or overwritten (customer records, invoices, source repositories).
  • System configurations altered to break availability or weaken controls.
  • Logs manipulated so the timeline cannot be reconstructed.
  • Malware activity that corrupts files or disrupts operations.

What evidence usually makes or breaks the story

Most Section 66 narratives turn on whether you can show who accessed what, from where, and what changed. That means you need more than screenshots and assumptions.

  • Access trails: authentication logs, VPN logs, admin actions.
  • System state: forensic images, file metadata, integrity checks.
  • Timeline: incident notes, ticket history, deployment records.

If you are handling this as an organisation, treat it like an incident response job, not an internal argument. See incident response for the typical sequence, and application security for prevention patterns that reduce repeat incidents.

What to do first if you suspect a Section 66 incident

  • Stop the bleeding: isolate affected systems without wiping evidence.
  • Preserve logs and snapshots before remediation changes the facts.
  • Record decisions: who did what, when, and why.
  • Escalate early if the incident affects customers or regulated data.

Need help triaging and preserving evidence?

If you need a technical timeline and an evidence pack that can stand up to scrutiny, contact our team for incident triage and preservation support.

Found this helpful?

Share this page with others