CERT-In and DPDP incident readiness for Indian companies

Incident readiness is where privacy law meets the stopwatch.

For Indian companies, incident response can no longer sit in separate security and privacy binders. CERT-In directions create a cyber incident reporting discipline for covered events, while the Digital Personal Data Protection Act, 2023 and the notified DPDP Rules, 2025 require organisations to handle personal data breaches with clear facts, mitigation and communication. The same incident may trigger both tracks. A useful readiness plan therefore starts with one shared fact room and then applies the correct legal tests.

What to review

Start by mapping the events that could involve both cyber security and personal data. Common examples include compromised administrator accounts, exposed cloud storage, ransomware affecting customer records, unauthorised exports, API abuse, payment data incidents, vendor platform breaches and leaked support tickets. The team should know which events are plainly security-only, which are privacy-only, and which need joint triage within the first hour.

Review the organisation's role for each dataset. A company may be a Data Fiduciary for its customers, an employer for workforce data, and a processor for enterprise clients. That role determines who can decide notifications, who must be informed, and what records need to be preserved. In outsourced systems, the vendor may hold the logs, but the company may still hold the customer relationship and the regulatory risk.

Check whether the incident plan lists the evidence needed for both workstreams: discovery time, containment actions, affected systems, personal data categories, number or range of individuals affected, root-cause notes, logs preserved, vendor facts and decisions made. CERT-In readiness also needs attention to incident categories and log retention, while DPDP readiness needs clear assessment of personal data impact and communication to affected people where required.

Implementation steps

Create a joint incident intake route for privacy, legal, security, product, IT and vendor alerts. The form should capture the reporting source, date and time noticed, system owner, suspected data categories, affected geography, customer impact, processors involved, containment status and whether logs have been preserved. Avoid asking the first reporter to make legal conclusions. Ask for observable facts.

Build a triage meeting template for the first response call. Security should cover containment, indicators, systems and evidence. Privacy or legal should cover personal data, Data Fiduciary or processor role, individual impact and notification analysis. Product and operations should confirm business impact, user-facing controls, customer support exposure and service continuity. The output should be a short decision log, not a long memo.

Maintain a combined evidence pack. It should include a chronology, preserved logs, screenshots where useful, access review notes, vendor communications, customer-impact estimates, mitigation steps, notification drafts and executive updates. CERT-In directions refer to maintaining logs securely for 180 days, so the readiness pack should name the systems from which those logs will be pulled and who can approve urgent access.

Pre-clear notification language. DPDP breach communication should be understandable to affected individuals and should not wait for perfect forensic poetry. Prepare clauses for what happened, when it was noticed, what personal data may be involved, likely consequences, steps taken, steps the individual may take and contact details. Keep separate templates for enterprise customers, processors, employees, regulators and affected people.

Run a tabletop exercise using an overlap scenario. A strong exercise might begin with unusual API traffic, then reveal a vendor credential compromise and a personal data export. Measure whether the team can identify CERT-In and DPDP paths, preserve evidence, brief leadership and draft plain communications without re-arguing ownership.

Common mistakes

• Running CERT-In and DPDP analysis in separate rooms, which creates inconsistent timelines and weak evidence.
• Treating vendor logs as someone else's problem until the incident has already aged beyond useful reconstruction.
• Drafting notifications from scratch during the incident instead of using pre-cleared templates with verified facts inserted.

How DataNuance can help

DataNuance helps Indian companies turn incident duties into usable operating routines. We map cyber and privacy incident triggers, design triage forms, align CERT-In and DPDP decision points, build evidence packs, prepare notification templates and run tabletop exercises for legal, security, product and leadership teams.

For companies preparing for enterprise audits, board reporting or DPDP implementation, we can test whether the current process answers the practical questions: who noticed the event, what personal data is involved, where the logs are, who owns the vendor call, what gets reported and what affected people are told. To convert the readiness plan into an incident workflow, contact DataNuance through the /contact page.

FAQs

Does every CERT-In reportable incident become a DPDP personal data breach?

No. A cyber incident may affect infrastructure without involving digital personal data. The incident team should test both tracks quickly and record the factual basis for the classification.

Can one evidence pack support both CERT-In and DPDP readiness?

Yes. A shared chronology, log bundle, containment record and decision log can support both workflows, provided the legal analysis and notification recipients are kept distinct.

Who should lead an overlap incident in an Indian company?

Security should usually lead containment and technical evidence. Privacy or legal should lead personal data assessment and notification analysis. Business owners should confirm user, vendor and customer facts.

How often should companies test CERT-In and DPDP incident readiness?

At least twice a year for organisations processing meaningful volumes of personal data, and after major cloud, vendor, product or support workflow changes.

Sources

• India Code, Digital Personal Data Protection Act, 2023.
• MeitY, Digital Personal Data Protection Rules, 2025.
• CERT-In Directions under section 70B dated 28 April 2022.