Chapter 26 — McKinsey and Big Four Approaches
1. Buy a work package, not a reputation
A board can reasonably seek outside help without surrendering ownership of the programme. The useful distinction is between the consultant’s method and the enterprise’s legal position. A method supplies questions, workshops, sequencing and specialist capacity. It does not decide which processing activities the enterprise actually conducts or relieve it of responsibility for processing undertaken on its behalf. Section 8(1) places that responsibility on the Data Fiduciary irrespective of an agreement to the contrary.[1] (Act, lines 330–337.)
The procurement question is therefore not whether McKinsey or a Big Four firm “does DPDP.” It is which evidenced approach helps solve the client’s particular delivery problem, what the contract must add to the public description, and who will operate the resulting controls. This chapter compares McKinsey, Deloitte, PwC, EY and KPMG at that level. The comparison is asymmetric because the retained evidence is asymmetric: a general operating-model publication is not the same object as a DPDP service catalogue. Neither is proof of successful implementation.
Use three columns in an engagement decision: documented approach, author-proposed adaptation, and unverified delivery commitment. Keeping those columns separate permits useful synthesis without inventing a ranking. The nine retained firm sources numbered 3–11 establish publications, service families and programme labels. They do not establish comparable prices, consultant availability, client outcomes, technical benchmarks or the contracting legal entity behind each brand. A firm’s silence in these pages means “not established here,” not “not offered.”
2. Five different starting points
The source numbers below resolve to exact retained files in the source notes. Line ranges count newline characters, not PDF pages or visual wraps. The enterprise deliverables and selection implications are author recommendations; the named labels and components are first-party source claims.
| Firm and exact label | Documented components and specificity | Proposed enterprise deliverable | Delivery unknown and selection implication |
|---|---|---|---|
| McKinsey — Organize to Value approach in What is an operating model and why does it matter? | Twelve interacting operating-model elements; generic, not a DPDP product.[11] Lines 71–97. Its consumer-data article separately proposes data mapping, operations, infrastructure and customer-facing practices.[10] Line 77. | Decision-rights design, service ownership, capacity allocation and an escalation model tied to the processing register. | Request a DPDP translation, named implementation team and technical handover; use the approach when organisational fragmentation is the bottleneck, not as evidence of a ready consent engine. |
| Deloitte — India’s DPDP Rules 2025: Leading digital privacy compliance and #DeloitteIndiaDPOForum | DPDP-specific publication and practitioner programme; roadmap separates “Do now,” “Do next,” “Do later” and ongoing operations.[4] Lines 11–17, 97–129. The Act page is a readiness publication.[3] Lines 11–33. | Dependency-aware readiness plan linking governance, notice redesign, logging, rights, retention and assurance to owners. | The programme label is not proprietary software. Ask for deliverable examples, dependency logic, staffing and current legal mapping before treating the roadmap as a delivery proposal. |
| PwC — Cybersecurity and Privacy, Information governance & privacy, Cybersecurity & privacy managed services | Generic service family explicitly spans information strategy, implementation and recurring operations; a separate DPDP briefing helps clients interpret business implications.[6] Lines 171–189.[5] Line 105. | Information-governance backlog joined to existing security controls, plus a transition-to-operations plan. | Which privacy activities are included in managed services, with what authority and tooling? Worth investigating where the client needs the security/privacy operating seam resolved rather than another standalone policy assessment. |
| EY — Data Protection and Data Privacy Services, plus India’s data privacy shift: Steering the DPDP compliance and readiness | Generic acquisition-to-disposal and incident-remediation services, paired with DPDP readiness guidance covering cross-functional awareness, mapping, consent, rights, grievances and simulations.[7] Lines 45–58.[8] Lines 107–145. | Lifecycle control assessment and a training/operations work package that includes business owners rather than only legal and technology teams. | Request the assessment method, technical assets, staffing and ongoing support scope. The linked survey/publication is not a customer-specific readiness measure or a software implementation specification. |
| KPMG — Digital Personal Data Protection (DPDP) Advisory Services | Explicit DPDP Act/Rules consulting and implementation-support catalogue: strategy, readiness, rights/consent, technology enablement, training, platform-led operations, managed services and third-party risk.[9] Lines 102–138. | A service catalogue and responsibility matrix covering design, implementation support and operation of selected privacy activities. | Ask which platform, connectors, SLAs and artifacts are actually included. The specificity supports a scoped request for proposal; it does not demonstrate broader capability than competitors. |
The strongest defensible contrast is what each source lets the buyer ask next. McKinsey’s material supports organisational design questions. Deloitte’s supports sequencing questions. PwC’s supports questions about the bridge from information governance into managed operations. EY’s supports lifecycle and cross-functional readiness questions. KPMG’s catalogue supports decomposition into named DPDP service packages. These are differences in the captured material, not exclusive competences of the firms.
A further distinction is important for EY. Its readiness article reports a survey, but this chapter does not convert the reported percentages into an estimate of the Company’s maturity or a probability of programme success. The retained page identifies respondents and reported findings, not a benchmark run against CASE-001.[8] Lines 107–134. Similarly, the benefits discussed in McKinsey’s operating-model article cannot be booked as DPDP savings in Chapter 24. Borrow the diagnostic method; do not import an unrelated outcome estimate.
3. Translate a framework without confusing its vocabulary
McKinsey’s twelve elements provide a useful worked translation precisely because they are not privacy controls. The source names purpose, value agenda, structure, ecosystem, leadership, governance, processes, technology, behaviors, rewards, footprint and talent.[11] Lines 73–93. The following is the author’s adaptation to the fictional Company’s CASE-001, not a McKinsey DPDP method or engagement result.
| Framework element | CASE-001 design question and resulting artifact |
|---|---|
| Purpose | Why does the enterprise provide the service? Keep this organisational purpose separate from PUR-001 loan processing and PUR-002 optional marketing. Produce a purpose vocabulary note. |
| Value agenda | Which customer outcomes and service constraints warrant investment? Produce an investment backlog that cannot trade away applicable legal floors. |
| Structure | Who owns SYS-010 authority events, SYS-011 rights cases and SYS-013 processor execution? Produce a service ownership map. |
| Ecosystem | What must ENT-004 and ENT-006 do, and what remains the Company’s task? Produce processor interface and escalation schedules. |
| Leadership | Who can stop an unauthorised marketing release? Produce named stop/restart decision rights. |
| Governance | How are exceptions and unresolved evidence escalated? Produce a decision log with expiry and review ownership. |
| Processes | What happens between WITHDRAW-001 and a verified downstream restriction? Produce an operating runbook including missing ACK-001. |
| Technology | Where are trusted authority decisions enforced? Produce a control-to-system map with bypass and restore paths. |
| Behaviors | Do operators preserve a failed acknowledgement or close the ticket to meet a target? Produce failure-reporting guidance. |
| Rewards | Does a closure metric encourage concealing exceptions? Produce a balanced service scorecard, not a paid-on-green dashboard. |
| Footprint | Where are operational staff and support paths located? Produce an access/location schedule, distinct from a legal transfer determination. |
| Talent | Which skills and backup operators are funded? Produce a workload-based capacity plan linked to Chapter 24. |
This translation exposes a concrete organisational defect: an event ledger may have an engineering owner while no one owns reconciliation with the marketing processor. Changing reporting lines alone will not close that defect. The acceptance artifact must identify the reconciliation operator, authority to restrict the affected route, evidence location and recovery conditions. That is a meaningful operating-model outcome even before software changes begin.
A Deloitte-style phased roadmap then asks when those artifacts must exist. Its published “later” bucket includes rights automation and retention engines.[4] Lines 115–129. The author’s adaptation would start manual rights servicing and retention decisions earlier, while automating them later; a sequencing label is not permission to leave an applicable duty unserved. Governance, incident readiness and inventory discovery can proceed in parallel. A dependency is a required input to a specific deliverable, not a reason to wait for every other workstream.
Legal dates must be independently anchored. The retained notification places core Act provisions in an eighteen-month tranche; Rule 1 has separate Rules tranches, and the corrigendum changes the publication wording.[39] Lines 49–59.[40] Lines 1005–1010.[41] Lines 25–38. Under this book’s retained baseline the core date is 13 May 2027. The Deloitte page prints 12 May 2027 in its phase table; this chapter uses its method, not that date as authority.[4] Lines 83–93. CASE-001’s later events assume the retained scheduled provisions commence unchanged; they are not evidence of future law or operational Board infrastructure.
4. Two clients, two procurement decisions
Both situations are hypothetical selection exercises. No named firm submitted a proposal, quote or successful test.
Client A is CASE-001: a 200-person fictional NBFC with engineering capacity but fragmented ownership of withdrawal, rights and processor follow-up. Its first purchase should be a bounded operating-model and handover engagement, not automatic replacement of every existing tool. The McKinsey framework is useful for diagnosing decision rights; Deloitte’s roadmap is useful for converting the diagnosis into delivery dependencies. Neither publication establishes that its publisher can supply the exact implementation bench needed. Client A therefore uses the adaptations to define the scope and invites evidence for that scope from eligible providers rather than declaring a publication winner.
The proposed output is deliberately small: an approved service map; the WITHDRAW-001 runbook; a scenario in which ACK-001 is missing and the case remains unresolved; an operator handover; and a costed backlog for unimplemented interfaces. The client evaluates whether its own operator can explain why marketing remains stopped after a stale grant arrives. If only the consultant can interpret the diagram, knowledge transfer is incomplete. A polished framework with no executable ownership arrangement does not pass this engagement’s acceptance gate.
Client B is CASE-101, a fictional retailer with established security infrastructure but insufficient privacy-operations staff. It has a different purchase: a staged managed-operations service with explicit interfaces into existing security and commerce teams. KPMG’s named privacy managed services and platform-led operations, and PwC’s information-governance/managed-services combination, are source-supported reasons to investigate those delivery models.[9] Lines 128–138.[6] Lines 171–189. EY’s lifecycle and incident-support description is another relevant starting point, especially if the work includes business-team training and remediation of acquisition-to-disposal handoffs.[7] Lines 45–58.[8] Lines 136–145.
The retailer does not infer that these firms have identical coverage. It requests the shift roster, permitted data access, tool dependencies, exception handling, monthly workload assumptions and ownership of customer communications. Its award hypothesis differs from Client A’s because recurring operating capacity is missing. Even a lower-priced assessment-only proposal would not solve that problem. Conversely, Client A should not buy indefinite managed operations merely because they are bundled with the framework.
For both clients, legal permissibility precedes price. A retailer cannot buy an assessment signature to legitimise targeted child advertising absent an applicable exemption. Section 9 separates verifiable parental consent from the prohibition on tracking, behavioural monitoring and targeted advertising; specified exemptions have conditions.[1] Lines 386–403.[40] Lines 1269–1275. The acceptance exercise should include a refused campaign, not only a successful implementation story.
5. Engagement and independence boundaries
There are three useful engagement models; they should appear once in the statement of work rather than as repeated generic prose. Advisory-only means the client implements recommendations and must test that its architecture matches the advice. Advisory-plus-implementation gives the provider more control over delivery but requires independent challenge of its own design. Implementation-only requires a sufficiently complete client design and a documented route for reporting design defects rather than blindly implementing them. These are author-designed procurement distinctions, not statutory categories.
For all three, specify exactly which artifacts transfer: editable inventories, decision records, permitted configuration exports, custom source code where contracted, interface schemas, test inputs and results, and operator runbooks. Do not promise source access to a proprietary product the engagement does not own. Replace informal sharing of credentials with client-owned identities, controlled access, rotation and revocation checks. Retain access to evidence after the provider’s administrative access ends.
Independence needs more precision than a blanket ban. Section 10(2)(b) requires an SDF to appoint an independent data auditor; the retained text does not define a universal firm-wide prohibition on every advisory and audit combination.[1] Lines 418–438. The author’s recommended safeguard is separate implementer and assurance procurement where self-review threatens the assessment, with documented financial, reporting, personnel and decision conflicts. Counsel should assess the actual arrangement and any other applicable independence requirements. A different team name is not itself proof of independence; nor is this chapter declaring all same-network arrangements legally prohibited.
CASE-001 remains not designated as an SDF. Its readiness work is voluntary, not evidence of designation. If designation occurs under the assumed future baseline, the engagement must address the individual India-based DPO and governing-body responsibility as well as audit independence.[1] Lines 404–429. Rule 13 adds the twelve-month DPIA/audit cycle, significant-observation reporting, algorithmic due diligence and restrictions for government-specified data.[40] Lines 1276–1293. A generic “annual compliance review” line item should not silently replace those distinct duties.
6. The decision record the reader should keep
Record the business bottleneck, source label and date, proposed adaptation, provider deliverable, retained client responsibility, unknown evidence, independence analysis and acceptance owner. For Client A, the decisive question is whether ownership survives handover. For Client B, it is whether an adequately staffed service can operate defined workflows without hiding exceptions. The same firm could be suitable for either after due diligence; the public material does not decide that.
Before signing, ask a bidder to price a rejected or unresolved branch as well as a successful branch. Who handles missing processor evidence? Who updates the source mapping? Who can stop a route? What happens if the client must replace the advisor or platform? Those questions convert methodology into a bounded, testable purchase. Chapter 27 applies the same discipline to technology-services firms, specialist operators and productized offerings without assuming that nationality predicts performance.
Source notes
Numeric references use the Q08 isolated ledger. Exact URLs and retained paths are generated below; vendor retrieval dates are not historical publication dates. The full URL/date/hash manifest is out/remediation/q08/source-manifest.json.
Retained file map
The line ranges cited above refer to these exact local captures:
- [1]
research/legal/evidence/01_dpdp_act_2023_gazette.txt - [3]
research/solutions/evidence/03-www.deloitte.com-the-digital-personal-data-protection-act-2023.md - [4]
research/solutions/evidence/04-www.deloitte.com-india-s-dpdp-rules-2025-leading-digital-privacy-compliance.md - [5]
research/solutions/evidence/05-www.pwc.in-the-digital-personal-data-protection-act-2023.md - [6]
research/solutions/evidence/06-www.pwc.in-cybersecurity-solutions-and-insights-pwc.md - [7]
research/solutions/evidence/07-www.ey.com-data-protection-and-data-privacy-consulting-ey-india.md - [8]
research/solutions/evidence/08-www.ey.com-india-data-privacy-shift-dpdp-compliance-guide-ey-india.md - [9]
research/solutions/evidence/09-kpmg.com-digital-personal-data-protection-dpdp-advisory-services.md - [10]
research/solutions/evidence/10-www.mckinsey.com-consumer-data-protection-and-privacy-mckinsey.md - [11]
research/solutions/evidence/11-www.mckinsey.com-what-is-an-operating-model-and-why-does-it-matter-mckinsey.md - [39]
research/legal/evidence/02_gsr_843e_commencement.txt - [40]
research/legal/evidence/05_gsr_846e_dpdp_rules_2025.txt - [41]
research/legal/evidence/06_gsr_892e_corrigendum.txt
Sources
[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf [3] https://www.deloitte.com/in/en/services/consulting/about/the-digital-personal-data-protection-act-2023.html [4] https://www.deloitte.com/in/en/services/consulting/about/indias-dpdp-rules-2025-leading-digital-privacy-compliance.html [5] https://www.pwc.in/consulting/risk-consulting/the-digital-personal-data-protection-act-2023.html [6] https://www.pwc.in/consulting/risk-consulting/cybersecurity.html [7] https://www.ey.com/en_in/services/consulting/data-protection-privacy [8] https://www.ey.com/en_in/insights/cybersecurity/india-s-data-privacy-shift-steering-the-dpdp-compliance-and-readiness [9] https://kpmg.com/in/en/services/advisory/consulting/cyber-risk-and-compliance/strategy-and-governance/data-privacy/digital-personal-data-protection-dpdp-advisory-services.html [10] https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/the-consumer-data-opportunity-and-the-privacy-imperative [11] https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-an-operating-model [39] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [40] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [41] 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