Marketing Cloud Account Engagement and the DPDP Act: What Indian B2B Marketers Actually Need to Fix

Here’s a question worth putting to your marketing team this week. If a prospect in Bengaluru wrote in tomorrow and asked you to prove she agreed to receive your emails, could you? Most Indian B2B teams can’t. They can show that she hasn’t unsubscribed yet, which is a different thing entirely.

So let’s clear up the biggest misconception straight away. The DPDP Act covers your B2B marketing data. There’s no business-to-business exemption hiding in the text. A work email address that identifies a real person is personal data, exactly like a personal one, and your Marketing Cloud Account Engagement instance is full of it.

What This Guide Covers

This is a practical walkthrough for anyone running MCAE, formerly Pardot, on an Indian prospect database. We’ll work through what the DPDP Act and the DPDP Rules actually ask of you, where each of those requirements lands inside your Account Engagement setup, and which parts the platform handles versus which parts you have to build yourself.

You’ll get a mapping table tying each obligation to specific MCAE features, a readiness checklist, a DPDP and GDPR comparison, and an honest list of the mistakes we keep finding. It’s written for marketing ops leads, Salesforce admins, RevOps teams and the compliance folks who sign off on all of it.

The Short Version

• Yes, DPDP applies to your B2B marketing data. Work emails count as personal data.
• The obligations that reshape a marketing database become enforceable around May 2027, so you have runway, though less than it looks.
• India recognises consent or a short list of specific legitimate uses. There’s no legitimate interest ground of the kind European B2B marketers rely on.
• MCAE gives you no native opt-in field, no consent timestamp and no audit trail. You build those.
• Deleting a prospect sends it to the recycle bin. That’s suppression, and it isn’t erasure.
• Section 6(10) puts the burden of proof on you. An Opted Out checkbox won’t discharge it.

One thing before we start. We’re Salesforce consultants, not lawyers. Everything here comes from the published text of the Act and the Rules, and we’ve flagged the places where the answer depends on legal interpretation. Read it as a technical readiness guide and have your counsel review the judgement calls with you.

Does The DPDP Act Apply To Marketing Cloud Account Engagement?

Short answer: Yes. In almost every realistic Indian B2B scenario, your MCAE prospect database sits squarely inside the Act.

The Digital Personal Data Protection Act, 2023 defines personal data as any data about an individual who’s identifiable by it or in relation to it. Open any prospect record in your instance. You’ll find a name, a work email, a job title, a phone number, a company, and a full behavioural history of page views, email opens and form submissions. That’s personal data on the plain wording.

Section 3 sets the boundaries. The Act covers processing inside India, whether the data was collected digitally or digitised later. It also reaches processing outside India when that connects to offering goods or services to people here. An Indian company emailing Indian prospects is covered, and so is a company running campaigns into India from an instance hosted abroad.

What About Publicly Available Data?

There’s one exclusion people misread constantly. The Act doesn’t apply to personal data that someone made publicly available themselves or that another party was legally required to publish. The Act’s own illustration describes a person sharing her details while blogging.

Marketers sometimes stretch this to cover scraping LinkedIn or buying compiled lists. Be careful. The exclusion is built around data the person themselves put out there, so a database assembled by a vendor is a much harder argument, and you’d be defending it. We wouldn’t build a program on that reading without written legal advice.

The Change That Matters Most For B2B

Here’s the part European-trained marketers find hardest. Section 4 recognizes exactly two lawful grounds. You either have consent, or your processing fits one of the specific legitimate uses listed in Section 7.

India has no open-ended legitimate interest ground. If your outreach program leans on legitimate interest for cold B2B email, that reasoning simply doesn’t exist here.

Section 7(a) does cover data someone voluntarily gave you for a stated purpose, where they haven’t objected. Filling in your form to download a whitepaper fits. A purchased list doesn’t obviously fit, and the Act’s illustration shows the ground falling away the moment the person says they’re no longer interested.

When Do These Obligations Actually Start Applying?

Short answer: The rules governing your marketing database become enforceable around May 2027. The Data Protection Board is already operational.

Parliament passed the Act on 11 August 2023, but it needed rules to work. MeitY notified the Digital Personal Data Protection Rules, 2025 through G.S.R. 846(E) dated 13 November 2025, published in the Gazette the next day. Rather than switching everything on at once, the Rules stagger commencement across three stages.

Look at that third row again. Rules 3 and 5 to 16 commence eighteen months after publication, and the Act’s matching provisions follow. Your practical deadline is May 2027.

Two things follow, and they pull against each other. You’ve got more runway than the alarmist content suggests, since nobody’s fining you today over missing consent timestamps. The runway is also shorter than it looks, because retrofitting consent onto a legacy database is slow work, and every month you run forms without a consent field adds records you’ll have to re-permission or delete later.

The penalty ceilings explain the attention. The schedule sets a maximum of 250 crore rupees for failing to take reasonable security safeguards, 200 crore for failing to notify a breach, 150 crore for Significant Data Fiduciary breaches, and 50 crore for other breaches. Those are ceilings, and the board weighs gravity, duration and whether you acted to fix things.

Which DPDP Requirements Touch Your Account Engagement Setup?

This is where the law meets the platform. Five categories run through the table.

• Native means MCAE does it for you
• Configuration means the capability exists and someone has to set it up
• Custom means fields, code or development work
• Operational means a documented human process
• Legal means a judgement call for your counsel that no platform setting can solve

Notice how few rows say Native. That’s the honest picture, and it’s the whole point of this guide.

What Does MCAE Handle For You, And What Doesn’t It?

Short answer: MCAE gives you the raw materials. It doesn’t give you a consent model, an audit trail, a retention engine or a rights workflow.

Implementing Salesforce doesn’t make you DPDP compliant. Neither does upgrading your MCAE edition. We’re being blunt because we’ve sat in meetings where a team genuinely believed the platform had it covered. Account Engagement runs on a permission-based marketing policy. Salesforce asks you to certify that you only contact people who agreed to hear from you. What it doesn’t hand you is a native opt-in field to record that agreement, or any trail proving when and how each person gave it. The obligation sits with you. So does the evidence.

Here’s what teams usually find missing once they look properly.

• No standard consent object. Source, timestamp, purpose and channel have to be custom prospect fields, populated consistently by every form, import and integration.
• The preference centre runs on public lists. It’s a subscription manager, and representing real processing purposes takes deliberate design.
• Deleting a prospect moves it to the recycle bin, which suppresses it from your working database without erasing anything.
• No retention engine. Nothing spots dormant prospects, applies a policy or deletes records once a purpose is served.
• No rights request workflow. No queue, no clock, no audit log.
• MCAE tracking and your cookie banner don’t talk to each other by default.
• Nothing reconciles consent across downstream systems. Warehouses, enrichment tools and analytics sit outside the platform’s awareness.

Closing these gaps usually spans MCAE, Salesforce CRM and several integrations at once. It’s the kind of scope our Salesforce Marketing Cloud services team handles alongside Salesforce customization work, because a consent model living only in the marketing tool breaks the first time the CRM syncs over it.

Why Isn’t The Opted Out Field Enough?

Short answer: Because it records that someone eventually said stop. It says nothing about what they agreed to, when, or for which purpose.

The Two Fields People Confuse

Account Engagement has an Opted Out field on the prospect record, which maps to Email Opt Out on Salesforce Leads and Contacts. It also has a separate Do Not Email field. Salesforce decoupled these on purpose.

Opted Out reflects what the prospect chose, through an unsubscribe link or your preference centre. Do Not Email is a suppression control for your own team.

Editing Opted Out manually is possible and a bad idea, because you’re overwriting what the person actually decided. If your team has been doing it for list hygiene, you’ve contaminated the only consent signal you had.

There’s a sync decision that catches people too. When MCAE and Salesforce hold different values for the same person, one has to win. Your admin sets which system is the source of truth, and that setting has changed across releases, so check what your org is on today.

What A Real Consent Record Captures

Section 6(10) puts the burden of proof on you. If a question comes up in proceedings, you have to show notice was given and consent validly obtained. A flag reading false proves nothing.

• Source: the form, event, import or integration it came through
• Timestamp: when it was given, stored where it can’t be silently overwritten
• Purpose: what they actually agreed to, since one yes doesn’t cover everything
• Channel: email, phone or WhatsApp, because those are separate agreements
• Notice version: the wording they saw, since notice and consent are linked
• Status and history: the current position plus the trail of changes
• Withdrawal record: when it happened and what you did about it

Where Do Your Prospects Actually Come From?

Form fills are the easy case. Everything else is where the work sits.

Trade show leads arrive as badge scans and spreadsheets. Somebody stopped at your booth. Whether that amounts to agreeing to a twelve-month nurture sequence is a question for your legal team before the import.

Webinar registrations hold up for follow-up about that webinar. Using them for unrelated campaigns is a purpose limitation problem, since Section 6(1) limits consent to what’s necessary for the stated purpose. Partner and co-marketing leads raise the same issue, because that consent went to a different company.

Sales-created contacts are the leak we find most often. A rep types someone into Salesforce, the record syncs into MCAE, and it lands in your marketing database having passed no consent capture at all.

Purchased and enriched data carries no trail you can evidence. In a framework with no legitimate interest ground, this is the hardest category to defend.

Legacy records predate all of this, and Section 5(2) speaks directly to them. Where consent was given before the Act commenced, you owe the person notice about the data and purpose as soon as reasonably practicable, and you can keep processing until they withdraw. That’s a workable path for an existing database, and it needs planning.

How Should Website Tracking And Cookies Work With MCAE?

Short answer: Your consent platform has to control the Account Engagement tracker. By default the two run independently, so a refused cookie banner won’t stop MCAE tracking.

Account Engagement drops a cookie through your tracker domain and follows anonymous visitors around your site. When somebody submits a form, that whole anonymous history attaches to a named prospect. Months of browsing become identifiable in one click.

That’s the moment to think about. Before the form you arguably hold behavioural data. After it you hold personal data with a rich profile attached, and the Act applies to all of it.

Most Indian B2B sites run a cookie consent tool on the website and MCAE tracking underneath, with nothing connecting them. Someone declines marketing cookies and the tracker carries on, because it never got the message.

MCAE does provide a Tracking and Consent JavaScript API built for this. It lets your consent platform decide whether Account Engagement tracking runs. Wiring it up spans your CMS, your consent tool and your MCAE settings, and it needs testing rather than trusting.

Worth saying plainly: India’s position on cookie consent is less settled than Europe’s. The Act is framed around consent for processing personal data rather than around cookies as such. Where tracking identifies a person, the safer reading puts it inside your consent framework, and that call belongs to your counsel.

Connecting a consent platform to Account Engagement tracking and your CRM is integration work more than marketing work, which is why it usually sits with a Salesforce integration services team rather than the campaign team.

What’s The Difference Between An Unsubscribe And A Consent Withdrawal?

Short answer: An unsubscribe stops emails. A withdrawal stops processing, everywhere, including at your vendors.

Section 6(4) lets anyone withdraw consent at any time, and requires that withdrawing be as easy as giving it. If someone consented by ticking a box, they shouldn’t need to email your legal team and wait a fortnight to reverse it.

Section 6(6) goes further. Once consent is withdrawn you have to stop processing within a reasonable time, and make your data processors stop too. That word processors carries weight, because your enrichment vendor, webinar platform, agency and warehouse are all potentially in scope.

So when someone clicks unsubscribe in an Account Engagement email, here’s the reality.

Then there’s the re-import problem, which quietly undoes all of it. Somebody exports a list, works it in a spreadsheet and uploads it back with the opt-out column stripped. Or a badge-scan import overwrites a suppression. Your import process needs a hard rule that consent status is never overwritten, and that rule needs enforcing rather than documenting.

How Do You Handle A Rights Request Across MCAE And Everything Connected?

Short answer: You need an inventory of every system holding prospect data first. Without it, you can’t answer a Section 11 request honestly.

Under Sections 11 and 12, people can ask for a summary of their personal data and how you process it, corrections, updates, and erasure. Rule 14 requires a grievance system that responds within a period not exceeding 90 days.

Section 11 holds the requirement that catches Salesforce teams out. A person can ask for the identities of every other Data Fiduciary and Data Processor you shared their data with, plus a description of what you shared.

Answering that honestly means having a current list of every connector, integration, API consumer, agency login, enrichment tool and export destination touching prospect data. Most organisations we assess can’t produce it. Building that list is a prerequisite, not an optional extra.

The other trap is assuming one action cascades. Deleting a prospect in Account Engagement doesn’t clear the Salesforce Lead. Deleting the Salesforce record doesn’t empty your warehouse. And nothing reaches the CSV your regional team saved to a shared drive last quarter.

A workable process needs a named owner, a tracked queue with the 90 day clock visible, a documented sequence covering every system on your inventory, a way to verify who’s asking, and a record of what you did. None of it ships with the platform.

How Long Can You Keep Prospect Data, And How Do You Actually Delete It?

Short answer: You have to erase once consent is withdrawn or the purpose is served. And deleting in MCAE sends records to a recycle bin, which isn’t erasure.

Section 8(7) is the provision that should worry marketing teams most. You have to erase personal data when consent is withdrawn or as soon as it’s reasonable to assume the stated purpose is no longer being served, whichever comes first, unless a law requires you to keep it.

Marketing databases run on the opposite instinct, since nobody wants to delete a prospect who might convert in three years.

A useful detail: the Third Schedule sets specific retention periods only for large e-commerce entities, online gaming intermediaries and social media intermediaries above stated user thresholds. Ordinary B2B companies aren’t on that list, which doesn’t exempt you, since Section 8(7) still applies. You have to define your own defensible position rather than copying a number from the Rules.

Pulling the other way, Rule 6 requires you to keep access logs and personal data for a year to support detection of unauthorised access, and Rule 8(3) sets a minimum one year retention for processing logs. So retention policy means holding some things and releasing others.

Why Deleting A Prospect Isn’t Erasure

When you delete a prospect in Account Engagement, the record moves to a recycle bin. It’s out of your working database and it still exists. Worse, a record sitting there can come back automatically if that person engages, say by clicking a link in an older email or submitting a form. Sync activity from Salesforce can restore records too.

Permanent deletion needs a support case raised with Salesforce. If your erasure process stops at the delete button, you’ve suppressed the record rather than erased the data, and you shouldn’t describe it to anyone as erasure.

Sequencing matters as well. Deleting the Salesforce Lead or Contact first is generally cleaner, since removing the CRM record removes the linked prospect, while deleting only in MCAE leaves a CRM record that can push it straight back. Verify the behaviour for your account type and current release rather than taking any blog’s word for it, ours included.

One last wrinkle. To honour a suppression permanently, you have to keep enough information to recognise that person if they’re imported again. Erasing every trace and keeping a reliable suppression list pull against each other. Most organisations keep a minimal hashed record, and that decision belongs with your legal team rather than an admin.

What Happens If You Have A Data Breach?

Short answer: You tell affected people without delay, tell the Board without delay, and file a detailed report with the Board within 72 hours.

On becoming aware of a breach, you must tell each affected person without delay, in clear language, covering what happened, the likely consequences for them, what you’re doing about it, what they can do, and who to contact.

You must also tell the Data Protection Board without delay with an initial description, then within 72 hours supply detail covering the facts and circumstances, mitigation, any findings about who caused it, remedial steps, and a report on what you told affected people.

Read the definition carefully. A personal data breach covers unauthorised processing and accidental disclosure, well beyond a dramatic external attack. An automation rule that emails the wrong segment, an over-permissioned export, or a departing employee’s live API token can all qualify.

Your MCAE and Salesforce admins own most of the prevention surface.

• User roles and permission sets, especially who can bulk export prospect data
• Connected apps and API integrations, including tokens for tools nobody uses any more
• Agency and contractor access, and whether it’s revoked when engagements end
• Export controls and visibility over who downloaded what
• Logging and monitoring, which Rule 6 requires for detecting unauthorised access
• An escalation path so an admin who spots something knows who to call within the hour

Rule 6 also expects appropriate contractual provisions with your processors, matching Section 8(2), which requires a valid contract before anyone processes data on your behalf. Access reviews and permission hygiene are exactly the continuous work our Salesforce managed services engagements cover, because these controls decay quietly between projects.

Can You Keep Your Data Outside India?

Short answer: Generally yes. India uses a restriction list rather than a localisation mandate, though Significant Data Fiduciaries may face limits.

India took a lighter approach than many expected. Section 16 lets the Central Government restrict transfers to specified countries by notification, and Rule 15 permits transfers subject to requirements the government may set. For most Indian B2B companies that’s workable, though Significant Data Fiduciaries face an extra possibility under Rule 13(4), where the government may name categories of data that can’t leave India.

What we wouldn’t do is assume where your data sits. Salesforce runs infrastructure across multiple regions and your instance location depends on your contract. Confirm it with Salesforce rather than guessing.

Then map everything downstream, because that’s where the surprises live. Enrichment platforms, webinar tools, analytics, BI dashboards, agencies with export rights and offshore support teams all move prospect data. Each one is a transfer to document.

Your MCAE DPDP Readiness Checklist

Work through this in order. The early items are discovery, and skipping them turns everything after into guesswork.

1. Inventory every source feeding prospects into MCAE: forms, imports, integrations, events, partners and sales-created records.
2. Count how many prospects have no evidence of consent source or timestamp. That number sizes your remediation.
3. Document every connector, API consumer, agency login and export destination touching prospect data, since Section 11 requires disclosing them on request.
4. Confirm in writing from Salesforce where your MCAE and CRM data is hosted.
5. Add custom prospect fields for consent source, timestamp, purpose, channel and notice version.
6. Rebuild forms and form handlers so each processing purpose gets its own affirmative choice instead of one bundled checkbox.
7. Redesign the preference centre around real processing purposes rather than internal list names.
8. Confirm withdrawing is as easy as consenting by timing both journeys, and stop marketers editing Opted Out manually.
9. Set a rule that consent status is never overwritten by an import, and enforce it in the import process itself.
10. Verify your opt-out sync setting between MCAE and Salesforce, and confirm which system is the source of truth.
11. Connect your website consent platform to MCAE tracking using the Tracking and Consent JavaScript API, then test that declining cookies stops the tracker.
12. Define a retention policy per data category, with a defensible reason for each period.
13. Document the full erasure sequence across MCAE, Salesforce, the recycle bin, the support case for permanent deletion, and every downstream system.
14. Decide with legal how you’ll maintain suppression without keeping more data than you can justify.
15. Create a rights request queue with a named owner and the 90 day clock visible.
16. Write a runbook for access, correction and erasure requests covering every system on your inventory.
17. Review MCAE and Salesforce permissions, focusing on who can bulk export prospect data.
18. Audit connected apps and API tokens, revoking anything tied to a tool or person you no longer use.
19. Write a breach escalation path that reaches privacy and legal fast enough to meet the 72 hour window.
20. Publish contact details for data questions on your website and in every rights response, as Rule 9 requires. Write notice copy giving an itemised description of the data and purposes, as Rule 3 requires.
21. Plan your Section 5(2) notices to the existing database, covering what you hold and why.
22. Check whether children could enter your database, since Section 9 prohibits tracking and targeted advertising directed at children.
23. Assign written ownership for each area, so no obligation sits with nobody in particular.

Is GDPR-Compliant Pardot Already DPDP Compliant?

Short answer: No, though your GDPR work transfers usefully. The lawful basis gap is the one that will catch you.

If you built GDPR processes into MCAE for European campaigns you’ve got a head start, since consent capture, preference centre and rights workflows all carry over.

The first row matters most. If your European programme leans on legitimate interest for outreach, that reasoning has no equivalent here. Campaigns into India need consent, or they need to fit inside Section 7, and that’s a different operating model.

What Are The Most Common MCAE Compliance Mistakes?

Treating Unsubscribe As Consent Management

One boolean can’t evidence what somebody agreed to, when, or why. It records only that they eventually said stop.

One Checkbox For Everything

A single agreement covering newsletters, product updates, event invitations, partner communications and phone calls fails the specific and limited standard in Section 6(1).

No Consent Source Or Timestamp

Section 6(10) makes you prove valid consent was obtained, and without a source and a timestamp you can’t. A preference centre wired to internal list names has the same problem, since prospects can’t tell what they’re agreeing to.

CRM Sync Resurrecting Deleted Records

A prospect deleted in MCAE reappears because the Salesforce record was never touched, or the recycle bin restored it after an engagement event.

Keeping Every Prospect Forever

Section 8(7) requires erasure once the purpose is served. An unbounded database is the default state of most marketing teams, and it’s now a position that needs defending.

Uncontrolled Exports And Forgotten Integrations

Every CSV export creates a copy nobody governs and nobody can find when a rights request lands. Tools connected during an old project keep pulling prospect data long after anyone remembers approving them.

Assuming Someone Else Handles Compliance

Salesforce builds capable tools and publishes its own commitments as a processor, while the Data Fiduciary obligations stay with you. Internally the same gap appears: marketing assumes IT owns it, IT assumes legal owns it, legal assumes the Salesforce admin owns it, and the admin was never told.

Who Should Own DPDP Readiness Inside Your Company?

Short answer: It splits across seven functions, and it fails whenever any one of them is missing.

How these combine depends on your size. The realities differ for a growing company versus a multi-region business, which is why our work with startups building on Salesforce in India looks different from our enterprise CRM engagements. What stays constant is that somebody has to be named against each row.

When Should You Bring In Outside Salesforce Help?

Plenty of teams read a guide like this, recognise every gap, and then stall. The problem is rarely understanding. It’s capacity and specialist knowledge.

That’s where Salesforce staff augmentation often fits better than a fixed-scope project. You keep ownership of priorities and sequencing, and you add certified people who’ve done this before. We place administrators, developers, consultants and architects into client-led programmes rather than taking the programme away from you.

The situations where extra hands genuinely help look like this.

• You have no dedicated MCAE administrator, and the platform is maintained by whoever has time
• You inherited a Pardot environment nobody documented, and the person who built it has left
• Your integrations are complex enough that nobody can say where prospect data goes
• Your legacy database is large, and re-permissioning it is a project rather than a task
• Documentation doesn’t exist, and you need it to defend your decisions
• You need a focused remediation push without adding permanent headcount
• You need ongoing cover so consent governance doesn’t decay once the project ends

The work usually covers MCAE and Salesforce administration, consent architecture, preference centre and form rebuilds, automation cleanup, sync reconfiguration, prospect data cleanup, retention and deletion workflows, integration remediation, and the documentation that makes it auditable.

Some organisations prefer a scoped engagement instead, particularly for assessment and architecture, which is closer to how our Salesforce consulting services are structured. Both models work. What matters more is that technical remediation and legal decisions move together, because a consent architecture built without legal input tends to get rebuilt.

We work with teams across India from our base in Jaipur, including clients in Delhi NCR and Mumbai. The pattern holds everywhere. Companies that start with an honest inventory finish faster than the ones that start by buying a tool.

Frequently Asked Questions

1. Is Salesforce a Data Fiduciary or a Data Processor under the DPDP Act?

   Under Section 2, the Data Fiduciary decides the purpose and means of processing, which is you. Salesforce processes data on your behalf, making it a Data Processor. Section 8(2) requires a valid contract, so confirm your Salesforce agreement covers it.

2. Do Indian startups get any exemption from DPDP?

   Section 17(3) lets the Central Government notify certain Data Fiduciaries, including recognised startups, as exempt from Section 5, Sections 8(3) and 8(7), and Sections 10 and 11. Nothing is automatic. The exemption applies only if your company is actually notified.

3. Does DPDP apply if we only market to prospects outside India?

   Section 17(1)(d) exempts processing of personal data of people outside India done under a contract with a person outside India. If your whole funnel is overseas, much of the Act may not apply. One Indian prospect brings it back.

4. Do consent notices have to be available in regional languages?

   Sections 5(3) and 6(3) require offering the notice and consent request in English or any language in the Eighth Schedule to the Constitution. Your MCAE forms, landing pages and preference centre may need a language option built in.

5. Is double opt-in required under DPDP?

   The Act never names double opt-in. It requires consent that is free, specific, informed, unconditional and unambiguous, with clear affirmative action. Double opt-in is a strong way to evidence that, especially since Section 6(10) puts proof on you.

6. Does DPDP apply to WhatsApp and SMS marketing sent through Salesforce?

   Yes. A phone number identifying a person is personal data, and the channel forms part of the specified purpose. Consent for email doesn’t extend to WhatsApp or SMS. Capture channel-level consent separately in MCAE and Salesforce.

7. What is a Consent Manager, and do we have to use one?

   A Consent Manager is a Board-registered Indian company running an interoperable platform where people give, manage, review and withdraw consent. Rule 4 governs registration from around November 2026. Using one is optional for most B2B Data Fiduciaries.

8. Do we need to appoint a Data Protection Officer for MCAE?

   Only Significant Data Fiduciaries must appoint a Data Protection Officer based in India under Section 10. Everyone else still has to publish contact details for a person who can answer questions about processing, as Rule 9 requires.

9. Does DPDP apply to leads collected offline at events and entered later?

   Yes. Section 3 covers personal data collected in non-digital form and digitised later. A paper sign-up sheet becomes covered data the moment someone keys it into MCAE or Salesforce, so capture consent at the event itself.

10. Is our marketing agency a Data Processor under DPDP?

    If your agency processes prospect data on your instructions, it’s a Data Processor. Section 8(2) requires a valid contract, Rule 6 expects security provisions inside it, and Section 8(1) keeps you responsible for whatever the agency does.

11. What happens if a prospect complains directly to the Data Protection Board?

    Section 13(3) requires a Data Principal to exhaust your grievance process before approaching the Board. A working, published grievance mechanism is therefore your first line of defence. The Board can also warn or impose costs for frivolous complaints.

12. Does DPDP affect Einstein or AI-driven lead scoring in MCAE?

    Rule 13(3) requires Significant Data Fiduciaries to verify that algorithmic software they use doesn’t risk Data Principals’ rights. Most B2B firms aren’t notified as SDFs, but scoring still counts as processing that needs a lawful basis and a stated purpose.

13. Does DPDP apply to existing customers as well as prospects?

    Yes. Customers are Data Principals too. Section 7(a) may cover processing for the purpose they originally shared data for, but unrelated marketing to customers still needs consent or another lawful ground under the Act.

14. Are DPDP penalties charged per violation?

    The Schedule sets a maximum for each breach type, and Section 33 lets the Board impose a penalty once it finds a breach significant. Separate breaches can attract separate penalties, and Section 33(2) treats repetition as an aggravating factor.

15. Can sales reps still send one-to-one emails from Salesforce under DPDP?

    A one-to-one email still processes personal data. If the contact was purchased or scraped, there’s no obvious lawful basis. If the person voluntarily shared details for that purpose, Section 7(a) may apply. Consent remains the safest ground.