Cyber / CERT-In

CERT-In Reporting Controls

CA Nikhil Gupta·June 2026·3 min readCyber / CERT-In

Six hours is too short to invent an incident process after the alert arrives.

Quick View

Decision

Pre-authorise incident classification and reporting so the first report can be made with available facts.

First action

Register CERT-In contact.

Core evidence

CERT-In directions.

Main warning

Reporting only after root cause.

Why It Matters

The CERT-In directions apply to service providers, intermediaries, data centres, body corporates and government organisations.

They require specified cyber incidents to be reported within six hours of noticing or being brought to notice, designate a point of contact, synchronise ICT clocks and retain logs securely for 180 days within India.

An initial report can be supplemented as investigation develops; waiting for full root-cause certainty can undermine the deadline.

Control Framework

AreaWhat to establishOperating rule
TriggerAnnexure-I incident category.Use triage matrix.
ClockNotice time and six-hour deadline.Record immediately.
ContactCERT-In point of contact.Keep current.
LogsAll ICT systems for rolling 180 days.Secure in India.

Action Checklist

  1. Register CERT-In contact.
  2. Synchronise system clocks.
  3. Test log coverage.
  4. Create incident categories.
  5. Prepare reporting template.
  6. Run six-hour tabletop exercise.

Practical Example

A company discovers ransomware at 2 a.m. but cannot identify who may report or access logs until the next business day.

Evidence to Keep

  • CERT-In directions.
  • Point-of-contact filing.
  • NTP configuration.
  • Log-retention inventory.
  • Incident report and acknowledgement.
  • Follow-up correspondence.

Warning Signs

  • Reporting only after root cause.
  • No overnight authority.
  • Logs stored for thirty days.
  • Different server time zones.
  • No record of notice time.

Detailed Review

Privacy governance should connect the personal data, individual, purpose, collection point, system, owner, recipient, access role, retention trigger and incident dependency. A policy that cannot be traced to this chain is difficult to operate.

Create a dated legal matrix rather than one status label. Record the DPDP provision, commencement date, present readiness action, current IT or sectoral obligation and the evidence owner.

Design controls in the product and system. A written rule cannot stop an SDK from firing, a shared folder from exposing payroll, or a vendor from retaining deleted users unless technology and operations enforce it.

Evidence should be generated during normal work: versioned notices, event logs, access approvals, request tickets, deletion reports, vendor registers, incident chronologies and management decisions.

Use proportionate identity and security checks. Excess verification creates more personal data, while weak verification can expose another person’s records or permit account takeover.

Synchronised clocks and durable logs are essential because incident reporting, transaction tracing and forensic conclusions depend on exact chronology.

The incident team should distinguish containment, evidence preservation, reporting, customer communication and recovery. Each has a different owner and deadline.

Control Test

Test the control using a real user journey from collection to deletion. Capture the notice shown, data stored, vendors called, employees with access, retention period and response if the user withdraws or complains.

Run a negative scenario: the vendor is breached, the user is a child, the employee exits, the phone is stolen, the data was inaccurate or the regulator asks for proof. Record which control fails.

Check that system records and public wording agree. Product forms, privacy notice, CRM fields, SDK behaviour, vendor contracts and support scripts should describe the same processing.

Assign a named owner and internal deadline for every gap. A risk register without funded action and closure evidence becomes an archive of known failures.

Retain the rejected alternatives and decision basis. This is especially important where the law is in phased commencement or a proportionate technical method is selected.

Escalation Route

Start with the system owner, privacy or security owner and the documented data flow. Preserve records before making changes, and separate current statutory reporting from future DPDP readiness.

For a breach, financial fraud, rights dispute, children’s-data issue or regulated-sector event, involve qualified legal, cyber, forensic and sector specialists and use the applicable official reporting or grievance channel.

Management Review

Management should record the risk owner, affected data population, financial or operational impact, current legal duty, future DPDP milestone and funded remediation date. A privacy register without accountable closure is only a list of known gaps.

The control should be tested with evidence rather than self-certification. Use screen recordings, exported logs, access reports, deletion output, vendor responses, tabletop minutes or complaint acknowledgements to prove that the workflow operates as designed.

Where several laws apply, maintain one incident or request chronology but separate each legal trigger and deadline. CERT-In, RBI, UIDAI, IRDAI, police, contractual and DPDP processes should not be collapsed into one generic notification decision.

Frequently Asked Questions

What is the reporting deadline? â–¼
Within six hours for specified incidents.
Can more details follow later? â–¼
Yes, organisations can provide available facts and supplement them.
How long must logs be kept? â–¼
A rolling 180 days under the directions.
Where should logs be maintained? â–¼
The directions state within Indian jurisdiction.