If Your Product Holds User Content, the IT Rules 2021 Apply to You
By Kiran · Founder, Combifer Technologies
General information, not legal advice. Intermediary obligations depend on the nature of your platform and change with amendments and judicial interpretation. Confirm your position with a qualified lawyer.
If your product lets users upload a file, send a message to a colleague, or store a record you did not author, you are almost certainly an intermediary under Indian law. That word carries obligations, and most companies of this size have never read them.
The Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 sit under Section 79 of the IT Act. Section 79 is the provision that protects you from liability for what your users do — the safe harbour. The Rules set out what you have to do to keep it.
That is the framing worth holding on to. These are not arbitrary compliance chores. They are the conditions attached to the protection you are already relying on.
Are you an intermediary?
The definition is broad: anyone who receives, stores or transmits an electronic record on behalf of another person, or provides a service in relation to it.
A B2B SaaS product where teams upload documents and talk to each other qualifies. So does a marketplace, a hosting service, a messaging feature, and most collaboration tools. Being business-to-business rather than consumer-facing does not exempt you, and neither does being small.
Publish rules, and tell people when they change
You are expected to publish your rules and privacy policy, make them accessible, and inform users of them — at onboarding and at least annually thereafter.
Those rules must tell users what they may not host. The Rules enumerate the categories: content belonging to someone else that the user has no right to; content that is obscene, paedophilic, invasive of privacy, or harassing on the basis of gender; content that is racially or ethnically objectionable; anything relating to money laundering or gambling; anything harmful to a child; intellectual property infringement; deliberately false or misleading information; impersonation; anything threatening the unity, integrity, defence or security of India or public order; software viruses; and anything otherwise unlawful.
A generic acceptable-use paragraph does not cover this. The list is specific and the expectation is that yours reflects it.
Two deadlines to design around
This is the part that catches people, because both are shorter than a normal support queue.
A grievance must be acknowledged within twenty-four hours and disposed of within fifteen days. That is not fifteen days to reply; it is fifteen days to resolve.
Certain complaints — content in the nature of nudity, a sexual act, or impersonation including morphed images — must be actioned within twenty-four hours of a complaint.
Separately, on receiving a court order or a notification from an appropriate government agency, you have thirty-six hours to remove or disable access to the content identified.
None of those timelines survive contact with an unmonitored inbox. If your grievance address routes to a shared mailbox nobody owns, you have a process failure waiting for its first real complaint.
Name a Grievance Officer, publicly
You are expected to publish the name and contact details of a Grievance Officer, along with the mechanism for making a complaint. That person has to be reachable and has to actually respond within the timelines above.
For most companies at this size this is a founder or an operations lead, which is fine. What is not fine is naming someone who does not know they have been named.
Keep records, and be able to produce them
Two record-keeping expectations follow from the rest.
When you remove content, keep it — along with the associated records — for the period prescribed, for investigation purposes. Deleting it entirely on receipt of a complaint can leave you unable to answer questions about it later.
And keep a log of what you did and when. If you are asked whether you met a thirty-six hour deadline, the answer needs to be evidenced rather than remembered. A takedown process without a record is very hard to defend.
How this connects to your other obligations
There is useful overlap with the DPDP Act. Both expect a named, reachable person handling complaints. Both expect defined response times. Both expect you to know what you hold and be able to act on it.
If you are building this once, build it once properly: a published contact, a logged intake, defined timelines, and a record of the action taken. That satisfies the intermediary requirement and most of the data-protection grievance requirement at the same time.
A short audit
Do your published terms enumerate prohibited content, or gesture at it?
Is there a named Grievance Officer on your site, with a working contact route?
If a takedown request arrived this afternoon, who would see it, and would they know the clock had started?
Can you evidence what you did about the last complaint you received?
Do your terms tell users what happens when they breach the rules, including suspension and termination?
Most companies can answer the first two after an afternoon of work. The third and fourth are where the real gap usually is, because they are about operations rather than documents — and safe harbour is lost through operational failure far more often than through bad drafting.