Run a DPDP and CERT-In Compliance Workflow for AI Systems

Tier: Advanced · Workflow area: AI governance, risk & compliance

These impose concrete, enforceable obligations: lawful processing with purpose limitation, security safeguards, breach reporting on a tight clock, and heightened duties for high-risk processing. This playbook builds the compliance workflow that keeps an AI system on the right side of Indian law — reconciling CERT-In's fast breach clock with the Data Protection Board's, embedding DPDP obligations into how AI tools process personal data, and preparing the DPIA-style assessment expected of significant data fiduciaries. It grounds the whole governance track in the actual law an Indian enterprise answers to.

When to reach for this

• •
  Your organization (or your client) processes personal data of individuals in India through AI systems.
• •
  You need an AI acceptable-use policy or risk register (pb-49, pb-51) to be defensible under DPDP, not just ISO/NIST.
• •
  You must reconcile CERT-In and DPDP breach-reporting obligations into one incident workflow.
• •
  Skip this only where no personal data of Indian data principals is processed; otherwise it applies regardless of which other frameworks you use.

The workflow

1. 1.

   Establish your role and lawful basis. Determine whether you are a Data Fiduciary (and whether "Significant"), what personal data your AI system processes, and the lawful basis (typically consent) for that processing. Purpose limitation means the AI use must match the purpose the data was collected for.

2. 2.

   Embed DPDP obligations into AI data handling. Encode data minimization, purpose limitation, and security safeguards into the AI workflow — redaction before prompting, approved endpoints for personal data (from the AUP, pb-51), and retention limits.

   Copy

   DPDP obligation          AI-system control
   Lawful basis / consent   Process personal data only for the consented purpose
   Purpose limitation       No repurposing of prompts/logs for model training w/o basis
   Data minimization        Redact/aggregate before sending to any AI endpoint
   Security safeguards      Encryption, access control, approved-endpoint allowlist
   Storage limitation       Defined retention + deletion of AI logs containing PII
   

3. 3.

   Build the reconciled breach-reporting runbook. India has two clocks: CERT-In requires reporting certain cyber incidents within 6 hours, while the DPDP/DPB regime sets its own personal-data-breach reporting timeline (on the order of 72 hours to the Board). Your runbook must satisfy the tighter CERT-In clock without missing the DPB obligation.

   Copy

   T+0h    Detect incident (incl. AI-system compromise: prompt-injection exfil, data leak)
   T+≤6h   CERT-In notification for reportable cyber incidents
   T+≤72h  DPB / data-principal notification for personal-data breach (per DPDP Rules)
   ...     Document, remediate, post-incident review
   

4. 4.

   Prepare a DPIA-style assessment for high-risk AI. Significant Data Fiduciaries face heightened obligations. For high-risk AI processing, run a data-protection impact assessment covering the processing, risks to data principals, and mitigations.

5. 5.

   Track the phasing timeline. Obligations arrive in stages — the DPB is operational, Consent Manager registration and substantive Data Fiduciary obligations phase in through 2026–2027, with penalties up to INR 250 crore. Map which obligations bind you now versus which to prepare for.

6. 6.

   Position DPDP alongside voluntary frameworks. India has no standalone AI law yet, so ISO 42001 (pb-48) and NIST AI RMF (pb-47) are the control frameworks that operationalize DPDP compliance. Show how each control satisfies a legal obligation.

Verify before you trust it

The workflow is trustworthy when the breach runbook actually hits the tighter clock and each DPDP obligation maps to a real control. Test the runbook with a tabletop exercise: simulate an AI-system data-leak incident and confirm the team can complete the CERT-In notification path within the 6-hour window and the DPB path within its timeline — a runbook that only works on paper fails at 3 a.m. Then run the obligation-to-control trace: for each DPDP obligation (lawful basis, purpose limitation, minimization, safeguards, storage limitation), confirm a specific implemented control satisfies it, not a policy sentence. A mapping where "security safeguards" points to no encryption or access-control evidence is incomplete. Finally, confirm the phasing analysis correctly identifies which obligations bind you today versus which are future-dated, so you neither over- nor under-comply.

Pitfalls

• Missing the tighter clock. Optimizing for the DPB's timeline while blowing CERT-In's 6-hour window is a real compliance failure. Build the runbook around the earlier deadline.
• Treating DPDP as future-only. Parts of the regime are already live and the rest phases in soon; "not enforceable until 2027" invites unpreparedness. Track what binds now.
• Repurposing prompts and logs. Feeding personal data captured for one purpose into model training or a new use violates purpose limitation. Gate secondary use on a valid basis.
• Ignoring AI logs as personal data. Prompt logs and outputs often contain PII and fall under storage-limitation and security obligations. Include them in retention and safeguards.
• Substituting a voluntary framework for the law. ISO 42001 or NIST alignment is evidence of diligence, not compliance with DPDP. Map controls to obligations; do not conflate them.

Tools

• India DPDP Act 2023 + DPDP Rules 2025the free primary legal references defining obligations, roles, and the personal-data-breach regime.
• CERT-In directionsthe free reference for the cyber-incident reporting clock the runbook must satisfy alongside DPDP.
• ISO/IEC 42001the voluntary control framework whose controls you map to DPDP obligations to operationalize and evidence compliance.

Client-safe variant

For a client, build the DPDP/CERT-In workflow around their specific role (fiduciary/significant fiduciary), their data, and their existing incident-response process — compliance is entity-specific and cannot be templated wholesale. Keep the DPIA, breach runbook, and obligation-to-control mapping inside their governance environment as their legal records, and coordinate with their counsel since this is legal territory, not just security. Deliver a reconciled breach runbook their team can execute against the real clocks, map their voluntary ISO 42001/NIST controls to their DPDP obligations, and flag the phasing dates relevant to them. Do not give a client legal advice in your own name; frame the work as compliance operations supporting their legal function, and never reuse one client's DPIA or determinations for another.