DPDP Compliance Checklist for SaaS & BFSI

Phase 1: Data inventory and classification

Before you can comply with the DPDP Act, you must know what personal data your product processes. Build a data inventory that maps every data element your application stores or transmits to its classification (personal data vs. sensitive personal data), the processing purpose, the lawful basis, the storage location, the retention period, and the third-party processors who receive it.

For AI-powered SaaS, extend the inventory to cover AI-specific data flows: which prompts contain personal data, which model providers receive it, what is logged by the AI system, and whether any personal data is used for model fine-tuning or evaluation. These AI data flows are frequently invisible in traditional data maps.

Classify personal data by sensitivity. The DPDP Act treats certain categories — financial data, health data, biometric data, genetic data, children's data, caste and religious information — as requiring heightened protection. Your inventory should flag these and ensure they have stricter controls than ordinary personal data.

Phase 2: Consent infrastructure

Audit every point in your product where personal data is collected or processed. For each point, verify: (a) there is a valid lawful basis, (b) if that basis is consent, the consent was obtained before processing and meets the Section 6 standard of being free, specific, informed, unconditional, and unambiguous, and (c) there is a record of that consent tied to the user's account.

Update your consent management system to handle AI-specific processing. Your existing privacy policy and cookie consent may not cover LLM processing. Add AI processing notices that describe: what data is sent to which model provider, for what purpose, with what protections (e.g., PII redaction), and how users can opt out of AI processing while retaining access to non-AI features.

Test withdrawal flows. Can a user withdraw consent for AI processing through self-service? Can your system immediately stop routing their data through LLM endpoints after withdrawal? If the answer to either is no, fix the withdrawal mechanism before the Act becomes enforceable.

Phase 3: Technical controls for AI workflows

Implement PII detection and redaction for all AI traffic. Every prompt sent to an LLM provider must be scanned for Indian personal data including Aadhaar (with Verhoeff checksum validation), PAN, UPI IDs, IFSC codes, Indian mobile numbers (10 digits starting with 6-9), Voter IDs, driving licences, and passport numbers. Generic regex is insufficient — use a purpose-built Indian PII detection library.

Establish tamper-evident audit logging for all AI interactions. Every request through your AI layer must generate an audit record that includes the timestamp, the requesting application or agent, the governance decisions applied (which PII was detected, which rules fired), the redacted payload sent to the model provider, and the provider's response. This log must be immutable and stored separately from operational logs.

Configure retention policies for AI data stores. Prompt logs, embedding databases, and AI-generated content must have documented retention periods tied to the processing purpose. If you use customer support conversations for model evaluation, those conversations must be deleted after the evaluation purpose is fulfilled, typically 30–90 days.

Phase 4: Vendor and processor management

Every AI model provider, cloud service, and data processor who receives personal data from your organisation is a 'data processor' under the DPDP Act. You must ensure each processor provides sufficient guarantees that they will protect the personal data you share with them. Obtain Data Processing Agreements (DPAs) from all processors that specify: the nature and purpose of processing, the types of personal data processed, the processor's security obligations, and the processor's obligations on breach notification.

Review the data handling policies of your AI model providers. OpenAI, Anthropic, Azure, and Google have different policies on prompt retention, training data usage, and data residency. For DPDP compliance, you need providers that do not use your prompts for model training by default (or where you can opt out), commit to data residency requirements if applicable, and notify you of breaches within a timeframe that allows you to meet your own notification obligations.

Consider routing all AI traffic through a governance gateway rather than calling model providers directly. A gateway allows you to enforce PII redaction before data leaves your infrastructure, apply consent and purpose limitation checks, maintain your own audit trail independently of provider logs, and switch providers without compliance gaps.

Phase 5: Rights fulfilment and grievance redressal

Implement technical capabilities to fulfil data principal rights within the timeframes that Rules will prescribe. For the right to information (Section 12), you need the ability to generate a complete summary of personal data processed for any user, including data in AI-specific stores. For the right to correction (Section 13), you need processes to update personal data across all stores including AI evaluation datasets.

Build a grievance redressal mechanism as required by Section 14. This must be a clearly advertised channel (email, in-app form, or dedicated portal) where individuals can raise complaints about personal data processing. Assign responsibility to a named individual. Establish internal SLAs for initial acknowledgement and resolution. Document every complaint and its resolution.

For BFSI companies, align your DPDP grievance mechanism with existing RBI and SEBI complaint handling obligations. The RBI's Integrated Ombudsman Scheme and SEBI's SCORES platform have their own timelines and escalation paths. Where a complaint involves both financial services and data protection, you need a coordinated response.

Phase 6: Incident response and breach notification

Prepare for data breaches now, not after they occur. Under Section 26 of the DPDP Act and the Rules that will follow, data fiduciaries will be required to notify the Data Protection Board of India and affected data principals within a specified period after becoming aware of a breach. The European precedent (GDPR's 72-hour rule) suggests this window will be short.

An AI-specific breach scenario: your LLM gateway logs contain unredacted Aadhaar numbers because PII detection missed some instances. This is a data breach — personal data was processed without adequate protection, creating the risk of harm to data principals. Your incident response plan must cover AI-specific breach scenarios including model inversion attacks, prompt leakage, and unauthorised fine-tuning data access.

Build your incident response capability around your audit trail. The ability to quickly identify which users were affected, what data was exposed, for how long, and what the root cause was — this capability determines whether you can notify within the regulatory window. AI governance platforms that maintain tamper-evident logs make breach scoping dramatically faster.

DPDP Act pillar implementation addendum

A pillar page should also connect the legal idea to a concrete implementation path. Start with ownership: name the product owner, engineering owner, security reviewer, and compliance reviewer for this topic. Then map the systems that can create, store, transform, or transmit the relevant personal data. The map should include frontend forms, backend APIs, queues, warehouses, LLM prompts, embedding stores, admin exports, vendor dashboards, and customer-success tooling.

Next, document the lawful purpose and the user-facing notice. The notice should be clear enough that a data principal understands what is processed, why AI may be involved, what categories of personal data are affected, and how consent or withdrawal works. If the workflow supports children, healthcare, financial services, employment, or government delivery, treat that context as higher risk and add stricter review before allowing personal data into model calls.

The engineering control should run before data leaves the application boundary. Scan the full prompt package, not just the user's message. That means system instructions, retrieved snippets, tool outputs, attachments, OCR text, chat history, and structured JSON all need inspection. When a high-confidence identifier is found, redact, tokenise, block, or route to a safer model depending on the policy. Keep the original sensitive value out of general logs unless a protected exception is approved.

Audit evidence should be designed for reconstruction. A reviewer should be able to answer: when did the request happen, which application sent it, which data type was detected, which rule fired, what action was taken, which provider received the final payload, and who approved any exception. Without that trail, teams are left with policy claims rather than proof. With it, they can respond faster to buyer diligence, internal audits, breach triage, and regulator questions.

Finally, make the process repeatable. Add sample payloads to tests, run scheduled scans against logs and representative documents, check sitemap and page health for public guidance, and keep the DPDP scanner linked from the page so readers can move from learning to action. The goal is not to freeze the system; it is to make every future AI workflow easier to review, safer to launch, and easier to explain.