Linking Purposes to Grounds and Notices

The Digital Personal Data Protection Act 2023 is organised around purpose. You may process personal data for a specified purpose, and almost every other duty in the Act follows from that specification. The data you collect has to be limited to what the purpose needs. The period you keep it for depends on how long the purpose lasts. A new use requires its own justification. The notice you give an individual describes the purpose in itemised terms.

A company that has not written down its purposes therefore cannot meet the rest of the Act properly, because there is nothing for the other duties to attach to. Retention becomes a guess. Notices describe activity in general terms because nobody has listed the specifics. An access request cannot explain what the data is being used for.

Purpose is also the level at which people in a company naturally think. Nobody describes their work as processing personal data. They describe it as onboarding a customer, settling a claim, running payroll, or sending a delivery. Recording purposes in those terms gives you a register that colleagues recognise and can correct.

TrustOS holds each purpose as a record with several things attached to it, and the attachments are what make the register operational and not merely descriptive.

Each purpose in TrustOS connects to the categories of personal data it involves, the processing ground being relied on, the retention requirement that applies to it, the team responsible for it, and the approved version of the notice presented to individuals.

Those five attachments answer the five questions that come up most often. What data does this involve. On what basis are we processing it. How long do we keep it. Who is accountable. What did we tell people.

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

The connection also prevents a specific and common failure. A company revises its privacy notice, publishes the new version, and continues processing on the basis of a purpose that the new notice describes differently. Nobody notices because the notice and the purpose live in different places. Where they are connected, the mismatch is visible.

Processing personal data under the Act rests either on consent or on one of the legitimate uses the Act specifies. Those legitimate uses are a closed list. They include employment purposes, compliance with law and with orders of a court, responding to a medical emergency, and data an individual has voluntarily provided for a specified purpose.

Companies used to working under the General Data Protection Regulation should note a difference that causes real problems. This Act carries no general ground equivalent to legitimate interests, under which a controller weighs its own interest against the rights of the individual and proceeds if the balance favours it. Processing under this Act either matches a described situation or it needs consent.

In practical terms, a good deal of ordinary commercial processing requires consent in India. Marketing, analytics, profiling, and reuse of data for purposes unconnected to the original one all fall on the consent side of the line.

Recording which ground applies is therefore a decision with consequences, and it belongs with somebody qualified to make it. TrustOS holds the decision and the reasoning behind it against the purpose, so the position can be explained later by somebody who was not part of the original discussion.

The ground recorded against a purpose determines what the platform does when circumstances change, and getting it wrong produces incorrect behaviour and not merely incorrect paperwork.

Processing that rests on consent has to stop when consent is withdrawn, and the data held only for that purpose enters the erasure obligations. Processing that rests on a legitimate use continues, because there is no consent to withdraw. An individual who asks a company to stop processing their employment records cannot end that processing by withdrawing something they never gave.

A company that records consent as the ground where a legitimate use actually applies will build a withdrawal path that should not exist, and will erase records it was obliged to keep. A company that does the reverse will continue processing after a withdrawal that should have stopped it.

Where a purpose could rest on either, the answer is to choose one deliberately, record the choice with its reasoning, and build accordingly. Leaving it ambiguous means the systems behave one way and the documentation says another.

The Digital Personal Data Protection Rules 2025 require a notice accompanying or preceding a request for consent to be understandable on its own, written in clear and plain language, and itemised. It has to describe the specific personal data being collected, the specific purpose, the goods or services that purpose enables, and how the individual can exercise their rights and lodge a complaint.

The word itemised carries the weight. A notice describing categories of data and broad business purposes falls short of the standard, because the requirement is to describe what is actually collected for the particular consent being requested.

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

The Rules also require notices to be available in English and in the languages of the Eighth Schedule to the Constitution, which means a single purpose carries a set of notice versions and not just one.

TrustOS records the approved version of the notice attached to each purpose, and it keeps the earlier versions instead of replacing them. The reason shows itself the first time somebody asks a question about a past event.

When an individual gave their consent, they saw a particular notice in a particular language. If that notice has since been revised, the question of what they agreed to is answered by the version they actually saw and not by the current one. A company holding only the current version cannot answer that question at all.

That is why consent decisions in TrustOS carry the notice version alongside them. The consent and the disclosure it rested on are recorded as one thing, because separating them weakens both.

Version history also supports the review process. Somebody examining whether a notice is accurate can see when it was last changed, what changed, who approved it, and which purposes were affected. That trail turns a vague question about whether notices are current into a specific answer with dates.

A notice version becomes approved through a step that TrustOS records instead of assuming. The draft reaches the responsible owner as an assigned action, they review it against the purpose and the data categories, and the approval is recorded with their name and the date.

That step matters because notices tend to be changed by people who are not accountable for them. A marketing team adjusts wording for tone. A product team 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 instead of beside it. The change still happens, and it happens after somebody has confirmed that the notice still describes the processing accurately.

The Act ties the life of personal data to the life of its purpose, and that connection drives the rest. Data is 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 to the purpose and not to the database table.

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

Recording the retention requirement against the purpose resolves that. Data held for a purpose with a three year requirement is treated accordingly, even where it sits in the same table as data held for a different purpose with a statutory ten year requirement.

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

A retention requirement recorded against a purpose remains 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 expire, assigned to the owner of the systems concerned.

Where the platform is connected to a system, the action can execute inside it and the completion is verified. 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 article on retention and erasure in this series covers the execution side in detail, including what happens when an action verifies in some systems and not others. The point to carry from here concerns the connection between rule and action, because a retention period nobody enforces stops being a rule at all.

The value of connected records shows 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 added to a form changes what a purpose collects, which raises a question about the notice. A change of processing ground changes how the systems should behave on withdrawal. A revised retention requirement changes the scheduled actions. A new purpose introduced for existing data requires its own ground, its own notice and its own retention rule.

Where these records sit in separate documents, none of those consequences is visible and each depends on somebody remembering. Where they are connected, the change surfaces as review work assigned to the responsible owner.

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

Most of the changes that matter here originate in product and engineering work and not in the privacy function. A new integration, a new field, a new feature that collects something it did not collect before.

A checkpoint in the release process is therefore 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. The cost is minutes at the point of release.

Companies that skip it pay considerably more later, because the alternative is a periodic reconciliation exercise where somebody compares the register against the systems and finds a year of undocumented change. That exercise takes weeks and has to be repeated.

The checkpoint also gives the privacy function something it usually lacks, meaning early sight of changes that will affect its obligations. Learning about a new data flow while it is being designed puts the privacy function in a different position from learning about it during an audit.

A company operating 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 individuals were told, and which version of the notice they saw.

That is the set of questions a regulator asks, and the set an enterprise customer asks during a security review. Answering them from a record instead of from a discussion turns a long conversation into a short one.

It also gives the privacy function a way to see its own coverage. Purposes with no ground recorded, no current notice, no retention rule or no owner appear as gaps, and that turns the question of whether the programme is complete into a list of specific items.

Companies without a purpose register should not attempt to build a complete one before doing anything else. A workable approach starts with the purposes that carry the most personal data or the most sensitive categories, records those properly with everything attached, and extends from there.

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

The inventory article in this series is the natural companion to this one. Purposes describe what you do with personal data, and the inventory describes where that data sits. Neither is much use alone, and together they carry most of the weight of the Act.

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.