Governance and accountability · DP032
A responsibility matrix for privacy work across a small team
Build a practical privacy responsibility matrix for a small team, covering notices, access, requests, vendors and incidents with named owners and backups.
Research cutoff: . This dated explainer is general information; check the linked instruments and your circumstances before acting.

Privacy work disappears between roles when everyone assumes another person owns it. The founder thinks the technology supplier handles deletion. The supplier expects instructions from operations. Operations waits for the founder to decide what may be removed. A responsibility matrix makes that deadlock visible before a customer request arrives.
For a small business, the useful version fits on one page and names people. It should explain who makes a decision, who performs the work and who provides a second pair of eyes. Elaborate job titles do not help if three employees do all the work.
As of 22 October 2026, the main DPDP obligations are scheduled for 13 May 2027 under the commencement notification. The responsibility matrix described here is a recommended preparation tool, not a statutory format or a reason to assume that every company must appoint a Data Protection Officer.
Separate accountability from execution
The Act’s section 8(1) keeps accountability with the Data Fiduciary for processing by it or on its behalf. Assigning a task to a staff member or supplier therefore does not transfer the business’s underlying responsibility.
Within the business, choose one decision owner for each process. That person approves the outcome and resolves uncertainty. An operator performs the steps. A reviewer checks higher-consequence decisions, and a backup covers absence. One person may hold several roles, but the arrangement should acknowledge where independent checking is limited.
A hypothetical six-person online stationery shop might use the founder as decision owner, the operations lead as request operator, an external accountant for retention advice and the application administrator for technical execution. The matrix should identify the actual people and contact routes behind those descriptions.
Start with five decisions that recur
For collection and notices, name the person who approves new fields and purposes. Product or sales staff may propose a change, but someone must check whether the explanation, ground and consent process still fit. Record who can publish the revised screen.
For access, identify who approves permissions and who removes them. Include the person responsible for informing the administrator when an employee or contractor leaves. Otherwise a technically sound access process can fail because the triggering information never arrives.
For individual requests, name the intake owner, verifier, decision owner and system operator. The future rights provisions in sections 11 to 14 require more than a mailbox: the business needs a route from a message to a reasoned outcome.
For suppliers, identify who checks the contract, controls configuration and receives incident notifications. Procurement approval and ongoing administration are separate tasks. A founder who signs an agreement may never see the dashboard where export permissions are granted.
For incidents, appoint a response coordinator and backup with authority to call the right people quickly. Include who assesses reporting obligations and who approves external messages. The future Rules 6 and 7 make safeguards and breach information relevant to this allocation, while existing incident duties need separate attention.
Give each row a trigger and proof
A role without a trigger often remains dormant. “Review access” should become “Review access when a person leaves, changes role or reaches the scheduled review date.” “Update the notice” should identify a new purpose, field, recipient arrangement or material process change as a reason to examine it.
Add the evidence that closes the task. An access removal ends with a confirmed account change. A supplier review ends with an approved contract and configuration record. A request ends with the decision, actions, communication and any justified retention exception.
This detail prevents the matrix becoming a directory of names with no operational effect. It also lets a backup understand what completion means without reconstructing the previous owner’s intentions.
Rehearse absence and disagreement
Run two short tests. First, the main owner is on leave when a customer reports exposure of a spreadsheet. Can the backup find the contacts and act? Second, sales wants to retain a list that operations believes should be erased. Who resolves the issue, using which facts?
Do not give a junior employee responsibility without authority to obtain information or stop an unsafe process. Escalation should lead to a person able to decide, rather than circulate between equal-status colleagues.
Review the matrix when staff, systems or major purposes change. Keep the current version somewhere the team can access during an incident. Its success is measured by fewer stalled decisions and clearer evidence, not by the number of coloured responsibility codes on the page.
A responsibility row that can be executed
Text version of the diagram
- Trigger: Request, change, departure or incident
- Decision owner: Approves scope and resolves uncertainty
- Operator: Performs the agreed system action
- Reviewer or backup: Checks consequences and covers absence
- Completion evidence: Records action, exception and communication
- Trigger → Decision owner: Assign decision
- Decision owner → Operator: Authorise action
- Operator → Reviewer or backup: Check where needed
- Reviewer or backup → Completion evidence: Confirm outcome
- Completion evidence → Decision owner: Escalate unresolved issue
Sources and reading context
These references support the original 22 October 2026 research. Source links and the date above make the scope of this article explicit.
- Commencement notification for provisions of the DPDP Act · Paragraph (c)
Main phase commencement
- Digital Personal Data Protection Act, 2023 · Sections 8 and 11 to 14
Accountability and rights processes
- Digital Personal Data Protection Rules, 2025 · Rules 6 and 7
Security and incident ownership