DPDP for Virtual Meetings: Consent Is No Longer Optional

Short answer. India's Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025. The substantive obligations — notice, consent, security safeguards, breach reporting, retention, data principal rights — commence on 13 May 2027. Consent-manager registration commences 13 November 2026. If you record meetings, transcribe them, or run an AI notetaker, every one of those meetings is personal data processing, and Section 6(10) of the DPDP Act puts the burden on you to prove that notice was given and consent was taken. A consent banner nobody logged is not proof. The employment carve-out in Section 7(i) covers your employees; it does nothing for the candidate, customer, or vendor on the call.

This is a practitioner's read, not legal advice. Get counsel before you make decisions on it.

The part everyone is getting wrong: how long you actually have

Nearly every DPDP explainer written in India right now says the same thing — "full compliance kicks in 2027, so there's time."

Count the months.

Today is 5 August 2026. The substantive provisions commence on 13 May 2027. That is a little over nine months. Consent-manager registration under Rule 4 commences on 13 November 2026 — about three months.

Nine months is not a long runway for something that touches your product's consent flows, your vendor contracts, your retention architecture, your logging, and your breach playbook simultaneously. Practitioners advising Indian SaaS companies are quoting eight to fourteen weeks for a focused readiness programme, and three to six months for a company starting from near-zero. Those estimates assume you start when you read them, not in Q1 2027 when everyone else has also woken up and every privacy consultant in the country is booked.

The Data Protection Board of India already exists. It was constituted in the same set of notifications on 13 November 2025, and the provisions establishing it came into force immediately — not in 2027. The enforcement body is standing up while the obligations mature.

So the honest framing is not "2027, relax." It is: you have about three quarters, and if your business runs on meetings, you have more work than most.

What actually changed on 13 November 2025

The DPDP Act, 2023 received assent in August 2023 and then sat in a strange half-life for over two years. The Act was law, but the Rules that operationalise it — the form of the notice, the mechanics of consent, the breach timeline, the Board's procedures — did not exist. Draft Rules were published on 3 January 2025 and went through public consultation.

On 13 November 2025, the Ministry of Electronics and Information Technology notified the final Digital Personal Data Protection Rules, 2025 via G.S.R. 846(E), along with notifications establishing the Data Protection Board of India and setting staggered commencement dates.

That is the change. Not "consent became mandatory" — consent was always the default basis under Section 4 of the Act. What changed is that the obligations now have dates, the enforcement body now exists, and the procedural detail that lets a regulator say "your notice was non-compliant" now sits in black-letter Rules rather than in a draft.

The phrase "consent is no longer optional" is directionally right and worth being precise about. Under Section 4, personal data may be processed on exactly two bases: the Data Principal's consent, or one of the "legitimate uses" listed in Section 7. There is no general "legitimate interest" balancing test of the kind GDPR gives you. If your processing doesn't fit a Section 7 use, consent isn't one option among several — it is the only door.

The three phases

The gazette wording for the third phase is "eighteen months after the date of publication." Some advisers compute that as 12 May 2027 and others as 13 May. The one-day difference does not change any decision you will make; I mention it so you're not confused when two law firm alerts disagree.

Why meetings are the hardest surface under DPDP

Most DPDP readiness work starts with the obvious places: the signup form, the cookie banner, the CRM, the marketing list. Those are well-understood, and there are templates.

Meetings are harder, for four reasons that compound.

The data is unusually rich. A meeting recording is not a name and an email. It is voice, tone, video of a person's face and their home, opinions they expressed, their reasoning, their mistakes, and — depending on the meeting — their health, finances, employment grievances, or legal position. All of it linked to an identified individual, which is exactly what Section 2 means by personal data. A single one-hour call can carry more sensitive material about a person than a year of their transactional data.

The room contains people who are not your users. Your signup flow only ever collects data from someone who chose to sign up. A meeting contains a candidate you've never onboarded, a customer's junior engineer, a vendor's finance lead, an investor. None of them accepted your terms. Several of them may not know your company's name. Every one of them is a Data Principal whose personal data you are processing.

The processing keeps going after the meeting. The recording gets transcribed. The transcript gets summarised. The summary gets scored, embedded, indexed, pushed to a CRM, and used to train something. Each of those is a distinct processing operation, and under Section 6(1) consent has to be "limited to such personal data as is necessary for such specified purpose." Consent to be recorded is not automatically consent to be analysed, and neither is consent to have your voice used as training data.

Nobody owns it. Ask who is accountable for your meeting data and you will get four answers. Sales think it's IT. IT think it's the vendor. Legal think it's covered by the MSA. The person who actually turned the notetaker on has never read any of it. Signup consent has an owner because it lives in the product. Meeting consent usually doesn't.

What DPDP-grade consent actually requires

Section 6(1) sets the standard. Consent must be:

"free, specific, informed, unconditional and unambiguous with a clear affirmative action"

and it "shall be limited to such personal data as is necessary for such specified purpose."

Five adjectives, each doing real work:

Free — not extracted by making the service conditional on it. A vendor who says "accept the notetaker or we can't take this call" is on thin ice.

Specific — tied to a stated purpose. Not "for business purposes."

Informed — preceded or accompanied by a compliant notice.

Unconditional — not bundled with other terms. Consent buried in clause 14.3 of your MSA is not consent under this Act.

Unambiguous, with clear affirmative action — silence is not consent. Neither is continuing to sit on the call. Neither is a pre-ticked box.

That last one deserves a moment, because the dominant industry practice fails it. The standard notetaker pattern — a bot joins, a small banner says "recording in progress," and the meeting continues — is notice without consent. Nobody performed a clear affirmative act. Under DPDP that gap is the whole problem.

The notice (Section 5 and Rule 3)

Consent is only valid if it follows a compliant notice, and Rule 3 is specific about what that notice must contain and how it must be presented:

• Standalone. It must be "presented and be understandable independently of any other information" you have made or may make available. You cannot satisfy the notice requirement with a paragraph inside your privacy policy.
• Clear and plain language, giving a fair account of what's needed for specific, informed consent.
• An itemised description of the personal data. Not "meeting data." Audio recording, video recording, transcript, speaker attribution, derived analysis — itemised.
• The specific purpose, and a specific description of the goods or services provided or uses enabled.
• A communication link through which the person can (i) withdraw consent, (ii) exercise their rights, and (iii) complain to the Data Protection Board.

Plus, under Sections 5(3) and 6(3), the person must have the option to access the notice in English or any language in the Eighth Schedule to the Constitution — all 22 of them. For a consumer-facing product with users across India, that is a real localisation project, not a footnote.

Withdrawal has to be as easy as consent

Section 6(4): the right to withdraw at any time, "with the ease of doing so being comparable to the ease with which such consent was given."

If consent was one tap, withdrawal is one tap. Not an email to support. Not a form. Not a callback. A Data Fiduciary that makes giving trivial and withdrawing laborious is in breach of both the Act and Rule 3, and that lands in the ₹50 crore residual penalty bucket.

And withdrawal has teeth. Under Section 6(6), once consent is withdrawn you must, within a reasonable time, "cease and cause its Data Processors to cease" processing. For a meeting stack, work through what that actually means: the recording, the transcript, the summary, the embeddings in your vector store, the row in your CRM, the analytics dashboard built on top, and the same set of artifacts inside every processor you've handed the data to. If you cannot propagate a withdrawal through that chain, you have an engineering problem that a policy document will not fix.

Section 6(10): consent you can't prove is consent you don't have

This is the provision that should reorganise how you think about meeting consent, and it gets almost no attention in the general DPDP coverage.

"Where a consent given by the Data Principal is the basis of processing of personal data and a question arises in this regard in a proceeding, the Data Fiduciary shall be obliged to prove that a notice was given by her to the Data Principal and consent was given by such Data Principal to the Data Fiduciary in accordance with the provisions of this Act and the rules made thereunder."

The burden of proof is on you. Not on the complainant. You have to prove both that a compliant notice was given and that consent was given.

Sit with the operational consequence. Someone complains to the Board about a sales call from fourteen months ago. What do you produce?

"Our tool shows a recording banner" is not proof. It establishes that a banner exists today, not that this person saw it on that call. "It's in our privacy policy" fails Rule 3's standalone requirement before you even reach the evidence question. "The host confirmed verbally" is testimony about an event with no record.

What discharges the burden is a consent record: which individual, which meeting, which version of which notice they were shown, timestamped, retained, and retrievable. That is an evidentiary artifact, and it has to be designed and built. It does not emerge from a UI banner.

This is why the Rules take consent managers as seriously as they do. A registered consent manager must keep records of consents given, denied and withdrawn, along with the notices that preceded them, for at least seven years, and provide them to the Data Principal in machine-readable form. Seven years is the regulator telling you plainly what timeframe of proof it has in mind.

You do not have to use a consent manager. You do have to be able to do what one does.

The question to take into your next vendor review: if the Board asks us to prove consent for a specific participant on a specific call from over a year ago, what file do we send? If nobody can answer, that's the gap — and it will not be closed by a policy PDF.

The employment carve-out, and the hole in the middle of it

Here is where most Indian companies will get their meeting compliance wrong, because the carve-out is real and it is narrower than it looks.

Section 7(i) permits processing without consent:

"for the purposes of employment or those related to safeguarding the employer from loss or liability, such as prevention of corporate espionage, maintenance of confidentiality of trade secrets, intellectual property, classified information or provision of any service or benefit sought by a Data Principal who is an employee."

Read plainly, that is a genuine and fairly broad basis. Practitioner commentary reads "purposes of employment" to cover payroll, performance management, internal investigations, onboarding, benefits administration and measures protecting the employer from loss. For internal meetings — the standup, the 1:1, the internal project sync — a well-documented reliance on Section 7(i) is a defensible position, and you are not required to collect employee consent for routine employment processing.

Now look at who else is on your calls.

The candidate in a first-round interview is not your employee. The customer on the QBR is not your employee. The vendor, the investor, the consultant, the partner's legal counsel — none of them are your employees. Section 7(i) does nothing for any of them. Every externally-facing meeting falls straight back to consent, with the full Section 5 notice and the Section 6(10) burden of proof attached.

For most B2B companies, that is the majority of recorded meetings. Sales calls, discovery, interviews, customer research, partner discussions — all consent territory.

Three further wrinkles worth knowing before you lean on this carve-out:

Recruitment is contested. The Act doesn't say whether pre-employment processing — shortlisting, interviewing, background checks — is "for the purposes of employment" when there is no employment relationship yet. Some commentators read it broadly to include recruitment; others point out that "employee" is used deliberately. Some argue Section 7(a) covers it instead, since a candidate voluntarily provides their data for a specified purpose. If you run AI interviews or record candidate screens at volume, this ambiguity sits directly on your highest-volume processing activity. Take a documented position with counsel rather than assuming the generous reading.

Contractors probably aren't covered. Section 7(i) says "employee." Agency staff, consultants, secondees and gig workers are, on the text, outside it. Indian companies run large contractor populations; if your standups include them, your internal meetings are not uniformly internal.

It ends when employment ends. "Purposes of employment" and "safeguarding the employer" both presuppose a live relationship. Once someone leaves, continued processing of their data on that basis becomes hard to defend — including the archive of every meeting they were ever in.

And a general point that applies throughout: relying on Section 7(i) removes the consent requirement. It removes nothing else. You still owe purpose limitation, data minimisation, reasonable security safeguards, retention limits, rights fulfilment and grievance redressal. Legitimate use is a lawful basis, not an exemption from the Act.

Is it even legal to record a meeting in India?

The most-searched version of this question conflates three separate legal questions. Separating them is most of the answer.

1. Can you record a conversation you're part of?

Generally, yes. India has no all-party-consent recording statute of the kind California or Illinois has. A participant recording their own conversation has long been treated as lawful, and the Supreme Court admitted a secretly recorded telephone conversation as evidence in R.M. Malkani v. State of Maharashtra (1973), subject to conditions on genuineness and relevance.

2. Can you record a conversation you're not part of?

No, and this one is criminal. Section 25 of the Indian Telegraph Act, 1885 penalises wilful interception by non-participants. Only the State may lawfully intercept, under Section 5(2) of the Telegraph Act or Section 69 of the IT Act, 2000, with proper authorisation. Private interception is not a grey area.

3. Does "not criminal" mean "fine"?

No — and this is where most people's mental model is out of date by about a decade.

Since K.S. Puttaswamy v. Union of India (2017), privacy is a fundamental right under Article 21. Several High Courts have since held that recording someone without their consent breaches it. In Aasha Lata Soni v. Durgesh Soni (Chhattisgarh High Court, 5 October 2023), the court held that recording a phone conversation without the other person's knowledge violates their Article 21 right to privacy, and set aside the family court order that had admitted it. The Delhi High Court made observations in a similar direction in Sanjay Pandey v. Directorate of Enforcement, noting that tapping or recording calls without consent is prima facie a breach of privacy.

The case law is not fully settled, and admissibility of a recording as evidence is a different question from the lawfulness of making it — courts have admitted recordings while criticising how they were obtained.

But here is the point that matters for your business, and it survives whichever way the case law lands:

Lawful to record is not the same as lawful to process.

The recording question is governed by the Telegraph Act, the IT Act, and Article 21 jurisprudence. The processing question — storing that recording, transcribing it, analysing it, retaining it, sending it to a vendor in another country, using it to train a model — is governed by DPDP. They are separate regimes with separate tests.

You can be entirely in the clear on the first and comprehensively in breach of the second. From 13 May 2027, the second is where the ₹250 crore numbers live.

What an AI notetaker adds to the problem

A human taking notes and an AI notetaker are not the same legal object, even though they feel like the same workflow.

Speaker diarization derives new data. To label who said what, the system analyses vocal characteristics to distinguish speakers. Whether that constitutes biometric data under Indian law is untested — DPDP has no special category for biometrics the way GDPR Article 9 does, which cuts both ways. What is clear is that you are now processing something derived from the individual's physical characteristics, and you should be able to name your lawful basis for it. That the entire US class-action wave against notetakers is built on exactly this point is a reasonable signal of where the pressure is.

Training is a separate purpose. If a vendor uses your meeting content to improve its models, that is processing for a purpose distinct from the one the participant was told about. Under Section 6(1), consent is "limited to such personal data as is necessary for such specified purpose." Consent to be transcribed so the host can have notes does not extend to model training. Check your vendor's default — historically, many have trained on customer content unless you were on an enterprise plan and explicitly opted out.

Retention defaults are usually indefinite. Section 8(7) of the Act requires erasure when the purpose is served and consent is withdrawn. A tool that keeps every transcript forever by default is the opposite of that posture, and "the vendor keeps it" is not a defence — the Data Fiduciary carries the obligation.

Cross-border is now a documented flow, not an invisible one. Most notetaking tools are US-incorporated and process on US infrastructure, often calling US model providers. Section 16 and the Rules take a blacklist approach: transfers are permitted except to countries the Central Government notifies as restricted. That is a comparatively liberal regime — but "permitted" still means you must know where the data goes, document it, contract for it, and be able to geofence if a destination gets restricted later. If you cannot draw the diagram of where a transcript of your last board call physically travelled, you have work to do.

Most vendors contractually push the consent duty onto you. This is the part buyers consistently miss. The prevailing pattern in notetaker terms is that the vendor requires the customer to obtain any necessary permissions from participants. Read as risk allocation, that means the vendor's terms make you the one who must satisfy Section 5 and discharge the Section 6(10) burden. Accepting those terms is accepting that obligation.

The offshore signal worth watching

To be explicit, because this matters for accuracy: what follows is United States litigation. BIPA and CIPA do not apply in India, and nothing here is Indian law.

That said, the direction is informative. In re Otter.ai Privacy Litigation (consolidated; lead complaint Brewer v. Otter.ai Inc., No. 5:25-cv-06911, N.D. Cal., filed 15 August 2025) alleges that an AI notetaker records conversations involving non-users without their consent and uses the resulting material to improve its technology. A companion action, Cruz v. Fireflies.AI Corp., was filed on 18 December 2025 by an attendee who had never created an account, arguing that speaker recognition necessarily creates voice-derived identifiers.

The theory being tested in both is precisely the one Indian companies should be examining under Section 6(10): that the host clicking "start" does not constitute consent from everyone else in the room. Different statutes, same structural weakness. Indian regulators will be reading these outcomes too.

Are you a Data Fiduciary or a Data Processor?

Get this wrong and every downstream contract is wrong.

A Data Fiduciary determines the purpose and means of processing. A Data Processor processes on the Fiduciary's behalf. In the meeting context:

• You decide to record the customer call, and why → you are the Data Fiduciary.
• Your notetaking vendor transcribes and stores it on your instruction → they are your Data Processor.
• Your vendor also uses the content to train its own models for its own purposes → for that processing, they are acting as a Fiduciary in their own right, and their basis for it is their problem to explain and yours to interrogate.

The accountability does not move. Under Section 8, the Data Fiduciary remains responsible for compliance regardless of whether processing is done by a processor. If your vendor loses your transcripts, the Board's inquiry is with you.

Which means the contract has to do real work. At minimum: a written data processing agreement that names the vendor as processor, restricts processing to your documented instructions, mirrors the Section 8 security obligations, requires breach notification to you fast enough that you can still meet your own 72-hour deadline, lists sub-processors and commits to notifying changes, sets deletion and return terms at end of contract, and explicitly addresses whether your content may be used for model training. Many vendor DPAs in market are still on pre-DPDP templates. Check the date on yours.

The operational floor: security, retention, breach, grievance

Consent gets the attention. These four are where the largest penalties actually sit.

Reasonable security safeguards (Section 8(5), Rule 6)

The highest-penalty contravention in the entire Schedule — up to ₹250 crore — is failing to take reasonable security safeguards. Rule 6 tells you what "reasonable" means, and unusually for Indian regulation it is concrete:

• Encryption, obfuscation, masking, or the use of virtual tokens
• Access control on the computer resources used
• Visibility through logs, monitoring and review, to detect unauthorised access, investigate it, and act
• Measures for continued processing if confidentiality, integrity or availability is compromised — backups
• Retention of logs and personal data for at least one year to enable detection of unauthorised access and remedial action, unless another law requires longer
• Contractual provisions requiring processors to maintain reasonable safeguards
• Appropriate technical and organisational measures for effective observance

Note the tension in the fifth item, because teams routinely get it backwards. Rule 6 requires you to keep access logs for at least a year. Section 8(7) requires you to erase personal data once the purpose is served. Both are true, and they apply to different objects: the log of who accessed a transcript is not the transcript. A retention policy that deletes everything aggressively, logs included, breaches Rule 6. One that keeps everything forever breaches Section 8(7). You need per-category retention, not one number.

Breach notification (Section 8(6), Rule 7)

Two obligations on two clocks.

To each affected Data Principal: intimation without delay, through their registered user account or another registered communication method, in concise, clear and plain language.

To the Board: layered reporting, with the detailed filing due within 72 hours of becoming aware.

One nuance worth carrying into your playbook: the 72-hour figure comes from the Rules; the Act itself (Section 8(6)) says "without delay." That distinction can matter in a penalty defence — early partial notification demonstrates good faith even if the detailed filing is difficult to complete inside 72 hours. Failure to notify carries up to ₹200 crore.

The clock starts at awareness, not at occurrence, which makes detection capability a compliance control and not just a security nicety. You cannot notify within 72 hours about a breach you find three months later. And if a breach happens at your notetaking vendor, your 72 hours does not pause while they investigate — which is exactly why your DPA needs a vendor-to-you notification window well inside your own.

Retention and erasure (Section 8(7), Rules 8 and 6)

Erase when the purpose is served or consent is withdrawn, unless another law requires retention. Sector rules — RBI, IRDAI, SEBI, tax — override, which is why a blanket "delete after 90 days" policy fails as often as no policy at all.

Specific classes of Data Fiduciary get prescribed limits under Schedule III: e-commerce entities with at least two crore registered Indian users, online gaming intermediaries with at least fifty lakh, and social media intermediaries with at least two crore. For those, erasure at three years from the Data Principal's last interaction, or from commencement of the Rules, whichever is later.

For meetings specifically, decide the retention period per purpose and be able to defend it. An interview recording kept for the duration of the hiring process plus a defined period for discrimination-claim defence is defensible. The same recording sitting in a shared drive four years later is not.

Grievance redressal — 90 days

The final Rules cap grievance redressal at 90 days. You need a named grievance officer, published contact details, an internal process that can actually locate one participant's data across your recording, transcription, CRM and analytics stack, and the ability to close inside the cap.

Penalties, and what gets enforced first

Consent and notice failures land in the ₹50 crore residual bucket. That is the smallest of the corporate numbers and still large enough to end a Series B company.

Two things worth being sober about. First, these are maximums, and the Board has discretion to impose far less — Section 33 requires it to consider the nature, gravity and duration of the breach among other factors. Nobody should expect ₹250 crore for a first-time procedural slip. Second, the realistic enforcement sequence in a new regime is complaint-driven: a Data Principal complains, the Board asks questions, and the questions are the ones you cannot answer on the spot. A disgruntled ex-employee asking what happened to the recordings of their performance conversations is a far more likely first contact than a proactive audit.

Which brings it back to Section 6(10). The first real test of most companies' meeting compliance will not be a fine. It will be a request to produce the consent record — and either you have one or you don't.

A nine-month plan for your meeting stack

Concrete, sequenced, and scoped to meetings specifically. Your broader DPDP programme is a bigger exercise; this is the part that is usually orphaned.

Months 1–2: find out what you actually have

Inventory every surface that captures a meeting. Conferencing platform recording, native AI companions, third-party notetakers installed by individuals, call recording in your sales tooling, interview platforms, support call recording. Expect to find tools nobody approved — individual adoption of notetakers is near-universal and rarely goes through procurement.

Map the flow for each. Where does audio go, where is the transcript stored, which sub-processors touch it, which country is it in, how long does it live, who can access it, is it used for training.

Classify meetings by participant type. Internal-only, internal-with-contractors, external. This map is what tells you which meetings might sit under Section 7(i) and which are firmly in consent territory. In most B2B companies the external bucket is much larger than people expect.

Ask the Section 6(10) question of every tool. Can it produce a per-participant, per-meeting, timestamped record of notice and consent? Write down the honest answer. This is your gap list.

Months 3–5: fix the consent architecture

Write a real notice. Standalone, plain language, itemised data description (audio, video, transcript, speaker attribution, derived analysis), specific purpose, and a link to withdraw, exercise rights, and complain to the Board. Plan for Eighth Schedule language coverage if you're consumer-facing.

Move from banner to affirmative action for external meetings. Participants should take a clear affirmative step before the recording starts, not read a notice while it's already running.

Build the consent record. Individual, meeting, notice version, timestamp, retained and retrievable. Seven years is the benchmark the Rules set for consent managers; use it as your reference point.

Build withdrawal, and make it propagate. One-tap withdrawal that actually stops processing and reaches your processors, per Section 6(6). Trace it through recording, transcript, summary, embeddings, CRM, and analytics.

Take a documented Section 7(i) position with counsel for internal meetings, and be explicit about contractors and recruitment rather than letting the ambiguity sit unexamined.

Months 6–8: contracts and controls

Re-paper vendor DPAs. Processor designation, processing limited to your instructions, mirrored Section 8 security obligations, breach notification to you inside 24 hours, sub-processor list and change notification, deletion at end of term, and an explicit no-training-on-our-content clause unless you have consciously agreed otherwise.

Set per-category retention. Different periods for recordings, transcripts, summaries and access logs — with Rule 6's one-year log minimum built in, not deleted through.

Harden the security floor. Encryption at rest and in transit, role-based access to recordings (a transcript archive readable company-wide is hard to call a reasonable safeguard), audit logging of access to meeting data, MFA.

Write and rehearse the breach playbook for the meeting stack specifically, including the case where the breach is at your notetaking vendor rather than in your own systems.

Month 9: prove it

Run the drill. Pick a real meeting from over a year ago and try to produce the consent record, the notice version, the retention justification and the access log. Whatever breaks in that exercise is what would have broken in front of the Board.

Name the grievance officer, publish the contact, and test the 90-day path end to end.

Train the humans. The best consent architecture in the country fails if an AE turns on an unapproved notetaker for a customer call. Policy plus tooling, not policy alone.

What good looks like in a product — and where we're not there yet

I run a company that builds AI meeting software, so treat this section with appropriate scepticism. I'd rather tell you exactly where we stand, including the part that doesn't flatter us.

What I think is genuinely right in our design: consent is a pre-join gate, not a banner. Before the device check, the participant sees a modal carrying a message you write — plain text or markdown, with formatting and links — and they either accept and proceed, or cancel and leave. It's commonly used to disclose that the session is recorded, transcribed and reviewed. That structure matches what Section 6(1) asks for far better than a notice that appears while recording is already running, because there is an actual affirmative act by the actual participant, before any processing starts.

And here is what we do not have. That consent click is enforced, but it is not written to an auditable consent table. There is no per-participant, per-version, timestamped record you could hand a regulator fourteen months later.

Under Section 6(10), that gap is material. It means our consent gate is good design and not yet sufficient evidence. If you are using Waterr — or frankly any meeting product — for processing where you'll carry the burden of proof, you need to know that today, and you'd need your own log alongside until the platform provides one. We're building it. It isn't built.

I'm putting that in a post about compliance because a compliance post is the worst possible place to overstate what your product does. Every vendor in this category, mine included, will be telling you they're DPDP-ready over the next nine months. The useful question to ask all of us is not whether we say we're ready. It's the Section 6(10) question: show me the consent record you'd produce for a meeting from last year. Vendors who can produce one will show you. Vendors who can't will talk about their security posture instead.

Frequently asked questions

Is it legal to record a meeting in India without consent? Recording a conversation you are a participant in is generally lawful — India has no all-party-consent statute, and R.M. Malkani (1973) established that such recordings can be admitted as evidence. Intercepting a conversation you are not part of is criminal under Section 25 of the Indian Telegraph Act. But several High Courts have held non-consensual recording breaches Article 21 privacy, and separately, DPDP governs what you then do with the recording. Lawful to record does not mean lawful to process.

When does the DPDP Act actually come into force? In phases. The Data Protection Board and definitional provisions commenced 13 November 2025. Consent-manager registration commences 13 November 2026. The substantive obligations — notice, consent, security, breach, retention, rights, cross-border — commence 13 May 2027, eighteen months after the Rules were notified.

Do I need consent to record internal meetings with my own employees? Possibly not. Section 7(i) permits processing for the purposes of employment or to safeguard the employer from loss or liability, as a legitimate use independent of consent. Take a documented position with counsel, note that it likely doesn't extend to contractors or to former employees, and remember it removes only the consent requirement — purpose limitation, security, retention and rights obligations all still apply.

Does that cover interviews and recorded candidate screens? This is genuinely unsettled. A candidate is not yet an employee, and the Act doesn't say whether pre-employment processing falls within "purposes of employment." Some argue Section 7(a) applies because the candidate voluntarily provided their data for a specified purpose. If recorded interviews are a high-volume activity for you, get a written position rather than assuming the generous reading.

Is a meeting transcript personal data under DPDP? Yes, where it relates to identifiable individuals — which a transcript with speaker attribution does by construction. So do the recording, the summary, and analysis derived from them.

Can I rely on my AI notetaker vendor's consent flow? Read the terms first. The prevailing pattern is that vendors require the customer to obtain necessary permissions from participants. If that's your contract, the Section 5 notice obligation and the Section 6(10) burden of proof are yours, not theirs.

What is the penalty for getting meeting consent wrong? Consent and notice failures fall under the residual head — up to ₹50 crore. If the same incident also involves a security failure, that is a separate contravention carrying up to ₹250 crore, and failure to notify a breach up to ₹200 crore. These are maximums; the Board has discretion to impose far less.

Do I need to register with a consent manager? No. Consent managers are a facility for Data Principals to manage consent across fiduciaries, and they must register with the Board from 13 November 2026. You aren't required to use one — but you are required to do what one does: keep provable records of notice and consent.

Can I send meeting recordings to a server outside India? Generally yes. The Rules take a blacklist approach — transfers are permitted except to countries the Central Government notifies as restricted. You still need to document where data goes, contract properly with recipients, and be able to change destination if a country is later restricted. Sector-specific rules (RBI, IRDAI) may impose stricter localisation.

How long can I keep meeting recordings? As long as the specified purpose requires, then erase — unless another law requires longer. Set the period per purpose and per artifact, and note Rule 6 separately requires access logs to be kept at least a year. Recordings and the logs of who accessed them are different objects with different rules.

What should I ask a meeting vendor before signing? Five questions. Can you produce a per-participant, per-meeting consent record from a year ago? Do you train on our content by default? Where does the data physically live, and which sub-processors touch it? How fast do you notify us of a breach — and is it inside 24 hours? When we delete, what actually gets deleted, and does it reach backups and derived artifacts?

We're a startup. Does DPDP apply to us? Yes. There is no exemption for size, revenue, or stage. It also applies extraterritorially to entities outside India offering goods or services to Data Principals in India.

Sources

Digital Personal Data Protection Act, 2023 (Act 22 of 2023) — Sections 4, 5, 6, 7, 8, 10, 16, 33 and the Schedule. Digital Personal Data Protection Rules, 2025, notified 13 November 2025 via G.S.R. 846(E), Ministry of Electronics and Information Technology — Rules 3, 4, 6, 7, 8, 13, 17–21 and Schedules I and III. K.S. Puttaswamy v. Union of India (2017). R.M. Malkani v. State of Maharashtra (1973). Aasha Lata Soni v. Durgesh Soni, Chhattisgarh High Court, CRMP No. 2112 of 2022, 5 October 2023. Sanjay Pandey v. Directorate of Enforcement, Delhi High Court. US matters cited as offshore context only: In re Otter.ai Privacy Litigation / Brewer v. Otter.ai Inc., No. 5:25-cv-06911 (N.D. Cal., filed 15 August 2025); Cruz v. Fireflies.AI Corp. (filed 18 December 2025).

Statutory position stated as at 5 August 2026. This is a practitioner's read for people building and buying meeting software — it is not legal advice, and it is not a substitute for counsel who knows your business.

Related reading: AI notetaker vs AI meeting agent on why the two are different legal objects, and how Waterr AI handles meeting privacy.