Mapping the Personal Data You Hold

Almost every obligation in the Digital Personal Data Protection Act 2023 assumes that a company knows where its personal data sits. A request for access requires searching every place that holds data about one person. An erasure requires reaching all of those places. A retention rule has to be applied to specific data in specific systems. A breach report has to describe what data was affected, which means knowing what was there.

A company that cannot answer the question of where its personal data lives cannot meet any of those duties reliably. It can attempt them, and the attempt will be incomplete in ways nobody can measure, because the gap is made of systems that nobody remembered to include.

That is why the inventory is the first piece of work in almost every programme, and why the platform treats it as the foundation that other areas connect to. A notice can only describe what a company knows it collects. A retention schedule can only cover data somebody has listed. An impact assessment can only assess processing that has been recorded.

Few companies have this picture when they start, and they are often surprised by how far from it they turn out to be. Data accumulates over years through decisions made by different people for good reasons at the time, and nobody sets out to lose track of it.

Personal data spreads through ordinary and reasonable activity. A team adopts a scheduling tool that stores customer names. An analyst exports a report to a spreadsheet and saves it on a shared drive. A developer copies production data into a testing environment to reproduce a defect. A marketing team uploads a contact list to a platform for one campaign and never removes it.

Each of those decisions made sense to the person making it, and none of them was recorded anywhere central. The result is a company that holds personal data in places its own privacy team has never heard of, and the discovery usually happens during an incident or a request instead of a planned review.

A second and quieter process degrades the picture as well. A system that was mapped correctly two years ago has since gained new fields, new integrations and new copies. The map is not wrong so much as out of date, and an out of date map is trusted in a way that no map at all would not be.

Both problems have the same practical consequence. When a request arrives, the company searches the places it knows about, returns what it finds, and has no way of knowing what it missed.

TrustOS holds the inventory in layers, because personal data does not sit in one kind of place. The record covers business services, applications, data stores, processors, personal data categories, processing activities, data movement and the person responsible for each of these.

Business services sit at the top because they are how the company describes itself to its own people. Onboarding, claims handling, patient registration, order fulfilment, payroll. Recording these first gives everything else a frame that people recognise, and that matters when you are asking colleagues across the company to help fill in the detail.

Applications and data stores are the systems underneath those services. Each one is recorded with the personal data categories it holds and the person who owns it. Processors are the outside parties that hold or handle personal data on your behalf, and they belong in the same inventory because your duties follow the data to them.

Processing activities describe what the company actually does with the data, and data movement describes how it travels between the places recorded above. Those last two are where companies tend to have the least written down, and they are the two that matter most when somebody asks a specific question.

A common instinct when building an inventory is to list every field in every database. That produces a document nobody maintains, because the number of fields in a working company runs into thousands and changes constantly.

TrustOS records categories of personal data instead. Contact details, identity documents, financial information, health information, employment records, location data, behavioural data. A category is stable enough to maintain and specific enough to be useful, and it maps directly onto the questions the Act raises.

The value of categories shows when the obligations arrive. Whether processing needs a stricter approach depends on how sensitive the data is, and sensitivity belongs to the category and not to the field. A retention rule usually applies to a category. A breach report describes categories. A notice lists categories. Building the inventory at that level means it can be used directly instead of being translated first.

Where a particular field genuinely needs recording on its own, because it carries unusual sensitivity or a specific legal treatment, the platform allows that. The general principle holds that categories carry the work and exceptions are recorded as exceptions.

Every entry in the inventory carries a responsible owner, and this is what turns a list into something operational. An application with no named owner cannot be reviewed, cannot be asked about, and cannot receive an assigned action.

The owner of a system is usually somebody in technology, while the owner of a processing activity is usually somebody in the business. Both matter and they answer different questions. The technology owner can tell you accurately what a system holds. The business owner can tell you why it holds it.

Companies filling in ownership for the first time regularly find systems that nobody claims. That finding is worth having, because an unowned system holding personal data is a risk nobody is watching, and identifying it is among the most useful outputs of the whole exercise.

The first pass at an inventory is usually built by asking people. You go to each team, ask what systems they use and what personal data those systems hold, and record the answers. That gets you a long way without getting you all the way, because people describe the systems they think of and forget the ones they use without thinking.

The second pass is checking. Where the platform is connected to a system, what that system actually holds can be confirmed instead of assumed. Where a connection is not available, the check can still be done by asking the technology owner to confirm against the system instead of from memory.

The gap between the two passes is where the value sits. A team that named four systems in the interview often turns out to be using seven, and the three that went unmentioned are exactly the ones that a later request would have missed.

Neither pass is a one time exercise. The asking establishes the picture and the checking maintains it, and both belong in a cycle instead of a project with an end date.

Certain kinds of location go unmentioned in almost every first pass, and knowing the list in advance shortens the exercise a good deal.

Spreadsheets and exports are the largest single category. Somebody produced a report, saved it, and the file has been sitting on a shared drive since. Testing and development environments are the second, because production data copied for a legitimate technical reason is still personal data. Email attachments and message threads hold a surprising volume of it. Backup copies hold everything the live system held, including data that was later deleted from the live system.

Outside services are the other blind spot. Tools adopted by a single team, often on a card payment instead of through procurement, and holding customer or employee data without appearing in any register. Analytics platforms and support tools are the common examples.

Recording these in the inventory does not oblige a company to keep them. In many cases the right outcome is to remove a copy that no longer serves a purpose, and finding it is the step that makes that decision possible.

A static picture of which system holds what is useful and incomplete. Personal data moves, and the movement carries obligations of its own. Data flowing from an application to a reporting store creates a second copy. Data flowing to a processor puts it in somebody else’s hands. Data flowing between countries raises questions about transfer.

TrustOS records these movements as part of the inventory and not as a separate exercise. Each movement connects the source, the destination, the categories involved and the purpose it serves.

Movements get recorded because questions about them arrive regularly and are hard to answer any other way. Where does this customer data go. Which outside parties hold it. What would we have to tell somebody who asked. A company with the movements recorded answers from the record, while a company without them starts an investigation.

Once movement is recorded, several other pieces of work become straightforward that were previously difficult. An erasure can reach the copies and not only the original, because the platform knows the copies exist. A notice can describe the recipients accurately, because the recipients are listed. A processor review can cover every processor holding a given category, because the connections are there.

Breach response benefits most. When an incident affects one system, the first question is what else was exposed, and the answer depends on knowing what flowed in and out of that system. A recorded set of movements turns that question into a lookup at the point when speed matters.

None of this requires a company to map every movement on day one. Recording the movements involving the most sensitive categories, and the ones that reach outside the company, covers most of the exposure and is achievable in a reasonable period.

An inventory built once and left alone is worse than useless, because people rely on it. A privacy officer working from a map that has not been touched for a year will search the systems it lists and report the search as complete.

Companies that treat the inventory as a project meet this problem reliably. The project finishes, the document is filed, and the company continues changing. New systems arrive, old ones are retired, integrations are added, and none of it reaches the document.

What prevents the decay is attaching maintenance to the events that cause change. When a new system is adopted, when an integration is built, when a processor is engaged, when a service is retired. Each of those is a moment where the inventory should be updated, and building that step into how those things are approved costs very little at the time.

TrustOS handles inventory maintenance the way it handles every other obligation, turning it into assigned work with an owner and a due date. A periodic review of a system reaches the person who owns that system, asking them to confirm what it holds and whether anything has changed.

Distributing the review this way makes it achievable. One person reviewing an entire inventory faces a task large enough to postpone indefinitely. Twenty owners each confirming their own systems face a short task, and the platform shows which of them have done it.

The record of the review carries as much weight as the review itself. Being able to show that each system was confirmed by its owner on a stated date is a stronger position than asserting that the inventory is current, and it separates a claim from evidence.

The immediate return on an accurate inventory is speed. A request for access becomes a search across a known list instead of an attempt to remember. An erasure reaches the copies. A question from a regulator about where a category of data sits is answered from the record.

Speed matters more than it appears to, because several duties under the Act come with time attached. A breach report has a deadline. Requests from individuals have response periods. Work that starts with an investigation into your own systems has less time left for the work itself.

A second return tends to be noticed later. An accurate inventory tends to reveal data that no longer serves a purpose, and removing it reduces both the cost of holding it and the exposure if something goes wrong. Companies frequently find that the exercise pays for itself in storage and licence savings before any compliance benefit is counted.

The inventory is the layer that everything else in TrustOS attaches to, and that is the reason to build it carefully. Purposes connect to the data categories they involve. Notices describe those categories. Retention rules apply to them. Consent decisions relate to purposes that rest on them. Breach records identify which of them were affected. Processor oversight covers the ones held outside the company.

Building the inventory first therefore makes each later area faster to bring in, because the records those areas need already exist. Building a later area first without an inventory means describing data that has not been mapped, and that produces a purpose register nobody can verify.

For a company deciding where to begin, that is the practical argument for starting here. The inventory is the piece of work with the widest effect on everything that follows, and it also answers the question companies find hardest of all, meaning what personal data they actually hold.

TrustOS is a DPDPA compliance platform developed and operated by Code Colonies Private Limited. It gives privacy, legal, security, technology, operations and audit teams a single system for personal data records, purposes and notices, consent and withdrawal, requests and grievances from individuals, retention and erasure, breach response, processor oversight and compliance evidence. Every obligation is connected to a responsible owner, turned into assigned work, tracked through to completion, and left with the records that an audit or a regulatory response will call for.

The platform can be deployed inside infrastructure that you control, and the agreed scope can include source code handover, environment setup, security configuration, technical documentation, integration support and knowledge transfer. A scoped gap assessment establishes your current position, the responsible teams, the priority gaps, the technical dependencies and a practical order in which to implement.

To see the platform or to discuss your requirements, continue to the product overview or start a gap assessment. To learn more about our consulting and engineering work, visit codecolonies.com. To start a conversation, write to us at consulting@codecolonies.com.