Know What Personal Data You Hold, Who Can See It, and What Happens If It Leaks

India’s Digital Personal Data Protection Act, 2023 is law, and the Digital Personal Data Protection Rules, 2025 set out how it works in practice. Under those Rules, duties such as the privacy notice and security safeguards take effect in May 2027. A shorter timeline has been proposed, so confirm the current date with your lawyer rather than relying on any date on a vendor’s website, including ours. The practical advice is to build for those duties now, because mapping data, fixing access and adding retention take months and cannot be done in the last fortnight.

No, and be careful with anyone who says they can. Compliance is a legal conclusion about your business, drawn by your lawyer, and it depends on decisions only you can make about purposes, retention and risk. What we can do is engineering and evidence: map what you hold, cut what you do not need, build consent records, access roles, retention and logging, write the breach runbook and document the decisions. That is what a regulator, a customer or a court would look at. The word compliant is not ours to give.

Find out what you hold. Almost every business underestimates it, because personal data is not only in the CRM. It is in exported spreadsheets, shared drives, an old enquiry inbox, WhatsApp groups, a marketing tool somebody connected once, backups and a former employee’s personal Google account. Until that map exists, every policy is guesswork and every control is applied to the wrong place. The mapping usually also produces the quickest wins, because it turns up data you can simply stop collecting or delete.

Ask your lawyer, because the position depends on rules about transfers outside India and on your own sector. Banking, insurance, health and payment businesses often have sector rules that bite harder than the general law. What we can tell you is the engineering side: which of your systems and vendors currently store data outside India, what the options are for hosting in an Indian region, and what moving would cost and break. We put that in the report so the legal decision is made with the facts in front of it.

Act, then tell. The Rules require that affected individuals are informed and that the Data Protection Board is notified, within the timelines the Rules set, so this is not something to work out on the night. Practically, the runbook we write names who is called first, what gets isolated or shut off, what evidence is preserved before anyone starts fixing things, who signs off the notification and what gets recorded. Preserving logs matters more than people expect, because a team in a hurry often destroys the evidence of what happened while trying to stop it.

Not for everything, and the distinction matters. Sending an invoice, a delivery update or a service notice to a customer you are already dealing with is different from marketing to a list. Consent has to be specific, informed and withdrawable, and the withdrawal has to actually work, which is where most businesses fail: the opt-out sets a flag and the next campaign is sent from an exported sheet anyway. We add consent capture with purpose and date, and test that withdrawal removes the person from the real sending list.

Only as long as the purpose you collected it for lasts, plus whatever a separate law requires you to keep. Tax, company and sector rules often force you to retain invoices and financial records for years, and those requirements win. The data that usually has no justification is the accumulated middle: enquiries from six years ago, candidates who never joined, closed accounts nobody will service again. Your lawyer sets the periods. We implement them as jobs that run on schedule, and report what was removed.

Backups are the honest hard part and anyone who waves it away has not implemented this before. You cannot practically reach into an encrypted backup from last March and remove one person. The workable approach is to set a backup lifecycle so old copies expire on a defined schedule, keep a record of erasure requests, and re-apply them if a backup is ever restored. That position is written down rather than left unsaid, because it is exactly the question you will be asked after an incident.

Whether a formal appointment is required depends on how the law classifies your business, and that is a question for your lawyer. What every business needs regardless is a named person who actually owns this: who receives requests from customers, who is called when something goes wrong, who reviews access every few months and who keeps the data map current. In most small and medium businesses this sits with an owner, a finance head or an operations head rather than a new hire.

It follows how much you hold and how spread out it is. An assessment for a business with one system, a website form and a few hundred customers is modest work. A clinic group with three branches, scanned documents, an old application and years of accumulated records is a different scale. The main drivers are the number of systems to map, how much data is unstructured, how much has to be built rather than configured, whether an existing application needs re-engineering, and whether ongoing review is included. We quote after the discovery, so the number reflects what we found.

Yes, and it usually goes better that way. We take the technical side: what exists, what is exposed, what can be built and what it would cost. They take the legal positions: purposes, lawful basis, retention periods, contractual terms with vendors and what has to be notified. Our report is written to be handed straight to them, with the technical findings stated plainly and the legal questions marked as legal questions rather than answered by us.

Size does not exempt you, but it does change what is proportionate. A ten-person firm holding company contacts and purchase history has a genuinely small problem and should spend accordingly: tighten who can log in, remove fields nobody uses, write a short notice, and stop. A ten-person clinic holding patient histories and scanned IDs has a real one. The mistake is assuming smallness makes you invisible, because most incidents at this size are not attacks at all but an employee leaving with the customer list or a shared drive nobody ever reviewed.

During the build, always, because the difference in cost is large. Consent fields, role-based access, audit logging, masking and retention are cheap when they are designed with the screens and expensive when they are retrofitted into a system already holding live records and habits. Retrofitting also means migrating data into new structures and retraining staff who have learnt the old permissions. If you are commissioning software now, this is one of the few places where spending earlier genuinely costs less overall.