A practical DPDP readiness plan for a team of five

A team of five cannot run every privacy project at once. It can, however, make one complete customer journey understandable and controlled. That is a useful starting point because the same journey connects notice, purpose, access, vendors, retention and customer requests.

As of 22 October 2026, most substantive DPDP duties are scheduled for May 2027. This is a suggested readiness plan, not a statutory four-week programme. The commencement notification, Act and final Rules provide the legal framework; the sequence below is an implementation choice.

Choose a journey with a clear finish

Imagine a hypothetical five-person business selling custom office furniture. Its journey runs from an enquiry through quotation, payment, delivery and after-sales support. The founder chooses this journey because it touches most customer data without requiring an inventory of every historic file on the first day.

Assign a coordinator who can arrange decisions and keep the work moving. The founder retains responsibility for budget and risk decisions. Sales explains collection, operations explains delivery, finance explains records that must remain, and the technical contact explains systems and vendors. One person may hold several roles, but each decision should still have an owner.

Week one: make the workflow visible

Follow two recent orders. List data items, collection points, systems, exports, recipients and staff access. Record why each item is needed. Ask where information goes after delivery and what happens when the customer does not proceed with a quotation.

The output can be a single shared register. It should distinguish facts from unknowns. “Courier receives address and phone number through an export” is a fact. “Courier deletes the export after delivery” remains an assumption until checked.

Prioritise obvious exposure while mapping. A publicly accessible customer folder or a former employee’s active login does not need to wait for a polished policy. Record the fix and preserve relevant evidence if there may already have been an incident.

Week two: repair the customer conversation

Draft a notice for the enquiry form and a separate choice for optional promotional messages. Test whether the intended reader can identify what is collected, why, and how to withdraw consent or raise a question. Sections 5 and 6 and rule 3 support this preparation.

Then practise withdrawal. Can sales stop a campaign without cancelling a delivery that has another valid reason to continue? Can the team explain necessary retention without implying that withdrawal is pointless? The exercise should expose system dependencies before the customer encounters them.

Do not assume every historic customer needs a fresh opt-in. Section 5(2) has a specific transitional notice approach for prior consent. Review the actual history and purpose rather than launching a blanket re-permission campaign without analysis.

Week three: agree the vendor and retention handoffs

Select the two vendors receiving the most consequential information. Ask what they receive, why, who else accesses it, how incidents are reported and how corrections or deletion instructions are implemented. Review contracts against the actual service rather than collecting a generic “compliant” declaration.

For retention, begin with enquiry, order and marketing records. Identify the purpose, trigger, period, legal reason and system action for each. Reconcile prospective erasure duties with rule 8(3), including at least one year of retention for Seventh Schedule purposes, and applicable sector or accounting rules. Do not invent a tax retention period from memory.

The output is a decision register with unresolved questions clearly assigned. It is acceptable to need specialist advice on one category; it is less useful to hide the uncertainty behind an arbitrary “keep seven years” rule.

Week four: test the programme with three scenarios

Use a customer access request, a wrong delivery address and an exposed spreadsheet. Ask who receives the issue, who verifies facts, who makes the decision and what evidence demonstrates completion. Keep the scenarios hypothetical and use dummy records where possible.

The incident scenario should consider existing CERT-In obligations separately from the future DPDP process. The CERT-In direction has its own coverage and six-hour reporting requirement. A small team needs an escalation path that works outside the coordinator’s working hours.

What the founder should receive

At the end, present the workflow map, revised customer communications, vendor questions, retention decisions and exercise findings. Include three unresolved risks with owners and target dates. Avoid a single compliance percentage that hides the importance of each gap.

Repeat the method for employees, recruitment or another customer channel. The programme becomes credible through tested workflows and retained evidence. Its size should reflect the business, while its decisions remain specific enough that another colleague can carry them out when the usual owner is absent.