You cannot write the notice, honour a rights request or erase anything until you know what personal data you hold.
Data mapping is the least discussed and most load-bearing part of a DPDP programme. The itemised notice Rule 3 asks for is impossible to write without it. A ninety day rights request cannot be answered without it. Purpose-limited erasure cannot be scheduled against data nobody has located. We find the personal data across your estate, including the places it ended up rather than the places it was meant to live, and turn it into a record your team can maintain.
Gates 4 obligationsNotice, consent, erasure, rights
Weeks, not monthsTypical mid-sized estate
Every storeNot just the databases
MaintainableA living record, not a one-off
Where personal data actually lives
The eight places we look, and what we usually find.
Every organisation can name its customer database. The DPDP problem is not the system you know about. It is the eleven copies of an export somebody made in 2022, the mailbox of a person who left, the test environment seeded with production records. These are the stores we sweep, in the order they tend to yield surprises.
Line-of-business databases and applications
The systems you expect: CRM, ERP, HRMS, billing, ticketing, the practice management or dealer management system. Straightforward to inventory and rarely where the risk sits, but they anchor the map because they define the purposes everything else has to be justified against. We record fields rather than systems, because an itemised notice is written at field level and a rights request is answered at field level.
File shares, SharePoint and OneDrive
Where exports go to live forever. Scanned identity documents, payroll spreadsheets, candidate CVs, customer lists pulled for a campaign and never deleted. On Microsoft estates we use the content search and sensitive information type classifiers you already hold entitlement to, which finds Aadhaar-shaped, PAN-shaped and account-number-shaped strings across the tenant rather than relying on somebody remembering where they saved something.
Mailboxes, including the dormant ones
Email is the largest uncontrolled personal data store in most Indian businesses. Identity documents sent as attachments, spreadsheets of customer records forwarded between colleagues, and shared or dormant mailboxes belonging to people who left years ago and were never dealt with. Dormant mailboxes are a recurring finding: still licensed, still holding personal data, and outside everybody mental model of where data lives.
SaaS platforms and vendor portals
Marketing automation, survey tools, e-signature platforms, recruitment portals, chat widgets, analytics. Each holds personal data, each was frequently signed up for on a card by a department rather than through IT, and each is a system you cannot query directly when a rights request arrives. Shadow SaaS discovery is part of the sweep, because a store nobody knows about cannot be mapped and becomes a ninety day problem later.
Backups and archives
The obligation that catches people out. If erasure means erasure, backups holding the erased record are a question you have to have an answer for. The answer is usually a documented position on backup rotation and restoration practice rather than surgical deletion from backup sets, but it has to be reasoned and written down rather than assumed. We record what backups exist, what they contain, how long they persist and what your restoration practice does with erased records.
Test, staging and development environments
Seeded with a copy of production because that was the fastest way to get realistic test data. Almost always under weaker access control than production, frequently outside the backup and monitoring regime, and reliably forgotten in every inventory we are handed before we start. This is the single most common serious finding in our discovery work.
Endpoints and removable media
Local copies on laptops, downloads folders, USB drives in a drawer, and the personal devices of people who do a bit of work from home. This is where the map meets your device management posture, because the practical remediation is usually a policy enforced through Intune rather than a hunt for individual files.
The systems outside IT governance
Biometric attendance terminals, CCTV and video management systems, visitor registers, access control panels, weighbridge and shop-floor kiosks. All of them process personal data, most of them were bought by facilities or HR rather than IT, and almost none of them appear on an IT asset register. Biometric attendance in particular processes sensitive data on hardware that frequently has never been patched.
What we record
The fields that make a map useful rather than decorative.
A list of systems is not a data map. What makes the record load-bearing is that every other DPDP obligation can be answered from it. These are the attributes we capture for each store, chosen because each one is required by something downstream.
What and where
Store name, owner and hosting location
Who is accountable, and whose infrastructure it sits on
Categories of personal data, at field level
Rule 3 requires an itemised notice, which is written from this
Whether any of it is sensitive or relates to children
Drives proportionality under Rule 6 and guardian consent duties
Approximate volume and growth
Rule 6 safeguards are proportionate to sensitivity and volume
Why and for how long
The specific purpose for each category
Not a general purpose. Rule 3 asks for specific
Lawful basis, determined with your counsel
We record it, we do not determine it
Current retention behaviour, as opposed to policy
What the system actually does today
Target retention and the erasure trigger
Rule 8 permits retention only while the purpose is served
Who can reach it
Roles with access, and whether access is attributable
Shared accounts break role-based access control
Processors and sub-processors receiving the data
Withdrawal and erasure have to cascade to them
Cross-border transfers and the destination
Subject to restrictions the government may notify
Whether the store can be queried for one individual
This is what makes a ninety day rights request answerable
How we work
Discovery from evidence, not from a survey.
We search the tenant before we interview anybody
On a Microsoft estate we start with content search, sensitive information types and audit logs, so the first conversation with a department head begins with what we already found rather than with a blank form. That changes the quality of the conversation completely, and it means the map does not depend on anybody memory or candour.
We use entitlements you already hold
Microsoft Purview content search, sensitive information type classifiers, data loss prevention in audit mode and unified audit logging cover most of what discovery needs, and businesses on Business Premium or the enterprise plans already own them. We check what your licences include before proposing any tooling, and in most engagements we propose none.
We record what downstream obligations need
The map is not the deliverable, it is the input to four other obligations. So we capture at the granularity those obligations demand: field level for the notice, per-individual queryability for rights requests, purpose and trigger for erasure, sensitivity and volume for proportionate safeguards. A map that cannot answer those has to be redone.
We stay on our side of the line
We record the lawful basis your counsel determines. We do not determine it. We find and describe the data, its purposes, its flows and its controls, and we hand your legal advisers a factual foundation they can reason from. Vendors who blur that boundary tend to be selling a document rather than an inventory.
What discovery turns up
Findings by sector, from engagements we have run.
Every estate is different and the pattern of surprises is remarkably consistent within a sector. These are the findings we expect before we start and usually confirm.
Healthcare and diagnostics
Report exports on shared counter machines, patient data in departmental spreadsheets outside the practice management system, and a retention position that has never been reconciled with clinical record requirements. Counter accounts shared between shifts make access unattributable.
BFSI and fintech
Generally the tidiest production systems and the messiest peripheries. KYC document stores outside the core system, test environments seeded with real customer records, and analytics extracts sitting in a data warehouse under different access control from the source.
Retail and consumer
The largest volumes and the weakest provenance. Loyalty databases merged from multiple sources, marketing lists whose consent basis nobody can evidence, and point-of-sale systems capturing phone numbers with no defined purpose or retention.
Manufacturing and logistics
Biometric attendance terminals holding template data on unpatched appliances, contractor records held by a labour contractor rather than by you, and vehicle telematics tracking named drivers, which is personal data whether or not anybody has treated it that way.
Education
Student and parent data across a student information system, a learning platform, a fee gateway and a communications app, with no single view. Children data by definition, so guardian consent and the profiling prohibition attach to all of it.
GCCs and SaaS
Sophisticated engineering practice, and personal data flowing through logging and observability pipelines nobody classified as a data store. Application logs capturing identifiers, error traces carrying payloads, and support tooling with broad read access are the recurring finds.
From real engagements
What the sweep turns up that the questionnaire missed.
These are anonymised versions of findings from discovery work we have run. They are not exotic. They are the same four or five patterns in different clothing, which is exactly why an automated sweep beats asking people what they think they have.
Financial services
Challenge
The inventory handed to us listed nine systems holding customer data. The staging environment was not one of them, because nobody thought of it as holding data, only as running code.
What we did
The sweep found a staging database seeded from a production snapshot taken during a release eighteen months earlier, reachable by the whole engineering team and two outsourced development partners, outside the monitoring and backup regime.
Outcome
Access cut to production standard within a day, and a masking project scoped for the next quarter with a documented interim position covering the gap.
Healthcare group
Challenge
Confident that patient data lived only in the practice management system, on the reasonable grounds that this is what the system is for.
What we did
Content search across the tenant found scanned identity documents and report exports in three shared mailboxes, two of them belonging to clinicians who had left, still licensed and still receiving mail.
Outcome
Dormant mailboxes exported and closed, a shared mailbox review added to the leaver process, and counter accounts moved off shared credentials.
Consumer brand
Challenge
Marketing owned a customer list and could not say where it had come from, which is a provenance problem before it is a technology problem.
What we did
Expense and sign-in evidence surfaced four marketing and survey platforms nobody in IT knew were in use, each holding a copy of overlapping customer data, none of them in any contract register.
Outcome
Two platforms retired, two brought under contract with processor terms, and procurement hooked into the map so a new tool registers at purchase.
Manufacturing
Challenge
IT governance stopped at the office network. Everything on the shop floor was treated as somebody else problem, which is a common and understandable division that the Act does not recognise.
What we did
Biometric attendance terminals across three plants were found holding template data on appliances last patched several years earlier, with a default administrative credential and no usable log output.
Outcome
Terminals segmented onto their own network, credentials rotated, vendor engaged on firmware, and the estate added to the asset register for the first time.
Two ways to do this
Questionnaire-based mapping against evidence-based discovery.
Most data mapping sold in the Indian market is a questionnaire circulated to department heads. It is fast, it is cheap, and it inventories what people remember rather than what exists. The difference matters most in exactly the places that carry the most risk.
Feature
Dimension
Questionnaire-based
Evidence-based discovery
What it finds
Systems people remember and are willing to mention
Systems people remember, plus the ones they forgot and the ones nobody owns
Dormant mailboxes and old exports
Missed almost always
Found, because the tenant is searched rather than surveyed
Test environments with production data
Rarely disclosed, because nobody thinks of it as a data store
Found and flagged as a priority finding
Shadow SaaS
Invisible by definition
Surfaced through sign-in, expense and network evidence
Field-level detail
System-level at best, so the notice cannot be itemised from it
Field-level, so Rule 3 notice and rights responses come straight off it
Effort on your team
Low for us, high for your department heads
Higher for us, lower for your team, and we validate findings with them
Useful during a breach
Tells you which systems might be affected
Tells you what data was in the affected system and whose
A map that is not maintained is worse than no map.
A data map produced for an assessment and filed is accurate for about a quarter. New SaaS gets signed up for, a department starts a new process, an integration begins syncing to somewhere new. When the record is stale but believed, it produces confident wrong answers to rights requests and confident wrong scoping during a breach. We build the maintenance into the handover rather than leaving it as an intention.
A named owner per store, so drift has somebody to notice it
A review cadence tied to something that already happens, usually the quarterly access review
Procurement hooked in, so a new SaaS tool registers on the map at purchase rather than at the next audit
Joiner-mover-leaver linked to the map, because departures are when dormant stores are created
The engagement
Four stages from nothing to a maintained record.
1
Automated sweep of the estate
Content search and sensitive information type classification across the tenant, audit log analysis to see which systems are actually being used, sign-in and expense evidence to surface SaaS nobody registered, and an inventory of mailboxes including dormant and shared ones. This runs before we take up any of your team time.
2
Structured interviews against what we found
Short sessions with each function, starting from the evidence rather than a blank questionnaire. The purpose is to establish why data exists and what the intended purpose is, to identify the stores automation cannot see, the biometric terminal, the visitor register, the vendor portal, and to assign an owner to each store.
3
Build the record and flag what needs action
Every store documented against the attribute set, flows between systems and out to processors drawn, and a findings register produced with severity. Typical priority findings: production data in test, dormant mailboxes still holding records, stores that cannot be queried per individual, and retention that runs forever with no trigger.
4
Hand over with maintenance built in
Owners named, a review cadence attached to something that already happens, procurement hooked in so new tools register at purchase, and joiner-mover-leaver linked so departures do not silently create new dormant stores. Then we walk your team through answering a rights request and scoping a breach from the record, because those are the two moments it has to work.
The sweep runs before it costs your team any time, and the findings are usually the most useful hour of a DPDP programme. Tell us roughly what your estate looks like and we will tell you what discovery would involve. Remote-first from Hyderabad, serving all of India.
