Six hours to report, one hundred and eighty days of logs held in India, and clocks synchronised to NPL or NIC.
The CERT-In Directions have been in force since June 2022 and are the most concrete cyber obligations most Indian businesses have, yet they are the ones we most often find nobody has actioned. Three requirements do almost all the work: report specified incidents within six hours of noticing, keep ICT logs for a rolling one hundred and eighty days inside India, and synchronise system clocks to NPL or NIC time. Each is testable, and each fails quietly by default.
- 6 hoursTo report a specified incident
- 180 daysRolling ICT log retention
- Within IndiaWhere those logs must live
- NPL or NICClock synchronisation source
Four obligations, and why each one quietly fails.
Six hour incident reporting
Specified cyber incidents have to be reported to CERT-In within six hours of noticing them or being notified about them. Six hours is short enough that it cannot be met by a process invented on the day. It needs a named person who can decide an incident is reportable, out of hours contactability, a pre-prepared submission, and clarity on what noticing means so the clock start is defensible. Most organisations we assess have none of these and would discover it during the incident.
One hundred and eighty days of ICT logs, stored in India
Logs for all ICT systems maintained on a rolling one hundred and eighty day basis and stored within Indian jurisdiction. Two things break here. First, default retention on firewalls, endpoints, servers and cloud tenants is routinely shorter, often ninety days or thirty. Second, the storage location requirement catches organisations whose logging pipeline ships everything to a region outside India, which is common with global SIEM deployments and with parent company tooling in GCCs.
Clock synchronisation to NPL or NIC
ICT system clocks synchronised to the Network Time Protocol served by the National Informatics Centre or the National Physical Laboratory, or to a source traceable to them. Entities with global infrastructure may use a different time source provided it does not deviate from NPL and NIC. This is the cheapest obligation to satisfy and one of the most commonly missed, because estates default to vendor or public NTP pools and nobody revisits it. It also matters practically: correlating an incident across systems whose clocks disagree is considerably harder.
A designated point of contact
A point of contact has to be designated to interface with CERT-In, and the details have to be current. This sounds administrative and it is the reason some organisations discover a problem late: CERT-In communications go to a person who left, or to a generic mailbox nobody monitors. It also has to be a real person who can act, not a role address that routes into a ticket queue with a next business day service level.
Knowing which incidents are actually reportable
The Directions list types of incident that must be reported, and the list is broader than most teams assume. It reaches beyond obvious breaches into unauthorised access, identity theft, phishing, attacks on servers and network appliances, malicious code, and incidents affecting data and applications. Under-reporting because an incident felt minor is a real risk. So is reporting everything, which burns credibility and team time. The practical answer is a written classification your team can apply under pressure.
Cooperating with information requests
CERT-In can require information for incident response and mitigation, and failing to provide it is itself non-compliance. That means the logs you are required to retain also have to be retrievable in a usable form, by somebody who knows where they are, at short notice. Logs that technically exist in cold storage nobody can query are compliant on paper and useless in the moment that matters.
The service provider obligations
Additional requirements attach to specified categories of provider, including data centres, virtual private server providers, cloud service providers, virtual private network service providers, and virtual asset and exchange providers, covering customer registration records and their retention. If your business is in one of those categories the obligations go beyond the general ones and are worth assessing specifically rather than assuming the general position covers you.
What non-compliance carries
Failure to comply, including failure to furnish information when required, can attract action under section 70B(7) of the IT Act, which provides for imprisonment of up to a year, or a fine, or both. We deliberately do not put the fine amount on this page, because in our experience quoting it produces panic purchasing rather than the sequenced remediation that actually closes the gaps. The obligations are cheap to meet; the argument for meeting them does not need a number.
Twelve checks you can run this afternoon.
Reporting readiness
- Is there a named person who can declare a reportable incident?And a deputy, reachable outside office hours
- Could you submit to CERT-In within six hours, tonight?Not in principle. Tonight
- Do you have a written list of what counts as reportable?Applied under pressure, not interpreted from the Directions
- Is your designated point of contact still employed and monitored?A departed contact is a common quiet failure
Logs
- Do firewall, endpoint and server logs go back 180 days?Check the actual oldest record, not the configured policy
- Does your cloud tenant audit log retention reach 180 days?Default retention is frequently shorter
- Are the logs stored within Indian jurisdiction?Check the region your SIEM or log archive writes to
- Can somebody actually query them at short notice?Retained but unqueryable is compliant and useless
Time and coverage
- Are system clocks synchronised to NPL or NIC, or a traceable source?Not a default vendor or public pool
- Does that include servers, firewalls, endpoints and appliances?Network gear is usually the one nobody checked
- Do biometric, CCTV and OT systems have any usable logs at all?ICT systems, and frequently outside IT governance
- If you are a specified service provider, are the extra duties covered?Data centres, cloud, VPS, VPN and virtual asset providers
Four obligations, mostly closed with configuration.
Most of this is settings, not spend
Clock source is a configuration change. Log retention is usually a retention policy and, where volume makes that expensive, a decision about which logs genuinely qualify as ICT system logs. The reporting process is a document and a rehearsal. Very few CERT-In engagements need new products, and we will tell you when yours is one of the exceptions rather than reaching for a purchase.
Microsoft Partner, so tenant logging is familiar ground
Unified audit log retention, Entra sign-in and audit logs, Defender and Intune telemetry, and where each one physically lands are the questions that decide whether a Microsoft estate meets the retention and location requirements. We work in these tenants daily and know which settings are licence-gated and which are simply switched off.
We build one incident process, not two
CERT-In and DPDP overlap and diverge in ways that matter under pressure. Rather than a CERT-In plan sitting beside a DPDP plan, we build a single decision tree that takes incident characteristics and produces the right notifications on the right clocks. Sectoral obligations for BFSI slot into the same tree.
We are clear about the legal boundary
Whether a specific incident is reportable, and whether your entity falls into one of the specified service provider categories with additional duties, are determinations for your counsel. We assess your technical position, build the capability, and give your legal advisers the facts to reason from. We do not offer legal advice.
What we find, by sector.
BFSI and fintech
Usually the strongest logging and the most complex routing, because CERT-In, DPDP and sectoral reporting to RBI, SEBI or IRDAI can all attach to one incident on different clocks. The decision tree matters more here than the technical remediation.
GCCs and global subsidiaries
The log location requirement is the recurring problem. Parent company SIEM deployments frequently write to a region outside India, which satisfies the group and not the Directions. Resolving it usually means a local retention tier rather than re-architecting the group pipeline.
Cloud, hosting and VPN providers
Specified categories carrying additional obligations around customer registration records and their retention. Worth assessing specifically, because the general position does not cover these and assuming it does is a meaningful exposure.
Manufacturing and logistics
Operational technology outside IT governance is the weak point. Shop-floor systems, biometric attendance and CCTV frequently produce no retrievable logs at all, which makes both the retention obligation and any subsequent investigation difficult.
Healthcare and diagnostics
Sensitive data raises the stakes on any incident, and estates are often a mix of a modern tenant alongside legacy clinical systems whose logging is limited and whose clocks have never been checked.
Education
Large user populations, thin IT teams, and a mix of managed and unmanaged devices. Reporting readiness is usually the gap rather than logging, because nobody has been designated and there is no out of hours path.
What closing each gap actually involves.
Pointing clocks at NPL or NIC
The quickest win available. In a domain environment you set the authoritative time server once and the estate follows. The work is in the places that do not follow: firewalls, switches, hypervisors, appliances and anything on the operational technology side keeping a vendor default.
- Set the authoritative source, then enumerate what does not inherit it
- Network and security appliances are the usual stragglers
- Global groups may use another source that must not deviate from NPL and NIC
Extending log retention to the longer requirement
CERT-In asks for a rolling one hundred and eighty days and DPDP Rule 6 expects at least a year, so set retention to the year and satisfy both. Configuration is quick; the history is not, because retention only evidences a period after that period has elapsed.
- Start this first, since it is the one thing you cannot accelerate later
- Check the oldest actual record per system, not the configured policy
- Where volume makes a year costly, scope which systems genuinely qualify
Bringing log storage inside India
The recurring finding in GCCs and subsidiaries of global groups, where the pipeline writes to a parent company region. The resolution is almost never re-architecting the group platform, which would be disproportionate and is rarely achievable anyway.
- Add a local retention tier in an Indian region for in-scope systems
- Leave the group security operations pipeline alone where possible
- Confirm the region each log destination actually writes to, not the console you log into
Naming who can declare, and reaching them
Six hours is short enough that the process fails on availability rather than on capability. A named primary and deputy, contactable outside working hours, with written guidance on what constitutes noticing, is most of the answer.
- Two people, both reachable by a method that works at night
- Write down what noticing means so the clock start is defensible afterwards
- Keep contact details on a review cycle so they do not quietly go stale
Turning the reportable list into a decision anybody can make
The Directions specify incident types, and reading a legal instrument at two in the morning is not a process. A short classification document that an on-call engineer can work through in minutes is, and it prevents both under-reporting and reflexive over-reporting.
- Plain-language categories with examples drawn from your own estate
- Explicit guidance at the edges, where judgement is actually required
- A default of escalate to the named authority when genuinely unsure
Making retained logs actually retrievable
CERT-In can require information, and logs sitting in cold storage nobody can query satisfy the retention obligation while failing the one that matters during an incident. Retrievability is a separate check from retention and is frequently assumed rather than tested.
- Run a query against the oldest retained data and time it
- Make sure more than one person knows how, and that it is documented
- Cold archive tiers can carry restore delays measured in hours
The default position against what the Directions require.
| Feature | Requirement | Typical default state | What is required |
|---|---|---|---|
Incident reporting | An escalation path aimed at restoring service, no regulator step | Reportable incidents submitted to CERT-In within six hours of noticing | |
Declaration authority | Emerges during the incident, often the next morning | Named in advance, with a deputy, contactable out of hours | |
Log retention | Vendor defaults, commonly thirty to ninety days | Rolling one hundred and eighty days across ICT systems | |
Log location | Wherever the SIEM or vendor cloud region happens to be | Stored within Indian jurisdiction | |
Log retrievability | Nobody has queried them since deployment | Usable at short notice, including for CERT-In requests | |
Time source | Vendor default or a public NTP pool | NPL or NIC, or a source traceable to them without deviation | |
Point of contact | A generic mailbox, or somebody who has left | A designated, current, actionable contact | |
Incident classification | Judged case by case under pressure | A written list the team can apply consistently |
CERT-In and DPDP are separate obligations on separate clocks.
One incident can trigger both, and they are not the same requirement. CERT-In covers specified cyber incidents whether or not personal data is involved, runs a six hour clock, goes to CERT-In, and expects one hundred and eighty days of logs held in India. DPDP covers personal data breaches, requires immediate notification to the Data Protection Board and to affected individuals with a detailed report inside seventy two hours, and expects at least a year of logs under Rule 6. The six hour clock binds first. Build one decision tree that routes correctly rather than two plans that each assume they are the only one.
- A ransomware event encrypting a customer database plausibly triggers both regimes
- Log retention should be set to the longer requirement, which is the DPDP one year
- Storage location follows the stricter requirement, which is CERT-In within India
- Individuals are notified under DPDP and not under CERT-In
Four stages, and the first one is quick.
- 1
Test the four obligations directly
Pull the oldest available log record from each major system rather than reading the retention policy. Check where those logs physically live. Check the configured time source on servers, firewalls, endpoints and appliances. Confirm who your designated contact is and whether they still work here. This is fast and it produces an unambiguous position.
- 2
Close the retention and time gaps
Retention extended to meet the longer of the CERT-In and DPDP requirements, storage location corrected where logs are leaving India, and clock synchronisation pointed at NPL or NIC or a traceable source across the estate. Where log volume makes full retention costly we work through which systems genuinely qualify rather than retaining everything by reflex.
- 3
Build the reporting capability
Declaration authority named with a deputy, a written incident classification your team can apply under pressure, a pre-prepared CERT-In submission, and the routing decision tree covering CERT-In, DPDP and any sectoral obligation. Contact details registered and put on a review cycle so they do not go stale.
- 4
Rehearse against the six hour clock
A tabletop with the real responders, run against the tightest clock rather than the comfortable one. The recurring findings are that nobody is sure who declares, that the classification list is ambiguous at the edges, and that the submission takes longer to assemble than anybody expected. Finding those in a room is inexpensive.
CERT-In compliance, answered plainly.
What sits either side of this.
Data breach response plan
The DPDP seventy two hour clock and the routing decision tree that sends one incident to the right regulators on the right timelines.
Learn moreDPDP Act compliance
The wider Indian statutory obligation, including the Rule 6 log retention expectation that runs longer than the CERT-In one.
Learn moreMicrosoft Sentinel
Cloud-native SIEM for the detection and retention half of the problem, including where the data physically lands.
Learn moreFour checks, and you will know where you stand.
Unlike most compliance work, CERT-In readiness is directly testable: pull the oldest log, check where it lives, check your time source, check who your designated contact is. We can run that with you quickly and tell you plainly what needs closing. Remote-first from Hyderabad, serving all of India.
Related Services
Explore more solutions that work great with this service