DPDP and your investor data room

If a document in your data room contains personal data about identifiable people (customers, employees, users) then putting it in front of an investor is processing, and you need a lawful basis for it.

You are the Data Fiduciary. That obligation is yours and cannot be outsourced to a vendor. What a tool can do is make the sharing deliberate, bounded and auditable instead of a folder link that spreads.

More than founders expect. In a typical room:

• A customer list with names, emails or phone numbers is personal data
• Employee contracts, salary sheets and PF records are personal data
• A user-metrics export whose IDs can be re-identified is personal data
• Support tickets or sales-call recordings are personal data, often sensitive
• Aggregate revenue by month is not personal data
• A cap table is personal data about your shareholders, though with a far clearer basis

The test is whether an individual is identifiable, not whether the document feels sensitive. A spreadsheet of email addresses is squarely in scope; a chart of MRR is not.

Dumping a raw customer export into the room because an investor asked for “cohort data”.

Your customers consented to you providing a service. They did not consent to their details being shown to a venture fund assessing whether to buy equity in you. That is a different purpose, and under the Act purpose matters.

The fix is nearly always sufficient and nearly always easier: share the aggregate. An investor wants retention curves, concentration and cohort behaviour. None of that requires a single real name. Pseudonymise the identifiers, share the shape, and keep the underlying rows out of the room entirely.

Four obligations bear directly on a data room:

1. Purpose limitation. Personal data collected to deliver your product cannot be freely repurposed for fundraising. Either rely on a legitimate basis you can articulate, or do not share it in identifiable form.
2. Data minimisation. Share what is needed, not what is convenient. “Here is the whole export” is the opposite of this.
3. Security safeguards. Reasonable measures against breach. A link that anyone can forward is difficult to defend as reasonable once something goes wrong.
4. Breach notification. If personal data leaks you may have to notify the Data Protection Board and affected individuals. You cannot report what you cannot reconstruct, which makes an access record a compliance asset, not a nice-to-have.

A link-shared Drive folder has three properties that are awkward under the Act, and they compound:

• It is forwardable. Whoever holds the link holds the access. You cannot show who the recipients were, which makes both minimisation and breach reconstruction guesswork.
• Access is all-or-nothing per folder. So the folder ends up containing the least-sensitive view everyone can see, or the most-sensitive view everyone should not.
• Revocation is retrospective at best. Removing a link does not un-download a file, and nothing records what was taken before you removed it.

None of this makes a shared folder unlawful. It makes it hard to evidence, and evidencing is the part that matters when someone asks.

The useful properties are unglamorous: who, what, when, and the ability to stop.

• Access is per person, not per link. Each investor is a named recipient with their own grant, so “who could see this” has an answer.
• Scope is per document. Granting the financials does not grant the employee contracts, so minimisation is the default rather than an intention.
• An NDA can gate entry. Your own agreement, accepted before anything opens, with the acceptance timestamped.
• Access can be revoked and time-limited. When a conversation ends, so does the access.
• There is a record. Who opened which document, and when.

An AI assistant over your data room adds an obligation worth stating plainly: the model must not read documents the reader was not granted.

In XDrop AI the access limit is applied when the system searches, not after it has found something. Documents outside an investor’s grant are never retrieval candidates, so they cannot be quoted, summarised or confirmed to exist. Filtering after retrieval is materially weaker, a summary that has already absorbed restricted text can leak it without ever naming the source.

Every AI query is also recorded: who asked, which documents were retrieved, what was answered. That is what makes an answer auditable rather than merely plausible.

XDrop AI runs on cloud hosting and object storage located in India (Mumbai). Cross-border processing, and every sub-processor with its location and purpose, is listed in our Privacy Policy. Published rather than supplied on request, because an investor’s counsel will ask and the answer should not require an email.

How the platform maps to the Act section by section (roles, lawful processing, Data Principal rights, retention, the Grievance Officer) is set out on the DPDP compliance page. Technical measures are on security.

1. Open each document and ask: is anyone identifiable in here?
2. If yes. Can an aggregate answer the investor’s question instead? Usually yes.
3. If it must be identifiable, be able to state your lawful basis in one sentence.
4. Grant it to a named person, not a link.
5. Make sure you could reconstruct who accessed it, if you ever had to.

This page is a practical summary, not legal advice. DPDP obligations depend on your specific processing; take advice on your own facts.