Chapter 23 — Programme Delivery, Migration and Change Management

1. The distance between a register and a running programme

The register identifies applicable obligations, commencement and uncertainty. The operating chapters identify controls and evidence. Delivery connects them while the estate continues to run. Progress should distinguish designed, implemented, locally tested, integration-tested and independently reviewed scope rather than compress all of those into one “done” flag.

A dependency-ordered plan is useful, but not a universal serial chain. Incident response, source monitoring, governance and safeguards begin immediately in parallel with inventory and purpose discovery. Complete erasure propagation depends on a target/contract map; it does not follow that incident containment must wait for that map to be perfect. The deliverable is a funded, owned operation with explicit gaps, not an attractive completion percentage.

2. The tension: racing the clock versus the discipline of verification

Under the retained commencement schedule, core duties are scheduled for 13 May 2027. The 13 November 2026 tranche concerns Section 6(9), Section 27(1)(d) and Rule 4, not a universal legacy-consent refresh deadline (COMM:49–59; RULES:1005–1010; CORR:28–30).[2][5][6] The dates constrain readiness planning; later instruments and entity-specific applicability still need verification.

• Speed pull. The commencement date is fixed, the board is watching the calendar, and the natural response is to optimise for visible completion: controls declared done, phases closed, the readiness dashboard turned green by definitional fiat. Under date pressure, “done” quietly redefines from tested to built, from built to documented, and from documented to scheduled.
• Verification pull. A meaningful gate needs applicable scope, an appropriate control, relevant observed evidence, a named owner and unresolved limitations. A passed fixture is one input; a missing integration path, legal condition or independent appointment does not disappear because local tests are green.

Failure modes:

• Race to the date. Declaring every task built while excluding untested restore, processor and incident paths can conceal non-readiness.
• Over-verify, under-deliver. Perfecting one easy path while consequential gaps wait consumes the same limited capacity.

Risk-weighted delivery should consider harm, scope, changes and evidence uncertainty alongside statutory exposure. A lower Schedule ceiling does not make an applicable obligation optional. Choose parallel workstreams and hard prerequisites deliberately: the plan should explain what must exist before a specific deployment, what can be investigated alongside it, and which unresolved defects restrict use.

3. From statutory clock to delivery plan

The following author-recommended phases overlap; they are not permission to defer existing legal/sector duties.

The initial breach-notice and detailed-update clocks must be designed from Rule 7 rather than postponed until all rights tooling is complete (RULES:1112–1139).[5] The inventory’s current best affected-person set and its uncertainty should inform response now, with correction as facts improve.

4. The delivery operating model

Owners and RACI. The operating-model discipline: every obligation’s control has a named Responsible and Accountable from day one of its build — not at go‑live. The matrix lives in the programme’s tracker and the Chapter 24 budget; a control without an owner is a task without a home.

Evidence gates. A release requires passed relevant tests plus a review of coverage, legal applicability and operational ownership. “Implemented” describes a scoped state, not legal certification. A failed mandatory gate restricts the affected use; a reviewer cannot approve it simply by changing the denominator.

The dependency backlog. Record dependencies by deliverable. Purpose/ground decisions precede authorising that use; consent capture must produce usable events before withdrawal propagation can be integrated; known processor endpoints and instructions precede verified chain-wide action. In parallel, safeguards and incident response use the best available inventory, and governance funds the unresolved work. Missing inventory is a reason to narrow claims and investigate, not a reason to wait before containing a breach.

Exception authority, named. Business governance can accept eligible operational uncertainty with bounds and expiry. It cannot waive missing lawful authority, prohibited targeting or a binding restriction. Record scope, reason, compensating measures and reopening conditions; Chapter 20’s legal stop gate governs what can be considered at all.

5. Migration: the estate that never stopped running

The cleanest green‑field plan is a fantasy; every real programme begins with an estate in production. Three migration workstreams carry the legacy, and each is a first‑class phase citizen, not an afterthought.

5.1 Legacy‑consent campaign (Section 5(2))

Section 5(2) requires notice as soon as reasonably practicable for prior-consent processing, and permits continued processing until withdrawal. It is re-notice, not an instruction to obtain fresh consent universally or to expire all legacy grants on 13 November 2026 (ACT:182–205).[1] A changed purpose or deficient existing authority is a separate issue requiring its own decision. Track notices due, attempted, delivered, bounced and unresolved without treating silence as new affirmative consent.

Recommended rollout steps are to validate population and channels, prioritise rights/harm and hard-to-reach cohorts rather than just valuable customers, test language access, and keep withdrawal usable throughout. The dashboard can show notice version and purpose-specific state; a one-click design is an internal choice, while comparable withdrawal ease is the legal standard (ACT:225–249).[1] Unreachable principals need owned retry and legal assessment of reasonably practicable steps, not a fabricated statutory refresh date. Delivery attempts are evidence of attempts; a bounce is not successful notification.

5.2 Data migration with governance intact

Migrations — cloud consolidation, platform re‑platforming, vendor moves — must carry the governance attributes with the data: purpose and ground tags, retention windows, processor‑map edges. A migration that drops the purpose tags re‑creates Chapter 8’s unsupported‑reuse problem; a migration that drops retention windows re‑creates Chapter 14’s orphans.

We deepen the migration blueprint:

• Metadata-preserving migration. Reconcile record counts, purpose/authority references, retention classes and processor edges at source and destination. A checksum proves equality only for what was included; validate omitted and transformed fields separately.
• Versioned manifest. Record snapshot time, schema, data scope, transformation, authority frontier and destination. These are proposed design fields, not a delivered migration service or statutory SDPM format.
• Quarantined rollback. A pre-withdrawal snapshot cannot be restored directly into active use. Replay subsequent restrictions before release and verify both the destination and any restored source, including non-primary copies. Restoration is not a way to reset current consent.

5.3 Processor re‑contracting and shadow de‑commissioning

Processor re-contracting and shadow-SaaS investigation proceed alongside technical adapters. The Company’s ENT-004/ENT-005 activities retain their fixed roles and rejected own-use boundary. A valid contract is necessary for the covered processor engagement, but a signature alone does not establish actual cessation or erasure (ACT:330–359).[1]

The proposed processor map records contract version, instructions, endpoints, scope and tested action status. Usage-log comparison can identify unknown services, but does not prove completeness. Legal staff review amendments; no automated pull request can determine statutory grounds or sign a supplier contract. Retired data follows its scoped retention/disposal decision rather than unconditional deletion on decommissioning (RULES:1153–1166).[5]

5.4 Pilot‑to‑Rollout Gate Criteria

A release is evaluated on applicable scope, not a fixture-derived penalty percentage. The recommended hard gates are:

1. Permissibility: every proposed active use has current authority and applicable restrictions resolved. Training without PUR-003 authority and child targeting without an exception remain stopped.
2. Mandatory controls: relevant negative and integration tests pass with coverage evidence; missing processor acknowledgements stay unresolved. A 95% suite average cannot clear the failed remainder.
3. Rights and retention: internal case targets are labelled as such; the published grievance period is separately checked under Rule 14(3). Retention follows Rule 6/Rule 8 and applicable law, not a fictional Rule 14 evidence window (RULES:1101–1104,1153–1166,1308–1311).[5]
4. Operations: named owners, access, retry/escalation, capacity and a rollback path that preserves current restrictions are ready. Known unsafe paths remain excluded until their gates are met.

No “risk-adjusted exposure ≤30%” condition is retained. The board receives individual mandatory failures and the decision they block rather than a reassuring weighted average.

5.5 Legacy re-notice and withdrawal walkthrough

This hypothetical CASE-001 exercise uses the fixed Company’s 100,000 adult registered customers, not a new 3.2-million-customer bank. Not every account is assumed to have the same notice or authority. The migration team first reconciles the eligible prior-consent cohort and unknowns. NOTICE-001 and the separate PUR-001/PUR-002 grants remain those of the dossier; no new consent is inferred from receiving a notice.

For SUB-001, WITHDRAW-001 withdraws optional marketing PUR-002 and must be accepted. The negative test is the later marketing operation, which must be denied by the proposed immediate admission gate. It is not a test that rejects the withdrawal itself. The separate loan-purpose and retention decisions remain scoped; the withdrawal does not retroactively invalidate lawful earlier processing (ACT:232–249).[1]

The local packet deliberately leaves ENT-004’s acknowledgement missing at the illustrative five-minute target. The Company may observe local denial but cannot report chain-wide completion. It freezes the affected rollout, investigates delivery/state reconciliation and retains the unresolved processor row. A subsequent synthetic ACK in the test closes only the simulated action; production completion would require authenticated evidence and scope validation.

Each wave’s recommended evidence bundle contains population definition, notice version, attempt/delivery/failed counts, purpose-specific events, expected-versus-actual test results and remaining actions. Store identifying data under its documented evidence purpose and applicable retention class, not “per Rule 14”. These are specifications for migration operations; the supplied sequential tests do not simulate bulk communication or measured client telemetry.

6. Change management: the discipline that keeps the plan true

Change is re‑verification. Chapter 22’s rule, applied to the programme: any change to a control, purpose, data class, processor, or cross‑border flow re‑triggers its gate before go‑live. The change that bypasses the gate is not agility; it is a new, unverified exposure wearing a deployment ticket.

Regulatory change re‑opens the plan. Chapter 2 §9’s monitoring loop feeds the programme: a notification that moves a register row re‑sequences the affected work — which is why the register, not the Gantt, is the programme’s spine. A programme that must be re‑planned from scratch at every GSR has built the wrong artefact; one that re‑opens the touched rows has built a resilient one.

People and the board. Training lands with each plane’s go‑live (its operators trained on what they now run); the board sees the readiness baseline at Phase 0, the gate status through Phases 1‑2, and the dashboard from Phase 3 onward (Ch.24) — so the board’s picture of readiness is the grid’s picture, not the Gantt’s.

Change‑request lifecycle. We add a lightweight yet auditable process:

1. Submit — a change request (CR) logs the proposed modification, the statutory clause it touches, and the risk weight.
2. Impact analysis — an owner maps the change to purposes, data paths, affected people, legal requirements and tests; an automated dependency tool is proposed, not supplied.
3. Gate rerun — execute the relevant tests against the actual candidate release and retain configuration/version evidence.
4. Approval — the accountable release owner considers legal scope, test coverage, operational capacity and remaining restrictions. Failed mandatory criteria block the affected scope; unrelated lawful work may continue if isolation is evidenced.

This is a review discipline, not a guarantee that every production change is compliant. A green CI suite cannot detect conditions it was never designed to observe.

7. A worked walkthrough

The fictional Company’s delivery work encounters the known missing ENT-004 acknowledgement from EVT-006. Local marketing denial does not establish processor cessation. The PMO can trace the failure to an owned adapter/contract/effect-evidence investigation without claiming that a contract amendment necessarily fixes a technical fault.

In the supplied model packet a deliberately defective cached gate allows marketing after withdrawal, then the repaired gate denies it. The recorded failure and retest are local synthetic observations. This is evidence for the sequential state rule only; the model does not prove production queues, supplier erasure or concurrency. The remaining rollout specification requires actual acknowledgements, late/replay handling and restricted-copy review before closure.

The lesson is that dependencies make a failure actionable, not inevitable success. A contract may be signed while an old export job continues to run. An adapter may return success while a subprocessor is absent from the target map. A mature gate preserves each unknown and asks what observation would close it. It cannot close them all with a new signature or a single successful API response.

8. What remains for the reader and the reviewer

The open items, each <residual>:

1. The legacy‑consent campaign’s sizing — the entity’s actual consent population, channels, and language obligations; the arithmetic is entity‑specific and decides Phase 1’s shape.
2. Sector constraints on sequencing — the Chapter 5 overlays may pull specific rows forward (a regulated entity cannot defer its dual‑clock breach rows past the sector’s own deadlines).
3. The change‑management cadence’s alignment with the Chapter 36 loop — the programme hands the loop a current register and grid at Phase 3’s close, or the hand‑off is a decay risk from day one.
4. Transfer restrictions in the actual estate — identify applicable general/special Government requirements under Rule 15 and any conditional Rule 13(4) specification. Route tags are a recommended evidence design, not a prescribed schema awaiting an asserted amendment (RULES:1287–1290,1319–1323).[5]

The question that hands the book its next chapter

The delivery plan closes with a programme that has built, verified, and handed over a running system — which raises the question every sponsor asks at Phase 3’s door and every CFO asks at every gate: what does this cost, who runs it now, and how do we know it’s working? Chapter 24 takes up Investment Case, Staffing, Metrics and Ongoing Operations — the money and the people behind the loop.

References (sources retained)

• DPDP Act 2023 (Section 5(2), Section 8); Commencement GSR 843(E); Rules GSR 846(E) (Rule 1’s own staging — the second clock the plan carries).
• Operating-model template: out/templates/operating-model/OPERATION_TEMPLATE.md; engineering workpaper: out/templates/engineering/ENGINEERING_EVIDENCE_TEMPLATE.md.
• Chapters 1 (the phases), 2 (the register‑as‑spine), 22 (the gates), 24 (the budget and BAU), 35 (the journey this chapter’s discipline ran), 36 (the loop the programme hands over to).

Source keys and evidence limits

Line locators use newline-based retained text, not PDF page numbers. Primary sources were reread locally; no complete live legal-update search or entity-specific opinion is asserted. Vendor passages are documented claims, not observed capabilities.

• COMM: research/legal/evidence/02_gsr_843e_commencement.txt.
• RULES: research/legal/evidence/05_gsr_846e_dpdp_rules_2025.txt.
• CORR: research/legal/evidence/06_gsr_892e_corrigendum.txt.
• ACT: research/legal/evidence/01_dpdp_act_2023_gazette.txt.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E)

Contents · Reader guide and citation conventions · Artifact index