A consent workflow needs an owner at every handoff

A consent workflow can have a clear beginning and still have no reliable owner at its most important moment. The customer makes a choice. A form saves it. An integration sends an update. Then one team assumes another team has applied it.

Assigning a privacy lead does not solve that handoff by itself. The lead may coordinate the work, but someone must own the customer-facing decision, someone must maintain the record, and someone must verify that each destination behaves accordingly.

Separate accountability from operational responsibility

The DPDP Act’s section 8(1) will place accountability on the Data Fiduciary for relevant processing carried out by it or on its behalf. A software supplier or messaging processor does not make the business’s responsibility disappear.

That legal principle needs an operational translation. For every transition, identify the person who can act, the person who can decide an exception and the person who checks completion. These may be the same individual in a small shop. The important point is that the role exists and has a reachable backup.

As of 22 October 2026, these provisions are scheduled for the substantive commencement phase on 13 May 2027. The official commencement notification should be read alongside the Act; the existence of the legislation does not mean every future duty is already active.

Describe a handoff as a small contract

A useful handoff says what the sender provides and what the receiver promises to do with it. “Send preference update to marketing” is incomplete. It leaves open the customer identifier, purpose, effective decision, version, retry behaviour and completion evidence.

For a proposed promotional-preference workflow, the sender might provide an internal customer reference, the affected purpose, the new preference state and an event identifier. The receiver checks that the event belongs to the correct business account, applies the change to the correct records and returns an outcome.

Distinguish receipt from completion. A receiving system may acknowledge a message before processing it. A task may be queued while the next campaign continues preparing. Use explicit states such as received, applying, completed and needs review, with a named owner for each unfinished state.

Avoid treating a timestamp as a full explanation. It matters which action happened at that time and which system observed it. Keep the minimum detail needed to reconstruct the decision.

A hypothetical handoff that goes wrong

Imagine an independent retailer using one system for checkout and another for promotional campaigns. A customer withdraws the promotional choice at the counter. The cashier records the request correctly, and the checkout system sends an update.

The campaign system rejects the update because its copy uses a different customer reference. If the checkout team owns only message delivery and marketing owns only campaign creation, the failure can sit between them.

Give the reconciliation task to a specific operating role. That person should see the mismatch, determine whether the records represent the same customer and resolve it through an authorised process. They should not copy the customer’s full purchase history into a shared chat to ask for help.

Section 6(6) addresses cessation of consent-based processing and causing processors to cease within a reasonable time, subject to processing authorised or required by law. The design implication is to trace the affected purpose through the receiving systems. It is not permission to invent one universal deadline for every integration.

Build a responsibility table people can use

A compact table is often enough to expose the gap:

Transition	Operational owner	Completion evidence
Choice displayed and recorded	Store operations	Correct purpose and notice version
Preference update sent	Integration owner	Delivery result and retry state
Campaign eligibility changed	Marketing operations	Updated eligibility decision
Identifier mismatch resolved	Named reviewer	Documented matching decision
Customer informed	Support owner	Accurate explanation of outcome

Agree the escalation route before launch. What happens when the owner is absent? Who can pause a campaign? Who can authorise a correction? An escalation address without decision-making authority is only another inbox.

Check ownership through a rehearsal

Use fabricated customers and deliberately interrupt one handoff. Ask the team to demonstrate who notices, who acts and what happens to the affected processing while the problem remains unresolved.

Before approving the workflow:

• Give every unfinished state one current owner and a backup.
• Identify which acknowledgements prove receipt and which prove completion.
• Define the evidence required to close each exception.
• Document how processor failures return to the business.
• Review permissions for people who can override a decision.
• Confirm that the customer-facing explanation matches the actual result.

Ownership should survive changes in staff and suppliers. Store the role in the process, then maintain the named person behind it. When a new tool replaces an old one, revisit the handoff contract instead of assuming that an identical screen means identical behaviour.