TL;DR: Data privacy and ethics is the single most commonly named barrier to legal AI adoption. This is the concrete checklist that answers it: where your data physically sits, whether prompts train the model and how to switch that off, retention and deletion, encryption, access control and audit logs, sub-processors, the privilege question, your DPDP Act obligations as a data fiduciary, breach notification, and the exact clauses to put in the vendor contract.

On this page

Why this checklist exists

According to the Wolters Kluwer 2026 Future Ready Lawyer Survey, which polled 810 lawyers across the United States, China, and nine European countries, 39 percent named ethics and data privacy as a barrier to AI adoption, tied with inadequate training at 39 percent, ahead of resistance to change at 35 percent. That survey did not poll Indian firms. But the underlying question it captures translates directly: before a partner will let an associate paste a client’s draft agreement into a tool, someone has to be able to answer where that text goes, who can read it, and what happens to it next.

Most firms never get a straight answer to those questions, because they never ask them in a structured way. This piece asks them in order, tells you what a real answer looks like against what a dodge looks like, and gives you the contract language to lock the good answer in before you sign.

This is the technical and contractual checklist. If you want the policy document that tells your associates what they may and may not do with AI day to day, read the law firm AI use policy. If you want the deeper explainer on data residency and cross-border transfer specifically, read legal AI data residency in India. Both are referenced throughout this checklist rather than repeated.

Where your data physically sits

The first question is not about the law. It is about geography. When you type a fact pattern into a legal AI tool, that text is transmitted to a server somewhere, held in memory during processing, and often written to disk in a log or a database before the response comes back. Where that server sits determines which country’s law enforcement, subpoena process, and government access regime can reach it.

Ask the vendor for the specific region or data centre location where prompts, uploaded documents, and generated outputs are stored at rest, not just where the company is headquartered. A vendor can be an Indian company with servers in Virginia, or a US company with an India region on a cloud provider. Neither fact alone tells you anything; you need the actual storage location, in writing, for each category of data (chat text, uploaded files, generated drafts, metadata and logs).

The Digital Personal Data Protection Act, 2023 does not impose blanket data localisation on personal data the way some other jurisdictions do. It permits cross-border transfer of personal data by default, subject to the government’s power under Section 16 to restrict transfers to specific countries by notification. As of this writing no such restriction list has been notified. That means the DPDP Act itself will not stop you from using a tool that stores data outside India. Your retainer terms, your firm’s confidentiality undertakings, and in some matters your client’s own regulatory obligations might. Government departments, banks, and other regulated clients frequently impose contractual localisation requirements that are stricter than the statute. Check the client engagement letter before you check the statute.

If the vendor cannot answer with a specific place name for every category, that is itself the answer.

Whether prompts train the model, and how to switch it off

This is the single most consequential setting in any legal AI tool, and the one most firms never check. Two things can happen to the text you submit. It can be used only to generate the response you asked for and then discarded or retained purely for service delivery. Or it can be retained and used to improve, fine-tune, or evaluate the underlying model, which means fragments of your client’s confidential facts could in principle surface, verbatim or near verbatim, in a response given to a different user months later.

Consumer-facing general chatbots have historically defaulted to training on submitted text unless the user opts out in account settings. Enterprise and business tiers of the same products typically default to not training on customer data, because that default is what enterprise customers demand as a condition of purchase. The word “typically” is doing real work in that sentence: defaults vary by product tier, by account type, and by date, and they change. This is not a fact you can assume from a product’s general reputation. It is a fact you confirm against that specific vendor’s currently published trust or privacy page, for the specific plan you are actually buying, on the date you check it. If a vendor has not published that commitment anywhere you can point to, ask them to put it in the contract instead of taking a sales call’s word for it.

The practical steps:

  1. Find the vendor’s trust, security, or privacy centre page, not the marketing homepage, and locate the sentence that states the training policy for your plan.
  2. If training is on by default, find the account-level toggle to turn it off, and confirm in writing that it applies retroactively to data already submitted, not just prospectively.
  3. Get the training commitment written into the order form or master service agreement, not left as a webpage that can change without notice.
  4. Ask whether the vendor’s own sub-processors, meaning the underlying model API it calls, have a separate training policy that could override the vendor’s front-end setting. A tool built on a third-party model API inherits that provider’s training terms unless the vendor has negotiated a no-training data processing agreement with it.

Retention and deletion

Retention is the question of how long your data sits somewhere after you stop actively using it, and deletion is whether it actually disappears when you ask it to, everywhere it was copied to.

Ask for the retention period in days or months for each category: active chat history, uploaded source documents, generated outputs, and system logs that might contain fragments of prompts for debugging or abuse-monitoring purposes. A vendor that says “we keep it as long as your account is active” has not answered the question, because it has not told you what happens to a document you uploaded and then deleted from your own view three months ago while your account remains active.

Ask a second, separate question: when you delete a document or close an account, is it deleted from primary storage, from backups, and from any cache or log store, and on what timeline for each. A vendor that deletes from the primary database instantly but retains encrypted backups for 30 or 90 days is not lying to you if it says “deleted,” but you need to know the backup retention window exists, because a breach of that backup store during the window is still a breach of your client’s data.

Get the retention and deletion commitment in writing with specific day counts, not the word “promptly.”

Encryption in transit and at rest

This is the baseline technical control, and it is also the one most vendors will answer confidently because it is genuinely standard practice at this point. Encryption in transit means the connection between the user’s browser or app and the vendor’s servers uses TLS, so a network intermediary cannot read the traffic. Encryption at rest means the stored files and database records are encrypted on disk, so someone who gains unauthorised access to the storage layer itself, rather than the network, still cannot read the content without the decryption keys.

The follow-up question that separates a real answer from a checkbox answer is key management: who holds the encryption keys, and can the vendor’s own support staff decrypt and read your data without your action. A vendor using standard cloud-provider-managed encryption keys can technically access plaintext data internally, subject to its own access controls, which is normal for most SaaS tools but worth knowing. A smaller number of vendors offer customer-managed keys or field-level encryption for sensitive fields, which is a materially stronger position for genuinely high-sensitivity work.

Do not accept “we use encryption” as a complete answer. Ask which standard applies (TLS 1.2 or higher in transit, AES-256 or equivalent at rest), and ask the key management question directly.

Access control and audit logs inside the firm

Vendor-side security only covers half the exposure. The other half is who inside your own firm can see what, and whether you can prove it after the fact.

A legal AI tool used across a firm should let you configure role-based access, so a paralegal working one matter cannot browse chat history or uploaded documents from an unrelated matter handled by a different team. Ethical walls that exist on paper for conflicted matters need to exist inside the tool too, or the tool has quietly created a bypass around a wall your firm built for a reason.

Audit logging is the second half. If a client, a court, or a disciplinary body later asks who accessed a document, when, and what they did with it, you need a log that answers that question without relying on memory. Ask the vendor whether audit logs exist at the user level (not just account level), how long they are retained, whether your firm’s compliance or IT administrator can export them, and whether the logs themselves are tamper-evident. A firm that cannot produce an access trail for a specific document six months after the fact has no way to answer a client who asks “who saw this.”

A research tool built around matter-scoped workspaces, rather than one shared account every associate logs into, makes this a default rather than a configuration project. Ask any tool on your shortlist, including niyam.ai, how it segregates access between unrelated matters.

Sub-processors: who else sees the data

Almost no legal AI vendor runs its own model from scratch on its own hardware. Most call an underlying large language model through an API, host on a cloud infrastructure provider, and use separate services for search, storage, analytics, or support tooling. Each of these is a sub-processor: a company other than the vendor you signed with that touches your data while delivering the service.

You are entitled to a full list of sub-processors, not a vague reference to “trusted partners.” A serious vendor maintains a published sub-processor list, updates it when it changes, and notifies customers of material additions with enough lead time to object or exit. Ask for that list before signing, and ask what happens if a new sub-processor is added after you sign: do you get notice, and do you get a right to terminate if you object to the addition.

The sub-processor chain is also where the training question from earlier in this checklist can quietly get overridden. A vendor’s own no-training commitment does not bind its underlying model API provider unless that commitment was specifically negotiated into the data processing terms between them. Ask the vendor to confirm, in writing, that its sub-processors are also bound to not train on your data.

The privilege question when a third party processes client material

Handing a client’s confidential document to a third-party AI vendor raises a distinct legal question from the data-protection questions above: does doing so waive or weaken privilege, or breach an advocate’s independent duty of confidentiality.

The relevant provision is Section 132 of the Bharatiya Sakshya Adhiniyam, 2023 (BSA), which replaced Section 126 of the Indian Evidence Act, 1872 with effect from 1 July 2024. Section 132 protects professional communications between an advocate and client from disclosure without the client’s express consent, subject to the illegal-purpose and crime-or-fraud exceptions written into the section itself. The full text is on India Code. Bar Council of India Rules, Chapter II, Part VI, Section II, Rule 17, separately require that an advocate shall not, directly or indirectly, commit a breach of this confidentiality obligation. Feeding client facts into a third-party AI tool without knowing where the data goes and who can read it is a live risk of exactly the disclosure that provision and that Rule are built to prevent.

There is an important limit on who this protection reaches. Section 132’s text protects communications with “an advocate,” and whether that extends to a salaried in-house counsel the same way it covers an independently briefed advocate has not been settled by any reported Supreme Court ruling. If your legal AI use sits inside an in-house legal team rather than a law firm advising an external client, do not assume Section 132 covers your prompts to a vendor the way it would cover a firm’s client communications. Build your vendor vetting and your internal policy on the assumption that in-house communications may carry a different, and in some respects thinner, protection, and treat confidentiality as a contractual matter with the vendor rather than relying on evidentiary privilege to do that work for you.

Either way, privilege protects communications from compelled disclosure in litigation. It does not protect data from a vendor’s own data breach, a rogue employee, or an overseas government access request under a different country’s law. Those are the risks the rest of this checklist, and the contract clauses below, address.

DPDP Act obligations on the firm as a data fiduciary

Under the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025, a law firm that collects and processes clients’ or opposing parties’ personal data (names, addresses, financial details, health information in a matter, and similar) is a data fiduciary in its own right, separate from any AI vendor it uses. When the firm hands that data to a legal AI tool for processing, the AI vendor typically becomes a data processor acting on the firm’s instructions, but the firm’s own obligations as fiduciary do not disappear because a processor is involved.

The DPDP Rules, 2025 were notified on 13 November 2025 and commence in phases rather than all at once. The DPDP Act itself is available on India Code, and PRS Legislative Research has published plain-English analysis of the Act’s provisions if the statutory text alone is not enough. Rules 1 to 2 and 17 to 21, covering definitions and the constitution of the Data Protection Board of India, came into force on notification. Rule 4, governing Consent Manager registration, comes into force around 13 November 2026. The bulk of the core operating rules, Rules 3 and 5 through 16 and 22 to 23, covering notice, consent, security safeguards, breach reporting, children’s data, and data principal rights, come into force around 13 May 2027. The full phase-by-phase breakdown, with a size-based preparation checklist, is in the DPDP compliance deadlines guide; the underlying obligations are explained in full in the DPDP Rules 2025 guide.

For a firm choosing a legal AI vendor today, three obligations matter most in practice, ahead of their formal commencement date, because building the underlying capability takes time:

Reasonable security safeguards. The Act requires a data fiduciary to protect personal data in its possession or control, including data processed on its behalf by a processor, with reasonable security safeguards to prevent breach. Choosing a vendor without encryption in transit and at rest, without access controls, and without a sub-processor list is difficult to reconcile with that duty once the operative security rule is in force, and is poor practice regardless of the exact commencement date.

Processor accountability. Where the firm engages a processor, the AI vendor, to process personal data on its behalf, the DPDP framework expects that engagement to happen under a contract that binds the processor to the fiduciary’s instructions and to security obligations no weaker than the fiduciary’s own. This is why the contract clauses later in this checklist matter: they are the mechanism by which the firm’s own statutory duty is discharged through the vendor relationship.

Consent and purpose limitation for the underlying personal data. If the documents you feed into an AI tool contain personal data of clients, opposing parties, or witnesses collected for a specific matter, using that data for an unrelated purpose, including allowing it to train a third party’s general-purpose model, sits uneasily against the purpose limitation principle the Act builds around consent. This is a second, independent reason the training-data question above is not optional due diligence. It is close to a compliance question in its own right.

Breach notification duties

Two separate breach reporting regimes can apply to an Indian law firm depending on what happened and what kind of data was involved, and firms sometimes conflate them.

Under the DPDP Act and Rules, once the relevant provisions come into force around 13 May 2027, a data fiduciary that experiences a personal data breach must inform affected data principals without delay and file a detailed report to the Data Protection Board of India within 72 hours of becoming aware of the breach. The 72-hour clock starts from awareness, not from the completion of an internal investigation, which means a firm needs a detection and reporting runbook ready well before the obligation is formally binding, not built in response to an actual incident.

Under the existing framework administered by the Indian Computer Emergency Response Team (CERT-In) within the Information Technology Act, 2000 regime, certain categories of cyber security incidents already carry a mandatory reporting obligation to CERT-In, separate from and predating the DPDP timeline. CERT-In’s own site is the authoritative source for the current scope and timeline of that obligation; check it directly, because incident-reporting directions have been amended before and can be amended again.

The practical point for vendor selection: ask the AI vendor what its own breach notification commitment to you is, in hours, and whether that is fast enough to leave your firm time to meet its downstream obligations to the Board, to CERT-In where applicable, and to the client. A vendor that promises to notify you “as soon as reasonably practicable” is not giving you enough runway to meet a 72-hour statutory clock that starts running from the vendor’s own awareness, which may predate yours by days if the vendor is slow to tell you.

Acceptable versus unacceptable vendor answers

QuestionAcceptable answerUnacceptable answer
Where is data stored at rest?✓ Named region or data centre, in writing, for each data category✗ “Cloud infrastructure” with no location named
Do prompts train the model?✓ Written no-training commitment for your plan, with a date on the trust page✗ “We take privacy seriously” with no plan-specific answer
Can training be switched off?✓ Named toggle or contractual clause, confirmed retroactive✗ “It’s on by default and there’s no setting to change it”
Retention period?✓ Specific day or month count per data category✗ “As long as needed” or “as long as your account is active”
Deletion on request?✓ Confirmed timeline for primary storage and backups separately✗ “Deleted” with no backup or cache timeline given
Encryption in transit?✓ Named protocol (TLS 1.2 or higher)✗ “Yes, it’s encrypted” with no protocol named
Encryption at rest?✓ Named standard (AES-256 or equivalent) plus key management answer✗ Silence on who holds the decryption keys
Sub-processor list?✓ Published, dated list, with a notice-of-change commitment✗ “Trusted partners” with no names
Breach notification to you?✓ Specific hours, in the contract✗ “As soon as reasonably practicable”
Certifications claimed?✓ Certificate name, issuing body, and current validity you can verify✗ A logo on the website with no verifiable certificate behind it
Access controls inside your firm?✓ Role-based access and matter-level segregation available✗ Every licensed user sees every matter by default
Audit logs?✓ User-level, exportable, retained for a stated period✗ Account-level only, or no logs at all
Government access requests?✓ Named process for notifying you before complying, where legally permitted✗ No answer, or a claim that it “never happens”
Data used for anything beyond service delivery?✓ Explicit no, in the contract, for analytics, marketing, or resale✗ Vague marketing language about “improving your experience”

Do not accept a certification claim, SOC 2, ISO 27001, or any other standard, at face value from a sales call or a badge on a homepage. Ask for the certificate or the audit report, check the issuing body and validity date, and treat an unverifiable claim the same as no certification.

The data path: prompt to vendor to sub-processor

The diagram below shows the minimum set of hops your data can take between the moment a lawyer types a prompt and the moment a response comes back. Every one of the questions above maps to a point on this path.

flowchart LR
    A["Lawyer types prompt<br/>or uploads document"] --> B["Firm's AI tool<br/>front end"]
    B --> C["Vendor's servers<br/>region and encryption"]
    C --> D{"Training on?"}
    D -->|Yes| E["Model training pipeline"]
    D -->|No| F["Processing only"]
    C --> G["Underlying model API<br/>sub-processor"]
    G --> H["Cloud infrastructure<br/>sub-processor"]
    C --> I["Logs and backups<br/>retention window"]
    F --> J["Response returned<br/>to lawyer"]
    E -.->|"risk: fragments in<br/>future responses"| K["Other users of<br/>the model"]

Every box on the right side of the front end is a place your client’s confidential facts sit outside your firm’s control for some period of time. This checklist puts a specific, verified answer against every one of those boxes before you send the first real matter through the tool.

The clauses to demand in the vendor contract

Everything above is worthless as a vetting exercise if it stays a sales conversation. Get each commitment written into the master service agreement, order form, or data processing addendum before signing. This is the copy-pasteable starting point; have your own counsel adapt it to the specific deal.

1. DATA LOCATION
   Vendor shall store all Customer Data, including prompts, uploaded
   documents, and generated outputs, only in the data centre region(s)
   specified in Schedule [X]. Vendor shall provide 30 days' written
   notice before adding or changing a storage region, and Customer may
   terminate without penalty if it objects to the change.

2. NO TRAINING ON CUSTOMER DATA
   Vendor shall not use Customer Data, in whole or in part, to train,
   fine-tune, or evaluate any machine learning model, including models
   operated by Vendor's own sub-processors, without Customer's prior
   written consent on a per-instance basis. This clause survives
   termination of the agreement for any data retained after
   termination.

3. RETENTION AND DELETION
   Vendor shall retain Customer Data only for [X] days after the
   earlier of (a) Customer's deletion request or (b) termination of
   the agreement, across primary storage, backups, and logs. Vendor
   shall provide written confirmation of deletion within 10 business
   days of a Customer request, itemised by storage location.

4. ENCRYPTION
   Vendor shall encrypt Customer Data in transit using TLS 1.2 or
   higher and at rest using AES-256 or an equivalent standard. Vendor
   shall disclose its key management model, including whether
   Customer-managed keys are available, on request.

5. SUB-PROCESSORS
   Vendor shall maintain a current, dated list of all sub-processors
   with access to Customer Data and shall make that list available to
   Customer on request and update it within 5 business days of any
   change. Vendor shall provide 30 days' notice before engaging a new
   sub-processor, during which Customer may object and, if
   unresolved, terminate without penalty.

6. ACCESS CONTROLS AND AUDIT LOGS
   Vendor's platform shall support role-based access control at the
   matter or workspace level. Vendor shall maintain user-level audit
   logs of access to Customer Data for a minimum of [X] months and
   shall make those logs available for export by Customer's
   administrator on request.

7. BREACH NOTIFICATION
   Vendor shall notify Customer of any Personal Data Breach, as
   defined under the Digital Personal Data Protection Act, 2023,
   affecting Customer Data within 24 hours of Vendor becoming aware,
   and shall provide all information reasonably required for
   Customer to meet its own regulatory notification obligations.

8. GOVERNMENT AND THIRD-PARTY ACCESS REQUESTS
   Where legally permitted, Vendor shall notify Customer before
   disclosing Customer Data in response to a government, law
   enforcement, or third-party legal request, and shall disclose only
   the minimum data legally required.

9. DATA PROCESSOR ACKNOWLEDGEMENT
   Vendor acknowledges that, with respect to personal data within
   Customer Data, it acts as a data processor under the Digital
   Personal Data Protection Act, 2023, processing such data only on
   Customer's documented instructions, and shall assist Customer in
   meeting its obligations as data fiduciary under the Act.

10. TERMINATION DATA RETURN
    On termination, Vendor shall, at Customer's election, return or
    permanently delete all Customer Data within 30 days and confirm
    completion in writing.

11. AUDIT RIGHT
    Customer, or an independent auditor engaged by Customer, may
    request evidence of Vendor's compliance with clauses 1 through 10
    no more than once per 12-month period, absent a suspected breach.

12. LIABILITY FOR BREACH OF THIS SCHEDULE
    A breach of any clause in this Schedule shall be treated as a
    material breach of the agreement, entitling Customer to terminate
    for cause and recover direct damages arising from the breach,
    notwithstanding any general limitation of liability clause
    elsewhere in the agreement.

None of these clauses are exotic. A vendor with a genuinely defensible security posture will have most of this language already in a standard data processing addendum, because enterprise customers in other regulated industries ask for the same thing. Resistance to putting a specific commitment in writing, when the vendor has just told you the same thing verbally, is the clearest signal in this checklist.

Running the checklist before your first upload

Treat this as a one-time gate per vendor, not a per-matter exercise. Before any associate uploads a real client document to a new AI tool:

  1. Get written answers to every question in this checklist, from the vendor’s trust or security page where published, and in writing from a named contact where not.
  2. Run the answers against the acceptable versus unacceptable table above. Any unacceptable answer is a stop, not a note for later.
  3. Get the twelve clauses, or your counsel’s adapted version, into the signed agreement before the first real matter goes through the tool. A verbal assurance from a sales call is not a contract term.
  4. Record the vendor’s answers and the signed clauses where your firm’s IT or compliance function can retrieve them without asking the partner who did the original vetting, since that partner will not remember the details in eighteen months.
  5. Re-run the check annually, or whenever the vendor announces a material change to its infrastructure, sub-processors, or terms.

For the broader governance layer around this, including what associates may and may not do day to day, see the law firm AI use policy. For the deeper legal analysis of cross-border transfer and residency specifically, see legal AI data residency in India. And for the compliance calendar behind the DPDP obligations referenced throughout this checklist, see the DPDP compliance deadlines guide.

A tool built for Indian legal research and drafting, with the security and residency questions answered up front rather than discovered during a client audit, removes a large share of this vetting burden. That is worth checking directly at niyam.ai alongside whatever else is on your shortlist.

When a matter involves verifying that a cited authority is still good law rather than overruled or distinguished, a citator that checks current status against the judgment text itself, rather than a general-purpose chatbot’s memory, avoids feeding the underlying document into a tool with none of the answers above settled. Good law checking is the narrower version of this same due diligence.

Frequently asked questions

Does the DPDP Act require Indian law firms to store client data only in India?

No. The DPDP Act, 2023 permits cross-border transfer of personal data by default. Section 16 gives the government power to restrict transfers to specific notified countries, but no such restriction list is currently notified. A firm’s own confidentiality undertakings or a regulated client’s contractual localisation requirement can be stricter than the statute, so check the engagement letter, not just the Act.

What is the difference between a data fiduciary and a data processor under the DPDP Act?

A data fiduciary determines the purpose and means of processing personal data and carries the primary statutory obligations, including security safeguards, notice, and consent. A data processor processes data on the fiduciary’s documented instructions. A law firm using an AI vendor is typically the fiduciary; the vendor is typically the processor, but the firm’s own obligations do not transfer away by using one.

Is Section 132 of the BSA the same protection as the old Section 126 of the Evidence Act?

Section 132 of the Bharatiya Sakshya Adhiniyam, 2023 replaced Section 126 of the Indian Evidence Act, 1872 with effect from 1 July 2024, and carries forward the protection for professional communications between an advocate and client from disclosure without consent, subject to the illegal-purpose and crime-or-fraud exceptions. Cite the current BSA number; commentary and older filings may still reference Section 126.

Does privilege protect data uploaded to an AI vendor from a data breach at that vendor?

No. Privilege and confidentiality duties govern compelled disclosure in legal proceedings and an advocate’s own conduct. They do not stop a vendor’s data breach, an employee’s misuse, or an overseas government access request from exposing the data. Those risks are addressed through vendor vetting, encryption, access control, and contract clauses, not through privilege doctrine.

Are in-house counsel covered by the same confidentiality protection as law firm advocates?

Not certainly, and the point has not been settled by any reported Supreme Court ruling. Section 132’s text protects communications with “an advocate,” and whether that reaches a salaried in-house counsel’s communications with their employer the same way it protects an independently briefed advocate’s communications remains an open question.

How do I find out if a vendor trains its model on my prompts?

Check the vendor’s published trust, security, or privacy page for the specific plan you are buying, not the general marketing site, and note the date on that page. If the commitment is not published or is ambiguous, ask the vendor directly and get the answer written into the order form or data processing addendum before you sign, not left as a verbal assurance.

What counts as a personal data breach under the DPDP Act?

The Act defines a personal data breach broadly as any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data, that compromises its confidentiality, integrity, or availability. A vendor’s unauthorised training on your uploaded client data, if it occurred, could itself fall within that definition.

When do the DPDP breach notification obligations actually become enforceable?

The core operating rules, including breach notification, come into force around 13 May 2027, 18 months after the DPDP Rules, 2025 were notified on 13 November 2025. Firms should build a detection and 72-hour reporting runbook before that date rather than after an incident forces the issue.

Does CERT-In’s breach reporting requirement apply separately from the DPDP Board’s 72-hour rule?

Yes, in principle these are separate regimes. CERT-In administers a cyber incident reporting obligation under the Information Technology Act, 2000 framework that predates and operates alongside the DPDP Board’s process. Check CERT-In’s own published directions for the current scope and timeline rather than assuming the two regimes are identical.

Ask for a full, dated, named list of every sub-processor with access to your data, including the underlying model API provider and the cloud infrastructure host. Ask what notice you get before a new sub-processor is added, and whether you have a right to object or terminate. A vendor that answers with “trusted partners” instead of names has not answered.

Is encryption at rest enough on its own?

No. Encryption at rest protects data if someone gains unauthorised access to the storage layer, but it does not answer who holds the decryption keys or whether the vendor’s own staff can read plaintext data during normal operations. Ask the key management question separately from the encryption question.

Can a law firm rely on a vendor’s SOC 2 or ISO 27001 badge without checking further?

No. A badge on a website is a claim, not proof. Ask for the actual certificate or audit report, confirm the issuing body, and check the current validity date, since certifications lapse and cover specific scopes that may not include every product or data flow you care about.

What is the minimum retention and deletion commitment to demand?

A specific day or month count, stated separately for primary storage, backups, and logs, plus a written confirmation process on request. “We delete data promptly” or “as long as necessary” is not a commitment you can enforce later.

Using a third-party tool does not automatically waive privilege, but it introduces a party outside the privileged relationship who now holds the communication, a separate confidentiality risk from privilege waiver in litigation. Vet the vendor’s terms as carefully as a co-counsel arrangement or an outsourced service provider.

How often should a firm re-run this vendor vetting checklist?

At minimum annually, and immediately whenever the vendor announces a material change to its infrastructure, sub-processors, or terms. Vendor security postures are not static, and a check done at onboarding two years ago tells you nothing about current practice.

What happens if a vendor refuses to put these clauses in the contract?

Treat the refusal as your answer. A vendor unwilling to commit in writing to terms it already described verbally is not a vendor whose verbal description you should rely on for a client’s confidential material.

Do smaller firms and solo practitioners need to go through this whole checklist?

Yes, in a scaled-down form. The DPDP Act’s obligations and the BSA confidentiality duty apply to every advocate individually, not only to larger firms. A solo practitioner has fewer people to catch a vendor’s gap before it reaches a client, which makes the upfront vetting more important, not less.

Where should this checklist sit inside the firm, procedurally?

Attach it to the firm’s tool approval process described in the law firm AI use policy, so no AI tool reaches an associate’s desktop without someone having run through data location, training, retention, encryption, sub-processors, and contract clauses first, and having the written answers on file.