Web Development Company in Pune: Why CERT-In's 6-Hour Breach Reporting Rule Still Catches Businesses Out in 2026
If your website handles logins, payments, or customer data, Indian law already requires you to report a security incident to the government within six hours of noticing it — not six hours of confirming it, six hours of noticing it. This isn't a 2026 proposal. It's been in force since 27 June 2022, under the Indian Computer Emergency Response Team (CERT-In) Directions issued on 28 April 2022 under Section 70B of the Information Technology Act, 2000. And yet, four years in, a large share of small and mid-sized business websites built by web development companies across Pune and the rest of India still have no logging in place that would let them meet that deadline even if they wanted to.
That gap is the subject of this guide. Not because the rule is new — it isn't — but because 2026 is the year several things are converging on it: enforcement attention on smaller entities has increased, the Digital Personal Data Protection (DPDP) Act's breach-notification duties now sit on top of CERT-In's, and a growing number of RFPs from banks, government departments and larger corporates now ask vendors to confirm CERT-In compliance before they'll even sign a contract. If you're briefing a web development company in Pune for a new build, a migration, or a security audit, this is one checklist item that's easy to overlook and expensive to retrofit.
Why This Guide Exists
Most CERT-In explainers are written for large enterprises with a dedicated CISO. This one is written for the actual audience that gets caught out: a 12-person D2C brand running WooCommerce on shared hosting, a clinic with a patient-enquiry form, an NGO with a donation gateway, a B2B firm with a customer portal. None of these outfits have a security team. All of them are, in the letter of the law, "body corporates" the Directions apply to.
What CERT-In's Directions Actually Require
The Directions apply broadly — to "service providers, intermediaries, data centres, body corporates and Government organisations" operating in India, with no carve-out for company size. If your website is reachable from India and processes any transaction, login, or personal data, you are inside the scope.
Three obligations matter most for a website:
1. Six-hour incident reporting. Any of the listed categories of cyber incident must be reported to CERT-In within six hours of the organisation becoming aware of it — via email, phone, fax, or CERT-In's online reporting portal. Six hours from awareness, not from when a formal investigation concludes what happened. For most website operators, "awareness" starts the moment a developer, host, or plugin alert flags something unusual.
2. Mandatory log retention. Organisations must enable and maintain logs of all their ICT systems for a rolling 180 days, and store those logs within Indian jurisdiction. If your host, CDN, or logging tool discards access logs after 7, 14, or 30 days — the common default on budget hosting plans — you are not compliant, breach or no breach.
3. Time synchronisation. System clocks must be synchronised to the Network Time Protocol (NTP) servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or to time sources traceable to them. This sounds trivial, but it matters directly for incident reporting: if your server logs, your payment gateway's webhook logs, and your CDN's edge logs all show different timestamps for the same event because none of them are synced to a common clock, reconstructing an incident timeline — something CERT-In will ask for — becomes far harder than it needs to be.
Who Is Reportable, in Plain Terms
The Directions list around twenty categories of reportable cyber incidents. The ones that actually show up on ordinary business and NGO websites include:
- Unauthorised access to a website, admin panel, database, or hosting account
- Website defacement
- Malicious code infection (malware, ransomware, cryptojacking scripts injected into a compromised WordPress or PHP site)
- Large-scale or targeted denial-of-service (DoS/DDoS) attacks that take a site offline
- Data breach or data leak involving personal or financial information
- Attacks on payment gateways or e-commerce/card-payment systems
- Unauthorised changes to DNS records or domain hijacking
- Phishing pages hosted on, or impersonating, the organisation's own domain
A defaced WordPress homepage, a leaked customer-enquiry CSV from a misconfigured form plugin, or a compromised admin account used to inject spam links — all of these are reportable incidents under the Directions, whether or not the business considers them "serious."
The Two Requirements Most Website Builds Get Wrong
In practice, the six-hour clock is rarely the hard part — most businesses can pick up a phone or send an email quickly once they know something is wrong. The two requirements that quietly go unmet, because nobody built them in at the time of development, are log retention and time sync.
180-Day Log Retention: Where It Actually Breaks
| Layer | Common default | What CERT-In requires |
|---|---|---|
| Shared/budget hosting (cPanel) | Access logs auto-rotated and deleted after 7-30 days | Logs retained 180 days on a rolling basis |
| WordPress error logs | Often disabled entirely, or overwritten on each deploy | Persistent, retained logs |
| CDN (e.g. free-tier Cloudflare) | Raw request logs may not be retained at all on free plans | 180 days of ICT system logs |
| Payment gateway webhook logs | Usually retained by the gateway itself, but rarely exported and archived by the merchant | Merchant should hold its own copy |
| Application-level audit trail (admin logins, content edits) | Frequently absent unless a plugin is deliberately installed | Should exist for anything handling personal data |
The fix isn't expensive, but it has to be deliberate: a centralised logging setup (even something as simple as shipping logs to a low-cost log storage service or a self-hosted solution), log rotation policies that archive rather than delete, and a written note of where each system's logs live so that, in an incident, nobody spends the first two of your six hours figuring out whether logs even exist.
NTP Sync: A Five-Minute Fix Almost Nobody Does
Most VPS and cloud servers ship with systemd-timesyncd or chronyd pointed at a generic public NTP pool by default — not at NIC or NPL. Pointing your server's NTP configuration at NIC's or NPL's time servers (or a source traceable to them) is a same-day change for a competent web development company in Pune to make during a server build or audit. It's the kind of item that costs nothing to fix in advance and a great deal of confusion to fix after an incident, when your server logs, your gateway logs, and your firewall logs disagree on when something actually happened.
Why 2026 Is the Year This Starts Mattering More
Three things have shifted the practical stakes since the Directions were first issued in 2022:
Enforcement attention has broadened. CERT-In's early years focused heavily on large regulated entities — banks, telecom, government systems. Awareness campaigns and compliance audits have since widened toward mid-sized digital businesses, partly driven by the sharp rise in ransomware and website-compromise incidents affecting SMEs.
The DPDP Act adds an overlapping duty. The Digital Personal Data Protection Act, 2023 and its 2025 Rules introduce a separate breach-notification obligation — to the Data Protection Board and to affected individuals — that runs alongside, not instead of, CERT-In's six-hour reporting duty. A business now has two regulators to notify on two different clocks for the same incident, which makes having a clean, pre-written incident-response process (not something assembled during a live breach) genuinely valuable rather than a nice-to-have.
Procurement is starting to ask. Banks, government departments, and larger corporates increasingly include a CERT-In compliance declaration in vendor onboarding and RFP paperwork. A web development company in Pune that can walk a client through logging, retention and reporting readiness — rather than treating it as the client's problem to solve later — becomes the easier vendor to sign off on.
What a Web Development Company in Pune Should Build Into Every Site
This is the practical checklist we work through with clients, whether we're building a new site or auditing an existing one before a migration.
- Centralised, retained logging for the web server, application, database and CDN layer, with an explicit retention policy of at least 180 days and log storage that stays accessible within India.
- NTP sync to NIC/NPL time sources on every server, container, or managed environment the site runs on.
- An admin/audit trail on the CMS or application layer — who logged in, when, and what they changed — not just server-level access logs.
- A named incident contact and a written six-hour response checklist: who gets notified internally, who drafts the CERT-In report, and where the reporting channel details are kept, so nobody is searching for CERT-In's email address while the clock is already running.
- A breach playbook that also covers DPDP notification, since the two obligations will usually be triggered by the same event but go to different places with different content requirements.
- Hosting and CDN plan review, since several popular free-tier and budget hosting/CDN plans simply don't retain raw logs long enough by default — this needs checking, not assuming.
None of this requires an enterprise security budget. It requires the logging and monitoring to be specified at build time, the same way SSL, backups, and page speed already are, rather than left as an afterthought.
How the Six Hours Actually Play Out
It helps to walk through what the clock looks like in practice, rather than treating it as an abstract legal figure. Take a common scenario: a business's WordPress admin account is compromised through a reused, weak password, and the attacker injects a spam-redirect script into the theme files.
- Hour 0: A developer or the site owner notices unusual redirect behaviour, or Google Search Console flags the site for "hacked content." This is the moment the six-hour clock starts — awareness, not confirmation.
- Hour 0-1: The team needs to know who owns the response. If there's no named contact and no written checklist, this hour is frequently lost to "who do we even call."
- Hour 1-3: Containment — locking the compromised account, pulling the injected code, checking server and application logs for the entry point. This step is where 180 days of retained logs (or their absence) decides whether the investigation is fast or effectively blind.
- Hour 3-5: Drafting the report to CERT-In: what happened, when it was first noticed, systems affected, and remedial action taken or planned. CERT-In accepts reports by email, phone, fax, or its online portal.
- Hour 5-6: Submission, plus internal notes on whether the incident also triggers a DPDP breach-notification duty, if personal data was exposed.
The businesses that hit the six-hour mark comfortably are, almost without exception, the ones that had logging, a named contact, and a written process before anything happened — not the ones who were simply lucky about the type of incident.
Reporting Channels CERT-In Accepts
CERT-In's own guidance lists multiple channels for incident reporting rather than a single mandatory format: email, telephone, fax, and its online reporting portal, with a preference for structured detail — organisation name and contact, systems and data affected, time of first detection, indicators of compromise if known, and remedial steps already taken. Having these fields pre-drafted as a template, with the blanks ready to fill in, removes most of the drafting time from an already-tight window.
Common Mistakes We See in Existing Websites
- Log rotation set purely for disk-space reasons, deleting after a week or two with nobody aware that a compliance clock, not just a housekeeping preference, applies.
- No single owner for "who reports a breach" — in a small team, everyone assumes someone else knows the process, and in practice nobody does until it's needed.
- Payment and form-data breaches treated as a customer-support issue rather than a reportable cyber incident, because the business doesn't recognise a leaked enquiry-form export as falling under the Directions.
- Free-tier CDN or hosting plans chosen for cost, without checking whether the plan actually retains the logs a compliance audit — or CERT-In, if it ever asks — would expect to see.
Frequently Asked Questions
Does CERT-In's six-hour rule apply to a small business website, or only large enterprises?
It applies broadly to "service providers, intermediaries, data centres, body corporates and Government organisations" without a size threshold in the Directions themselves. A small business website that handles logins, forms, or payments falls within scope in the same way a large enterprise does, even though enforcement attention has historically concentrated on bigger, regulated entities first.
What counts as the start of the six-hour window?
The Directions measure from when the organisation becomes aware of, or is notified of, the incident — not from when an investigation confirms its scope or root cause. This is why having logging and a named contact in place matters: the clock starts before you fully understand what happened.
Do we need to host our servers in India to comply?
The specific requirement is that ICT system logs be maintained and stored within the Indian jurisdiction for the mandated 180-day retention window, not that every server or CDN edge node physically sit inside India. In practice this usually means ensuring your logging or backup pipeline retains a compliant copy within India, even if application servers or CDN nodes are elsewhere.
Is this the same requirement as the DPDP Act's breach notification rules?
No — they are separate obligations that can both be triggered by the same incident. CERT-In's Directions require reporting a defined list of cyber incident types to CERT-In within six hours. The DPDP Act and its 2025 Rules separately require notifying the Data Protection Board and affected individuals about a personal data breach, on their own timeline and with their own content requirements. A single incident involving a personal-data leak can trigger both.
What's the actual penalty for not reporting?
Non-compliance with CERT-In's Directions has been reported by legal and compliance commentary as carrying a fine of up to ₹1 lakh and imprisonment of up to one year under the relevant IT Act provisions. Businesses evaluating their exposure should treat this as the kind of detail worth confirming with a lawyer for their specific situation rather than relying solely on secondary summaries — including this one.
We're a WordPress site on shared hosting — is compliance realistic?
Yes, but it usually requires deliberate changes rather than defaults. Shared hosting plans are frequently configured to rotate and delete logs quickly for storage-cost reasons, and NTP sync is rarely pointed at NIC/NPL by default. Both are fixable without moving off shared hosting, though a VPS or managed cloud environment generally makes centralised logging easier to set up correctly the first time.
Where to Start
If you're not sure whether your current site would let you produce 180 days of logs on request, or whether your servers are synced to an Indian time source, that's a half-day audit, not a rebuild. As a web development company in Pune, we build logging, retention and incident-response readiness into every website build we deliver, and it matters even more directly for sites running a checkout or payment system, where a breach is both a CERT-In and a DPDP event at once.
Govindani Infotech's pricing for a compliance audit or a new build with this checklist built in is confirmed directly with our team based on your current setup — get in touch with us to have your hosting, logging and incident-response readiness reviewed.
Sources: