Information Technology Act, 2000

Overview and Legislative Context

The Information Technology Act, 2000 ("IT Act") is India's primary legislation governing electronic records, digital transactions, cybersecurity, intermediary liability, and several forms of cybercrime. It was enacted to provide a legal framework for an increasingly digital economy, where communication, commerce, and government services were rapidly moving online.

Before the IT Act came into force, Indian law was largely designed for a paper-based world. While electronic communication was becoming more common, there was no comprehensive legal framework recognising electronic records or digital signatures. This created uncertainty around the validity of online transactions, electronic contracts, and digital evidence.

The IT Act addressed this gap by giving legal recognition to electronic records and digital signatures, allowing electronic transactions to enjoy the same legal validity as their paper-based counterparts. It also established a regulatory framework for certifying digital signatures, created civil and criminal liability for various cyber offences, and introduced mechanisms for adjudication and enforcement in matters involving information technology.

The Act was based largely on the UNCITRAL Model Law on Electronic Commerce, 1996, which sought to harmonise electronic commerce laws across different jurisdictions. India adopted many of its core principles, particularly the idea that electronic records and electronic communications should not be denied legal effect merely because they exist in digital form.

The IT Act came into force on 17 October 2000. However, it has evolved considerably since then.

Over time, technological developments exposed several gaps in the original legislation. The internet had expanded beyond electronic commerce into social media, online platforms, cloud computing, digital payments, and large-scale data processing. As cyber threats became more sophisticated, the original Act was no longer sufficient to address the realities of India's digital ecosystem.

To respond to these developments, Parliament enacted the Information Technology (Amendment) Act, 2008, which significantly expanded the scope of the legislation. Among other things, the amendment:

• strengthened the framework governing cyber offences;
• introduced data protection obligations for body corporates under Section 43A;
• established the legal basis for CERT-In as India's national cyber incident response agency;
• expanded the Government's powers relating to interception, monitoring, decryption, and blocking of online content;
• modernised provisions relating to digital signatures and electronic authentication; and
• introduced the modern framework governing intermediary liability and the safe harbour protection available under Section 79.

Today, the IT Act regulates far more than electronic commerce. It forms the backbone of India's digital legal framework and interacts with numerous subordinate rules, including:

• the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021;
• the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (SPDI Rules);
• the Blocking Rules, 2009;
• the Monitoring Rules, 2009;
• the Traffic Data Rules, 2009; and
• several rules governing digital signatures and Certifying Authorities.

The IT Act has also influenced amendments to several other statutes. To ensure that India's legal system could recognise and rely upon electronic records, it amended multiple existing laws, including:

• the Indian Penal Code, 1860;
• the Indian Evidence Act, 1872;
• the Bankers' Books Evidence Act, 1891; and
• the Reserve Bank of India Act, 1934.

These amendments ensured that electronic records, digital evidence, and electronic transactions could operate within India's broader legal system.

Why the IT Act is Criticised Today

Although the IT Act was a landmark piece of legislation when enacted, technology has evolved far more quickly than the law itself.

Many provisions were drafted before the emergence of smartphones, artificial intelligence, social media platforms, cloud computing, blockchain technology, and modern digital ecosystems. As a result, several provisions now struggle to address contemporary technological challenges.

Critics have also argued that some provisions grant broad powers to the Government, particularly in relation to surveillance, interception, monitoring, and blocking of online content. Others point to gaps in the Act's treatment of emerging technologies and the absence of a comprehensive, modern framework for digital governance.

The Future: Towards the Digital India Act

Recognising these limitations, the Ministry of Electronics and Information Technology (MeitY) has proposed replacing the IT Act with a new Digital India Act.

The proposed legislation is expected to adopt a more technology-neutral and future-oriented approach, addressing issues such as online safety, emerging technologies, artificial intelligence, platform regulation, and modern digital governance.

However, the Digital India Act has not yet been introduced in Parliament. Until it is enacted and brought into force, the Information Technology Act, 2000—together with the rules framed under it—continues to serve as the principal legislation governing information technology in India.

It is also important to read the IT Act alongside newer statutes, particularly the Digital Personal Data Protection Act, 2023 (DPDP Act), which establishes India's dedicated framework for personal data protection. Together, these statutes form the foundation of India's evolving digital regulatory landscape.

Commonly Used Terms in the Information Technology Act, 2000

Before diving into the substantive provisions of the IT Act, it is helpful to understand some of the key terms used throughout the legislation. Many of these definitions appear repeatedly in later chapters, so having a clear understanding of them will make the rest of the Act much easier to follow.

Legal Recognition of Electronic Records and Digital Signatures

One of the primary objectives of the Information Technology Act, 2000 was to remove the legal uncertainty surrounding electronic transactions. Before the Act was enacted, Indian law largely assumed that important documents would exist in physical form and would bear handwritten signatures. As business and government increasingly shifted online, this approach became impractical.

The IT Act addresses this problem by recognising electronic records and digital signatures as legally valid. In simple terms, the Act ensures that a document does not lose its legal value merely because it exists in digital form instead of on paper.

Section 4 – Legal Recognition of Electronic Records

What does Section 4 provide?

Section 4 states that where any law requires information to be:

• in writing;
• typewritten; or
• printed,

that requirement is satisfied if the information is made available in an electronic record, provided that the record is accessible and can be referred to whenever required.

In other words, a document cannot be rejected simply because it exists in electronic form.

Why is this important?

Section 4 is the legal foundation for India's digital economy.

Without it:

• emails would not have the same legal standing as letters;
• electronic contracts could be challenged merely because they were not printed;
• online banking records would have limited legal value;
• e-governance would become extremely difficult; and
• businesses would still need to maintain paper copies of almost every important document.

By giving legal recognition to electronic records, the Act allows individuals, businesses, and government departments to conduct transactions electronically with confidence.

Section 5 – Legal Recognition of Digital Signatures

While Section 4 recognises electronic documents, Section 5 recognises digital signatures.

Where any law requires a person's signature, that requirement is satisfied if the document is authenticated using a digital signature or any other electronic authentication technique recognised under the Act.

This places properly authenticated electronic signatures on the same legal footing as handwritten signatures.

Why are digital signatures important?

A handwritten signature mainly proves that a person intended to sign a document.

A digital signature goes much further.

It helps establish:

• who signed the document;
• whether the document has been altered after signing;
• whether the signature is genuine; and
• whether the signer can later deny having signed it (known as non-repudiation).

These safeguards make digital signatures significantly more secure than ordinary handwritten signatures in many situations.

Digital Signatures vs Electronic Signatures

Many people use these terms interchangeably, but they are not the same.

A digital signature is a specific type of electronic signature that uses cryptographic technology, particularly asymmetric encryption and hash functions.

An electronic signature is a broader concept. It includes any electronic method of indicating approval or consent that satisfies the legal requirements under Section 3A of the IT Act.

Every digital signature is an electronic signature.

However, not every electronic signature is a digital signature.

Sections 3 and 3A – Methods of Authentication

Section 3 – Digital Signatures

Section 3 recognises authentication through digital signatures based on asymmetric cryptography and hash functions. This remains the traditional and most secure method of authentication under the IT Act.

Section 3A – Electronic Signatures

Technology continues to evolve, and Parliament recognised that future authentication methods might not rely solely on traditional digital signatures.

Accordingly, Section 3A allows the Central Government to notify additional forms of electronic authentication, provided they satisfy prescribed standards of reliability, security, and integrity.

This ensures that the law remains technologically neutral and can adapt to future developments without requiring fresh legislation every time authentication technology evolves.

Digital Signature Certificates (DSCs)

A digital signature can only be trusted if the recipient knows that it genuinely belongs to the claimed individual.

This is where a Digital Signature Certificate (DSC) becomes important.

A DSC functions much like a digital identity card. It links a person's identity with their public cryptographic key and allows others to verify that a digital signature genuinely belongs to that individual.

Digital Signature Certificates are issued only by Certifying Authorities licensed under the IT Act.

These authorities operate under the supervision of the Controller of Certifying Authorities (CCA), who regulates their functioning and ensures compliance with the standards prescribed under the Act.

Why These Provisions Matter

Sections 3, 3A, 4, and 5 collectively form the legal backbone of electronic commerce in India, without which these provisions, countless everyday activities would face legal uncertainty, including:

• online banking;
• electronic contracts;
• e-commerce transactions;
• digital filing before government authorities;
• corporate compliance filings;
• GST and income tax returns;
• electronic procurement; and
• digital governance initiatives.

These provisions ensure that the law focuses on the reliability and authenticity of a document rather than the medium in which it exists. A document does not become legally inferior simply because it is stored on a server instead of in a filing cabinet.

Electronic Records as Evidence

As more and more communication, business transactions, and government records moved online, courts had to answer an important question:

Can an electronic record be used as evidence in the same way as a paper document?

The answer is yes—but only if certain legal requirements are met.

While Section 4 of the Information Technology Act gives legal recognition to electronic records, their admissibility in court is governed primarily by the Indian Evidence Act, 1872 (now substantially carried forward under the Bharatiya Sakshya Adhiniyam, 2023). The IT Act and the law of evidence therefore work together: the IT Act recognises electronic records as legally valid, while the Evidence Act lays down the conditions for proving them in court.

What is an electronic record?

As discussed earlier, an electronic record includes any information created, stored, received, or transmitted electronically. This covers emails, text messages, PDFs, photographs, CCTV footage, WhatsApp chats, databases, audio recordings, videos, and many other forms of digital information.

Today, electronic records appear in almost every legal dispute—from commercial litigation and contract disputes to criminal investigations and family law matters.

The challenge with electronic evidence

Unlike a paper document, an electronic record can be copied, edited, or deleted without leaving obvious signs of alteration. A photograph can be edited, an email can be manipulated, and a document can be modified in seconds.

Because digital evidence is easier to tamper with, the law requires additional safeguards before it is admitted in court. The purpose of these safeguards is not to make electronic evidence difficult to use, but to ensure that the record being produced is genuine and has not been altered.

Sections 65A and 65B of the Evidence Act

The special procedure for proving electronic records is contained in Sections 65A and 65B of the Indian Evidence Act, 1872.

Section 65A acts as the gateway provision. It states that the contents of an electronic record must be proved in accordance with Section 65B.

Section 65B then explains when a copy of an electronic record—such as a printout, CD, DVD, pen drive, or other computer output—can be treated as a document and admitted as evidence.

In other words, unlike ordinary documents, electronic records cannot usually be proved using the general rules of documentary evidence. They must satisfy the specific requirements laid down in Section 65B.

The Section 65B Certificate

One of the most important requirements under Section 65B is the certificate mentioned in Section 65B(4).

This certificate serves as proof that the electronic record is genuine. It must:

• identify the electronic record being produced;
• explain how it was created or obtained;
• describe the computer or device from which it was generated; and
• be signed by a person occupying a responsible position, such as an IT administrator, system manager, or another person familiar with the operation of the device.

The certificate essentially assures the court that the electronic record has been produced from a reliable source and has not been altered during the process.

Without this safeguard, it would often be difficult to distinguish genuine electronic evidence from manipulated or fabricated material.

Anvar P.V. v. P.K. Basheer (2014)

This case fundamentally changed the law on electronic evidence in India.

The dispute involved electronic evidence stored on CDs that had been produced in court without the certificate required under Section 65B.

The Supreme Court held that because electronic records are particularly vulnerable to alteration and manipulation, the safeguards contained in Section 65B are mandatory. As a result, electronic records that do not satisfy these requirements are generally not admissible as evidence.

This decision established Section 65B as the primary method of proving electronic records before Indian courts.

Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal (2020)

The Supreme Court later clarified that the requirement of a Section 65B certificate remains mandatory in most cases.

However, the Court also recognised that a party may not always have control over the device containing the electronic record. For example, CCTV footage may be held by a shopping mall, or call records may be in the custody of a telecom service provider.

In such situations, where the party cannot reasonably obtain the certificate themselves, the courts may adopt a more practical approach to ensure that justice is not defeated.

Sonu @ Amar v. State of Haryana (2017)

The Supreme Court held that objections relating to the absence of a Section 65B certificate should ordinarily be raised when the evidence is first produced. A party should not wait until the appeal stage to challenge its admissibility on this ground.

Union of India v. Ravindra Desai (2018)

The Court also recognised that, in appropriate cases, the absence of a Section 65B certificate may be treated as a curable defect. This means that the certificate can sometimes be produced later, depending on the circumstances of the case.

Why these provisions matter

Today, a significant portion of the evidence produced before courts exists only in digital form. Commercial contracts are negotiated through email, conversations take place on messaging applications, payments are made electronically, and surveillance cameras record important events.

Sections 65A and 65B ensure that courts can rely on these electronic records while protecting against fabrication and manipulation. Together, they strike a balance between embracing digital technology and preserving the integrity of the judicial process.

E-Contracts: Validity and Enforcement

Today, most contracts are entered into electronically rather than on paper. Whether you're opening a bank account online, subscribing to a streaming service, buying something on Amazon, or downloading an app, you're almost certainly entering into an electronic contract (or e-contract).

But this raises an obvious question:

Can a contract be legally valid even if no physical document is signed?

The answer is yes.

Section 10A of the Information Technology Act, 2000 makes it clear that a contract cannot be denied legal validity simply because it was formed through electronic means.

This provision works alongside the Indian Contract Act, 1872. An electronic contract must satisfy the same essential requirements as any other contract. In other words, it must contain:

• an offer;
• acceptance;
• lawful consideration;
• free consent;
• competent parties; and
• a lawful object.

The only difference is that these requirements are fulfilled electronically instead of through paper documents.

How are e-contracts authenticated?

Some electronic contracts are authenticated using digital signatures or other forms of electronic signatures recognised under Sections 3 and 3A of the IT Act.

However, many everyday online contracts do not require formal digital signatures. Instead, they rely on the user's conduct—for example, clicking a button, creating an account, or continuing to use a service after being presented with its terms.

Whether such contracts are enforceable depends largely on whether the user had a reasonable opportunity to read and accept the terms.

Types of Electronic Contracts

Electronic contracts generally fall into two broad categories.

Part II: Regulation of Digital Infrastructure

In the previous chapter, we saw how the Information Technology Act gives legal recognition to electronic records and digital signatures.

But that raises another important question.

How can someone trust that a digital signature actually belongs to the person who claims to have signed the document?

For example, suppose you receive a digitally signed contract from a company. How do you know that the digital signature genuinely belongs to that company and has not been forged?

The answer lies in a system known as Public Key Infrastructure (PKI).

The IT Act creates an entire legal framework to regulate this system. It identifies who can issue Digital Signature Certificates (DSCs), who supervises them, and how digital signatures are verified. Together, these institutions create a chain of trust that allows individuals, businesses, and government agencies to rely on electronic documents with confidence.

Controller of Certifying Authorities (CCA)

The Controller of Certifying Authorities (CCA) is the regulator responsible for India's digital signature ecosystem.

The Central Government appoints the CCA under Section 17 of the IT Act.

Its primary role is to regulate organisations known as Certifying Authorities (CAs), which are licensed to issue Digital Signature Certificates.

Think of the CCA as the regulator of digital identity providers. Just as a financial regulator supervises banks, the CCA supervises organisations that verify digital identities and issue Digital Signature Certificates.

Licensing Certifying Authorities

A company or organisation cannot begin issuing Digital Signature Certificates simply because it has the necessary technology.

Instead, it must first obtain a licence from the CCA under Section 21 of the IT Act.

Although the Act states that "any person" may apply for a licence, approval is granted only if the applicant satisfies the technical, financial, operational, and security standards prescribed under the Act and the relevant rules.

Before granting a licence, the CCA examines factors such as:

• technical expertise;
• security infrastructure;
• financial capability;
• qualified personnel; and
• compliance with the prescribed operational standards.

Only organisations that satisfy these requirements become licensed Certifying Authorities (CAs).

Supervising Certifying Authorities

The CCA's role does not end once a licence is granted.

It continues to supervise Certifying Authorities to ensure that they comply with the IT Act and the standards prescribed under it.

If a Certifying Authority fails to meet these requirements, the CCA may suspend or revoke its licence under Sections 25 and 26, after giving it an opportunity to be heard.

For example, the CCA may take action where:

• important information was concealed while applying for the licence;
• the Certifying Authority no longer satisfies the prescribed standards;
• it fails to comply with the Controller's directions; or
• its operations create security risks.

If a licence is suspended or revoked, the CCA must publish an appropriate notice so that users are aware that the organisation is no longer authorised to issue Digital Signature Certificates.

When can a licence be refused?

The Information Technology (Certifying Authorities) Rules, 2000 also specify circumstances in which the CCA may refuse to grant a licence.

For example, an application may be rejected if the applicant:

• fails to provide the required information;
• is being wound up or placed under the control of a court-appointed receiver;
• has been convicted of offences involving fraud or dishonesty;
• fails to furnish the required bank guarantee;
• does not comply with its Certification Practice Statement;
• fails to submit mandatory audit reports; or
• is otherwise unable to satisfy the Controller that it can safely perform the functions of a Certifying Authority.

These safeguards help ensure that only reliable organisations are entrusted with issuing Digital Signature Certificates.

Public Key Infrastructure (PKI)

The legal framework described above operates through Public Key Infrastructure (PKI).

PKI is the technical system that allows digital signatures to be trusted.

Earlier, we saw that digital signatures rely on public keys and private keys.

PKI builds on that idea by creating a chain of trust between everyone involved in the system.

Instead of asking every user to verify everyone else's identity individually, trusted authorities verify identities on behalf of everyone else.

This makes secure electronic communication possible on a national scale.

The Chain of Trust

India's Public Key Infrastructure works in layers.

At the top of the system is the Root Certifying Authority of India (RCAI).

Below it are the licensed Certifying Authorities (CAs).

Finally, at the bottom are the subscribers—the individuals, companies, and organisations that obtain Digital Signature Certificates.

Each level verifies the one below it.

As a result, anyone who trusts the Root Certifying Authority can ultimately trust the Digital Signature Certificate issued to an individual subscriber.

This layered structure is commonly referred to as the chain of trust.

How Public Key Infrastructure (PKI) Works

As we saw earlier, every digital signature relies on a public key and a private key. But this creates an important problem.

How do you know that a public key actually belongs to the person or organisation claiming to own it?

For example, imagine you receive a digitally signed contract from a company. The signature can only be verified using the company's public key.

But what if someone creates a fake public key and falsely claims that it belongs to the company?

If there were no way to verify ownership, digital signatures would quickly become unreliable.

This is exactly the problem that Public Key Infrastructure (PKI) solves.

Instead of asking every person to verify every public key themselves, PKI relies on trusted organisations that verify identities and issue Digital Signature Certificates. Anyone who trusts these organisations can also trust the certificates they issue.

The Chain of Trust

India's PKI follows a simple hierarchy where each level verifies the identity of the one below it.

As a result, when you verify someone's Digital Signature Certificate, you are not just trusting that individual—you are trusting the entire chain that issued the certificate.

Step 1: The Root Certifying Authority (RCAI)

At the top of India's PKI is the Root Certifying Authority of India (RCAI).

The RCAI is the highest level of trust in the system.

It does not issue Digital Signature Certificates directly to individuals or companies.

Instead, its role is to certify the organisations that are authorised to issue those certificates.

These organisations are called Certifying Authorities (CAs).

Once the Controller of Certifying Authorities grants a licence under Section 21, the RCAI digitally signs the Certifying Authority's public key.

This tells everyone:

"This Certifying Authority has been verified and can be trusted."

Step 2: Certifying Authorities

After becoming licensed, a Certifying Authority can begin issuing Digital Signature Certificates (DSCs) to subscribers.

These subscribers may include:

• individuals;
• companies;
• government departments; or
• other organisations.

Before issuing a certificate, the Certifying Authority must verify the applicant's identity.

Depending on the type of certificate, this may involve verifying documents such as:

• Aadhaar;
• PAN;
• Passport;
• organisational credentials; or
• other forms of identity prescribed by the Controller.

Some categories of certificates may also require biometric or video-based verification.

Only after completing this verification process can the Certifying Authority issue a Digital Signature Certificate.

Step 3: Creating the Digital Signature Certificate

Once the subscriber's identity has been verified, a pair of cryptographic keys is generated.

These consist of:

• a private key, which remains secret and is known only to the subscriber; and
• a public key, which forms part of the Digital Signature Certificate.

The private key is usually stored securely in a hardware token or other protected environment so that nobody else can access it.

The public key, on the other hand, is meant to be shared with anyone who wishes to verify the subscriber's digital signature.

What does the Digital Signature Certificate contain?

A Digital Signature Certificate contains much more than just the subscriber's public key.

It generally includes:

• the subscriber's public key;
• the subscriber's identity;
• the certificate's serial number;
• its validity period;
• the name of the issuing Certifying Authority;
• the hashing algorithm used; and
• the digital signature of the Certifying Authority.

Together, this information allows anyone receiving the certificate to verify both the subscriber's identity and the authenticity of the certificate itself.

Why doesn't the Certifying Authority sign the public key directly?

This is where hashing comes into the picture.

Instead of digitally signing the entire certificate, the Certifying Authority first runs the certificate through a hash function.

As discussed earlier, a hash function converts data into a fixed-length value known as a hash or digital fingerprint.

Even changing a single character in the certificate would produce an entirely different hash.

The Certifying Authority then encrypts this hash using its own private key.

The encrypted hash becomes the Certifying Authority's digital signature on the certificate.

This approach is much faster and more efficient than encrypting the entire certificate, while providing the same assurance that the certificate has not been altered.

How is the certificate verified?

Suppose someone receives a digitally signed document.

Before trusting the signature, they first verify the Digital Signature Certificate.

This happens in four steps.

Step 1: The verifier obtains the issuing Certifying Authority's public key.

Step 2: Using that public key, the verifier decrypts the Certifying Authority's digital signature attached to the certificate.

Step 3: The verifier independently generates a fresh hash of the certificate using the same hashing algorithm.

Step 4: The two hash values are compared.

If the hashes match, the verifier knows that:

• the certificate has not been altered;
• it was genuinely issued by the Certifying Authority; and
• the subscriber's public key can be trusted.

If the hashes do not match, the certificate has either been tampered with or is not genuine.

Why does the system work?

The entire system depends on trust flowing down the chain.

You trust the Root Certifying Authority of India.

Because the RCAI trusts a licensed Certifying Authority, you trust that Certifying Authority.

Because the Certifying Authority has verified the subscriber's identity before issuing the certificate, you can trust the subscriber's Digital Signature Certificate.

This layered verification process allows millions of people to exchange digitally signed documents without having to verify each other's identities individually.

Why PKI matters

Every time you digitally sign an income tax return, submit a filing to the Ministry of Corporate Affairs, participate in an e-procurement process, or execute a high-value electronic contract, Public Key Infrastructure is working behind the scenes.

Without PKI, there would be no reliable way to prove who signed an electronic document or whether it had been altered after it was signed.

The IT Act therefore combines cryptography with legal regulation to create a trusted digital ecosystem. By regulating Certifying Authorities and establishing a secure chain of trust, it ensures that digital signatures remain both technically reliable and legally enforceable.

Issuance, Suspension and Revocation of Digital Signature Certificates (DSCs)

A Digital Signature Certificate (DSC) is not permanent. Like a passport or driving licence, it can be issued, suspended, or revoked under certain circumstances.

The Information Technology Act lays down clear rules governing each stage of a certificate's lifecycle. These safeguards help ensure that Digital Signature Certificates remain trustworthy and cannot continue to be used if their authenticity or security is compromised.

Issuing a Digital Signature Certificate

As discussed earlier, a person or organisation seeking a Digital Signature Certificate must apply to a licensed Certifying Authority (CA) under Section 35 of the IT Act.

Before issuing the certificate, the Certifying Authority must verify the applicant's identity and ensure that all legal and technical requirements have been satisfied.

Once the verification process is complete, the Certifying Authority issues the Digital Signature Certificate, linking the subscriber's verified identity with their public key.

The subscriber can then use the corresponding private key to digitally sign electronic records.

Suspension of a Digital Signature Certificate

There may be situations where a Digital Signature Certificate should temporarily stop being used while an issue is investigated. In such cases, the Certifying Authority may suspend the certificate.

Under the IT Act, a Digital Signature Certificate may be suspended in two situations:

• at the request of the subscriber (or someone authorised to act on their behalf); or
• where the Certifying Authority considers suspension necessary in the public interest.

Suspension is generally intended to be a temporary measure. For example, a subscriber may request suspension if they believe their private key has been compromised or their hardware token has been lost.

Opportunity to be heard

The Act also provides an important safeguard.

If a suspension is likely to continue for more than 15 days, the subscriber must first be given an opportunity to be heard.

This ensures that certificates are not suspended for extended periods without following principles of natural justice.

Revocation of a Digital Signature Certificate

Revocation is different from suspension.

While suspension is temporary, revocation permanently cancels the certificate, meaning it can no longer be used.

A Certifying Authority may revoke a Digital Signature Certificate in several circumstances.

At the subscriber's request

A certificate may be revoked if:

• the subscriber requests its cancellation; or
• an authorised representative makes the request on the subscriber's behalf.

Where the subscriber no longer exists

A certificate may also be revoked if:

• the subscriber has died; or
• the subscriber is a company, firm, or other organisation that has been dissolved, wound up, or otherwise ceased to exist.

Since the subscriber no longer exists, there is no longer any purpose in keeping the certificate active.

Where the certificate should never have remained valid

The Certifying Authority may also revoke a certificate where serious problems affect its validity, including where:

• important facts were concealed or misrepresented while obtaining the certificate;
• the legal requirements for issuing the certificate were never satisfied;
• the Certifying Authority's own private key or security system has been compromised; or
• the subscriber has been declared insolvent or otherwise becomes legally incapable of continuing to hold the certificate.

In each of these situations, allowing the certificate to remain active could undermine the reliability of the digital signature system.

Opportunity to be heard

Before revoking a Digital Signature Certificate, the subscriber must generally be given an opportunity to present their case.

This reflects the broader principle of natural justice, ensuring that a person's digital identity cannot be cancelled without following a fair procedure.

Notice of suspension or revocation

Whenever a Digital Signature Certificate is suspended or revoked, the Certifying Authority must:

• notify the subscriber; and
• publish the suspension or revocation in the certificate repository referred to in the certificate.

This allows anyone relying on the certificate to verify whether it is still valid before accepting a digitally signed document.

X.509 Certificate Policy for India

The IT Act provides the legal framework for Digital Signature Certificates, but the detailed technical standards governing their use are contained in the X.509 Certificate Policy for India.

This policy lays down the operational and security requirements that licensed Certifying Authorities must follow. Among other things, it governs:

• the issuance and management of Digital Signature Certificates;
• identity verification procedures;
• security standards for key management;
• certificate validity and renewal; and
• the circumstances in which certificates may be suspended or revoked.

Together with the IT Act and the Information Technology (Certifying Authorities) Rules, the X.509 Certificate Policy forms the technical backbone of India's Public Key Infrastructure.

Why these provisions matter

The reliability of digital signatures depends on more than just cryptography—it also depends on trust.

If compromised or invalid certificates could continue to be used indefinitely, it would become much easier to impersonate individuals, forge electronic documents, and undermine confidence in digital transactions.

By regulating how Digital Signature Certificates are issued, suspended, and revoked, the IT Act ensures that only valid and trustworthy certificates remain in circulation. This is essential for maintaining confidence in electronic contracts, e-governance, digital filings, and countless other online transactions that rely on digital signatures.

Part III: Cybersecurity and Privacy

As technology has become more deeply integrated into everyday life, so have the risks associated with it. Today, individuals and organisations routinely store sensitive information—such as financial records, medical information, business data, and personal communications—in digital form.

While this has made information easier to access and share, it has also made it easier to steal, manipulate, or destroy.

Cybercriminals can hack into computer systems, steal confidential information, install malicious software, disrupt online services, or impersonate individuals for financial gain. In many cases, these attacks occur without the knowledge of the person whose data has been compromised.

The Information Technology Act addresses these risks through a combination of preventive measures, civil liability, criminal offences, and institutional mechanisms for responding to cybersecurity incidents.

What is Cybersecurity?

Section 2(1)(nb) of the IT Act defines cybersecurity as the protection of:

• information;
• computers;
• computer resources;
• communication devices;
• networks; and
• the information stored on them,

from unauthorised access, use, disclosure, disruption, modification, or destruction.

Put simply, cybersecurity is about ensuring that digital systems remain secure, reliable, and available only to authorised users.

Although the Act does not define the term cybercrime, most cyber offences involve the unauthorised use of a computer system or computer resource to access, manipulate, damage, or steal digital information.

How does the IT Act regulate cybersecurity?

The IT Act adopts a three-layered approach to cybersecurity.

Section 43A – Liability for Failure to Protect Data

Section 43A applies specifically to body corporates, such as companies and other organisations that collect or process personal information.

It provides that a body corporate may be liable to pay compensation if three conditions are satisfied:

• it possesses, deals with, or handles Sensitive Personal Data or Information (SPDI);
• the information is handled through a computer resource that the organisation owns, controls, or operates; and
• a person's wrongful loss or another person's wrongful gain results from the organisation's failure to implement reasonable security practices and procedures.

In simple terms, Section 43A says that organisations cannot ignore cybersecurity. If they fail to take reasonable steps to protect sensitive information and that failure causes harm, they may be required to compensate the affected person.

Why were the SPDI Rules introduced?

Section 43A established the obligation to protect sensitive information, but it left several important questions unanswered.

For example:

• What exactly counts as Sensitive Personal Data or Information?
• What are reasonable security practices?
• Does every data breach automatically mean that an organisation failed to provide adequate security?

The SPDI Rules answer these questions by setting out the standards that organisations are expected to follow when collecting, storing, using, and sharing sensitive personal information.

They effectively translate the broad obligations contained in Section 43A into practical compliance requirements.

Why this matters

Section 43A and the SPDI Rules represented India's first comprehensive attempt to regulate how private organisations protect personal information.

Although many aspects of data protection are now governed by the Digital Personal Data Protection Act, 2023, the SPDI Rules remain an important part of the IT Act and continue to apply in contexts where they have not been displaced. They also provide valuable insight into how Indian data protection law evolved before the enactment of a dedicated privacy statute.

The SPDI Rules, 2011

The Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, commonly known as the SPDI Rules, were introduced to give practical effect to Section 43A of the IT Act.

While Section 43A establishes that organisations can be held liable for failing to protect sensitive personal information, the SPDI Rules explain what information is protected and what organisations must do to protect it.

Although India now has the Digital Personal Data Protection Act, 2023 (DPDP Act), the SPDI Rules remain an important part of India's digital law framework and continue to illustrate the country's earlier approach to data protection.

What is Sensitive Personal Data or Information (SPDI)?

The SPDI Rules distinguish between personal information and Sensitive Personal Data or Information (SPDI).

Personal Information

Under Rule 2(1)(i), personal information means any information relating to a natural person that can identify that person, either by itself or when combined with other information that is reasonably available.

For example, information such as a person's name, address, email address, or phone number may qualify as personal information if it can be linked to an identifiable individual.

Sensitive Personal Data or Information (SPDI)

Some categories of personal information are considered especially sensitive because unauthorised access to them could cause significant harm.

Rule 3 classifies the following as Sensitive Personal Data or Information (SPDI):

• passwords;
• financial information, such as bank account or payment card details;
• physical, physiological, and mental health information;
• medical records and medical history;
• biometric information; and
• any information relating to these categories that is provided to a body corporate for providing a service.

These categories receive greater legal protection because they are more likely to expose individuals to financial loss, identity theft, discrimination, or other forms of harm if they are compromised.

It is important to remember that these obligations apply only to body corporates. The SPDI Rules do not impose the same compliance requirements on individuals acting in a personal capacity.

Collecting SPDI

The SPDI Rules do not prohibit organisations from collecting sensitive information. Instead, they regulate how it may be collected.

The basic principle is simple:

Collect only what you genuinely need, and tell people why you are collecting it.

Retaining and Using SPDI

Collecting information is only the beginning. Organisations must also ensure that they use and retain it responsibly. The SPDI Rules create a framework for that as well:

Sharing SPDI

The SPDI Rules also regulate when sensitive information may be shared with others.

Reasonable Security Practices

Perhaps the most important obligation under the SPDI Rules is the requirement to implement reasonable security practices and procedures.

Rule 8 recognises ISO/IEC 27001, an internationally accepted information security standard, as one recognised benchmark for compliance.

Organisations are expected to implement appropriate:

• technical safeguards;
• managerial safeguards; and
• organisational policies

to protect the information they handle.

The exact measures required will depend on the nature of the organisation and the risks associated with its activities.

Alternative security standards

Some industries may follow security standards other than ISO/IEC 27001.

The SPDI Rules permit this, provided those standards receive approval from the Central Government.

This allows the law to remain flexible as cybersecurity standards continue to evolve.

Regular security audits

Compliance is not a one-time exercise.

Rule 8 requires organisations to conduct security audits:

• at least once every year; or
• whenever significant changes are made to their systems or security infrastructure.

Regular audits help organisations identify vulnerabilities before they result in data breaches or cybersecurity incidents.

Why these Rules matter

The SPDI Rules introduced many concepts that are now considered fundamental to modern privacy law, including:

• informed consent;
• purpose limitation;
• data minimisation;
• storage limitation;
• correction rights;
• security safeguards; and
• accountability for organisations handling sensitive personal information.

Although many of these concepts have since been expanded and modernised under the Digital Personal Data Protection Act, 2023, the SPDI Rules marked India's first comprehensive attempt to regulate how private organisations collect, use, store, and protect personal information.

Punitive Measures under the IT Act

The IT Act does more than recognise electronic records and regulate digital infrastructure. It also creates a legal framework for dealing with cyber offences.

Broadly speaking, the Act provides two kinds of consequences when someone misuses a computer or computer system:

• Civil liability, where the wrongdoer must compensate the victim for the loss caused; and
• Criminal liability, where the wrongdoer may be prosecuted and punished with imprisonment, a fine, or both.

The distinction is important because not every cybersecurity incident is a crime. Some acts merely require the wrongdoer to compensate the victim, while others are considered serious enough to attract criminal punishment.

In some situations, both civil and criminal proceedings may arise from the same incident.

Civil Liability – Section 43

Section 43 is the primary civil liability provision under the IT Act.

It provides that a person who accesses or interferes with another person's computer, computer system, computer network, or computer resource without permission, and causes loss or damage, may be required to pay compensation to the affected person.

Unlike many criminal provisions, Section 43 does not require dishonest or fraudulent intent. The focus is on the unauthorised act and the harm it causes.

What kinds of activities are covered?

Section 43 covers a wide range of unauthorised activities, including:

• accessing a computer or computer network without permission;
• downloading, copying, or extracting data without authorisation;
• introducing malware, viruses, or other harmful software;
• damaging or disrupting computer systems or networks;
• denying authorised users access to computer resources;
• assisting another person in gaining unauthorised access;
• manipulating computer systems to wrongfully charge another person for services;
• destroying, deleting, or altering data; and
• stealing, concealing, or modifying computer source code where such acts cause loss or damage.

The provision is deliberately broad so that it can address many different forms of unauthorised interference with computer systems.

What does "without permission" mean?

The IT Act does not define what amounts to valid permission.

In practice, unauthorised access generally arises where a person:

• accesses a computer system without the owner's consent;
• exceeds the authority that has been given to them; or
• circumvents technical or contractual restrictions imposed by the owner.

For example, an employee who accesses confidential files beyond the scope of their authorised role may be acting without permission, even though they are otherwise permitted to use the company's computer system.

What counts as "access"?

The Act defines access broadly.

It is not limited to hacking over the internet.

A person may gain unauthorised access by:

• remotely entering a computer system through a network;
• exploiting software vulnerabilities;
• bypassing passwords or other security measures; or
• physically accessing a computer's hardware or storage devices without authorisation.

In other words, both digital and physical methods of gaining unauthorised access may fall within Section 43.

Why is unauthorised access taken so seriously?

Unauthorised access is often the starting point for more serious cyber offences.

The Law Commission of England and Wales identified three major harms associated with unauthorised access:

• it can cause financial loss to the owner of the computer system;
• it often serves as the first step towards more serious cybercrimes; and
• repeated cyberattacks reduce public confidence in digital systems and discourage investment in technology.

These concerns are equally relevant today, particularly as businesses and governments become increasingly dependent on digital infrastructure.

What amounts to "damage"?

Section 43 adopts a very broad definition of damage.

Damage includes:

• destroying data;
• deleting information;
• altering files;
• adding or modifying data;
• rearranging information; or
• damaging computer systems, databases, software, or networks.

The law therefore recognises that digital harm is not limited to physically destroying a computer. Altering or interfering with digital information may be equally harmful.

Compensation

Originally, the IT Act capped compensation under Section 43 at ₹5 crore.

However, the Information Technology (Amendment) Act, 2008 removed this limit.

Today, the amount of compensation depends on the value of the claim.

Under Section 46(1A):

• claims up to ₹5 crore are decided by the Adjudicating Officer appointed under the Act; and
• claims exceeding ₹5 crore must be brought before the court having the appropriate pecuniary jurisdiction.

This allows compensation to be assessed according to the actual loss suffered rather than an arbitrary statutory ceiling.

Civil Liability vs Criminal Liability

Not every unauthorised act amounts to a crime.

A person may accidentally damage another's computer system or exceed authorised access without any intention to deceive or cause wrongful gain.

In such cases, civil liability under Section 43 may be sufficient.

However, where the same acts are carried out dishonestly or fraudulently, the IT Act treats them much more seriously.

These situations fall under the criminal provisions beginning with Section 65.

The key difference is intent.

Civil liability focuses on the damage caused.

Criminal liability focuses on both the damage and the offender's state of mind.

Criminal Offences under the IT Act

The IT Act creates a number of criminal offences for more serious forms of cyber misconduct.

Unlike Section 43, these provisions generally require proof of a particular mental element—such as knowledge, dishonesty, fraud, or intent.

Because criminal convictions can result in imprisonment, the prosecution must establish these elements beyond reasonable doubt.

Relationship with other criminal laws

Many cyber offences may also appear to fall under general criminal laws such as the Indian Penal Code, 1860 (now largely replaced by the Bharatiya Nyaya Sanhita, 2023).

Where this happens, an important legal principle applies:

A special law overrides a general law when both deal with the same subject matter.

This principle is expressed through the Latin maxim generalia specialibus non derogant.

Since the IT Act is a specialised law dealing specifically with cyber offences and electronic records, its provisions generally prevail where there is direct overlap.

Section 65 – Tampering with Computer Source Code

Computers and software operate using source code—the human-readable instructions that tell a computer how to perform a particular task. In many cases, organisations are legally required to preserve this source code, either because of regulatory requirements or because it forms part of an official computer system.

Section 65 of the IT Act makes it a criminal offence to tamper with such source code where the law requires it to be maintained.

A person commits an offence if they knowingly or intentionally:

• conceal;
• destroy; or
• alter

computer source code that is legally required to be kept or maintained.

The offence is punishable with:

• imprisonment of up to three years;
• a fine of up to ₹2 lakh; or
• both.

Why does this provision exist?

Source code forms the foundation of many critical digital systems. If it is deliberately altered or destroyed, it may become impossible to understand how a system operated or whether it has been manipulated.

For example, imagine a company that is legally required to maintain the source code of software used to process financial transactions. If an employee deliberately deletes or modifies that source code to conceal fraud, investigators may no longer be able to determine how the system originally functioned.

Section 65 seeks to prevent precisely this kind of misconduct by protecting the integrity of legally maintained source code.

A note on interpretation

Terms such as "conceals," "destroys," and "alters" are not exhaustively defined in the IT Act.

As a result, courts interpret these expressions based on their ordinary meaning and the facts of each case. Over time, judicial decisions will continue to shape the precise scope of this provision.

Section 66 – Computer-Related Offences

Section 66 builds directly on Section 43.

As we saw earlier, Section 43 imposes civil liability for unauthorised access to, or interference with, a computer system.

Section 66 takes those very same acts and makes them criminal offences when they are committed dishonestly or fraudulently.

In other words:

Section 43 tells you what acts are prohibited. Section 66 tells you when those acts become crimes.

A person who commits any of the acts listed in Section 43 dishonestly or fraudulently may be punished with:

• imprisonment of up to three years;
• a fine of up to ₹5 lakh; or
• both.

What do "dishonestly" and "fraudulently" mean?

These terms are not defined in the IT Act itself.

Instead, the Act relies on the definitions found in the Indian Penal Code, 1860 (now reflected in the Bharatiya Nyaya Sanhita, 2023).

Dishonestly

A person acts dishonestly when they intend to cause:

• wrongful gain to themselves or another person; or
• wrongful loss to someone else.

For example, hacking into another person's bank account to transfer money would clearly involve dishonest intent.

Fraudulently

A person acts fraudulently when they act with the intention of deceiving another person.

Fraud generally involves two elements:

• deception; and
• injury or prejudice caused by that deception.

For example, creating a fake online banking website to steal customers' login credentials would amount to acting fraudulently.

When does Section 66 apply?

To establish an offence under Section 66, the prosecution must generally prove two things:

1. the accused committed one of the unauthorised acts listed in Section 43; and
2. the act was committed dishonestly or fraudulently.

Without this additional mental element, the conduct may still attract civil liability under Section 43, but it will not ordinarily amount to a criminal offence under Section 66.

Can a person face both civil and criminal proceedings?

Yes.

A person who commits a computer-related offence may face:

• a civil claim for compensation under Section 43; and
• criminal prosecution under Section 66.

These proceedings are independent of one another.

This means that compensation awarded in a civil proceeding does not prevent the State from prosecuting the offender for the criminal offence.

Similarly, an acquittal in a criminal case does not automatically prevent a victim from pursuing civil compensation where the legal requirements are otherwise satisfied.

Why is Section 66 important?

Section 66 is often described as the IT Act's general cybercrime provision because it applies to a wide range of unauthorised activities involving computer systems.

Many cyber offences begin with conduct that falls under Section 43—for example, gaining unauthorised access to a computer or copying confidential information. When those same acts are carried out with dishonest or fraudulent intent, Section 66 transforms what would otherwise be a civil wrong into a criminal offence.

This provision therefore acts as the bridge between civil liability and criminal punishment, making it one of the most frequently invoked sections of the IT Act.

Section 66A – Sending Offensive Messages (Repealed)

Important: Section 66A is no longer law. The Supreme Court declared it unconstitutional in Shreya Singhal v. Union of India (2015), and it cannot be used to prosecute anyone today.

Despite being repealed, Section 66A remains one of the most significant provisions in the history of India's internet laws because it fundamentally shaped the relationship between free speech and online regulation.

What did Section 66A provide?

Before it was struck down, Section 66A made it a criminal offence to send electronic messages that were:

• grossly offensive;
• menacing in nature;
• information known to be false but sent to cause annoyance, inconvenience, danger, obstruction, insult, injury, criminal intimidation, enmity, hatred, or ill will; or
• messages sent by email or other electronic communication for the purpose of misleading recipients about their origin.

The offence was punishable with:

• imprisonment of up to three years;
• a fine; or
• both.

At first glance, the provision appeared to target online abuse and harmful communications. In practice, however, its wording was so broad that it became a tool for prosecuting a wide range of online speech.

Why was it controversial?

The biggest criticism of Section 66A was that many of its key expressions were never defined.

Terms such as:

• "grossly offensive";
• "annoyance";
• "inconvenience";
• "ill will"; and
• "hatred"

were vague and highly subjective.

What one person considers offensive may simply be criticism or satire to someone else.

Because the provision did not clearly define its limits, it gave law enforcement authorities wide discretion to decide what kinds of online speech should attract criminal liability.

This created significant uncertainty and raised concerns about freedom of speech.

How was Section 66A used?

The broad wording of the provision meant that it was invoked in many situations that had little to do with genuine cybercrime.

For example:

• In Abu v. State of Kerala, Section 66A was invoked in a case involving allegations of blackmail.
• In Sushmit Sunilbhai Roy v. State of Gujarat, it was used in proceedings relating to dowry harassment.
• In Tintu Shaji v. State of Kerala, it was invoked in connection with the unauthorised publication of a news excerpt.

These cases illustrated how the provision extended far beyond its original objective and was increasingly being used in disputes involving ordinary online communication.

Shreya Singhal v. Union of India (2015)

Section 66A ultimately came before the Supreme Court in one of the most important constitutional cases involving the internet.

The case arose after two young women were arrested for Facebook posts questioning the shutdown of Mumbai following the death of political leader Bal Thackeray.

Although the criminal proceedings against them were eventually dropped, the incident sparked nationwide debate about the misuse of Section 66A.

This led to a constitutional challenge before the Supreme Court.

The challenge

The petitioners argued that Section 66A violated Article 19(1)(a) of the Constitution, which guarantees the fundamental right to freedom of speech and expression.

While Article 19(2) allows the Government to impose reasonable restrictions on free speech—for example, in the interests of national security, public order, defamation, or incitement to an offence—the petitioners argued that Section 66A went far beyond these recognised grounds.

Because the provision criminalised vague concepts such as "annoyance" and "offensive" messages, it could potentially cover a vast amount of legitimate online speech.

This, they argued, would discourage people from expressing their opinions freely—a phenomenon often described as the "chilling effect" on free speech.

The Government's arguments

The Government defended Section 66A by arguing that Parliament has the authority to enact laws addressing new challenges posed by the internet.

It also argued that the possibility of misuse should not, by itself, be a reason to declare a law unconstitutional. According to the Government, misuse could be addressed through better enforcement rather than by striking down the provision altogether.

The Supreme Court's decision

The Supreme Court unanimously struck down Section 66A as unconstitutional.

The Court held that the provision was vague, overbroad, and disproportionate.

In particular, it observed that expressions such as "grossly offensive" and "annoyance" had no clear legal meaning. As a result, people could not reasonably know what conduct was prohibited.

The Court also found that Section 66A criminalised protected speech without requiring any real connection to the grounds listed in Article 19(2), such as public order, defamation, or incitement to an offence.

Simply causing annoyance or inconvenience could not justify criminal punishment.

Because of its broad wording, the provision had the potential to discourage lawful criticism, satire, political discussion, and other forms of legitimate expression on the internet.

The Court therefore declared Section 66A unconstitutional in its entirety.

Why Shreya Singhal matters

The decision is widely regarded as one of the most important free speech judgments in Indian constitutional law.

It established several important principles:

• restrictions on online speech are subject to the same constitutional protections as offline speech;
• criminal laws affecting speech must be clear and precisely drafted;
• vague or overbroad laws that discourage lawful expression may violate the Constitution; and
• freedom of speech cannot be restricted merely because someone finds a statement offensive or annoying.

The judgment continues to shape debates on platform regulation, online content moderation, intermediary liability, and digital free speech in India.

Offences Against Individuals

While Sections 65 and 66 primarily protect computers and computer systems, the next set of offences focuses on protecting people.

These provisions deal with situations where technology is used to:

• possess or use stolen devices;
• steal another person's digital identity;
• impersonate someone online; or
• invade an individual's privacy.

Together, they address some of the most common forms of cybercrime encountered today.

Section 66B – Receiving or Retaining Stolen Computer Resources

Technology has made electronic devices extremely valuable—not just because of the devices themselves, but because of the sensitive information they contain.

A stolen laptop, mobile phone, or hard drive may contain financial records, confidential business information, personal photographs, passwords, or access to online accounts.

Recognising this, Section 66B makes it a criminal offence to dishonestly receive or retain a stolen computer resource or communication device when the person knows, or has reason to believe, that it has been stolen.

The offence is punishable with:

• imprisonment of up to three years;
• a fine of up to ₹1 lakh; or
• both.

Why was this provision introduced?

Ordinary theft laws already punish the theft of property.

However, Section 66B addresses a different problem—the circulation and use of stolen digital devices.

For example, someone who knowingly purchases a stolen laptop containing confidential company data may not have committed the original theft, but they are still contributing to the misuse of stolen computer resources.

The provision therefore discourages the secondary market for stolen electronic devices and helps protect the sensitive information stored on them.

Section 66C – Identity Theft

One of the fastest-growing forms of cybercrime is identity theft.

Instead of stealing physical property, cybercriminals steal digital credentials that allow them to impersonate another person.

Section 66C makes it an offence to dishonestly or fraudulently use another person's:

• electronic signature;
• password; or
• any other unique identification feature.

The punishment is:

• imprisonment of up to three years;
• a fine of up to ₹1 lakh; or
• both.

What is a "unique identification feature"?

The IT Act does not define this expression.

This is intentional.

Rather than limiting the law to existing technologies, Parliament adopted a broad phrase capable of covering new methods of digital identification as technology evolves.

Depending on the circumstances, a unique identification feature may include:

• one-time passwords (OTPs);
• biometric credentials;
• authentication tokens;
• digital certificates;
• Aadhaar-based authentication credentials; or
• other technologies used to uniquely identify an individual.

This flexible approach helps ensure that the provision remains relevant as new authentication technologies emerge.

Why does identity theft matter?

Many online services rely entirely on digital credentials.

If someone gains access to another person's password, OTP, or digital authentication token, they may be able to:

• access bank accounts;
• make financial transactions;
• impersonate the victim online;
• obtain confidential information; or
• commit further cyber offences.

Section 66C therefore criminalises the misuse of digital identity even before it is used to deceive someone else.

Section 66D – Cheating by Personation Using Computer Resources

Identity theft and impersonation often occur together, but they are not the same.

While Section 66C focuses on stealing or misusing another person's identity, Section 66D applies when that stolen identity is actually used to deceive someone.

Section 66D makes it a criminal offence to cheat by personation using a computer resource or communication device.

The punishment is:

• imprisonment of up to three years;
• a fine of up to ₹1 lakh; or
• both.

What is "cheating by personation"?

The concept comes from the general law of cheating.

A person commits cheating by personation when they pretend to be someone else in order to deceive another person.

This may involve:

• pretending to be a real individual;
• pretending to represent an organisation;
• assuming a false identity; or
• knowingly allowing someone else to be mistaken for another person.

Section 66D applies this traditional concept to the digital world.

Section 66C vs Section 66D

Although the two provisions often arise together, they punish different conduct.

A simple way to remember the distinction is:

Section 66C is about stealing an identity. Section 66D is about using that identity to cheat someone.

The same incident may involve both offences.

For example, a cybercriminal who steals another person's banking credentials (Section 66C) and then uses those credentials to fraudulently transfer money (Section 66D) may be prosecuted under both provisions.

Section 66E – Violation of Privacy

The increasing use of smartphones, hidden cameras, and social media has made privacy violations easier than ever before.

Section 66E was introduced by the Information Technology (Amendment) Act, 2008 to address this growing problem.

The provision makes it a criminal offence to intentionally capture, publish, or transmit images of another person's private area without their consent, where the person has a reasonable expectation of privacy.

The punishment is:

• imprisonment of up to three years;
• a fine of up to ₹2 lakh; or
• both.

What is a "private area"?

The Act defines a private area to include:

• the genitals;
• the pubic area;
• the buttocks; and
• the female breast,

whether uncovered or covered only by undergarments.

The provision therefore protects against much more than complete nudity.

What is a "reasonable expectation of privacy"?

Whether a person has a reasonable expectation of privacy depends on the circumstances.

For example, individuals would ordinarily expect privacy when they are:

• using a restroom;
• changing clothes in a trial room;
• inside a hotel room;
• receiving medical treatment; or
• in another private setting where they would not reasonably expect to be photographed or recorded.

Capturing or sharing images taken in such situations without consent may amount to an offence under Section 66E.

Consent is the key

The central element of Section 66E is consent.

Even if a person knows they are being photographed, that does not necessarily mean they have consented to the image being shared or published.

Similarly, sending the image privately to a single individual may still amount to an offence.

The law does not require the image to be widely circulated—even a one-to-one transmission can violate the victim's privacy.

This reflects the broader recognition of privacy as a fundamental right under K.S. Puttaswamy v. Union of India, where the Supreme Court affirmed that informational and bodily privacy form part of the right to life and personal liberty under Article 21 of the Constitution.

Why these provisions matter

Technology has changed the nature of crime.

Many offences today no longer involve breaking into homes or stealing physical documents. Instead, they involve stolen passwords, hacked accounts, fake identities, online impersonation, and unauthorised sharing of intimate images.

Sections 66B to 66E recognise this shift. Rather than protecting computers alone, they protect the people who use them by criminalising some of the most common forms of digital exploitation and abuse.

Sections 67, 67A and 67B – Obscene Content, Sexually Explicit Material, and Child Sexual Abuse Material

The IT Act contains three escalating provisions dealing with objectionable content published or shared online — moving from general obscenity, to sexually explicit material, to the most serious category: child sexual abuse material (CSAM).

Section 67 – Publishing or Transmitting Obscene Material

Section 67 punishes anyone who publishes or transmits obscene material in electronic form — content that is lustful, sexually offensive, or intended to arouse sexual interest, particularly where it is likely to deprave or corrupt those who see it. This covers material shared through websites, messaging apps, emails, or social media.

The punishment depends on whether it's a first or repeat offence:

• First offence: up to 3 years' imprisonment and a fine of up to ₹5,00,000
• Repeat offence: up to 5 years' imprisonment and a fine of up to ₹10,00,000

Section 67A – Sexually Explicit Material

Section 67A, added in 2008, targets content that goes beyond general obscenity — material that depicts actual sexual acts or conduct, rather than merely suggestive or lustful imagery. The punishment is correspondingly stricter:

• First offence: up to 5 years' imprisonment and a fine of up to ₹10,00,000
• Repeat offence: up to 7 years' imprisonment and a fine of up to ₹10,00,000

Section 67A is, in some ways, more straightforward to apply than Section 67. While Section 67 turns on how society perceives the material, Section 67A focuses on whether the content depicts an actual sexual act — a more objective question that doesn't depend as heavily on evolving social standards.

Section 67B – Child Sexual Abuse Material (CSAM)

Section 67B is the IT Act's strictest provision on objectionable content, aimed specifically at preventing child sexual abuse material online. It covers a broad range of conduct — including creating, collecting, seeking, browsing, downloading, advertising, promoting, exchanging, or distributing material depicting children in sexually explicit acts, as well as soliciting a child to participate in such material.

• First offence: up to 5 years' imprisonment and a fine of up to ₹10,00,000
• Repeat offence: up to 7 years' imprisonment and a fine of up to ₹10,00,000

Overlap with POCSO

Section 67B operates alongside the Protection of Children from Sexual Offences (POCSO) Act, India's principal legislation on child sexual offences. Section 14 of POCSO specifically penalises using children for pornographic purposes, with even more severe punishment than Section 67B. In practice, prosecutions frequently invoke both statutes together.

Why these provisions matter

Together, Sections 67, 67A and 67B form a graduated response to online content — from general obscenity, through explicit sexual content, to the strictest protections reserved for child safety. Because "obscenity" itself resists precise definition, much of the real content of Section 67 has been shaped by courts rather than the statute's text alone, while Sections 67A and 67B were added specifically to give prosecutors more objective, easier-to-apply provisions for the most serious categories of harmful content.

Part IV: Intermediaries

Before we examine the Intermediary Rules, it is important to understand why intermediaries occupy such a unique position in internet law.

Every day, billions of messages, photographs, videos, emails, and other forms of digital content are shared online. Most of this content is not created by companies like WhatsApp, Instagram, YouTube, or X (formerly Twitter). Instead, it is created by their users.

This raises an important legal question:

Should an online platform be held legally responsible for everything that its users post?

If the answer were always "yes," social media platforms would face enormous legal risks. They would either have to review every piece of content before it is published or risk being sued or prosecuted for users' actions.

On the other hand, giving platforms complete immunity could allow illegal content to remain online without any accountability.

The Information Technology Act attempts to balance these competing interests through the safe harbour principle contained in Section 79, together with the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021.

Together, they define both the protections available to intermediaries and the responsibilities they must fulfil.

What is an Intermediary?

Section 2(1)(w) of the IT Act defines an intermediary as any person or entity that receives, stores, transmits, or provides services relating to electronic records on behalf of another person.

Unlike publishers, intermediaries generally do not create the information that passes through their platforms. Instead, they provide the infrastructure that allows users to communicate, share content, or access online services.

Common examples include:

• Internet Service Providers (ISPs);
• social media platforms;
• messaging applications;
• cloud service providers;
• web-hosting providers;
• search engines;
• online marketplaces; and
• payment gateways.

Although these entities facilitate communication, the content itself usually belongs to the users.

Why are intermediaries treated differently?

Imagine someone posts defamatory content on a social media platform — who should be liable, the person who wrote the post or the platform that hosted it? The law generally places primary responsibility on the person who created the content.

An intermediary is normally considered a neutral facilitator rather than the author or publisher of user-generated content.

The Delhi High Court recognised this distinction in Jitendra Singh Yadav v. Union of India (2017), observing that intermediaries generally provide the technological infrastructure through which information is transmitted, rather than exercising editorial control over every piece of content.

However, this protection is not absolute.

If an intermediary fails to comply with its legal obligations, it may lose the protection available under Section 79.

This is where the concept of safe harbour becomes important.

Section 79 – The Safe Harbour Principle

The idea behind safe harbour is simple.

An intermediary should not automatically be held liable for content created by its users, provided it acts responsibly and complies with the law.

Without safe harbour protection, operating an online platform would be practically impossible.

Every social media post, email, product review, comment, or video would expose the platform to immediate legal liability.

Safe harbour allows intermediaries to facilitate communication without becoming legally responsible for every action taken by their users.

Where did the idea come from?

The concept of intermediary immunity did not originate in India.

One of the earliest and most influential decisions came from the United States in Religious Technology Center v. Netcom On-Line Communication Services (1995).

The case involved allegations of copyright infringement through an Internet Service Provider (ISP).

The Court held that the ISP acted merely as a passive intermediary. Since it neither created nor controlled the infringing content, it should not automatically be held liable simply because the content passed through its servers.

This decision helped shape the modern concept of intermediary liability around the world.

Evolution of Section 79

When the IT Act was originally enacted in 2000, Section 79 provided protection mainly to network service providers.

However, the internet changed dramatically over the following decade.

Social media platforms, search engines, online marketplaces, and cloud service providers became central to digital communication.

Recognising this shift, the Information Technology (Amendment) Act, 2008 significantly expanded Section 79.

Today, the provision protects a much wider range of intermediaries, provided they satisfy the conditions laid down by the Act.

When does safe harbour apply?

Section 79 does not provide blanket immunity.

An intermediary receives protection only if three broad conditions are satisfied.

The 2026 Amendment: Regulating Synthetic Media and Deepfakes

On 10 February 2026, MeitY notified the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Amendment Rules, 2026, which took effect on 20 February 2026. These amendments update the 2021 Intermediary Rules discussed above and represent India's first dedicated legal framework for AI-generated content and deepfakes. Rather than regulating AI technology itself, the amendment regulates how AI-generated content is created, identified and distributed online — directly affecting the safe harbour analysis under Section 79.

What counts as "synthetically generated information"?

The amendment introduces a new legal term: synthetically generated information, or synthetic media. In simple terms, this refers to AI-generated or AI-manipulated audio, images or videos that are made to look or sound real — for instance, a convincing deepfake video of a politician saying something they never said, or an AI-generated voice recording impersonating someone.

Earlier draft rules would have covered almost any content modified using AI, which many experts warned was far too broad. The final version narrows this considerably, focusing only on AI-generated content that appears authentic and could mislead people into believing it is real.

Who has to follow these rules?

The rules apply to intermediaries — the same broad category discussed above — including social media platforms, search engines, online marketplaces, cloud and web-hosting providers, and telecom companies. Significant Social Media Intermediaries (SSMIs) — platforms with more than five million registered users in India — face additional, stricter obligations because of the scale at which they distribute information.

What do platforms now have to do?

Platforms offering AI tools for creating or modifying content can no longer simply provide the technology and step away from responsibility. They must take reasonable technical measures to stop users from creating or sharing unlawful AI-generated content, and if AI-generated content is permitted on the platform, it must generally be clearly identified.

This can be done through visible labels, embedded metadata, digital watermarks, unique identifiers, or other technical methods. For videos and images, the label must be obvious to viewers; for audio, there should be a spoken disclosure at the start so listeners know immediately that the recording was AI-generated. An earlier draft required labels to occupy 10% of the content, but after industry feedback the government removed this rigid requirement — platforms now have flexibility in how they display labels, provided they remain prominent and cannot be easily removed or tampered with.

Extra responsibilities for large social media platforms

SSMIs must require users to declare, at the point of upload, whether their content is AI-generated. Critically, the platform cannot simply rely on that declaration — it must also use automated tools or other technical systems to verify whether the declaration is accurate. If either the user or the platform's own verification confirms the content is AI-generated, the platform must clearly label it before allowing it to remain online. Responsibility is therefore shared between users and platforms, rather than resting entirely on either one.

Faster takedown timelines

The amendment significantly shortens the time platforms have to remove illegal content. For particularly sensitive material — such as non-consensual intimate images or deepfakes — the compressed timelines are especially aggressive.

Why does safe harbour matter here?

As explained above, safe harbour under Section 79 shields intermediaries from liability for user-generated content, provided they meet due diligence requirements. The 2026 amendment makes clear that platforms risk losing this protection if they:

• Knowingly allow unlawful AI-generated content to remain online
• Fail to comply with the new labelling requirements, or
• Ignore their obligations under the amended Rules

Why these rules matter

The 2026 amendment shows MeitY responding to public feedback: compared to the earlier draft, the government narrowed the definition of synthetic media and abandoned the rigid watermarking requirement, reducing the risk of over-regulating harmless everyday AI use. At the same time, it places considerably greater responsibility on online platforms, which must now identify AI-generated content, label it clearly, detect unlawful deepfakes, respond to complaints within hours, and maintain moderation systems capable of meeting these demanding timelines. Whether the shortened takedown deadlines prove practical in operation remains to be seen — many platforms may need significant upgrades to their moderation and compliance infrastructure to keep pace.

The Information Technology (Procedure and Safeguards for Blocking for Access of Information by Public) Rules, 2009 ("Blocking Rules")

The internet allows information to spread almost instantly. While this has transformed communication, it has also created new challenges for governments.

Online content may sometimes threaten:

• national security;
• public order;
• friendly relations with foreign States;
• the sovereignty and integrity of India; or
• other interests protected by law.

This raises an important question:

Can the Government require websites or online platforms to block access to certain content?

The answer is yes, but only in limited circumstances and only by following the procedure laid down in Section 69A of the Information Technology Act and the Blocking Rules, 2009.

These Rules establish who may request blocking, who decides whether blocking is justified, and the safeguards that must be followed before content is removed.

Section 69A – Power to Block Content

Section 69A empowers the Central Government to direct an intermediary or Government agency to block public access to online information.

However, this power cannot be exercised simply because the Government disagrees with the content.

Blocking is permitted only where it is necessary or expedient in the interests of:

• the sovereignty and integrity of India;
• the defence of India;
• the security of the State;
• friendly relations with foreign States;
• public order; or
• preventing the commission of a cognisable offence relating to any of these grounds.

These grounds closely resemble the constitutional restrictions on free speech contained in Article 19(2) of the Constitution.

Why are the Blocking Rules necessary?

Section 69A grants the power to block content.

The Blocking Rules explain how that power must be exercised.

Without these procedural safeguards, there would be a risk of arbitrary censorship.

The Rules therefore attempt to balance two competing interests:

• protecting national security and public order; and
• safeguarding freedom of speech and expression.

Who can request blocking?

Not every Government officer can order content to be blocked.

The Rules establish a structured process involving several different authorities.

Requests may originate from:

• a Ministry or Department of the Central Government;
• a State Government;
• a court order; or
• another authorised Government agency.

Private individuals cannot directly invoke the Blocking Rules.

Instead, complaints generally pass through the appropriate Government authorities before entering the formal blocking process.

The Designated Officer

The central figure in the blocking process is the Designated Officer, who is typically an officer of the rank of Joint Secretary in the Ministry of Electronics and Information Technology (MeitY).

The Designated Officer receives blocking requests and examines whether they should proceed further.

Importantly, the Designated Officer does not decide the matter alone.

Instead, they convene a specialised committee to examine each request.

Committee for Examination

Once a request is received, it is placed before the Committee for Examination of Blocking Requests.

The Committee includes representatives from several Government departments, including those dealing with:

• law;
• home affairs;
• information and broadcasting;
• telecommunications; and
• information technology.

The objective is to ensure that blocking decisions are not made unilaterally by a single authority.

The Committee examines:

• whether the request falls within Section 69A;
• whether blocking is necessary; and
• whether the proposed action is proportionate.

Opportunity to be Heard

As a general rule, the originator of the information or the intermediary hosting the content should be given an opportunity to present their case before blocking is ordered.

This is an important procedural safeguard.

It reflects the principles of natural justice, ensuring that content is not blocked without first allowing affected parties to explain why blocking may be unnecessary or inappropriate.

However, this opportunity may not always be possible in urgent situations.

Final Decision

After considering the Committee's recommendations, the matter is placed before the Secretary, Ministry of Electronics and Information Technology (MeitY).

Only the Secretary has the authority to approve a blocking direction under the ordinary procedure.

If approval is granted, the Designated Officer issues the blocking direction to the relevant intermediary or Government agency.

The intermediary must then disable public access to the specified content.

Emergency Blocking

Not every situation allows time for the ordinary procedure.

Where delaying action could seriously threaten national security, public order, or other protected interests, the Rules provide an emergency procedure.

In such cases:

• the Designated Officer immediately places the matter before the Secretary, MeitY;
• the Secretary may issue an interim blocking direction without first hearing the affected party; and
• the Committee subsequently reviews the decision.

This allows urgent action where immediate intervention is genuinely necessary while still providing post-decisional oversight.

Confidentiality

One distinctive feature of the Blocking Rules is their confidentiality requirement.

The Rules provide that blocking requests, proceedings, and directions are generally confidential.

The stated objective is to protect sensitive national security investigations and prevent blocked content from receiving additional publicity.

However, this confidentiality requirement has also attracted criticism because it limits public scrutiny of blocking decisions.

Judicial Review – Shreya Singhal v. Union of India

The constitutional validity of Section 69A and the Blocking Rules was challenged before the Supreme Court in Shreya Singhal v. Union of India (2015).

Unlike Section 66A, which the Court struck down, Section 69A was upheld as constitutionally valid.

The Court observed that the Blocking Rules contain several procedural safeguards, including:

• limited statutory grounds for blocking;
• examination by a Government committee;
• approval by the Secretary, MeitY;
• opportunities to be heard in ordinary cases; and
• the availability of judicial review.

Because of these safeguards, the Court concluded that Section 69A was sufficiently narrow and did not suffer from the same constitutional defects as Section 66A.

This distinction is important.

While Section 66A criminalised vague categories of speech, Section 69A regulates access to content through a structured administrative process subject to procedural safeguards.

Criticisms of the Blocking Rules

Although the Supreme Court upheld the Rules, they remain controversial.

Critics argue that:

• the confidentiality requirement reduces transparency;
• blocking orders are often unavailable to the public;
• affected users may not always know why content has been blocked;
• the emergency procedure may be susceptible to overuse; and
• the broad interpretation of "public order" and national security may permit excessive censorship.

Supporters, however, argue that confidential procedures are sometimes essential where national security, terrorism, or public safety is involved.

Relationship with Intermediaries

The Blocking Rules operate closely alongside the Intermediary Rules, 2021.

While the Intermediary Rules require platforms to comply with lawful directions, the Blocking Rules establish the legal procedure through which those directions are issued.

Failure to comply with a valid blocking order may expose an intermediary to legal consequences and may also affect its entitlement to safe harbour protection under Section 79.

The Information Technology (Procedure and Safeguards for Interception, Monitoring and Decryption of Information) Rules, 2009 ("Monitoring Rules")

The internet allows people to communicate instantly through emails, messaging apps, social media, cloud services, and other digital platforms.

In certain situations, however, the Government may need to access these communications—for example, while investigating terrorism, organised crime, cyberattacks, or threats to national security.

This raises an important question:

Can the Government intercept or monitor private digital communications?

The answer is yes, but only under limited circumstances and subject to the safeguards contained in Section 69 of the Information Technology Act and the Monitoring Rules, 2009.

Unlike the Blocking Rules, which deal with restricting public access to online content, the Monitoring Rules deal with accessing private electronic communications and digital information.

Section 69 – Power to Intercept, Monitor and Decrypt

Section 69 authorises the Central Government or a State Government to direct an agency or intermediary to:

• intercept;
• monitor; or
• decrypt

information generated, transmitted, received, or stored in any computer resource.

However, these powers cannot be exercised arbitrarily.

They may be used only where it is necessary or expedient in the interests of:

• the sovereignty and integrity of India;
• the defence of India;
• the security of the State;
• friendly relations with foreign States;
• public order; or
• preventing the incitement or investigation of cognisable offences relating to these interests.

These grounds broadly correspond to the restrictions recognised under Article 19(2) of the Constitution.

Interception, Monitoring and Decryption: What's the Difference?

Although these terms are often used together, they refer to different activities.

Interception

Interception means capturing a communication while it is being transmitted.

For example, law enforcement may intercept an email or message before it reaches its intended recipient.

Monitoring

Monitoring involves observing or recording communications or activities over a period of time.

For example, investigators may monitor a suspect's online communications as part of an ongoing investigation.

Decryption

Decryption refers to converting encrypted information into a readable form.

If information has been protected using encryption, the Government may require the relevant person or intermediary to assist in decrypting it, provided the legal requirements of Section 69 are satisfied.

Why are these Rules necessary?

Section 69 grants the Government the power to intercept, monitor, and decrypt information.

The Monitoring Rules explain how that power must be exercised.

Without procedural safeguards, such powers could seriously affect:

• privacy;
• freedom of speech;
• confidential communications; and
• trust in digital services.

The Rules therefore attempt to balance legitimate law enforcement needs with constitutional protections for individual rights.

Who can issue an interception order?

An interception order cannot be issued by every Government officer.

Under the ordinary procedure, the order must be approved by:

• the Secretary to the Government of India in the Ministry of Home Affairs (for the Central Government); or
• the Secretary in charge of the Home Department of the relevant State Government.

This ensures that interception powers are exercised only by senior officials.

Emergency Procedure

There may be situations where waiting for formal approval is not possible.

In cases of genuine emergency, an interception order may initially be authorised by an officer not below the rank of Joint Secretary, who has been specifically authorised by the competent Government.

However, the order must subsequently be confirmed by the competent Secretary within the prescribed time.

If approval is not granted, the interception must cease, and the information obtained cannot continue to be retained or relied upon under the Rules.

This emergency procedure is intended to address urgent threats while maintaining accountability.

Who must comply?

Section 69 imposes legal obligations on:

• intermediaries;
• subscribers;
• persons in charge of computer resources; and
• any person capable of providing technical assistance.

Where a lawful direction is issued, they may be required to:

• provide access to information;
• assist in interception;
• facilitate monitoring; or
• decrypt protected information.

Failure to comply with a valid direction is itself an offence under the IT Act.

Confidentiality

Like the Blocking Rules, the Monitoring Rules require strict confidentiality.

Information relating to:

• interception requests;
• interception orders;
• monitored communications; and
• the implementation of those orders,

must generally remain confidential.

The purpose is to protect ongoing investigations and prevent suspects from becoming aware of surveillance measures.

Review Committee

The Rules also establish an important oversight mechanism.

Every interception order must be reviewed by a Review Committee.

The Committee examines whether:

• the order was lawfully issued;
• the statutory grounds under Section 69 were satisfied; and
• continued interception remains necessary.

If the Committee concludes that the order does not comply with the Act or the Rules, it may direct that the interception be discontinued and that the records obtained be destroyed.

This serves as an important safeguard against misuse of surveillance powers.

Relationship with the Right to Privacy

Government surveillance directly affects an individual's right to privacy.

In Justice K.S. Puttaswamy v. Union of India (2017), the Supreme Court recognised privacy as a fundamental right under Article 21 of the Constitution.

The Court held that any restriction on privacy must satisfy the requirements of:

• legality;
• legitimate State aim;
• necessity; and
• proportionality.

Although the case did not specifically decide the validity of the Monitoring Rules, these constitutional principles now shape how Government surveillance powers are interpreted and exercised.

In practice, this means that surveillance cannot be justified merely because it is convenient. It must have a clear legal basis, pursue a legitimate objective, and go no further than necessary to achieve that objective.

Criticisms of the Monitoring Rules

The Monitoring Rules have been the subject of significant debate.

Supporters argue that they are essential for:

• preventing terrorism;
• investigating organised crime;
• responding to cyber threats;
• protecting national security; and
• enabling effective law enforcement.

Critics, however, argue that:

• surveillance powers are extremely broad;
• interception orders are confidential, limiting public scrutiny;
• individuals are rarely informed that they have been subjected to surveillance; and
• meaningful judicial oversight is limited because approval is primarily executive rather than judicial.

These concerns have become even more significant with the widespread use of encrypted messaging services and cloud-based communication platforms.

Monitoring Rules vs Blocking Rules

Although they are often discussed together, the two sets of Rules serve different purposes.

Why these Rules matter

The Monitoring Rules form one of the pillars of India's digital security framework.

They recognise that governments sometimes require surveillance powers to investigate serious offences and protect national security. At the same time, they impose procedural safeguards by limiting who may authorise surveillance, prescribing review mechanisms, and requiring confidentiality.

As debates around encryption, digital privacy, and Government surveillance continue to evolve, these Rules remain central to discussions about how India balances individual privacy with public safety and national security.

The Information Technology (Procedure and Safeguards for Monitoring and Collecting Traffic Data or Information) Rules, 2009 ("Traffic Data Rules")

When people think about digital surveillance, they often imagine governments reading emails or listening to phone calls.

However, investigators do not always need access to the content of a communication.

Sometimes, the metadata surrounding a communication can be just as valuable.

For example:

• Who sent the message?
• Who received it?
• When was it sent?
• From which IP address?
• Which server was used?
• How long did the communication last?

This information is known as traffic data.

The Traffic Data Rules, 2009 establish the procedure through which authorised Government agencies may collect and monitor this information for cybersecurity purposes.

Unlike the Monitoring Rules, these Rules generally focus on communication data rather than the contents of the communication itself.

What is Traffic Data?

The IT Act defines traffic data as any data generated by a computer resource during a communication that indicates:

• the communication's origin;
• its destination;
• the route it travelled;
• the time of transmission;
• its size;
• its duration; or
• the type of underlying service.

In simple terms:

Traffic data explains how a communication occurred—not what was actually said.

For example, a WhatsApp message contains two different kinds of information:

Content

"Let's meet at 5 PM."

Traffic data

• sender's account;
• recipient's account;
• date and time;
• IP address;
• device identifiers;
• duration of the connection.

The Rules primarily concern the second category.

Why is traffic data important?

Traffic data plays a crucial role in cybersecurity investigations.

Even where investigators cannot access the contents of a communication, traffic data may help them:

• identify the source of a cyberattack;
• trace malicious network activity;
• investigate hacking incidents;
• analyse malware campaigns;
• detect denial-of-service attacks;
• investigate cyber fraud; and
• understand how an attacker moved through a network.

For this reason, traffic data is often one of the first forms of digital evidence examined after a cybersecurity incident.

Who may collect traffic data?

The Rules authorise designated Government agencies to monitor and collect traffic data where necessary for carrying out the functions specified under the IT Act.

Collection cannot occur arbitrarily.

It must be carried out by authorised agencies following the procedure prescribed under the Rules.

Intermediaries and persons in charge of computer resources may be required to assist these agencies where a lawful direction has been issued.

Duties of Intermediaries

Where a lawful request is made, intermediaries may be required to:

• preserve relevant traffic data;
• provide access to that data;
• assist authorised agencies in collecting it; and
• maintain confidentiality regarding the request.

Failure to comply with a valid direction may attract legal consequences under the IT Act.

Confidentiality

Like the Monitoring Rules and the Blocking Rules, the Traffic Data Rules impose strict confidentiality obligations.

Information relating to:

• monitoring requests;
• collected traffic data;
• investigations; and
• the implementation of Government directions,

must generally remain confidential.

This helps protect ongoing investigations and prevents suspects from becoming aware that their network activity is being analysed.

Traffic Data vs Content Data

One of the easiest ways to understand these Rules is to distinguish traffic data from content data.

Although traffic data does not usually reveal the actual message, it can still disclose highly sensitive information about an individual's activities, movements, relationships, and online behaviour.

For this reason, many privacy scholars regard traffic data as deserving strong legal protection.

Relationship with CERT-In

The Traffic Data Rules operate closely alongside CERT-In, India's national computer emergency response team.

During cybersecurity incidents, traffic data often helps CERT-In:

• identify the source of an attack;
• analyse malicious network activity;
• coordinate incident response;
• issue security advisories; and
• reduce the impact of cyber incidents.

Traffic data therefore plays an important role in both cybersecurity investigations and incident response.

Criticisms of the Rules

Supporters argue that the Rules are essential because modern cyber investigations often depend on analysing network traffic rather than the contents of communications.

Critics, however, point out that traffic data can reveal a surprising amount about an individual's private life.

Even without reading a person's messages, metadata may reveal:

• who they communicate with;
• how frequently they communicate;
• where they were located;
• which websites they visited; and
• patterns of behaviour over time.

As a result, many privacy experts argue that access to traffic data should be subject to strong procedural safeguards and robust oversight.

These concerns have become even more significant following the Supreme Court's recognition of privacy as a fundamental right in Justice K.S. Puttaswamy v. Union of India (2017).

Monitoring Rules vs Traffic Data Rules

These two sets of Rules are often confused, but they regulate different forms of information.

Section 70 – Protected Systems and Critical Infrastructure

Some computer systems matter more than others. A hacked personal blog is a nuisance; a hacked power grid or stock exchange is a national emergency. Section 70 gives the Government a way to treat these systems differently.

Why single out some systems for extra protection?

Think of the difference between a shop's till and a country's power grid. Both can be hacked, but the consequences aren't remotely comparable. Section 70 exists so that a narrow category of genuinely critical systems — power grids, stock exchanges, defence networks, and similar infrastructure — gets a much harder legal wall around it than an ordinary computer system does.

This category is officially called Critical Information Infrastructure (CII), and it's overseen by the National Critical Information Infrastructure Protection Centre (NCIIPC), a nodal agency created by executive notification specifically to protect these systems.

Section 70B – CERT-In's Role

Section 70B is what actually empowers CERT-In (India's national cybersecurity incident response agency, discussed earlier in this guide) to collect cybersecurity data, analyse it, and forecast or prevent cyber-harms before they escalate. Where Section 70 draws the protective line around specific critical systems, Section 70B gives CERT-In the legal basis to actively watch for and respond to threats across the wider digital ecosystem.

Adjudication and Appeals: How the IT Act Is Actually Enforced

Every provision covered so far in this guide — safe harbour, data breaches, cyber offences, blocking orders — eventually raises the same practical question: if something goes wrong, who actually decides the case, and where can you appeal?

Adjudicating Officers (Section 46)

Most disputes under the IT Act aren't decided by an ordinary court in the first instance. Instead, they go to an Adjudicating Officer (AO) — a Government-appointed official, not below the rank of Director, with recognised experience in both IT and law.

When deciding how much compensation to award, an AO considers:

• The amount of unfair gain made by the wrongdoer (where this can be calculated)
• The amount of loss actually caused
• Whether the same person has done this before

An AO can only hear claims up to ₹5 crore. Anything above that goes straight to a higher court instead.

Appeals — The TDSAT

If either side disagrees with an AO's decision, they can appeal — but not to a regular court. The IT Act routes these appeals to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT), the same tribunal originally set up to handle telecom disputes.

The TDSAT isn't bound by the same rigid procedure as a civil court — it can summon witnesses, demand documents, and decide cases based on affidavits, all guided by general principles of natural justice rather than the full Code of Civil Procedure. If a further appeal is needed after the TDSAT rules, it goes to the High Court, within 60 days.

Why does this machinery matter?

A right is only as real as the mechanism for enforcing it. All the protections discussed elsewhere in this guide — compensation for data breaches, safe harbour disputes, penalties for cyber offences — ultimately rely on this two-tier system: an Adjudicating Officer first, the TDSAT on appeal. Section 61 reinforces this by explicitly barring ordinary civil courts from hearing matters that fall within the AO's or TDSAT's jurisdiction — this pathway isn't optional, it's the only route available.

The Act also allows most contraventions to be compounded — resolved by paying a penalty instead of facing prosecution — though anyone who repeats the same violation within 3 years loses that option.