CERT-In clarifies the six-hour reporting trigger for cloud and SaaS incidents

CERT-In has issued an advisory clarifying how the six-hour incident reporting obligation applies where the affected systems are operated by a cloud or SaaS provider rather than by the reporting entity itself.

The clarification

Three points, all of which narrow the scope for argument.

The clock starts on noticing, not on confirming. The obligation is triggered when the entity notices an incident or is brought to notice of one. Time spent establishing whether an incident occurred is inside the six hours, not before it.

Third-party operated infrastructure is in scope. Where an incident affects the entity's data or services, the obligation rests with the entity regardless of who operates the infrastructure. Waiting for a provider's confirmation does not extend the window.

Provider notification counts as being brought to notice. A security bulletin or breach notification from a SaaS vendor starts the clock for every customer entity to whom it is relevant.

What this breaks

Most incident response processes have a triage stage before formal declaration, precisely so that the organisation does not report noise. The advisory makes clear that this stage sits inside the reporting window rather than before it.

For an organisation with a large SaaS estate, the third point is the harder one. Vendor security bulletins arrive regularly. Each one that touches your data is a potential trigger, and somebody has to assess it against the twenty incident categories within hours.

The practical design

Organisations meeting this reliably have converged on a similar pattern:

• A single intake channel that receives internal detections and vendor notifications alike
• A pre-agreed assessment rubric mapping the twenty CERT-In categories to observable signals, so the assessment takes minutes rather than a meeting
• Named, rostered authority to report, with no approval chain above it — the person on duty reports, and escalation happens in parallel
• A default-to-report posture, because over-reporting has no penalty and under-reporting does

The last point is the cultural change. Teams accustomed to reporting only confirmed material incidents find it uncomfortable, and it is nonetheless the design the obligation implies.

Interaction with DPDP

Where the incident involves personal data, a separate DPDP breach intimation obligation arises to affected data principals and the Data Protection Board, with no materiality threshold. The two obligations have different triggers, different recipients and different content. Running them as one process reliably fails one of them.