DPDP Compliance Checklist for Indian E-Commerce & D2C Businesses

What It Means

Under Section 6 of the DPDP Act, consent has to be free, specific, informed, unconditional, and clear. If consent is coming from pre-ticked boxes, tied choices or hidden opt-out, it does not match the rule. For an e-commerce site that deploys analytics cookies, advertising pixels (Meta Pixel, Google Ads), and third-party chat widgets, every category of cookie that processes personal data needs a distinct consent choice — and that choice must be granular.

Why It Matters

Advertising-dependent e-commerce brands are particularly exposed. Running Meta Pixel or Google Enhanced Conversions without proper consent constitutes processing personal data without a lawful basis. Beyond the regulatory penalty, ad platforms themselves are increasingly requiring proof of consent for signal verification. Non-compliance risks both regulatory sanction and platform restrictions on ad delivery — a double blow to performance-marketing-driven D2C growth models.

How to Implement

• Audit every script on your site using a tag scanner — identify which ones collect or share personal data before any user interaction.
• Split cookie choices into these groups, keeping each one as its own option: Strictly Necessary, Functional, Analytics, and Advertising and Marketing.
• Use a consent management platform like Consiva.ai. Show a banner on the first visit, before any non-essential scripts start running.
• Ensure your CMP blocks non-consented scripts at load time — not just via a visual banner that fires scripts anyway in the background.
• Record consent timestamps, user choices, and the version of your privacy notice shown at the time of consent. This audit log is your proof of lawful basis if questioned.
• Provide an equally prominent opt-out mechanism in your site footer and account settings — making it as easy to withdraw consent as it was to give it, as required by Section 6(4).
• Re-show the consent banner to returning users whenever your privacy notice version changes materially.

What It Means

Section 5 mandates that the Data Fiduciary give a notice to the Data Principal — before or at the time of collecting personal data — that is clear, plain-language, and contains: (a) the personal data being collected, (b) the purpose of processing, (c) how to exercise rights under Sections 12 to 14, and (d) how to file a complaint with the Data Protection Board. Your existing generic privacy policy almost certainly does not meet this standard.

Why It Matters

A non-compliant privacy notice invalidates the consent obtained under it. This is not merely a documentation problem — it means every marketing email sent, every retargeted ad served, and every customer record retained after that notice was used may lack a valid lawful basis. Courts and regulators look at the notice at the moment of consent, not the one on your site today.

How to Implement

Rewrite the privacy policy using plain language. Do not use heavy legal wording. Use clear section titles. Add bullet points. Add a table of contents so readers can jump to what they want quickly.

Put the notices in parts. First, show a short notice at the moment you collect the data. For instance, during checkout, tell the person you need the shipping address to send the order. Also say you need a phone number so you can handle delivery questions. Second, place the full privacy policy nearby so people can read the complete details if they want to.

• List out every single third-party processor you send data to — logistics providers, payment gateways, analytics platforms, remarketing tools, and customer support desks.
• Make sure you've got a dedicated "Your Rights" section with super clear instructions on how to submit Data Subject Requests, including a link to your DSR intake form.
• Update the policy over time and keep older versions too — regulators may ask to see what notice was shown when you first collected the data.

What It Means

Sections 12, 13, and 14 of the DPDP Act give data principals the right to ask for a summary of their personal data and what's happening with it (12), fix any mistakes in their info (13), and wipe their data and withdraw consent (14). The Act expects that these rights should be super easy to exercise — most places say 30 days is a reasonable time to get back to someone with the answer. Rules under the DPDP Act will probably formalize similar timelines.

Why It Matters

E-commerce shops get DSRs all the time — customers asking to delete their account, update their address, or just know what data you've got on file. Without a clear plan in place, these requests get lost in the support queues or get handled in a million different ways — that creates compliance headaches and a seriously bad customer experience. And let's be honest, if you don't even know where to start looking for that customer's data in your CRM, order management system, loyalty program, and email platform then you can't even fulfill a deletion request.

How to Implement

• Build or procure a dedicated DSR intake form linked from your privacy policy, account settings page, and site footer.
• Map every system that holds customer personal data — CRM, OMS, ESP, CDP, helpdesk, analytics, payment logs — so you know where to search when a request arrives.
• Assign a DSR coordinator with a defined SLA and escalation path for complex requests.
• Build identity verification into the intake flow to confirm the requester is the Data Principal before disclosing or erasing any data.
• Log all DSRs — date received, nature of request, steps taken, date completed — as evidence of compliance in the event of a Board inquiry.
• For deletion requests, create a cascade deletion checklist covering all downstream systems including backup snapshots. Document what is retained for legal or regulatory reasons (financial records for GST, for example) and under what authority.

What It Means

India's Computer Emergency Response Team (CERT-In) Directions of 2022 — which remain in force alongside the DPDP Act — require all entities to report cybersecurity incidents to CERT-In within six hours of detection. The DPDP Act additionally requires notification to the Data Protection Board and affected Data Principals of personal data breaches. Effective compliance means being able to detect, assess, and initiate notification within 72 hours of a breach — a very short window for an organisation that has not planned for it in advance.

Why It Matters

E-commerce platforms are high-value targets for attackers — your customer database contains PII combined with purchase history, which is extremely marketable on dark-web forums. A breach response that kicks off with "let's figure out what happened" on Day 1 is never going to hit a 72-hour notification deadline — and the regulators know it. Worldwide, we see that organisations which self-report quickly and can show they've got a handle on the situation get off much easier than those who drag their heels or try to keep it under wraps.

How to Implement

• Enable real-time alerts from your Cloud setup (we're talking AWS GuardDuty, Azure Defender, or the equivalent) and your Web Application Firewall to let you know about any fishy data-access patterns.
• Define breach severity tiers internally — not every security incident is a personal data breach requiring Board notification, but you need a documented decision tree to make that call quickly under pressure.
• Appoint a Breach Response Lead with authority to convene the response team and trigger formal notifications without waiting for multi-level board approval.
• Sort out pre-drafted notification templates for the Data Protection Board, CERT-In, and any data principals who might be affected — that way you can use those 72 hours wisely to investigate and contain the issue, not scrambling around to get a notification written from scratch.
• Run a tabletop exercise on your detection-to-notification pipeline at least once a year to test it out and make sure you'd actually be able to send out a notification if the worst happened — and update your breach response plan with any lessons you learn from it.

What It Means

The DPDP Act treats vendors who process personal data on your instructions as Data Processors. You, as the Data Fiduciary, remain responsible for ensuring that processors handle data in accordance with the Act. This requires a written contract — a DPA — that defines what data the processor can access, for what purpose, retention limits, security requirements, and sub-processor restrictions. Without DPAs, your processors' mishandling of customer data is legally your problem.

Why It Matters

A typical mid-size D2C brand uses 30 to 60 SaaS tools — logistics APIs, email service providers, payment aggregators, customer support platforms, marketing automation, analytics dashboards, and loyalty engines. Every one of these tools that touches personal data of your Indian customers is a Data Processor under the DPDP Act. A single logistics partner that fails to secure shipment data creates regulatory liability for your brand, not just theirs.

How to Implement

• Build a vendor data inventory: list every tool, what personal data categories it receives, and the legal basis for that transfer.
• Review existing vendor contracts for data protection clauses — most legacy agreements predate DPDP and are wholly insufficient.
• Add an extra DPA addendum for every processor that handles personal data for Indian customers. The main parts are: using data only for the stated purpose, keeping data safe under security duties that match ISO 27001 or a similar standard, getting your approval for any sub-processor, telling you about a breach within the set time, and deleting the data when the contract ends.
• Focus first on processors with higher risk. This includes payment gateways and logistics partners. Also include any vendor that can see large volumes of customer records, and those who process sensitive categories — like health data for wellness brands, or financial data when there are BNPL integrations.
• Track DPA renewal dates alongside vendor contract renewals — a lapsed DPA is as problematic as no DPA at all.
• See also: how to map data flows for DPDP compliance.

What It Means

Section 4(1)(b) of the DPDP Act establishes that personal data must be collected only to the extent necessary for the specified purpose. This is the data minimisation principle — a direct constraint on the habit of collecting as much data as possible "because it might be useful later." For online shops, start by checking the parts of the site where you ask for info. Look at the checkout page, the sign-up steps, and any marketing settings page. Remove fields that you do not truly need for the reason you say you are collecting the data.

Why It Matters

Taking too much data can raise your risk. If you do not store a type of data, there is less to lose in a breach. It also cannot be used in ways you did not plan. This can cut down on regulatory worry. It can also lower how much data you have to keep. In many cases, it helps the stored data stay more accurate. Teams that use data minimisation often handle data subject requests faster. They also see a smaller impact when something goes wrong. That helps day to day work and it helps with legal needs.

How to Implement

• Go through each place where data is gathered. Include the checkout form, the account sign-up page, wishlists, loyalty sign-ups, review forms, customer support ticket fields, and exit-intent prompts.
• For each field collected, document the specific processing purpose it serves. If no clear purpose can be documented, remove the field from the form.
• Remove optional fields that add friction and serve no documented purpose — for instance, date of birth on a fashion D2C site with no age-restricted products or loyalty birthday benefits.
• Review CRM custom fields — most brands accumulate dozens of fields over time that no team actively uses or reports on.
• Adopt a data-minimisation review as standard practice for new features: before the engineering sprint starts, ask "what personal data does this feature need, and why?" Make the answer part of the sprint brief.

What It Means

Under Section 8(7) of the DPDP Act, Data Fiduciaries must delete personal data once the reason for collecting it is met. They also have to make sure their processors delete it too. An exception exists when the law says the data must be kept longer. This is a big shift from the old habit of holding onto customer data forever, just in case. You should have a written data retention plan. It must say how long each type of data is stored and what event starts the deletion.

Why It Matters

Some e-commerce brands keep customer records for years, even after there is no clear business need. The same data can be found in live databases, email lists, and backup or offline storage. That kind of stash can turn into a risk if it is exposed. Your retention rules should also cover backups, system logs, and analytics event records, which are often overlooked.

How to Implement

• Set retention by data category: transaction records (order history, invoices) — 7 years is standard for tax and GST compliance; customer PII in marketing systems — 3 years after last purchase is a common rule; cookies & tracking data — 13 months is a good benchmark.
• Document any legal holds that override your standard deletion process — data involved in active litigation, regulatory inquiries, or tax scrutiny needs to be kept until the hold is lifted.
• Automate deletion where possible — most CRM and ESP platforms support automated list suppression and record deletion based on configurable date rules.
• Include your Records of Processing Activities (ROPA) in the retention review cycle — ROPA entries should reflect the actual retention timelines in practice, not just on paper.
• Document and test deletion procedures quarterly, especially for backup and disaster-recovery systems where data persists beyond primary-system deletion timelines.

What It Means

Section 9 of the DPDP Act imposes heightened obligations before processing the personal data of children — defined as persons under the age of 18. The Act requires verifiable parental consent before collecting a child's personal data, and prohibits processing that could cause harm to a child's wellbeing, including tracking and behavioural advertising directed at children. This is a hard legal obligation with significant penalties for violation, not a soft guidance note.

Why It Matters

Many D2C categories — toys, kids' apparel, educational products, gaming, and general fashion — have substantial under-18 user bases. If your site allows under-18 users to create accounts, purchase products, or interact with personalisation features without age verification and parental consent, you are processing children's data without a valid legal basis. Additionally, deploying behavioural advertising pixels without verifying that the user is not a child creates separate exposure under Section 9(3).

How to Implement

• Assess honestly whether your product or category is attractive to under-18 users. If the answer is yes, implement age-gate mechanisms at account creation and checkout flows.
• For verified minor users: disable behavioural advertising pixels and suppress data from being shared with advertising platforms and retargeting systems.
• Build a parental-consent workflow for brands where parents need to approve their child's account — especially relevant for edtech, gaming, and specialist kids' brands.
• Go through your CRM and check for any records with DOBs that indicate someone is under 18 — add some extra protections to those records and get them out of any behavioural marketing segments right away.
• Get your marketing team up to speed on what it's not okay to do — train them on what constitutes targeting kids, and put together a pre-campaign checklist that includes verifying the age of the audience before kicking off any new campaign.
• If you can't do good age verification in your current setup, consider restricting account creation to people 18 and over at sign-up — that's a decent stopgap.

What It Means

The DPDP Act's obligations fall on the organisation as a Data Fiduciary, but data protection failures are almost always caused by people — phishing attacks that succeed because employees click links, customer data exported to personal drives, privacy-invasive product features shipped without a privacy review. A training programme is not a tick-box exercise; it is the primary mechanism for converting legal requirements into consistent employee behaviour across the organisation.

Why It Matters

Regulators globally treat the existence and quality of employee training as a significant mitigating factor in enforcement actions. An organisation that can demonstrate a structured training programme, track completion rates, and show that employees understood their obligations will be treated more leniently after a breach than one with no training record at all. Training also reduces incident frequency — making it a risk-management investment, not just a compliance cost.

How to Implement

• Create role-based training programmes: the all-staff basic training should cover the basics of data protection, phishing awareness and handling customer data right; your marketing team should get training on what consents you need, pixel stuff, and the rules around audience segmentation; the engineers should learn about privacy by design, coding securely, and what data to leave out when developing new features; and your customer support team should know how to handle DSR requests and verify identities before giving any customer info out.
• Run mandatory training at onboarding and annually thereafter, with a short assessment to confirm comprehension — not just completion.
• Use real-world scenarios from your own category — e.g., "a customer calls asking to delete their account; what do you do next?" — rather than generic hypothetical case studies.
• Document completion records and assessment scores. These records become evidence of due diligence in a regulatory inquiry or Board audit.
• Name a Data Protection Point of Contact. This person should handle internal escalations, update the training materials when the DPDP Rules change, and act as the main link if the Data Protection Board needs to be contacted.

What It Means

A Breach Response Plan, or BRP, is the internal guide used right after someone flags a possible personal data breach. It spells out roles and tasks, and it names who should reach out to whom. It also covers how to check what happened, what to do to limit further spread, and the point at which notifications need to be sent. After the incident is over, it lists the next steps too. This is not the same as an IT recovery plan that mainly aims to bring systems back online. A BRP is built for the legal and compliance duties that follow a breach. That includes the 72-hour notification timeline and the need to notify the people whose data was affected.

Why It Matters

When there is no BRP, the response happens in a rush and often under stress. People end up debating ownership of tasks. Legal advice may arrive too late to be useful. Decisions about alerts and messages can drag on. In some cases, the required time window passes and the organization is left exposed. Not notifying adds more risk than most teams expect. It can also worsen trust damage when the public sees a messy and unready effort. A practiced BRP helps keep the response steady, with records and clear steps.

How to Implement

First, set up a breach response group and assign roles in plain terms. Engineering handles containment and evidence collection. Legal or Compliance makes notification calls and stays in contact with the right regulators. Communications prepares messages for customers and any public updates. Customer Support deals with questions from affected users.

• Build a severity matrix. Match each incident type to the notification duties it triggers. Not every security event triggers DPDP Board notification, but you need a documented decision framework to make that determination within 24 hours of detection.
• Pre-draft notification templates for: the Data Protection Board, CERT-In, affected Data Principals by email and SMS, and a holding public statement for media enquiries.
• Establish secure out-of-band communication channels for the response team — if your primary email system is compromised, you need an alternative coordination channel ready to use.
• Run a tabletop exercise simulating a realistic breach scenario at least annually. Update the BRP based on lessons learned from each exercise and from any real incidents.

What It Means

A Record of Processing Activities, or ROPA, is a list kept inside your organisation. It covers every process where personal data is handled. For each entry, the record notes: what kind of personal data is used, why the data is processed, the legal reason for doing it, who is affected (the data subjects), who does the work as a processor, which recipients get the data, whether any data goes across borders, and how long the data will be kept before it is deleted or disposed. While the DPDP Act does not use the GDPR's explicit "ROPA" terminology, the accountability obligations and the Data Protection Board's broad audit powers make an equivalent internal record essential for demonstrating compliance at any point.

Why It Matters

When the Data Protection Board is on your case and demanding evidence of your data-protection practices, your Record of Processing Activities is the one document that shows for sure you've taken the time to get a handle on what you're doing with personal data. For e-commerce businesses, a ROPA usually ends up covering 15 to 30 different processing activities — once you've gone through and documented the ins and outs of things like marketing, logistics, payment processing, customer service and analytics. And let's be honest, trying to build this from scratch when the auditors are breathing down your neck is just plain tough. See our guide on automating your ROPA for DPDP compliance.

How to Implement

• Kick things off with a data-flow mapping exercise — sit down with the people in charge of each business area (marketing, logistics, finance, customer support and IT) and get them to tell you what kind of personal information each of their teams are collecting, using, sharing and hanging onto.
• Use a ROPA template that's been laid out in a way that makes sense, so you can be sure you're capturing everything you need. Consiva.ai generates and maintains your ROPA automatically as part of the compliance workflow, reducing the manual maintenance burden significantly.
• Assign ROPA ownership: each processing activity should have a named business owner responsible for keeping that record current and accurate.
• Review the ROPA quarterly and whenever a new processing activity is introduced — a new marketing channel, a new logistics partner, or a new analytics tool all require new or updated ROPA entries.
• Cross-reference your ROPA against your privacy notice — every processing activity documented in the ROPA should correspond to a disclosure in the notice visible to Data Principals. Gaps in either direction require immediate remediation.

What It Means

A privacy audit is a way to see how well your group handles personal data. The goal is to see if you meet the DPDP Act rules. You should do it at least one time each year. You should also redo it after major changes — think of a big product release, a purchase or merger, moving into a fresh market, or a serious data breach. During the audit, you look at your safeguards. First, you confirm they are in place. Then, you test that they actually work in daily use. You also check whether they still fit your current way of doing business. When the audit ends, you receive findings. Next, you turn those findings into a plan for fixes. The plan names who must handle each item, sets dates to finish the work, and reserves money for the updates.

Why It Matters

Compliance is not a one-time project — it is an ongoing state that requires active maintenance. An e-commerce brand that completed a DPDP compliance exercise and has since launched new product lines, onboarded new SaaS vendors, and migrated to a new customer data platform without revisiting its compliance posture is almost certainly out of compliance in several material respects. The annual audit is the governance mechanism that catches and corrects this drift before it becomes a regulatory problem.

How to Implement

• Schedule the audit on a fixed calendar date with executive sponsorship — not "when we have bandwidth," because that day rarely arrives without a committed schedule.
• Use the 12-item checklist above as the baseline audit scope, supplementing with any Significant Data Fiduciary obligations that apply to your organisation's scale and data volumes.
• Bring in an outside privacy specialist or a well-trained auditor to do the yearly check. Your in-house reviews can help you stay alert, but rule makers usually ask for something that stands on its own.
• Write up the audit results as a formal report. Include a list of issues with risk ratings, and add a remediation plan that has dates and names for who owns each fix.
• Send the findings to your senior leaders or board. Privacy and data handling issues touch the entire company — it is not only a back-office compliance item. When leaders can see the issues, the fixes tend to move faster.
• Find out if your size and how much data you process makes you a Significant Data Fiduciary. If yes, you must meet more duties. This can include having a DPO and running Data Protection Impact Assessments.