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.
Questions we get asked
Data mapping, answered plainly.
On a mid-sized estate, typically a few weeks end to end. The automated sweep runs in days and takes almost no time from your team. The interviews are usually a short session per function. The time goes into resolving what the sweep and the interviews disagree about, which is where the useful findings live, and into building a record at field-level granularity rather than system level. Estates with many custom applications, several acquired businesses, or a lot of unmanaged operational technology take longer, and we tell you which of those apply after the sweep rather than guessing up front.
It serves the same function and the DPDP Rules do not use that term. Under GDPR, Article 30 mandates a record of processing activities with a defined content list. The DPDP Rules impose no equivalent standalone documentation duty, but they impose several obligations that are impossible to discharge without one: an itemised notice under Rule 3, safeguards proportionate to sensitivity and volume under Rule 6, purpose-limited erasure under Rule 8, and rights responses inside ninety days. So the record is required in practice rather than by name. If you already hold a GDPR-compliant record of processing activities, you are most of the way there and the work is adding the DPDP-specific attributes.
You can, and it is better than nothing. Understand what it will and will not find. A questionnaire inventories what people remember and are willing to write down, so it reliably captures the systems you already knew about and reliably misses dormant mailboxes, test environments seeded from production, old exports on file shares, and SaaS a department signed up for on a card. Those four are where our most serious findings come from. If budget is the constraint, a reasonable middle path is to run the questionnaire yourselves and bring us in only for the automated sweep, which is the part that finds what nobody remembers.
On Microsoft estates, almost always nothing new. Purview content search, sensitive information types, data loss prevention in audit mode and unified audit logging cover the bulk of discovery, and Business Premium and the enterprise plans already include them. We check your entitlements first and tell you what you already own. Where we do recommend tooling it is usually for a specific gap, such as scanning on-premises file servers at scale or classifying data in a database estate, and we say plainly whether it is worth it for your size rather than defaulting to yes.
We map them and help you form a documented position, and we are honest that surgical erasure from backup sets is rarely practical. The reasonable and commonly accepted approach is that erasure applies to live systems, that backups age out on a defined rotation, and that a restored backup has erased records re-applied as part of the restoration procedure. What matters is that the position is reasoned, written down, and actually reflected in your restoration runbook. What does not survive scrutiny is having no position at all, or a policy claiming erasure from backups that your team has never tested and could not perform.
It is the most common serious finding we report, and the severity depends on what is in it and who can reach it. The concern is that test environments almost always run weaker access control than production, sit outside the monitoring and backup regime, and are frequently accessible to contractors and vendors who would never be granted production access. Under Rule 6 that is difficult to defend as proportionate safeguards. The fix is masking or synthetic data for test, which is real engineering work, so the interim step we usually recommend is to lock access down to the production standard and set a date for remediation rather than leaving it open while a masking project is scoped.
It is the difference between a seventy two hour clock you can meet and one you cannot. When a system is compromised, the Board notification requires the nature and extent of the breach and its likely impact, and affected individuals have to be told. Without a map, scoping that starts with working out what was in the system, which takes days you do not have. With a field-level map you know within the hour what categories of personal data were held there, roughly how many individuals, whether any of it was sensitive or related to children, and which processors also received it. That is why we walk your team through a scoping exercise at handover.
Yes. Employees are data principals and the Act does not carve them out. Payroll, HRMS records, attendance including biometric templates, performance records, CCTV footage that identifies people, and the contents of work mailboxes are all personal data you process. In practice employee data is often mapped less carefully than customer data because it feels internal, and it is frequently where the weakest access control sits, with HR spreadsheets on shared drives and attendance appliances outside IT governance. We map it on the same basis as customer data.
One named individual with authority, supported by an owner per store. The named individual is usually whoever holds IT or information security accountability, and in larger organisations it is the Data Protection Officer if one has been appointed. What does not work is ownership resting with a committee or with the compliance function in the abstract, because the map decays through many small changes and needs somebody who notices them. We put a review cadence on something already in your calendar, normally the quarterly access review, so maintenance is not a separate thing anybody has to remember.
You have to know it exists, who holds it, what categories it covers and whether you can reach it, because your obligations do not stop at your own perimeter. You remain the data fiduciary when a processor holds data on your behalf, which means a rights request or an erasure has to be executable across their systems and a breach at their end can be your notifiable breach. What you do not have to do is inventory the internals of their estate. The practical output is a processor register recorded alongside the map: who they are, what they hold, what the contract says about security and about assisting you with rights requests, and how you would actually get an answer out of them inside ninety days. That last column is the one that usually exposes a problem, because plenty of contracts say a vendor will cooperate and very few specify how fast.
Delete it, once you have checked nothing else depends on it and that no statutory retention requirement applies. This comes up in almost every engagement and it is the single cheapest risk reduction available, because data you do not hold cannot be breached, cannot be the subject of a rights request and does not need safeguarding. The usual finds are old exports, superseded copies, test data and records from a business line that closed years ago. The reason it does not happen without prompting is that deletion feels irreversible and nobody wants to be the person who deleted something that turned out to matter. We handle that by staging it: identify, isolate to a restricted location, wait an agreed period with the owner informed, then delete. It converts an uncomfortable decision into a routine one.
Mostly yes. The automated sweep is entirely remote, the interviews work well over video, and the record is built and handed over remotely. The exception is operational technology and physical systems, biometric attendance terminals, CCTV and video management, access control panels and shop-floor kiosks, where a site visit is genuinely more effective than trying to inventory them over a call. We are based in Gachibowli, Hyderabad, and where a site visit adds value we schedule senior engineers to travel with the scope agreed in advance. Initial enquiries get a reply within 4 business hours.
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.
