01
Accountability
Role map
Roles depend on who decides purpose and means, who acts on instructions, and what each party actually does. Record the conclusion and its evidence; do not infer it from the vendor label.
- Name the business owner, channel administrator, inbox provider, CRM owner and agent teams.
- Record Meta and any business-solution provider roles from current agreements and architecture.
- Separate the person who approves message purpose from the person who can send.
02
Collection surfaces
Collection and notice touchpoints
Walk each entry path as a real user. Save the notice, fields, choices, time and destination rather than relying on a policy page alone.
- Click-to-chat, QR codes, website forms, inbound messages and offline collection.
- Template messages, agent replies, media, support notes and conversation tags.
- Cloud API webhooks, shared inboxes, bots, CRM sync and exported transcripts.
03
Purpose discipline
Purpose and data minimisation checks
Every field and copy should have a named operating reason, accountable owner and review event.
- Ask only for information needed in the conversation.
- Prevent agents from moving sensitive content into notes or personal devices.
- Limit webhook payload, transcript export and CRM field copying.
04
Choice evidence
Consent and preference evidence
When consent is relied on, preserve the affirmative action and withdrawal path. Where another legal route is assessed, record that analysis instead of manufacturing a consent record.
- Record the notice and invitation at the channel entry point.
- Distinguish service messaging from marketing-choice evidence.
- Test opt-out propagation across templates, inbox and CRM.
05
Least privilege
Access control and privileged roles
Test ordinary view, sensitive fields, bulk action, export, configuration and integration access separately.
- Review business administrators, system users, tokens, phone-number access and agent roles.
- Restrict transcript, media and export access.
- Exercise token rotation and agent offboarding.
06
Lifecycle
Retention, deletion, backup and export behaviour
A delete button is not a lifecycle rule. Record the start event, end event, exception, system action, residual copy and accountable approver.
- Define retention for conversations, media, templates, webhook logs and CRM copies.
- Test provider, inbox, CRM and local export deletion separately.
- Record any mandatory or operational retention exception.
07
Service chain
Processor, sub-processor and contract checks
Use the current contract and actual architecture. A product page cannot establish the complete role allocation for your organisation.
- Retrieve current Meta and provider terms and sub-processor information.
- Inventory inbox, bot, CRM, webhook host and archival services.
- Record security, incident, assistance, deletion and exit commitments.
08
Detection + response
Logs, monitoring and breach evidence
Coverage, event types, retention and exportability vary. Preserve an evidence timeline without claiming that one log proves the complete event.
- Log template, admin, token, webhook and bulk-send changes where available.
- Monitor delivery failures, unexpected exports and anomalous agent access.
- Connect provider alerts and business incidents to an internal evidence timeline.
09
Request workflow
Rights-request search, export, correction and erasure workflow
- 01
Verify the requester using a safe process that does not expose chat history.
- 02
Search phone identifiers across inbox, CRM, webhook logs, exports and agent tools.
- 03
Review exceptions before correction or erasure.
- 04
Record downstream confirmations and residual media or backup handling.
10
Bounded configuration
Configuration checklist
The person sees the appropriate notice before or at collection.
- Admin path
- Verify in the current admin console
- Evidence to save
- Dated screenshots of each QR, link or form journey.
Business admins, tokens and agent roles are bounded and reviewed.
- Admin path
- Verify in the current admin console
- Evidence to save
- Access inventory, token owner and review record.
Payloads and downstream fields are necessary, protected and retained deliberately.
- Admin path
- Verify in the current admin console
- Evidence to save
- Payload sample, destination map and retention decision.
No menu-path fiction: open the current vendor documentation and your live console together. Feature names, paths and entitlements can change.
11
Retrievable proof
Evidence to save
Channel entry-point notice record
Template and purpose register
Admin, system-user and agent review
Webhook payload and destination map
Opt-out propagation test
Conversation-search and deletion exercise
Save redacted configuration evidence in an approved internal location. This private preview does not accept uploads or store these records.
12
Do not overclaim
Known limitations and questions for the vendor
Known limitations
- This guide does not assume the consumer app, Business app and Cloud API behave identically.
- Provider, inbox and CRM retention can differ.
- Official documentation and commercial terms change; verify the chosen architecture.
Questions to resolve
- Which WhatsApp product and provider are used?
- Where do webhook payloads and media land?
- Can every agent export transcripts?
- Does opt-out stop every connected sender?
13
Traceable record
Official vendor sources, DPDP sources and corrections
Vendor documentation supports configuration questions only. DPDP statements are mapped separately to official Indian sources and phased commencement records.
Official vendor documentation
Official DPDP record
- Act No. 22 of 2023Ministry of Law and Justice, Government of India · checked 2026-09-27 ↗
- G.S.R. 843(E)Ministry of Electronics and Information Technology, Government of India · checked 2026-09-27 ↗
- G.S.R. 846(E)Ministry of Electronics and Information Technology, Government of India · checked 2026-09-27 ↗
- G.S.R. 892(E)Ministry of Electronics and Information Technology, Government of India · checked 2026-09-27 ↗
Reviewed · not counsel-reviewed · educational implementation guidance, not legal advice, certification or a legal conclusion.
Report or inspect a correctionWhatsApp and Meta are trademarks of Meta Platforms, Inc. They are referenced nominatively; no affiliation or endorsement is implied.