If your website has a contact form, your app has a login, or your team sells on WhatsApp, you’re already collecting personal data—names, phone numbers, emails, addresses, location, device IDs, support chats, invoices.
In 2026, the question isn’t “Does DPDP apply to us?”
It’s: Can we prove what data we collect, why we collect it, where it goes, how long we keep it, and how a customer can get it deleted?
This guide is built for SMBs (service businesses, local brands, D2C, clinics, coaching, SaaS, agencies)—people who want clear actions and implementation steps for websites + mobile apps.
Not legal advice. Use this as an execution checklist, then validate with counsel for your exact business model.
Quick DPDP refresher (in plain English)
India’s Digital Personal Data Protection (DPDP) law focuses on digital personal data (data that identifies an individual). It introduces roles and responsibilities:
- Data Principal: the individual (your customer/user/lead)
- Data Fiduciary: you (the business deciding why/how data is processed)
- Data Processor: vendors processing data on your behalf (hosting, email, CRM, analytics, WhatsApp API provider, payment gateway, etc.)
The operational expectation: collect less, explain clearly, secure it, retain only as needed, and honor user requests.
What counts as “personal data” on SMB websites/apps?
Typical DPDP-relevant data you’re already handling:
- Lead forms: name, phone, email, city, requirement text
- WhatsApp chats: phone numbers, chat history, attachments
- Support tickets: order IDs + personal info
- App telemetry tied to a user: device identifiers, IP addresses (often)
- Payments: billing address, transaction refs (via gateway)
- Marketing: newsletter lists, remarketing audiences
- Employee/admin accounts: staff emails, phone numbers
Key point: DPDP is not only about “cookies.” It’s about any digital personal data you collect, store, or share.
Minimum Viable DPDP Compliance (MVDC) for SMBs (the 80/20)
If you do only one thing this quarter, do this pack:
- Privacy Notice that matches reality (not copied)
- Consent + recordkeeping (where consent is needed)
- Retention + deletion rules (stop keeping everything forever)
- Vendor DPAs + access control (CRMs, hosting, WhatsApp, analytics)
- DSAR workflow (access/correction/deletion)
- Security safeguards + breach plan (basic, but provable)
Everything below expands these into execution checklists.
The DPDP Compliance Checklist (Web + App)
1) Data inventory (you can’t protect what you can’t list)
Deliverable: a simple spreadsheet/table that answers:
- What data do we collect? (fields + source)
- Why do we collect it? (purpose)
- Where is it stored? (DB, CRM, email, sheets, devices)
- Who can access it? (roles)
- Who do we share it with? (vendors)
- How long do we keep it? (retention)
- What is the deletion method? (manual/automated + SLA)
Practical tip: Start with 15 rows. Most SMBs only have 15–30 “data items” that matter.
2) Privacy Notice (make it specific and auditable)
Your privacy notice should be consistent with your real processing.
Must-haves (practical):
- What personal data you collect (by channel: website/app/WhatsApp/calls)
- Purposes (lead handling, service delivery, billing, support, marketing, fraud prevention)
- Who you share it with (categories + key vendors if possible)
- Retention (plain language; don’t say “we keep forever”)
- How users can withdraw consent / opt out
- How users can request access/correction/deletion
- Grievance/contact details and response expectations
- If you handle children’s data: how you manage it
Pitfall: Copy-pasting a GDPR policy that mentions things you don’t do (or misses what you do). That’s a credibility and compliance risk.
3) Consent (and the “proof of consent” problem)
DPDP expects that where consent is the basis, it is:
- informed (clear notice)
- specific (not bundled)
- freely given
- unambiguous
- withdrawable
- and recorded
Where SMBs typically need consent
- Marketing communications (WhatsApp/SMS/email campaigns)
- Newsletter opt-ins
- Optional profiling/remarketing
- Collecting more data than required for service delivery
Technical implementation: consent logging (minimum)
Store an audit trail. At minimum:
- user identifier (email/phone/user_id)
- consent purpose (e.g.,
marketing_whatsapp,newsletter_email) - status (granted/withdrawn)
- timestamp
- capture source (web form/app screen/WhatsApp keyword)
- privacy notice version / text hash
- IP/device (if you already collect it—don’t add more data just for this)
Pitfall: “Checkbox exists, but we can’t prove when/how it was checked.” That’s the common failure.
4) Data retention & deletion (the most ignored requirement)
Most SMB systems have “infinite retention” by accident: CRMs, Google Sheets, old backups, email inboxes.
Create a retention table like:
- leads not converted: delete/anonymize after X months
- customers: keep invoices for statutory needs, but delete non-essential data after X years
- support chats: delete after X months unless needed for disputes
- backups: keep rolling backups for X days/weeks
Technical implementation: deletion that actually deletes
- DB deletion job (scheduled)
- “soft delete” for application logic (optional), but ensure hard delete eventually
- delete from:
- primary DB
- files/storage (S3/Drive)
- CRM where feasible
- analytics identifiers (where feasible)
- maintain a deletion log (no sensitive content—just event metadata)
Pitfall: Deleting from the app UI but leaving it in exports, logs, or shared sheets.
5) Data Principal requests (DSAR) workflow for SMBs
Even if you’re small, you need a repeatable process for requests like:
- “What data do you have about me?”
- “Correct my number/email”
- “Delete my data”
- “Stop marketing messages”
Minimum DSAR SOP (simple + safe)
- Intake channel: a form + email (or ticket)
- Identity verification: verify via OTP/email link before exporting/deleting
- Categorize request: access/correction/deletion/opt-out
- Fulfill: export or delete across systems
- Close with confirmation + internal log entry
Pitfall: Deleting the wrong person’s data due to weak verification.
6) Vendor management (your stack is your compliance surface)
Typical processors in an SMB stack:
- hosting/VPS/CDN
- email provider
- CRM (Zoho/HubSpot/etc.)
- analytics tools
- WhatsApp Business API provider / shared inbox
- payment gateways
- customer support tools
What to do (practical):
- Maintain a vendor list with:
- data shared
- purpose
- access roles
- contract/DPA status
- Ensure least-privilege access:
- don’t give everyone admin in CRM
- remove ex-employees immediately
- Avoid “shadow systems”:
- random Google Sheets with customer lists
- leads forwarded to personal WhatsApp numbers
Pitfall: Running sales/support on personal phones with no control, no audit trail, and no deletion capability.
7) Security safeguards (what you should implement and be able to prove)
You don’t need enterprise security. You need baseline controls that are actually implemented.
Security baseline checklist (SMB-friendly)
- HTTPS everywhere + HSTS
- Strong admin authentication (MFA for admin panels, CRM, Google Workspace)
- Role-based access control (RBAC) for staff dashboards
- Encryption at rest (where available) + encrypted backups
- Secrets management (no API keys in code/repos)
- Logging + alerting for failed logins, unusual exports, and admin actions
- Regular updates/patching for CMS/plugins/framework dependencies
- Vulnerability basics: rate limiting, input validation, WAF/CDN rules
- Incident response plan (who does what, within what timeline)
Pitfall: “We’re secure because we use a big hosting provider.” Security is mostly about your configuration and your access controls.
8) Children’s data (if your product touches minors, treat this as high-risk)
If your website/app is targeted at children or knowingly processes children’s data, you’ll need stricter controls, typically including:
- age gating where relevant
- verifiable parental consent (if applicable)
- limiting tracking/profiling
- tighter retention rules
Pitfall: Edtech/coaching/tuition apps collecting student data with marketing automation turned on by default.
9) Cross-border data transfers (don’t assume “India-only”)
Many SMBs host on AWS/GCP, use US-based tools, or route data via global CDNs.
Action: document where data is stored/processed and ensure your vendor contracts and configuration match your DPDP posture.
Pitfall: Saying “we store in India” while your CRM/analytics/email tooling processes abroad.
Technical Implementation Guide (what your dev team should build)
If you’re building or revamping an SMB website/app in 2026, implement these “compliance primitives” as product features:
A) Privacy notice + versioning
- Store
privacy_notice_version - Record which version the user consented to (if consent is used)
- Keep an archive of prior versions
B) Consent & preferences center
- A simple preferences page:
- marketing opt-in/out
- WhatsApp/SMS/email channel preferences
- Webhook update to CRM so marketing tools respect opt-outs
C) Data request endpoints (admin + user)
- “Request my data” flow → generates export (CSV/JSON/PDF) securely
- “Delete my data” flow → starts deletion workflow + confirmation
- Admin dashboard to track status + exceptions
D) Retention jobs (automated)
- Scheduled job to delete/anonymize data by policy
- Report: “records deleted this week” + “records pending deletion due to legal hold”
E) Audit logs (for sensitive actions)
Log:
- exports
- permission changes
- bulk downloads
- admin viewing sensitive records
(Keep logs lean; don’t dump full personal data into logs.)
Common DPDP Compliance Pitfalls (SMBs keep repeating these)
-
Treating DPDP like a one-time “policy page” task
Compliance is operational + technical. -
Consent without withdrawal
If users can’t easily opt out, you’re inviting complaints. -
No retention plan
Old data becomes liability. Always. -
Leads scattered across WhatsApp phones and Sheets
You can’t honor deletion/opt-out requests if you can’t even find the data. -
Unclear vendor boundaries
Marketing tools, CRMs, analytics—each is a data processor risk surface. -
No breach playbook
Even a simple plan is better than panic + silence.
A realistic 2–3 week “DPDP readiness sprint” for SMBs (how we run it)
Week 1: discovery + risk mapping
- data inventory + vendor list
- current privacy notice gap analysis
- retention policy draft
Week 2: implement the primitives
- consent logging + opt-out enforcement
- privacy notice update + versioning
- DSAR intake workflow (form + ticket + SOP)
Week 3: security + operational hardening
- access control cleanup (MFA, roles, offboarding)
- audit logs for exports/admin activity
- incident response checklist + staff training
CTA: Want this implemented cleanly (without guesswork)?
Mejona Technology LLP helps SMBs get DPDP-ready with a practical, engineering-first approach—website/app updates, consent + logs, retention + deletion workflows, and security baseline hardening.
Option A: DPDP Readiness Audit (fast)
- data + vendor inventory
- gap report + prioritized fixes
- “minimum viable compliance pack” roadmap
Option B: Done-for-you implementation
- policy + product changes
- consent/opt-out + DSAR workflow
- retention + deletion automation
- access control + audit logging
Book a DPDP Readiness Call: https://mejona.in/contact
WhatsApp us: https://wa.me/918095990277
Email: info@mejona.com
FAQ (good for SEO + real objections)
1) Does DPDP apply if we only collect leads (name + phone)?
Yes—lead data is personal data. You still need notice, purpose limitation, security, retention, and opt-out for marketing.
2) Do we need a cookie banner for DPDP?
DPDP is broader than cookies. You need transparency and consent where required for your processing. If you use trackers/remarketing, disclose it and capture appropriate permissions.
3) We use WhatsApp for sales—what’s the DPDP risk?
The risk is untracked consent, no opt-out enforcement, data stored on personal devices, and inability to delete or audit. Move to a controlled inbox/CRM-linked setup where possible.
4) Can we just copy a privacy policy template?
You can start with a template, but it must match your actual data flows. If it doesn’t, it becomes a liability.
5) What’s the biggest “quick win”?
Retention + opt-out enforcement. Stop storing data forever and stop messaging people who opted out.
