Linking purposes to grounds and notices

A loan app with one notice for everything

A digital lending NBFC in Hyderabad has a single privacy policy linked from the footer of its app. It says the company collects "personal, financial and device information to provide and improve services". In practice the app does at least six different things with that data: KYC checks, credit assessment using bank statements and bureau reports, disbursal and repayment, collections, cross-selling a partner's insurance, and marketing push notifications.

When the product team adds SMS reading to speed up income checks, nobody updates the policy, because it is worded so broadly that it seems to cover everything. When a borrower withdraws consent for marketing, the team cannot say whether that also stops the insurance cross-sell, since both were described in the same sentence. And when a borrower complains to the grievance officer that he never agreed to share data with an insurer, the company cannot show which version of the notice he saw when he signed up.

All three problems have one cause. The company never wrote its purposes down, one by one.

Purpose as the organising idea

Why the Act starts with why

The Digital Personal Data Protection Act, 2023 is built around purpose. You may process personal data for a lawful purpose, and almost every other duty in the Act follows from that. What you collect should be limited to what the purpose needs. How long you keep it depends on when the purpose ends. A new use needs its own justification. The notice you give a person describes the purpose and the specific data it involves.

An organisation without a written list of purposes therefore struggles with the rest of the Act, because the other duties have nothing to attach to. Retention becomes guesswork. Notices stay general because nobody has listed the specifics. An access request cannot explain what the data is used for.

Purpose is also the level at which people naturally think about their work. Nobody in the business says they process personal data. They say they do KYC, run collections, settle claims, run payroll or send a delivery. A register written in those words is one colleagues recognise and can correct.

TrustOS holds each purpose as a record with several things attached to it. The attachments are what make the register something you can operate, beyond a description you keep on file.

What is attached to a purpose

Each purpose in TrustOS links to the categories of personal data it involves, the ground relied on, the retention rule that applies, the team responsible, and the approved version of the notice shown to people.

Those five links answer the five questions that come up most often: what data is involved, on what basis it is processed, how long it is kept, who is accountable and what people were told.

Holding them together matters more than holding each one well. A retention schedule kept apart from the purpose register drifts, because a change to one leaves no visible mark on the other. Linked records move together, and a change to a purpose shows at once as a reason to review everything attached to it.

The link also prevents a specific and common failure. An organisation revises its privacy notice, publishes the new version, and keeps processing for a purpose that the new notice describes differently. Nobody notices, because the notice and the purpose live in different places. When they are linked, the mismatch is visible.

Choosing and recording a ground

The grounds the Act provides

Processing under the DPDP Act rests either on consent or on one of the legitimate uses in section 7. That list is closed. It includes data a person voluntarily gives for a specified purpose without indicating that they object, certain State benefits and services, compliance with law or with a court order, medical emergencies, disasters and breakdowns of public order, and employment purposes, among the situations the Act sets out.

Teams used to the GDPR should note a difference that causes real problems. The DPDP Act has no general ground like legitimate interests, where an organisation weighs its own interest against the person's rights and proceeds if the balance favours it. Processing under this Act either fits a described legitimate use or it needs consent.

In practice a good deal of ordinary commercial processing needs consent in India. Marketing, analytics, profiling and reusing data for purposes unconnected to the original one usually fall on the consent side of the line.

Recording which ground applies is a decision with consequences, and it belongs with someone qualified to make it, such as your legal team or advisers. TrustOS records the decision, the reasoning and who made it against the purpose, so the position can be explained later by someone who was not in the original discussion. The platform keeps the decision; the judgement stays with your people.

Why the ground changes how systems behave

The ground recorded against a purpose decides what the platform does when circumstances change. Getting it wrong leads to wrong behaviour in the systems, on top of wrong paperwork.

Processing based on consent must stop when consent is withdrawn, and the data held only for that purpose then falls due for erasure. Processing based on a legitimate use continues, because there is no consent to withdraw. An employee who asks the company to stop processing his payroll records cannot end that processing by withdrawing something he never gave.

Record consent where a legitimate use applies, and you build a withdrawal path that should not exist and may erase records you were obliged to keep, such as KYC records an NBFC must hold under RBI directions. Record a legitimate use where consent applies, and you keep processing after a withdrawal that should have stopped it.

Where a purpose could rest on either, choose one deliberately, record the choice with its reasoning and build to match. Leaving it ambiguous means the systems behave one way while the documents say another.

Notices and their versions

What a notice must contain

Under the DPDP Rules, 2025, a notice given with a request for consent must make sense on its own, independent of any other information, and be written in clear and plain language. It must give an itemised description of the personal data and the specific purpose, along with the goods or services that processing enables. It must also explain how to withdraw consent, how to exercise rights and how to complain to the Data Protection Board. These duties apply from around 13 May 2027 under the Rules as notified on 13 November 2025; check for later amendments.

Itemised is the word doing the work. A notice that describes broad categories of data and general business purposes falls short, because the requirement is to describe what is actually collected for the consent being asked for. "Personal, financial and device information" fails. "Your PAN and Aadhaar number to verify your identity; your last six months of bank statements to assess your loan eligibility" passes.

That changes what a notice is. It stops being a document a lawyer writes once and becomes content assembled from the data inventory and the purpose register. When a new field is added to a form, the notice for the affected purpose is out of date, and someone has to review it.

The Act also gives a person the option to read the notice in English or in any of the 22 languages in the Eighth Schedule to the Constitution. One purpose may therefore carry a set of notice versions across languages, and TrustOS can hold each of them against the purpose.

Why versions are recorded and kept

TrustOS records the approved notice version attached to each purpose and keeps the earlier versions alongside it. The reason becomes clear the first time someone asks about a past event.

When a borrower consented in 2027, he saw a particular notice in a particular language. If that notice changed later, what he agreed to is set by the version he saw. An organisation holding only the current version cannot answer that question at all.

That is why each consent in TrustOS carries the notice version with it. The consent and the disclosure it relied on are stored as one thing, since separating them weakens both.

Version history also helps with review. Someone checking whether a notice is accurate can see when it last changed, what changed, who approved it and which purposes were affected. A vague question about whether notices are current becomes a specific answer with dates.

Approval as an assigned action

A notice version becomes approved through a step that TrustOS records. The draft goes to the purpose owner as an assigned action, they check it against the purpose and the data categories, and the approval is recorded with their name and the date.

The step matters because notices are often edited by people who are not accountable for them. Marketing adjusts the wording for tone. Product adds a line about a new feature. Both changes are reasonable, and neither has been checked against what the systems actually collect.

Routing notice changes through an approval action puts the check in the path of the change. The edit still happens, after someone has confirmed that the notice still describes the processing accurately.

Retention attached to purpose

Why the retention rule belongs here

The Act ties the life of personal data to the life of its purpose. Data should be erased when consent is withdrawn or when the purpose is no longer being served, unless another law requires it to be kept. Retention therefore belongs with the purpose. The database table is the wrong place to hang it.

Many organisations keep retention rules in a separate schedule organised by system or data type, and that creates a mismatch. One table often holds data collected for several purposes with different periods, and a single rule applied to the table is too long for some of it and too short for the rest.

Recording the rule against the purpose fixes that. In the Hyderabad lender's customer table, data held for collections is kept as long as lending rules require, while data held for marketing is kept only until consent is withdrawn, even though both sit in the same rows.

The platform also records what sets each period, because a rule with no reasoning cannot be defended or revised sensibly. Some periods come from law and some from a genuine business need, and the difference matters when someone asks why data is still being held.

How the rule becomes an action

A retention rule recorded against a purpose stays a statement of intent until something acts on it. TrustOS turns it into scheduled work, creating actions to erase or dispose of data as periods run out, assigned to the owners of the systems concerned.

Where the platform is connected to a system, the action can run inside it and the result is recorded by that system. Where it is not, the action still reaches the owner with the detail they need, and they record what they did. Both routes leave a record.

The guide on executing retention and erasure across systems covers the execution side in detail, including what happens when an action completes in some systems and fails in others. What matters is the link between rule and action. A retention period that nothing enforces is a rule in name only.

What happens when something changes

A change to one thing affects the others

Linked records show their value most clearly when something changes, because a change in one place creates work in the others and the platform makes that work visible.

A new field on a form changes what a purpose collects, which raises a question about the notice. Adding SMS reading to the loan app is exactly this kind of change. Moving a purpose from consent to a legitimate use changes how systems should behave on withdrawal. A revised retention rule changes the scheduled actions. A new purpose for existing data needs its own ground, its own notice and its own retention rule.

When these records sit in separate documents, none of those consequences is visible, and each depends on someone remembering. When they are linked, the change appears as review work assigned to the responsible owner.

That is what keeps a programme current between reviews. Organisations rarely fall out of compliance through one large decision. They drift, one small change at a time, and each change looked harmless because nobody could see what it touched.

The release checkpoint

Most of the changes that matter start in product and engineering work: a new integration, a new field, a feature that collects something the app did not collect before.

A checkpoint in the release process is worth building, and it is a small one. When a change affects what personal data is collected or where it goes, the purpose record, the notice and the data flow entry are updated as part of the change. A single question on the release checklist, asking whether the change alters what personal data you collect or where it goes, catches most of it in a few minutes.

Organisations that skip it pay more later. The alternative is a periodic reconciliation where someone compares the register with the systems and finds a year of undocumented change. That takes weeks and has to be repeated.

The checkpoint also gives the privacy function something it usually lacks: early sight of changes that affect its duties. Hearing about a new data flow while it is being designed is a far better position than hearing about it during an audit.

What this gives you

An answer you can defend for every purpose

An organisation working this way can answer a specific question about any purpose without preparation: what data it involves, what ground supports it, why that ground was chosen, how long the data is kept and on what authority, who owns it, what people were told, and which version of the notice they saw.

Those are the questions a regulator asks, and the ones an enterprise customer asks in a security review. Answering them from a record turns a long conversation into a short one.

It also lets the privacy function see its own coverage. Purposes with no ground, no current notice, no retention rule or no owner appear as gaps, and the question of whether the programme is complete becomes a list of specific items.

Where to start if the register does not exist

Avoid trying to build a complete register before doing anything else. Start with the purposes that carry the most personal data or the most sensitive categories, record those properly with everything attached, and extend from there.

That order puts the most exposed processing under control first, and it teaches you how your own organisation describes its activities. The vocabulary that emerges from the first ten purposes makes the next thirty faster.

The purpose register works alongside the data inventory. Purposes describe what you do with personal data, and the inventory describes where that data sits. Each needs the other, and together they carry most of the weight of the Act.

Checklist

• List purposes in the words your teams use, one per line.
• For each purpose, record data categories, ground, reasoning, owner and retention rule.
• Check that every consent-based purpose has a working withdrawal path.
• Rewrite notices as itemised lists of data and purpose.
• Decide which of the 22 languages your users need first.
• Keep every notice version and link it to each consent.
• Add a personal data question to your release checklist.

The Purposes and notices page shows how the register works in TrustOS.