Data Retention Policies Under DPDPA: How Long Can You Hold Personal Data?

    The DPDPA establishes a clear principle: personal data should not be held beyond the period necessary for its stated purpose. For most Indian businesses, this requires fundamental changes to their data retention practices.

    OneConsentBlog
    6 min read
    Wednesday, 12 August 2026
    DPDPA data retention and compliance concept showing secure personal data management, retention periods, regulatory review, and data deletion for Indian businesses

    If you ask most Indian businesses why they still have customer data from 2016 sitting in a server somewhere, you'll usually get some version of the same answer: "just in case." Nobody quite remembers why it's there, nobody wants to be the person who deletes it and turns out to be wrong, and storage is cheap enough that it's easier to just... not deal with it.

    That approach worked fine when there was no law telling you otherwise. It doesn't work anymore.

    The Digital Personal Data Protection Act, 2023 puts a firm end date on the "keep everything forever" habit. Buried in its provisions is a principle that sounds simple on paper but is going to be genuinely disruptive in practice: you can't hold on to personal data any longer than you actually need it for the purpose you collected it for. Once that purpose is done, or once someone withdraws their consent, the data is supposed to go too.

    For a lot of organisations, this isn't a small policy tweak. It's a rethink of how data has been managed for years.

    What the Act Actually Requires

    Strip away the legal language and the DPDPA's retention rule boils down to three obligations for anyone classified as a Data Fiduciary. First, collect only what you actually need — no scooping up extra fields on a form "for future use." Second, use that data only for the purpose you originally stated, not whatever new idea comes up six months later. And third, once that purpose has been served, or consent has been pulled back, delete the data — unless there's a specific legal reason you're required to keep it.

    It's worth being clear about something here: this isn't a soft recommendation or a best-practice suggestion sitting in some guidance document. It's an enforceable legal obligation, and getting it wrong carries real penalty exposure. Companies that treat this as optional are going to find out the hard way that it isn't.

    So What Counts as "Necessary," Exactly?

    This is where a lot of the confusion is going to live, because "necessary" isn't a fixed number of days or years — it depends entirely on why you collected the data in the first place.

    Take transaction data collected for accounting purposes. That has a legitimate reason to stick around for as long as your statutory audit requirements demand. But contact information gathered for a specific marketing push? That should be gone once the campaign wraps up, or the moment someone withdraws consent — whichever comes first. Behavioural data built up through tracking a customer's activity on your platform shouldn't outlive the customer relationship itself.

    The practical test every business needs to start applying, category by category, is this: what is the specific, documented reason we're still holding onto this piece of data today? If you can't answer that clearly, that's usually a sign the data should have been deleted already.

    Actually Building a Retention Policy

    Knowing the principle is one thing. Operationalising it is another. A retention policy that would actually hold up under DPDPA needs a few concrete pieces:

    • Defined retention periods for every category of personal data you hold — not a vague blanket rule, but specifics per data type

    • A documented legal basis behind each of those periods, whether that's consent, a contractual need, a regulatory requirement, or a legitimate use under Section 7

    • A clear deletion mechanism mapped to each data category and the systems it lives in

    • Named ownership — someone accountable for actually implementing and monitoring this, not just writing it down

    • A periodic review cycle, because what counts as "necessary" today might not be necessary in eighteen months

    Skip any one of these and the policy tends to become a document that exists but doesn't actually do anything.

    Where Sector Regulations Complicate Things

    Here's where it gets a bit tangled for regulated industries. A lot of Indian businesses already have retention obligations baked into sector-specific law, and those don't disappear just because DPDPA exists.

    RBI requires banks and NBFCs to hold onto KYC records for five years after an account closes. SEBI wants investor records kept for eight years. IRDAI has its own retention windows for insurance records, running through the policy period and beyond in case of a lapse. Income tax law generally expects financial records to be retained for six to eight years, and the Companies Act pushes certain corporate records out to eight or even ten years.

    These sector rules do give you a legal basis to retain data — but only for the exact purpose those rules were written for. You can't use "SEBI requires us to keep investor records" as a blanket justification to also keep that same customer's marketing preferences or browsing history sitting around indefinitely. Each retention justification has to be tied to its specific purpose, not stretched to cover everything else in the file.

    The Part Nobody's Ready For: Actually Deleting the Data

    Here's the uncomfortable truth most compliance conversations skip past: writing a retention policy is the easy part. Executing deletion is where things get genuinely hard.

    Personal data doesn't live in one tidy place. It's in your primary database, sure, but it's also in backups, data warehouses, analytics tools, CRM exports, spreadsheets someone downloaded two years ago, and probably a handful of third-party processors you've forgotten you're even sending data to. Deleting it everywhere, reliably and verifiably, is a technical problem most organisations have simply never had to solve before — because until now, nobody was making them.

    Building the infrastructure to delete data systematically is just as important as writing the policy that says you will. A retention policy without a working deletion mechanism behind it is just a document that makes promises your systems can't keep.

    Where This Leaves Indian Businesses

    There's no getting around it — the DPDPA's retention requirements are going to force a lot of uncomfortable conversations about data hoarding habits that have gone unchecked for years. But it's worth zooming out for a second, because the flip side of this is genuinely positive.

    Organisations that actually know what data they hold, have retention periods that make sense, and can execute deletion when the time comes aren't just avoiding penalties. They end up with cleaner, more reliable data, fewer systems cluttered with stale records, and a much lower risk profile overall. Getting this right isn't just about compliance — it's about running a tighter, more trustworthy operation.

    The businesses that start this work now, rather than waiting for a notice from the Data Protection Board, are the ones who'll find the transition far less painful.
    Zence CRM includes data retention policy management tools aligned with DPDPA requirements. Zence CRM

    Frequently Asked Questions

    Have more questions?

    Search our full DPDP knowledge base for more answers.

    See it live

    See OneConsent in action

    Get a personalised walkthrough of how OneConsent helps your teams stay DPDPA compliant.

    • 30-minute walkthrough
    • DPDPA-ready by design
    • Tailored to your stack