DPDP Act and AI: What CA Firms Need to Know

A CA firm becomes DPDP-ready for AI not by reading the Act once but by putting a small number of concrete things in place: someone accountable, a list of every AI tool touching client data, updated consent language, real vendor contracts, a staff policy, and a breach plan. This is the operating checklist for partners — what to build, in what order, over the next 90 days — assuming you already understand why the DPDP Act applies to your firm (if you don't, start with the DPDP Act and AI tools handling client data, which covers the concepts this guide turns into action).

The four things every firm must have before AI touches client data

Before anything else, a firm needs: (1) a named person accountable for data-protection decisions, (2) a written list of every AI tool in use and what it touches, (3) engagement letter language disclosing AI use, and (4) at least a one-page policy staff have actually seen. Firms that skip straight to "which tool should we buy" without these four in place end up retrofitting compliance after the fact, which is harder and less convincing to a client or a regulator than building it in from day one.

Step 1: Appoint someone accountable

The DPDP Act's formal Data Protection Officer obligation attaches to entities classified as significant data fiduciaries, which most CA firms will not be. That does not mean accountability should be diffuse. Name one partner — or, in a larger firm, a compliance manager reporting to a partner — as the person who owns AI and data-protection decisions: approving new tools, reviewing the inventory, and being the first call if something goes wrong. Put the name in the internal policy so staff know exactly who to escalate to, rather than guessing or staying quiet.

Step 2: Build the AI tool inventory

This is the step firms skip and the one that unlocks everything else. List every AI tool anyone in the firm uses for client-related work — including the ones nobody officially approved. For each tool, record:

• What it is used for (drafting, research, reconciliation, bookkeeping, notice replies).
• Whether it touches identifiable client data, and if so, which category (financial, PAN-linked, banking, payroll).
• Account tier (free consumer, paid business, enterprise) and whether a data processing agreement exists.
• Where the vendor processes and stores data (India-hosted or not).
• Whether the vendor commits, in writing, not to train on your inputs.

Most firms are surprised by how many tools show up once staff are actually asked — this is often where "shadow AI" (unapproved tools staff adopted on their own) becomes visible for the first time. You cannot manage a risk you have not listed, so this register comes before any policy or vendor negotiation.

Step 3: Fix consent and engagement letter language

Once you know which tools touch client data, update the disclosure clients receive. Add a short clause to the engagement letter stating that the firm may use AI tools in the course of the engagement, distinguishing tools used for general drafting and research (no client data involved) from tools that process the client's actual data, and naming the safeguards applied — anonymisation by default, vetted tools for anything identifiable. This converts an unstated assumption into a documented position the client has accepted, which matters both for DPDP purpose-limitation reasoning and for your professional-conduct position if a client later asks why their data went where it did.

Step 4: Get real vendor contracts, not just terms of service

For every tool in the inventory that touches identifiable client data, insist on a genuine data processing agreement — not just clicking "I agree" on consumer terms. The clauses that matter for a data fiduciary:

• No training on your data. In writing, covering both the vendor and any model provider it relies on.
• Data residency. Where the data is actually processed and stored; India-hosted is simplest to defend.
• Deletion on request. A defined process and timeline for having client data removed when an engagement ends or a client withdraws consent.
• Sub-processor disclosure. A list of every party downstream of the vendor that touches the data, since a chain of vendors is only as private as its weakest link.
• Security safeguards. Encryption in transit and at rest, and access controls the vendor can actually describe when asked.

Vendors that build specifically for regulated Indian financial data tend to have these answers ready. Serenvya pairs AI process automation with DPDPA compliance consultancy for Indian businesses, and Finnect positions its finance agents around secure, compliant enterprise workflows — both are the kind of vendor conversation that should produce a real contract, not a shrug.

Step 5: Write and roll out an internal AI use policy

Staff need a written answer to "what may I put into which tool," not an assumed one. This does not need to be long on day one — a single page naming approved tools, prohibited data categories for consumer tools, and the escalation contact from Step 1 is enough to start. For the full copy-paste template with every section a firm policy should cover, see AI policy for CA firms: a practical template and guide.

Step 6: Build a breach response plan and register

The DPDP framework expects a data fiduciary to act on a personal data breach, including notification as required, and you cannot notify what you have not detected. With the inventory from Step 2 in hand, write a one-page plan: who gets told first (the Step 1 owner), how staff report a suspected incident (accidental upload, a compromised account, a vendor breach notice), and what the firm's standard response sequence is — contain, assess scope, notify as required, document. Keep a simple breach register even if it stays empty for years; a firm that can show it had a plan is in a materially better position than one improvising during an actual incident.

Step 7: Train staff and log sign-off

A policy nobody has read protects no one. Run a short training session — even 30 minutes — covering the approved tools list, the "no identifiable client data in consumer chatbots" rule, and who to call if something goes wrong. Have each staff member acknowledge they have read the policy, and keep that log. This is also the natural moment to connect AI policy to the firm's existing engagement-quality controls: verification sign-off on AI-assisted work should sit next to data-handling sign-off, not as a separate, forgotten process.

A 90-day implementation sequence

Partners can follow this directly:

• Days 1–15: Name the accountable owner (Step 1). Start the tool inventory (Step 2) by asking every staff member what they currently use.
• Days 16–30: Finish the inventory. Flag every tool touching identifiable data without a data processing agreement.
• Days 31–50: Draft the engagement letter clause (Step 3) and start using it on new engagements; roll it into renewals as they come up.
• Days 51–70: Chase vendor contracts for flagged tools (Step 4); drop or replace any vendor that cannot answer the five clauses above.
• Days 71–85: Finalise the one-page internal policy (Step 5) using the template in AI policy for CA firms; write the breach plan (Step 6).
• Days 86–90: Run staff training and collect sign-off (Step 7). Set a calendar reminder to revisit the whole checklist in six months.

This sequence deliberately front-loads the inventory, because every later step — the policy, the vendor contracts, the training — is more accurate and faster to write once you actually know what tools and what data you are dealing with.

Frequently asked questions

Does a small CA firm need to appoint a formal Data Protection Officer?

The DPDP Act's formal Data Protection Officer requirement is tied to significant data fiduciary status, which most small firms will not meet. But every firm still benefits from naming one internal person accountable for data-protection decisions — call them whatever you like — because "everyone is responsible" in practice means no one is, and that is the person who should own the tool inventory, the vendor checks, and the breach response.

How is this guide different from the earlier DPDP Act privacy overview?

The earlier piece explains the concepts — fiduciary duty, consent, purpose limitation, what to check in a vendor. This guide assumes you already accept those concepts and gives partners the operating checklist: who to appoint, what register to keep, what clause to add to the engagement letter, what to put in the vendor contract, and a 90-day sequence to get it all in place.

What is the single highest-priority action for a firm that has done nothing yet?

Build the AI tool inventory first. You cannot manage risk, write a sensible policy, or respond to a breach for tools you have not listed, and most firms are surprised by how many AI tools staff are already using informally. Everything else in this guide depends on that list existing.

Do we need a separate data processing agreement for every AI tool we use?

For any tool that processes identifiable client data, yes — a proper DPA, not just acceptance of standard terms of service, should exist before the tool goes into regular use. Tools used only for anonymised drafting or general research do not carry client personal data and do not need the same contractual weight, though you should still record what they are used for in your inventory.

The takeaway

Getting DPDP-ready for AI is not a one-time reading of the Act — it is a small, concrete set of artefacts a firm builds and maintains: a named owner, a tool inventory, engagement letter language, real vendor contracts, a staff policy, a breach plan, and a training log. None of these require reinventing your practice; they require sequencing the work sensibly, starting with the inventory, and treating the result as a living document you revisit as tools and terms change. Firms that do this now are the ones who can answer a client's question — or a regulator's — calmly instead of scrambling.