Configuring for the data environment you have

The template that almost fitted

A hospital group with four sites in Gujarat starts its DPDP work by loading a healthcare example into its compliance tool. The example is sensible. It lists patient registration, OPD consultations, lab reports, pharmacy billing, insurance and TPA claims, and staff records. It names the usual data categories and the usual vendors: a hospital information system, a lab system, a cloud host.

Three weeks later the privacy lead runs a test. She picks a real patient and asks the team to find everything the group holds about him. The search covers the systems in the template. It misses the radiology PACS bought separately by one site, the WhatsApp Business number the front desk uses to share reports, the spreadsheet of corporate health check-ups that the HR team at a client company sends every quarter, and the copy of last year's billing data sitting on a test server. None of these were secret. They were simply missing from the example, because the example was written for a typical hospital and this group is a particular one.

That gap between a typical hospital and this group is where configuration work begins.

What configuration actually means

The platform describes your company back to you

TrustOS holds records of business services, applications, data stores, processors, personal data categories, processing activities, data movement and responsible owners. Every one of those entries describes something specific about your organisation, so the platform only becomes useful once it reflects what you actually run.

That work is called configuration, and it covers far more than settings. It means recording your services under the names your own people use, listing the systems those services depend on, naming the teams accountable for each, mapping the outside parties who hold data on your behalf, and setting out the purposes you process for, with their grounds and retention rules.

Configuration is also where a compliance platform either fits the company or sits beside it. Software that assumes every company is arranged alike forces you to describe yourself in its terms. Software configured around your company lets you keep your own terms. That matters, because those terms are what colleagues will see when they are asked to confirm something.

A platform configured well reads like a description of the company written by somebody who works there. A platform configured badly reads like a form somebody filled in, and colleagues quietly stop using it because it does not match their world.

The difference depends far less on the software than on how carefully the configuration was done, and by whom.

Why the law makes this matter

The DPDP Act never uses the word configuration, but almost every duty assumes you can describe your own processing accurately. A notice has to list the specific personal data and the specific purpose. A request for access, correction or erasure has to reach wherever that person's data sits. Under Rule 6 of the DPDP Rules, security safeguards include access control, logs and monitoring, and suitable terms in contracts with the processors who handle data for you, which assumes you know who those processors are. Most of these duties apply from around 13 May 2027 as notified, unless amended.

A compliance system that describes a company like yours will produce notices, searches and erasures for a company like yours. The gaps show up only when a real request, a breach or an audit tests them.

The knowledge configuration depends on

Accurate configuration rests on somebody knowing what data sits where and who owns it. Where that knowledge is complete, configuration is a recording exercise. Where it is partial, finding the missing pieces becomes the first phase of the work.

Organisations are often surprised by how partial their picture turns out to be. Systems adopted by individual teams, data flowing to services nobody registered, copies of production data in test environments, exports sitting on shared drives. None of it was hidden, and none of it was written down in one place.

The pattern behind it is ordinary. Somebody needed a tool, found one, paid for it and got on with their work. Nobody set out to keep it off the register, and there was no register to put it on. Multiply that across several years and several teams and the gap between what a company thinks it runs and what it actually runs becomes substantial.

Finding that out during configuration is uncomfortable and useful. The alternative is finding it out during a rights request, a breach or an audit, when the missing systems produce an incomplete answer that somebody then has to explain.

A scoped assessment ahead of configuration establishes how much is known and how much still has to be found. That figure sets the length of the first phase more than any other factor.

Why sector examples help

What a sector example gives you

Organisations in the same industry process similar categories of data for similar purposes under similar regulatory pressure. Two NBFCs both handle KYC documents, bank statements, bureau reports and repayment records. Two hospitals both handle patient records, treatment histories and insurance details.

That similarity makes a sector example genuinely useful as a starting point, in three ways:

• It gives you vocabulary. It supplies words for purposes, a list of the data categories that usually appear and the processors that commonly feature. A team shown twenty typical purposes can correct a list far faster than it can write one from nothing.
• It prompts questions. Seeing "teleconsultation recordings" in a healthcare example may remind a hospital that it started storing video calls last year and never listed them.
• It points to overlapping rules. An example for lending will remind you that RBI directions and record keeping requirements sit alongside the DPDP Act.

Where the example stops being right

Every organisation differs from its sector in ways that matter for compliance. Two hospitals of the same size run different software, bought at different times from different vendors, with different legacy data from past mergers.

Team structures differ too. In one organisation the purpose "insurance claims" belongs to the billing head. In another it sits with a TPA desk inside operations. The purposes may look alike while the systems holding the data and the people answerable for them are entirely different.

Regulatory position differs as well. Two companies in the same sector may sit differently under the Act depending on volume, on whether either has been notified as a Significant Data Fiduciary, and on which other regulators they answer to. A sector example cannot carry any of that, because it belongs to the company and has nothing to do with the industry.

If you adopt the example without correcting it against your own environment, you end up with a platform describing a company that resembles yours. Requests then search systems you do not have and miss the ones you do.

The example is scaffolding. It gives the shape and the vocabulary, and you supply the facts. Treating it as a finished configuration is the most common way this work goes wrong.

Doing the configuration well

Involving the people who know

Configuration done by the privacy team alone produces a picture of the company as the privacy team understands it. That picture is usually accurate at the top and thin underneath. The detail lives with the people who run the systems and do the work.

Getting their time is the practical obstacle, and the way you frame the request decides whether it works. Asking a system owner to "review the data inventory" usually produces silence. Asking them to confirm four specific facts about the one system they own usually gets an answer the same week.

Good questions are short and pointed:

• For a system owner: what personal data does this system hold, and where does it send data?
• For a business owner: why does this activity exist, and what would break if it stopped?
• For procurement or finance: which outside services do we pay for that touch customer or staff data?

Each of those contributions takes a few minutes from somebody outside the compliance function, and together they produce a configuration that is accurate as well as plausible. In TrustOS the confirmations go out as assigned actions to named people, each with a specific question and a due date, so each request reaches a person as a specific question they can answer quickly.

The record of who confirmed what, and when, is worth as much as the content. A configuration nobody can trace back to a source is one nobody will defend when it is questioned.

Use your own names

If your staff call it "the HIS", "the LOS" or "the Tally export", use those names. People confirm records they recognise. They ignore records written in someone else's terms.

Start narrow and extend

Configuring an entire organisation before the platform does anything useful is the approach that most often stalls. The exercise runs for months, the people contributing lose interest, and the configuration ages while it is being assembled.

Configuring one area properly gets the platform working within weeks. That might be the inventory for the systems holding the most sensitive categories, such as patient health records or the loan application flow, or the rights request process, or processor oversight. The area that carries the most exposure today is usually the right one.

Working this way has a second benefit that teams notice afterwards. The first area teaches them how their own company should be described, and the vocabulary that settles there makes every later area quicker to configure.

The scoped assessment sets that sequence, and the guidance on choosing where to begin covers how the order is decided.

Keeping the configuration current

Companies change and configurations stay put

A configuration reflects the organisation as it was on the day it was recorded. After that, the company buys a smaller clinic, switches courier partners, retires an app, moves its CRM, launches a new course or reorganises a team. None of this reaches the platform by itself.

Acquisitions cause the sharpest version of the problem. A company that buys another inherits its systems, its processors, its data and its obligations, often before anybody has mapped them. The acquired environment sits outside the configuration until somebody brings it in, and the obligations apply from the moment the data changes hands.

An outdated configuration is more dangerous than none, because people trust it. A rights request searched against last year's system list returns an answer that looks complete and is missing whole systems.

What prevents the decay is attaching maintenance to the events that cause change: a new system adopted, an integration built, a processor engaged, a service retired, a team restructured. Each of those is a point where the configuration should be updated, and making that step part of how those things are approved costs very little at the time.

Review as assigned work

Alongside event driven updates, periodic review catches the drift that no single event triggers. TrustOS assigns those reviews to the owners of the records concerned, so a system owner confirms their system and a relationship owner confirms their processor.

Spreading the review this way makes it achievable. Twenty owners each confirming two or three entries finish quickly, and the platform shows who has and has not done it.

The completion record then supports a claim you may need to make later. A statement that the inventory is up to date is an assertion. Confirmations with names and dates are evidence.

What good configuration delivers

The platform stops needing translation

When the configuration matches the organisation, nobody has to translate between what the platform says and what they know. A front desk executive handling a patient request sees system names she recognises. An engineer receiving an erasure action sees his own databases listed correctly.

That familiarity decides adoption more than any feature. A system that speaks the company's own language gets used by the people who have to use it. A system that describes an abstraction gets used reluctantly, by the compliance function alone.

It also decides accuracy where it matters. Searches reach the right systems. Erasures reach the right copies. Notices describe what is actually collected. Each of those depends on the configuration being right, and a capable platform cannot make up for a configuration that is wrong.

What to expect from the first phase

A first phase of configuration should end with one defined area working properly. That means the records for that area recorded and confirmed by their owners, the duties in that area turned into assigned work, and evidence building up as the work happens. A complete map of the company is a later goal.

It should also end with a written view of what remains: areas not yet configured, systems with no owner, and questions still open. That list is the plan for the next phase.

Organisations that measure the first phase by how much of the company was mapped tend to be disappointed. Those that measure it by whether one area now runs properly get a truer picture, and a platform doing real work while the rest is brought in.

Checklist

• Load a sector example only as a starting point and mark every entry as unconfirmed.
• List your business services in the words your staff use.
• Ask finance for the list of paid tools and vendors, and compare it with the example.
• Look for the usual missing places: WhatsApp numbers, spreadsheets, test servers, tools bought by a single team.
• Send each system owner a short set of specific questions, and skip the survey.
• Name an owner for every system and every purpose.
• Add a configuration step to new system and new vendor approvals.
• Schedule owner reviews at a fixed interval.

The Data inventory page shows how these records are held and reviewed.