Link each data store to a purpose and an accountable owner

A data store needs someone who can explain why it exists and someone who can operate it safely. Those responsibilities may sit with different people. The engineer who administers a database may not be authorised to decide whether its contents can be reused for a new campaign.

A useful ownership model connects each store with the purposes it supports, the people who make decisions about those purposes and the people who implement the resulting controls.

Name the purpose at the level decisions occur

“Customer data” is too broad to guide a retention or access decision. A shared database may support order fulfilment, dispute handling, account administration and promotional activity. The same field can participate in more than one purpose.

Record those purposes separately where their rules differ. This lets the team distinguish ending a promotional use from retaining a record required for another justified activity.

The DPDP Act’s definition of Data Fiduciary concerns determination of purpose and means. An internal owner register does not replace that legal classification. It helps the organisation identify which people can act for the business when a processing decision is needed.

Avoid treating a supplier’s product label as the answer. A service can support one activity on the business’s behalf and perform a different activity under a different role. Assess the actual arrangement.

Separate three practical responsibilities

The business owner explains the task and approves intended uses. The system custodian understands the technical location, access paths and lifecycle. The control owner checks that the agreed behaviour is implemented and monitored.

In a small organisation, one person may hold more than one responsibility. Record that openly and provide a backup. In a larger organisation, avoid a table full of department names with no one able to make a decision.

For a hypothetical bicycle-rental service, the operations manager may own the booking purpose, the engineering lead may administer the booking database, and a designated reviewer may approve access and retention exceptions. Each should know which decisions they can make.

Ownership should include the authority to stop an inappropriate use, not merely the obligation to answer questions after it has happened.

Give owners information they can use

A store record should identify the data classes, purposes, principal users, external recipients, retention rules and important dependencies. Add links to approved decisions, contracts or procedures where those are needed.

Do not copy every personal record into the inventory. The inventory describes the store and its use. Actual customer information should remain in the controlled system unless a specific review requires access.

A practical owner should be able to answer three questions quickly: who can access this, where does it go next, and what happens when the purpose ends? If the answer requires searching through several disconnected teams, the register has exposed a coordination problem.

NIST’s Privacy Framework supports identifying and managing privacy risk. Use ownership to connect that risk to a decision, a person and a review trigger, rather than treating the completed register as the final outcome.

Resolve a new-use request explicitly

Suppose the hypothetical rental service wants to use booking histories to suggest promotions. The database custodian can technically produce the file, but the request needs review of the proposed purpose, data scope, legal ground and recipients.

Route it to the appropriate decision owner. Record what was approved, what was excluded and which controls are required. If the request crosses several purposes, involve the owners who can assess those parts.

The OWASP Authorization Cheat Sheet recommends least privilege and consistent permission checks. Translate the approved decision into actual access, including exports and administrative routes. An approval email without corresponding technical scope leaves too much to individual judgement.

If the decision changes, make sure the technical permissions and downstream instructions change with it.

Keep ownership current through change

An employee departure, supplier replacement or new export can invalidate an otherwise accurate record. Define those events as review triggers. Do not rely solely on an annual reminder to discover that the named owner left months earlier.

For each important store, check:

• Are its distinct purposes understandable?
• Is there a current business decision owner?
• Is there a technical custodian and backup?
• Can access and retention exceptions reach an authorised reviewer?
• Are recipients and copies documented?
• Do changes trigger an ownership review?
• Can the owner demonstrate one relevant control?

The register should make the next decision easier. A store with five names but no clear authority remains unowned in practice. A small record with explicit responsibilities, current contacts and evidence can be much more useful.