INDIA • DPDPA 2023 • T−363d

— INDIA • DPDPA 2023 • T−363 days

A legal, technology, & AI transformation converging at once.

~70% of large transformations fail.*About 7 out of 10 large transformations fail.*

*McKinsey: common pitfalls in transformations

₹250crore — penalty cap
202713 May — deadline
~70%large programmes fail

— The Transformations

Three transformations converge on one deadline.

Each is enterprise-wide and continuous. None can be sequenced.

01. The legal front

A new Act

A new Act ties data processing to a named purpose and consent — with penalties to ₹250 crore.

02. The technical front

A new architecture

The Act demands controls on every system handling personal data — across the enterprise and its vendors.

03. The AI front

A new pace

AI delivers the programme on time — and itself becomes something the Act must govern.

— The 70% problem

What McKinsey, BCG, and HBR agree on

All studied large transformations. The findings are similar.

— 7 DPDPA patterns

The 70% problem hits DPDPA programmes in seven predictable patterns.

Visible in surveys, embedded in systems and integrations. The cost of unwinding compounds toward May 2027.

Enterprise complexity compounds across transformations; it does not dissolve. DPDPA inherits the regulatory and technical layers an SDF has accumulated over decades, and AI now adds a new layer. The seven patterns that follow are predictable not because the subject is simple, but because the structural conditions — layered systems, layered governance, a fixed deadline — keep producing the same shapes.

RoPA accuracy decides every penalty defence

Survey-based records cannot evidence the systems the regulator examines. Inaccurate RoPA caps every dependent control — DPIA, breach response, children's data.

Reference data needs one firmwide source

Without one governed source of truth — systems, vendors, data categories, regulations — DPDPA collides with RBI, SEBI, IRDAI, and tax retention floors team by team.

Rights are operations, not service requests

A vendor portal captures the request. Fulfilling it means reading, updating or deleting personal data across every system the enterprise and its vendors operate.

Consent must reach the data plane

Capturing consent is solved. Starting and stopping processing as consent changes — across every operational system — is where most programmes stop short.

The foundation is assumed, not built

Security safeguards, audits, breach response — each is handed to a different tech team. The shared foundation beneath them is presumed in place — and rarely built as one.

AI is feasibility, not upside

Most teams still discover data by survey and build software by waterfall — methods too slow for a deadline that will not move.

DPDPA is reviewed, rarely owned

DPDPA's penalties are board-scale — yet boards delegate the work as a compliance project and review it monthly. An owner accountable for the whole is rarely named.

Without knowing where data actually lives and flows, every dependent control breaks. Gap assessment is guessing. Reference data is free-text. DPIA is fiction. Consent management is UI theatre. Rights fulfilment is a treasure hunt. Discovery by survey is decay. Security is guarding the vault while copies float downstream. Breach response is damage control in the dark. Ownership is mistaken for attendance.

— The Solution

One product, one strategy

The product builds the architectural foundation — an engineer- and AI-verified data flow map — from which DPDPA capabilities inherit.

The advisory keeps each capability anchored to the foundation, under one technical-first owner. Together: shorter calendar, lower cost, and compliance as a reusable asset rather than recurring overhead.

Both pillars are easy to describe. The case study below shows them delivered.

— The case study

Months of shelved decks. One unified read. The DPDPA programme realigned.

Inside one of India’s largest banks: two consulting engagements produced months of documents but no defensible foundation. A few strategic inputs across legal, tech, AI, and cost course-corrected the programme within weeks. Crores saved across integrations, vendors, and teams.

— The Product

MithrilMap†

Compliance foundation software. Lightweight armour for India’s heaviest data regulation — built once, holds up under what follows.

One unified design — simple enough for business, legal, and technical teams to use together. The data flow map is the RoPA — engineer- and AI-verified, kept in step with the systems where personal data lives rather than reconstructed once a year.

What the foundation answers

§8(5)SecuritysafeguardsBreachresponse§8(6)DPIA§10(2)(b)Rights§11–14Dataaudit§10(2)(c)§9Children’sdata

Every smaller penalty in the Act — one source, one audit trail.

† Mithril — a fictional metal from J.R.R. Tolkien’s The Lord of the Rings — light as silk, strong as steel. Hence MithrilMap: a lightweight architecture that withstands DPDPA’s heaviest demands.

— The Strategy

A unified strategy does the work of many engagements

Most Significant Data Fiduciaries meet DPDPA as fragmented procurement — each function buys its own piece, and no one owns the whole. A unified strategy treats it as one designed programme instead: the Act read as engineering work, every provision placed across the enterprise's functions under a single accountable owner.

The leverage is in the diagnosis — one cross-cutting reading of the problem does the work that fragmentation splits across many engagements. And a programme designed once, rather than procured in parts, lifts profit from both sides: it cuts cost, and it keeps the bank's data lawfully earning.

— Capabilities

One foundation makes each capability defensible

Nine capabilities, all read from one verified foundation. They run the length of DPDPA — from the ₹250-crore security provision to the everyday data-principal request — and each holds up under audit because the foundation beneath it does.

Security safeguards

Evidence reasonable security at rest, in transit, and in use across every system the map records — the Act's ₹250-crore exposure.

Breach response

Compute the blast radius in hours, not weeks — principals affected, fields exposed — to meet the 72-hour notification clock.

Children's data

Flag children's data wherever it flows and hold it to the Act's stricter limits — verifiable parental consent, no behavioural tracking.

RoPA

Read an audit-ready Record of Processing Activities off the maintained map — not a survey reassembled once a year.

DPIA

Run the annual Data Protection Impact Assessment on real flows and live controls, not questionnaire answers.

Data audit

Give the independent auditor and the Data Protection Board a standing evidence trail, not one assembled each cycle.

Data principal rights

Fulfil access, correction, and erasure where personal data actually lives — across every system that holds it, inside the enterprise and out.

Consent enforcement

Carry consent — granted, reviewed, updated — from the capture point into every system that processes the data.

Grievance redressal

Answer each grievance with full lineage — what data, under which consent, through which systems, under what controls.

— The Founder

A systems thinker, proven across more than one field

A decade in global finance, books in print, companies founded — and an engineer's training from IIT Bombay beneath it all. Through every one of them runs a single habit of mind: thinking in systems.

anilrajput.com LinkedIn

Contact Us

Whether you are a Data Fiduciary or Data Processor weighing your compliance posture, a consulting firm exploring co-delivery, or a vendor evaluating partnership — a few lines by email, and Anil replies personally.

contact@anilrajput.com

We typically respond within one business day.

Your email is your consent — to MithrilMap using your details for the purpose you state, and nothing else. This site does not use cookies or tracking.

Case Study

A few architectural inputs, an entire programme corrected

At one of India's largest banks, two parallel consulting engagements produced months of documents and no defensible foundation. A small set of strategic and technical inputs redirected the programme within weeks — at materially lower cost than the path that had been authorised.

A Field NoteSource: Direct engagementReading time · 6 min

The bank had committed substantial budget and time to two parallel consulting engagements. The first conducted an Excel-based Record of Processing Activities (RoPA) exercise driven by product teams. The second interpreted the Act and produced business-requirements documents on top of a strategy that proposed serving data principal rights from the data warehouse. Both engagements were structurally insufficient for what DPDPA actually requires.

Weeks
To diagnose the failures
and redirect the strategy
Crores
Saved across integrations,
vendors, teams, and remediation
One
Unified strategy replacing
two fragmented engagements

Strategic and technical inputs at this scale cannot precisely compute the costs avoided or the time recovered — those figures only emerge years downstream, and the counterfactual cannot be measured. The order of magnitude is not in question: at SDF scale, building compliance infrastructure on the wrong foundation is a multi-year, multi-crore commitment that compounds with every subsequent capability built on top of it. This case study captures the diagnoses and the redirects; the impact is honestly framed as architectural prevention rather than measured savings.

The setting

One of India's largest banks, a Significant Data Fiduciary under DPDPA, operating across hundreds of product and services teams. Personal data spread across operational databases, downstream analytical warehouses, vendor connections, and shared customer-information systems centrally owned by individual teams but consumed by the rest of the bank. The DPDPA programme was running on two parallel tracks: a tier-1 consultancy leading a survey-based RoPA exercise; a major systems integrator working with the internal risk team to interpret the Act and prepare business-requirements documents.

Where the engagements fell short

№ 01

A survey-based record without engineering ground truth

The RoPA exercise asked product teams to fill Excel templates describing the personal data their products processed — including the security of data at rest and data in transit on the systems involved. No business head signed off the templates that were submitted. Different product teams used different free-text names for the same systems and data categories.

The structural problem went deeper. A centrally-owned customer-information system used across hundreds of product and services teams cannot be accurately described by any one of those teams — the system is owned by another team, and the security details (encryption at rest, security of every API connected to it) are not visible from a product team's vantage point. Asking a hundred product teams to characterise the security posture of a system they do not operate produces inaccurate, inconsistent, and unsigned answers — and an unsigned, inconsistent record evidences nothing to the regulator.

№ 02

The wrong source of truth for rights

The second engagement proposed that data principal rights — access, correction, erasure — be served from the data warehouse, paired with service-request management systems supplied by vendors. The strategy was technically incorrect at its foundation. The data warehouse is a downstream analytical copy, not the source of truth for personal data; erasing a record there leaves the operational systems that originated it untouched. Access requests served from it return stale, partial, or reconciled views.

The engagement also produced business-requirements documents and user stories focused entirely on the front of the rights workflow — the user journeys for capturing requests through new UIs. What happens after the request is captured — how it reaches the operational systems where the record actually lives, and onward to external processors — was not addressed. The technical depth required for DPDPA defensibility was absent.

The architectural redirect

№ 01

Firmwide governed metadata before any mapping

The first move was to install a Metadata Management System (MMS): a single, governed inventory of the bank's systems, vendors, data categories, processes, and applicable regulations. Each entry was proposed by AI, checked by the team that owned the system or process, and approved by a tech lead or business head. From it, every name, system, category, and regulatory citation now meant the same thing across every product team — replacing free-text survey entries with firmwide governed reference data.

From this foundation, the technical data flow map was built — a unified record of which systems hold which categories of personal data, how data flows between them, and how each flow is secured. A parallel RoPA captured the bank's processes, assembled with AI assistance over the existing process documentation and verified by the engineering and process teams. Both artefacts were constructed from operational ground truth — schemas, APIs, logs, and operational records — not authored from a working group.

№ 02

Single sources of truth, automated synchronisation, reused interfaces

The data-warehouse-served-rights strategy was discontinued. In its place, a small set of operational source-of-truth systems were identified — the systems where each category of personal data is created and authoritatively held — and the rights workflow was redesigned to operate against those sources directly. Identifying them takes more than a manual pass: systems are built and rebuilt and teams change, so the complete set surfaces from the engineer- and AI-verified data flow map, with manual identification alongside. Read, update, and erasure requests are served against the source-of-truth system, and the processors the data was shared with are kept in synchronisation by the same metadata layer that powers the data flow map.

The customer-facing UI for capturing rights requests was identified as a solved, commodity problem. Rather than procure new systems from vendors, a responsive, accessible UI was built in-house with AI assistance, reusing the bank's existing systems, integrations and teams, and adding only what the work required. Data minimisation and retention policies were authored alongside the rights workflow — collecting only what was needed, de-identifying as early as possible, and automating retention and synchronisation. The architecture became a coherent system rather than a stack of disconnected vendor procurements.

The outcome

Within weeks of the architectural redirect, the programme was on course. One unified strategy replaced two fragmented engagements. The bank's executives — across risk, technology, and privacy — aligned on a single architectural commitment that every subsequent compliance capability would inherit from.

Several other strategic and technical inputs followed across the programme — patterns of reuse over rebuild, automation over headcount, extending existing tools over procuring new ones. Each input cut redundant cost, redundant timeline, and redundant risk; each maximised reuse of what the bank already had. Compounded over the calendar that remained before the May 2027 deadline, the difference was between a defensible programme and one that would have failed audit by construction.

The redirect was small because the diagnosis was not. Both engagements had failed for one root cause — no verified foundation beneath the programme — and naming it is what let a few inputs do the work of many: each addressed the root, and so reached across several DPDPA provisions and several transformation dimensions at once. That is the differentiator a competent strategist brings — not a long list of single-purpose fixes, but a few inputs, each one multi-dimensional by design.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
  2. Digital Personal Data Protection Rules, 2025 (as published by the Ministry of Electronics and Information Technology). meity.gov.in
The Product

The map is the RoPA

MithrilMap delivers one architectural artefact — an engineer- and AI-verified data flow map — that is the Record of Processing Activities, not a path to it. Kept current with the systems where personal data actually lives. Built on two governed modules.

A Product BriefSources: DPDPA 2023 · DPDP RulesReading time · 7 min

DPDPA defensibility has a single binding constraint: an accurate, verifiable record of every processing activity. Surveys produce documentation; instrumentation produces evidence. MithrilMap's product is the instrumentation — a data flow map that doubles as the RoPA, kept in step with the systems where personal data is created, changed, and stored — as closely as maker-checker controls and connection SLAs allow — and governed by firmwide reference data. Every penalised provision of the Act inherits its defensibility from this single artefact.

Two
Foundational modules — MMS
and DFM, governed together
Four
Verification surfaces — UI,
API, database, and logs
One
Artefact — the data flow map
that is the RoPA

One architectural artefact

The data flow map is not a separate document assembled from surveys. It is a verified record of every processing activity at the bank — what data is processed, by which system, for what purpose, under which legal basis1, with what security controls, and for how long. The same artefact is the RoPA — the record the Act's data audit and Data Protection Impact Assessment (DPIA) draw on.

The shift the artefact represents is structural. Survey-based RoPA is authored: a snapshot taken from people who answer for systems they may not operate. The data flow map is generated: read against schemas, APIs, logs, and operational records — the systems where data actually lives — as far as the SLA on each connection allows. When a system changes, that change re-enters the verification cycle, so the record tracks operational reality rather than freezing into a snapshot between surveys.

Two modules, one foundation

№ 01

MMS — Metadata Management System

The Metadata Management System (MMS) is a single, governed inventory of the bank's systems, vendors, data categories, processing purposes, applicable regulations, and the relationships between them — along with whatever further categories a DPDPA programme surfaces as it runs. Its model is built to anticipate the kinds of metadata the programme tracks, so change rarely calls for redesign — a new regulatory body or a new rule is added as an entry, not built as a feature. Every name, system, category, and regulatory citation means the same thing across every product team — replacing the free-text survey fields that fracture compliance into per-team interpretations.

Each entry is governed under a maker-checker-approver pattern: an AI maker proposes new entries from system instrumentation; an engineer or process owner checks the proposal against operational reality; a tech lead or business head approves it. Reference data — system names, vendor names, data categories, regulatory mappings — moves from authored survey content to firmwide governed architecture.

№ 02

DFM — Data Flow Map

The Data Flow Map (DFM) is the technical record of every system that holds personal data, every flow between systems, and every security control on each flow — built on top of the MMS and verified against operational ground truth. Each is held as a structured record the rest of the programme can query, not a line of free text in a survey.

The RoPA is not a separate artefact assembled later; it is a view of the DFM itself, in the form the Act's data audit and DPIA call for. DPIA findings, breach-response timelines, rights-fulfilment plans, and retention enforcement all read against that same model.

Engineer- and AI-verified

The artefact's defensibility comes from its construction, not its review. Both modules — MMS and DFM — are populated and maintained under a maker-checker-approver workflow that combines AI throughput with human judgement.

The AI maker reads schemas, API specifications, logs, system documentation, and configuration data — the four verification surfaces — and proposes entries. The engineer or process owner who runs the system checks each proposal against operational reality. The tech lead or business head approves. At Significant Data Fiduciary scale, the work of inventorying hundreds of systems and instrumenting their flows exceeds human throughput within the May 2027 window1; the AI maker shifts the bottleneck from human capacity to access — which systems the AI can read, under what governance, with what audit trail. Every entry the regulator examines was proposed by AI, checked by an engineer, and approved by an accountable human.

What gets built on top

Every dependent control inherits its defensibility from the same artefact. RoPA is read from the map, not authored as a parallel document. DPIA findings reference the same processing activities the map enumerates. Breach-response timelines2 run against the map: when a system is affected, the blast radius reads from the flows it records. Rights fulfilment — read, update, erasure, retention1 — reaches the operational systems the map identifies and the processors the map names. §8(5) reasonable-security assertions cite the security controls the map records.

The compliance programme stops being a stack of disconnected workflows building on different sources of truth. It becomes one architecture, with one governed metadata layer, one verified map, and one record of processing activities. Every capability the bank's DPDPA programme produces inherits its defensibility from this single foundation.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
  2. Digital Personal Data Protection Rules, 2025 (as published by the Ministry of Electronics and Information Technology). meity.gov.in
The Strategy

A unified strategy, not a stack of procurements

DPDPA defensibility is a design problem, not a procurement list. A unified strategy treats it as one programme — the Act read as engineering work, one foundation every obligation inherits, and profit lifted from both cost and revenue.

A Strategy BriefSources: DPDPA 2023 · DPDP RulesReading time · 7 min

Most DPDPA programmes are run as procurement: a privacy platform here, a consent-management vendor there, a rights-management portal elsewhere, held together by a tier-1 consultancy's interpretation document. The result is a stack of disconnected systems that costs more, ships slower, and produces compliance no one in the bank fully owns. A unified strategy treats DPDPA as one designed programme instead — read as engineering work, built on one foundation, owned end to end, and disciplined on what is built and what is reused.

One
Designed programme — not
a stack of procurements
Two
Directions of profit —
cost cut, revenue guarded
Three
Tiers of scope — build,
deliver on demand, advise

Fragmentation is the default failure

Run as procurement, a large DPDPA programme splinters. Each obligation — records of processing, consent, rights, breach response, retention — goes to a different function and runs as its own project. Legal interprets the Act, risk commissions a survey, technology buys platforms, security guards its perimeter, and a consultancy authors the document meant to tie them together. Five fragments, five budgets, and not one answer to the whole.

Nothing in that arrangement is accountable for the whole, and nothing in it treats DPDPA as the transformation it is rather than a project to deliver and close. The interpretation document assumes a foundation no one is building; the platforms assume data no one has mapped; the survey assumes the people answering can see the systems they describe. Two years and several crores later, the bank owns many systems and no defensible programme. A unified strategy replaces that arrangement — not with a better vendor, but with one designed programme under one owner.

Read the Act as engineering work

Most programmes read DPDPA as a legal and policy exercise. That reading is where they go wrong. The Act's language is legal, but the work it creates is largely engineering — the controls that protect personal data and govern its use live in systems, not in binders. A unified strategy begins by reading every provision through a technical lens: what, concretely, does this clause require a system to do, and which of the bank's systems and teams does that task land on?

That translation is the strategist's core work, and it is rare. It needs someone who can read the Act and read a schema — place each technical task across an enterprise of many functions, and name the one owner accountable for the whole. Done well, it produces a diagnosis, not a task list.

A sharp diagnosis is leverage. Because it names the root cause, one insight reaches every provision and every function that cause touches — a few moves doing what a fragmented programme, divided across many engagements and internal teams, had not. The case study on this site is one worked instance: a programme already under two consulting engagements, put on course within weeks once its root cause was named. A unified strategy is built to find that diagnosis, not to lengthen the list of fixes.

One foundation, every obligation inherits

Fragmentation builds the same foundation many times — partially, and under many owners. A unified strategy builds it once. A small set of foundational products — a governed metadata layer and a verified data flow map — becomes the operating layer the rest of the programme runs on. Records of processing, impact assessments, breach response, rights fulfilment, retention, the §8(5) reasonable-security1 evidence: each reads against the same foundation rather than rediscovering the systems for itself.

The foundation is designed to absorb change. DPDPA is not the last instrument the bank will answer to — the Rules will be revised2, sectoral regulators will add their own, the Data Protection Board will issue guidance over years. The metadata model is built comprehensively at the outset, so a new regulation, body, or category enters as data the programme already knows how to hold — not as a redesign. Compliance stops being rebuilt each time the ground shifts.

Building once is also what makes the May 2027 calendar reachable. Survey-and-waterfall delivery — teams describing systems by hand, software specified on assumptions and shipped in sequence — cannot inventory hundreds of systems and build their controls in the window the Act leaves. AI-assisted execution compresses research, design, and build together; and a foundation built once is not a foundation rebuilt by every workstream. The rework that fragmentation repeats is designed out.

Three tiers of disciplined scope

A unified strategy is deliberate about what it builds. Every capability sorts into one of three tiers — what to build as core, what to deliver on demand, and what to advise on without building. Each boundary is explicit, and naming it candidly is part of what a bank is buying.

№ 01

Tier 1 — what the strategy builds

The core build, and the hardest work to do well: a governed metadata layer, the verified data flow map, the records of processing read from it, and the foundational workflows that depend on them — breach blast-radius, rights fulfilment, retention orchestration, consent enforcement to the data plane. Every other capability inherits its defensibility from this tier, which is why it is built first and built once.

№ 02

Tier 2 — what it delivers on demand

Capabilities adjacent to the core, productised when a customer asks. Data Protection Impact Assessment (DPIA) tooling — risk-rating, a mitigation library, a sign-off workflow on top of the foundation — sits here: the foundation is already in place, so productisation takes weeks rather than months. Federated breach-impact queries sit here too. The discipline is to build these when an engagement needs them, not to lead with them.

№ 03

Tier 3 — what it advises, not builds

Adjacent domains where capable vendors and the bank's own teams already operate well: consent-capture platforms, breach-detection tooling, cross-border specialist legal, sectoral regulator work, guardian management for minors. The strategy advises here — including the case for learning, adaptable consent over static forms — and integrates with whatever the bank chooses, but does not build, lead with, or sell these as product. Naming the boundary is itself part of the strategy.

Profit from both directions

A unified strategy is not a cost-reduction exercise, and not a growth pitch. It is one designed programme — and a programme designed well raises profit twice over: once on cost, once on revenue.

Cost falls. Platform licences avoided, redundant integrations not built, parallel teams not staffed, vendors not procured for problems the bank already solved. The May 2027 calendar is met without the rework a fragmented programme repeats. At Significant Data Fiduciary scale, the saving compounds across hundreds of integrations and dozens of vendor relationships — and it persists, because every system not built is a system not operated, year after year.

Revenue follows the same architecture. DPDPA splits a bank's data processing in two. Processing the customer relationship itself — running the account, serving the regulator — rests on its own lawful footing. Marketing does not. It is optional processing: cross-sell, partner offers, and analytics beyond the original purpose may proceed only on the data principal's consent, captured for that specific purpose and recorded so it survives an audit years later. A bank can lawfully monetise its data exactly as far as that consent reaches, and no further. That makes consent architecture more than a compliance control: it is the asset that sets how much of the bank's data can still earn.

This is why consent-based marketing belongs inside the strategy, not after it. The consent surface a bank builds sets the ceiling on its post-DPDPA revenue. A static form captures a single yes or no and then freezes; a dynamic, configurable surface lets the bank add new purposes as they arise, lets customers tune their own preferences, and lets the bank learn which purposes customers grant and which they decline. As enforcement matures and preferences shift, the static form quietly loses reach while the adaptive one keeps marketing live. A unified strategy cannot stop at protecting data; it has to leave the data lawfully earning.

A further return owes nothing to a marketing budget at all. A visibly defensible programme is a trust signal, and in a regulated market where customers choose between providers, trust becomes a reason they choose this bank and stay. The advantage compounds for whoever moves first, and a late entrant cannot quickly buy it back.

Cost and revenue are not the strategy. They are what a unified strategy produces. The strategy is the design — one programme, read as engineering work, built on one foundation, owned end to end.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
  2. Digital Personal Data Protection Rules, 2025 (as published by the Ministry of Electronics and Information Technology). meity.gov.in
Capabilities

One foundation answers the whole Act

DPDPA's penalties run from ₹250 crore down to ₹50 crore. Nine capabilities answer that range — each read from the same engineer- and AI-verified foundation, and grouped here by what failure costs.

A Capability BriefSources: DPDPA 2023 · DPDP RulesReading time · 10 min

DPDPA hands the bank a stack of provisions to satisfy — security safeguards, breach intimation, children's data, records of processing, impact assessments, audits, the rights of every data principal, consent, grievance. Read as a list, the surface is overwhelming. Read against the foundation — the verified data flow map that is itself the record of processing — each one becomes a read against the same model, and defensibility stops being assembled at audit and starts being inherited.

Nine
Capabilities, all read from
one verified foundation
Three
Penalty bands — from
₹250 crore to ₹50 crore
One
Foundation — the data flow
map that is the RoPA

Nine capabilities, one foundation

The tile grid on the page that opened this modal lists nine capabilities. None is a separate system or a separate purchase. Each is a view of the same model — the verified data flow map, governed by the metadata layer beneath it. The surface is wide; the architecture under it is one.

The nine are grouped here by a measure every board reads first — the penalty the Act attaches to getting each wrong. Band one carries the severe exposures, ₹200 to ₹250 crore. Band two, the Significant Data Fiduciary's reporting obligations, ₹150 crore. Band three, the data principal's own provisions, ₹50 crore. One foundation serves all three; the bands only mark where failure costs most.

Band one — the severe provisions

Three of the Act's heaviest penalties sit here — ₹250 crore, ₹200 crore, ₹200 crore. A failure here is not a line item; it is an event the board answers for. All three are read from the same foundation.

№ 01

Security safeguards · §8(5) · ₹250 crore

DPDPA §8(5)1 obliges a Data Fiduciary to protect personal data with reasonable security safeguards — and a breach that follows their absence carries the Act's heaviest penalty, ₹250 crore. 'Reasonable' is judged in context, so the strategy holds security as risk-graded metadata: a baseline per data category, stricter controls where sensitivity or volume raises the risk, and whatever an external regulator mandates. The data flow map records the control applied on every system and every flow; AI verification then checks each declared control against the live system — code, configuration, logs, API contracts — not against a form. The §8(5) assertion the bank makes to the Board becomes a citation from a maintained record — honest about what automated checks confirm and what they cannot, with operational evidence carrying the rest.

№ 02

Breach response · §8(6) · ₹200 crore

When a breach is declared, the Act1 and the 2025 Rules2 start a 72-hour clock to inform the Data Protection Board and the affected data principals; missing it carries ₹200 crore. The hard part is not the notice but its content — which principals, which fields, which downstream systems and vendors held copies, what consent and what security applied at the time. Read by hand across hundreds of systems, that scoping takes weeks; read against the data flow map, it takes hours, because the map already records every flow the exposed data travelled. MithrilMap does not detect the breach — the bank's security stack does that — but from the moment one is declared, the map turns blast-radius from a frantic reconstruction into a query.

№ 03

Children's data · §9 · ₹200 crore

DPDPA §91 holds children's data to a stricter regime — verifiable parental consent, and a bar on behavioural monitoring and targeted advertising — with ₹200 crore behind it. Enforcing any of it depends first on knowing which records belong to children, and in mainstream banking that is rarely settled: date-of-birth fields are inconsistent, missing, or self-declared. The strategy flags children's data at the granularity reality allows — a whole product, a whole system, or a single record. AI cross-verification then scans for the markers a product team misses, a second signal rather than the only one. Because each flag is computed from date of birth, it also lifts on schedule: the day a principal reaches eighteen, the children's-data treatment expires on its own.

Band two — the reporting obligations

DPDPA designates the largest fiduciaries as Significant Data Fiduciaries, and asks of them what it does not ask of the rest: a Data Protection Impact Assessment and an independent data audit, each once every twelve months, with ₹150 crore behind their neglect. Both rest on a complete record of processing — and that record rests on the map.

№ 04

Records of processing · the RoPA

A Record of Processing Activities (RoPA) lists every system, dataset, and activity that touches personal data — and every other obligation in this band reads from it. Built the usual way, by survey, it is wrong on arrival: the teams filling the templates cannot see inside the systems they describe, and the document drifts further from reality with every deployment. The strategy does not author a RoPA; it generates one. The verified data flow map is the RoPA — the same record, read at the level the Act's audit and impact assessment call for. Maker-checker control keeps it in step with live systems, so it is current when the regulator asks, not accurate only on the day it was signed.

№ 05

DPIA · §10 · ₹150 crore

The 2025 Rules2 require a Significant Data Fiduciary to run a Data Protection Impact Assessment every twelve months — an examination of how personal data is processed and what risk that processing carries. A DPIA built on survey answers assesses a fiction; one built on the data flow map assesses the processing as it actually runs, against the controls actually in place. The strategy delivers that evidence base as a capability of the foundation; the risk-rating and mitigation workflow on top is a thin layer, productised on demand rather than sold as a separate platform. The assessment is only as honest as the record beneath it — which is why the record comes first.

№ 06

Data audit · §10 · ₹150 crore

The same Rules2 require an independent data audit each year — an external auditor checking that the bank's processing matches its obligations, with findings reported to the Data Protection Board. An audit is only as quick and as credible as the evidence it can draw on. Where compliance is fragmented, each cycle re-assembles that evidence by hand; where it is one foundation, the audit reads a standing trail — every processing activity, every flow, every control, with the record of who approved what and when. The strategy's contribution is not the audit but the architecture that makes the audit short, repeatable, and hard to dispute.

Band three — the data principal's provisions

The Act's lowest penalty band — ₹50 crore — is also its busiest. These are the parts of the Act a customer touches directly: the right to see, correct, and erase their data; the consent that governs its use; the grievance channel when something goes wrong. Low-cap per finding, but high-volume and public — handled badly, this is where reputational damage and a pattern of findings accumulate.

№ 07

Data principal rights · §11 and §12

Sections 11 and 121 give every data principal the right to access their personal data, to correct it, and to erase it — read, update, delete, across every system that holds a copy. A vendor portal captures the request and counts the clock; it does not fulfil it. Fulfilment is an operation. It has to reach the source-of-truth system where each attribute is authoritative — the map identifies which — then carry through to the downstream copies and the external processors the data was shared with. The strategy serves rights against those sources, reusing the bank's existing identity and case-management systems rather than standing up a parallel stack.

№ 08

Consent enforcement · §6

Consent under §61 is not a one-time switch — a data principal grants it, revisits it, and updates it, in either direction, across the life of the relationship. Capturing that decision is solved; carrying it into the systems that process the data is not. The strategy treats consent as a state every operational system must stay synchronised with. When it changes, what each system may do changes with it — marketing stops, a purpose closes — within a defined time, not at the next batch run. The capture screen is the bank's to choose; the enforcement that reaches the data plane is the architecture's to deliver.

№ 09

Grievance redressal · §13

Section 131 gives every data principal a grievance channel and the bank a duty to answer it within a set time. A grievance is answerable only with the facts at hand — what data the bank holds on this person, under which consent, shared with whom, under what controls. Where those facts are scattered, each grievance is an investigation; where they read from one foundation, the answer is a query that carries its own evidence. The strategy wires DPDPA grievances into the bank's existing redressal workflow and gives each resolution the lineage that holds up if the principal escalates to the Board.

Beyond the nine

The capabilities above are the built core. Two scope boundaries sit around them, and drawing them is itself part of the strategy.

Productised on demand. The Data Protection Impact Assessment workflow — risk-rating, a mitigation library, sign-off — and federated queries that resolve affected data principals across systems during a breach: the foundation already carries what these need, so productising them takes weeks. The strategy builds them when an engagement asks, not before.

Advised, not built. Consent-capture platforms, breach-detection tooling, cross-border specialist legal, sectoral-regulator filings, guardian management for minors — capable vendors and the bank's own teams already serve these well. The architecture connects to them rather than duplicating them. A strategy that names its own edges is worth more to a bank than one that claims everything.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
  2. Digital Personal Data Protection Rules, 2025 (as published by the Ministry of Electronics and Information Technology). meity.gov.in
The Founder

A career that only looks many-sided

Engineer, author, and founder are three roles, but one discipline runs under all of them — thinking in systems, then building or explaining them with that lens.

A ProfileAnil RajputReading time · 4 min

Anil Rajput trained as an engineer at IIT Bombay, and an engineer is what he has stayed. The decade since has run through global finance, a Principal Engineer's seat at one of India's largest banks, two companies of his own, and a book that found its readers. What ties those together is not a job title. It is a habit of mind: reading the world as systems, and treating each as something to understand, build, and improve.

№ 01

The engineer, in global finance

The training is from IIT Bombay. He spent the decade that followed inside three of the world's largest investment banks — Goldman Sachs, J.P. Morgan, and Merrill Lynch — and then as a Principal Engineer at one of India's largest. The work throughout was systems: the platforms that move money, hold customer data, and have to be right every time. Few engineers have worked on systems this large, in institutions this regulated, for this long.

№ 02

The author, in print

His writing is where the systems habit is most explicit — Cognitive Fitness, his book, with more now in progress. Across that work he reads natural, social, and familial systems, the nervous system, and the technological and AI systems now remaking daily life. He looks for the pattern that runs across them all. It is the rarer half of a systems mind: not only building systems, but seeing how they fit together.

№ 03

The founder, more than once

Before MithrilMap there were two companies of his own — Neural Stone and Actual Automation, the latter an early practice in AI-assisted product development. A company is a system too, and building one well is the same discipline applied to people, capital, and time. He works in three modes at once — founder, advisor, and author — and MithrilMap is where they converge.

None of this is a brochure. It is a record: systems built, run, written, and understood — across global finance, print, and enterprise. That is the competence behind MithrilMap.

Pattern 01 · DPDPA Transformation

RoPA accuracy is the binding constraint on every penalised provision

A RoPA either describes the systems or evidences them — and only evidence survives a Data Protection Board audit.

A Field NoteSource: DPDPA 2023Reading time · 2 min

A Record of Processing Activities (RoPA) is the document that lists every system, dataset, and processing activity touching personal data. Inaccurate or unverifiable RoPA caps the defensibility of every provision that carries a penalty under the Act1 — Data Protection Impact Assessments (DPIA), data audits, the §8(5) reasonable-security declaration, breach-response timelines, and children's data controls. Survey-based RoPA — the typical consulting deliverable — does not evidence the systems and operational reality the Data Protection Board examines.

A RoPA produced by departmental owners answering for systems they do not operate diverges from operational reality in ways the regulator finds at audit, not before. Defensibility requires the document to be read against the systems where data actually lives, not authored as a snapshot from a working group.

The methodology that survives audit is engineer- and AI-verified — schemas, APIs, application logs, and live traffic inspected directly, not described from a working group. What developers say their system does is treated as a hypothesis; what the code, schema, and traffic do is treated as truth. Coverage is measured, not assumed; conflicts are surfaced, not buried.

Verification is continuous, not snapshot. A one-time scan decays the moment any system ships a change. Every deployment, schema migration, and new endpoint triggers re-verification, so the document and the data plane do not drift apart silently in the months between audit cycles.

Every data processing control and governance, risk and compliance (GRC) capability depends on the same architectural artefact: an engineer- and AI-verified data flow map. Without it, penalty exposure compounds across every dependent control.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
Pattern 02 · DPDPA Transformation

Reference data is one firmwide source of truth, not survey free-text

Without one governed source of reference data, the same retention conflict is answered differently in every team.

A Field NoteSources: RBI · IRDAI · SEBI · sectoral statutesReading time · 2 min

DPDPA does not arrive on a clean slate. RBI Master Directions on cyber security and IT governance1, IRDAI Information and Cyber Security Guidelines2, SEBI's Cyber Security and Cyber Resilience Framework3, the Income Tax Act, the Companies Act, FEMA, and the Prevention of Money-Laundering Act4 each prescribe how customer data must be stored, retained, audited, and reported. Retention floors of five, six, eight, ten years frequently conflict with DPDPA's erasure obligations. The Act's §16 cross-border transfer mechanism adds a further dimension — restrictions on transfer to specified countries, by Central Government notification — and the notifications are still being finalised, leaving cloud, payment, and SaaS architectures exposed to localisation requirements that may shift.

Reconciling the stack is not a free-text task. Without firmwide reference data — system names, vendor names, data categories, and applicable regulations all governed and reconciled centrally — each conflict gets resolved locally, by whoever filled the cell. Compliance becomes a function of authoring, not governance.

Reference data sits in a layer of its own — a metadata management foundation — separate from the data flow map. The map records what flows where; the metadata layer records what each attribute means, who owns it, what its valid values are, what its retention rule is, what its consent linkage is. Two systems holding the same logical attribute under different names produce a misleading map; one logical attribute mapped under two different names produces an ambiguous register.

The discipline is federation, not duplication. Where authoritative metadata already lives in the bank's domain systems — security catalogue, contract management, IDM, HR — the layer reads via API and preserves domain governance. The DPO curates the DPDPA-relevant view; domain owners remain owners of their categories. Where retention rules conflict — DPDPA erasure against tax, AML, and Companies Act floors — the layer holds every rule simultaneously and applies the most restrictive.

Footnotes & Sources
  1. Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices, and the Master Direction on Outsourcing of Information Technology Services. Reserve Bank of India, 2023. rbi.org.in
  2. Information and Cyber Security Guidelines for the insurance sector. Insurance Regulatory and Development Authority of India. irdai.gov.in
  3. Cyber Security and Cyber Resilience Framework. Securities and Exchange Board of India. sebi.gov.in
  4. Prevention of Money-Laundering Act, 2002 (Department of Revenue, Ministry of Finance), the Income Tax Act, 1961, and the Companies Act, 2013, each prescribe retention floors of five to ten years for specified records.
Pattern 03 · DPDPA Transformation

Capture is solved; fulfilment is engineering

Capturing a rights request is the easy part; fulfilling it means reading, updating or deleting personal data across hundreds of systems.

A Field NoteSources: DPDPA 2023 · DPDP RulesReading time · 2 min

The Act gives every data principal the right to access, correct and erase their personal data1, on deadlines fixed by the Rules2. The common answer is to buy a service-request platform — a portal that captures each request and counts down the clock. But capturing a request is not fulfilling it: fulfilment is an operation on personal data scattered across hundreds of internal and external systems.

Read, update, delete — that is what the three rights demand. An access request is a read: the data principal's personal data gathered from every system that holds it. A correction is an update: the same change made everywhere the record exists. An erasure is a delete: the record removed from each system, and from the processors it was shared with. The portal does none of it.

Behind the three sits a fourth operation — create. Every system that writes its own copy of personal data enlarges the footprint a later read, update or delete must cover; uncontrolled creation makes the other three impossible to complete. And the footprint keeps shifting — data principals come and go, consents are granted and withdrawn — so fulfilment has to stay correct on its own, continuously, not by a manual sweep after each change.

Capture is a solved problem. The request portal, the case-management workflow, the deadline tracker — most banks already run mature versions for grievance and operations. Fulfilment is the opposite — per-system engineering that no service-request product performs — and the gap between the two is where most rights programmes fail. An SDF that buys the portal and stops there has bought a clock, not compliance.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
  2. Digital Personal Data Protection Rules, 2025 (as published by the Ministry of Electronics and Information Technology). meity.gov.in
Pattern 04 · DPDPA Transformation

A consent change must reach the data plane, not just the banner

Capturing consent is solved; enforcing it across operational systems as it changes is where most programmes stop short.

A Field NoteSource: DPDPA 2023Reading time · 2 min

Consent is captured under the Act1 in a notice-and-consent flow every consent management vendor solves. Enforcement is the harder problem: when a data principal modifies or withdraws consent, the change has to flow into the CRM, the marketing tools, the analytics pipeline, partner integrations, and offline batch jobs that already pulled yesterday's snapshot.

That is a synchronisation problem. Every operational system that processes the personal data must stay in step with the data principal's current consent — the moment consent changes, what each system may do changes with it. A consent decision has to alter processing, not just the banner.

Children's data raises the stakes. The Act requires verifiable parental consent and forbids behavioural monitoring or targeted advertising of minors — but enforcing any of it depends on knowing which records belong to children, and that is rarely settled at source: date-of-birth fields are inconsistent, missing, or self-declared.

The common mistake is to treat the consent platform's UI as the compliance surface. The platform records the decision; it does not carry it down to the data plane, where the processing actually happens. And that is what the Data Protection Board examines — not whether the banner displayed, but whether processing changed. We did not know is not a defence it is likely to accept.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
Pattern 05 · DPDPA Transformation

Beyond RoPA, every major obligation rests on the same foundation

Each obligation is handed to a different tech team; the foundation they all depend on is built, if at all, in fragments.

A Field NoteSource: DPDPA 2023Reading time · 2 min

RoPA is where the data foundation first proves it is needed — and it is not where the need ends. The Act's reasonable-security obligation, its data audits, its children's-data controls and its breach-reporting duties1 each carry a penalty, and each rests on the same thing: a verified picture of where personal data lives and how it moves. Without it, a security safeguard cannot be evidenced and a breach cannot be scoped.

Yet the foundation is rarely built as one thing, because the technical work is rarely owned as one thing. In a typical SDF the effort is parcelled out — one team procures a rights-request platform, another works only with the CISO on security controls, a third runs a data-discovery project, a fourth owns “privacy”. Each builds what its own slice needs.

So the shared foundation is built several times over, partially, or not at all — and every provision that depends on it inherits the weaknesses. This is a failure of ownership, not of skill: the SDF has capable technical teams but no unified technical owner for the DPDPA architecture. The CTO and CISO between them hold every part of the answer, and an org chart that keeps the parts apart.

Built once, under one technical owner, that foundation serves every obligation at once. The provisions are many; the foundation is one; the open question is whether anyone owns it.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
Pattern 06 · DPDPA Transformation

On this calendar, AI is the difference between finishing and not

Survey-built RoPA and waterfall delivery cannot finish before May 2027 — and the date will not move.

A Field NoteSource: DPDPA 2023Reading time · 2 min

The volume of DPDPA work is set by the Act1; so is the deadline. The one variable still open to an SDF is method — and the methods most teams are using will not finish the work in time.

Take RoPA. The usual method is the survey — teams across the bank describe, by hand, the personal data their systems hold. At the scale of an SDF, hundreds of systems, the survey is slow to gather and slower to reconcile, and it is out of date before it is signed off. AI given access to the systems builds the same record far faster, and rebuilds it as the systems change.

The same choice runs through the build. The software DPDPA needs — consent capture, rights handling, retention controls — is still mostly specified on assumptions and delivered waterfall-fashion, one sequential stage after another. Used well, AI compresses research, design and development together: faster, at lower cost, and without trading away quality.

AI is not the upside on a DPDPA programme. On this calendar, it is the difference between a programme that finishes and one that does not.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
Pattern 07 · DPDPA Transformation

The board carries the penalty; the programme has no defined owner

Reviewed at every steering meeting and owned at none, DPDPA is run as a project to delegate, not a transformation to lead.

A Field NoteSource: DPDPA 2023Reading time · 2 min

DPDPA's penalties are board-scale: a single failure of reasonable security safeguards carries exposure of up to ₹250 crore1, and the board answers for it. Yet most boards meet that exposure the way they meet any compliance task — they delegate it, set a budget, and review it monthly. A project is given a project manager; a transformation needs an owner — one accountable person with authority across legal, technology, security and risk. Boards appoint the first and rarely the second.

Without a defined owner, the work has no centre. Functions deliver their own parts and report them complete; the architecture that should join the parts goes unplanned. The board reads five green status lines — and a programme that is not, underneath, being built.

Attendance is mistaken for ownership. The board meets DPDPA through a monthly steering review — a consultant's slides, a status colour, a budget line — and rarely through the Act itself: the specific provisions, the penalty behind each, the architecture the deadline demands. A board that reviews the programme without reading the Act has held the meeting, not the accountability.

DPDPA is not a compliance task the board can delegate, budget and review like the rest. It is a transformation the board has to own — which, concretely, means naming one person accountable for the whole, with the authority to direct the functions the Act touches. Until then, the penalty stays the board's, and the programme's owner stays undefined.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
The Legal Front · DPDPA Transformation

DPDPA transforms every data processing activity, not just the privacy policy

Complying reaches every processing purpose, every retention rule and every vendor contract — inside the enterprise and beyond it.

A Field NoteSources: DPDPA · DPDP Rules · RBI · PMLAReading time · 2 min

The Digital Personal Data Protection Act, 2023 (DPDPA) is why a Significant Data Fiduciary (SDF) opens a programme — not the whole of it. What follows is a legal transformation: the basis on which the SDF processes personal data has to be rebuilt across every internal system and every external transfer.

Start inside the enterprise. DPDPA permits personal data to be processed only for a declared purpose, and only on a lawful basis — the data principal's consent, or one of the Act's narrow legitimate uses1. For most of an SDF's processing, neither has ever been recorded; the systems predate the law that now requires both. Customer data that moved freely between the master, the transaction store and the KYC repository now needs a purpose, a notice and a consent record2 — and the processing must stop the moment consent is withdrawn.

The same rule reaches AI. Personal data fed to an AI model — one the SDF runs itself, or one a vendor runs for it — is processed for a purpose of its own. An SDF may decline to adopt AI; the purpose still has to be declared.

Retention is where the conflict sharpens. When a customer withdraws consent, DPDPA requires the Data Fiduciary to delete their personal data — unless another law compels keeping it. The RBI mandates KYC records held for five years after the relationship ends3, and anti-money-laundering law adds its own five-year mandate4. One record can then sit under both an erasure duty and a retention floor, and which obligation prevails is a per-record reading of two statutes.

Now turn outside. An SDF runs around 200 vendor relationships that touch personal data — payment processors, KYC providers, cloud platforms, analytics tools. Each vendor is a Data Processor under the Act, and each contract has to become a data-sharing agreement that carries the Data Fiduciary's duties: breach-notification timelines, sub-processor disclosure, erasure on instruction, audit rights1. These clauses did not exist in the legacy contracts, and every one has to be reopened.

This is legal work that legal cannot finish alone. The purpose labels, consent records and retention rules only hold once engineering wires them into operational systems; the DPO's regulatory artefacts are built on that foundation. Legal interprets the Act for both; in turn, both tell legal what the systems can enforce. Treated as a documentation exercise, the programme yields binders that do not survive a Data Protection Board audit.

DPDPA is not a standalone project an SDF completes and closes. It is a transformation of how the enterprise processes personal data — continuous, cross-functional, absorbed into the operating model. And it is one of three: the legal work cannot run ahead of the engineering that enforces it or the AI that reconciles its instruments, and all three are bound to one May 2027 deadline.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
  2. Digital Personal Data Protection Rules, 2025. Ministry of Electronics and Information Technology, Government of India. meity.gov.in
  3. Master Direction — Know Your Customer (KYC) Direction, 2016 (as amended); records retained for five years after the business relationship ends. Reserve Bank of India. rbi.org.in
  4. The Prevention of Money-Laundering Act, 2002, and the Prevention of Money-Laundering (Maintenance of Records) Rules, 2005, which require specified records to be retained for five years. Department of Revenue, Ministry of Finance, Government of India. indiacode.nic.in
The Technical Front · DPDPA Transformation

Architecture sets DPDPA's technical cost, not procurement

Compliance carries a one-time cost and a recurring one — architecture decides both.

A Field NoteSource: DPDPA 2023Reading time · 2 min

Faced with the technical side of DPDPA1, many SDFs reach first for procurement — a platform for rights requests, a consent-management suite, a privacy tool with its own audit trail. But ticketing, consent capture and audit logging are problems a bank solved years ago. Buying them again adds licence fees and another system to operate; it does not add compliance.

The transformation lies elsewhere. The work DPDPA actually demands — locating personal data, enforcing consent and retention, carrying rights into operational systems — is largely technical: the governance, risk and compliance controls (GRC) that protect that data and govern its use live in the systems; people follow procedure. And those controls keep shifting — consent is granted and withdrawn; relationships with Data Principals and Data Processors begin and end — so the engineering tracks a moving target, not a fixed one.

Every obligation in the Act resolves, technically, to a control in a specific system. Traditionally GRC is a framework the risk function documents and attests to; under DPDPA it has to be controls the systems themselves enforce, on every system that touches personal data. The work is not the IT department's alone — the controls are risk's to define and engineering's to build, and both rest on the personal data the business's products run on. That shift — from a documented framework to enforced controls, owned across the org chart rather than in one function — is the technical transformation.

What that engineering costs is set by how it is organised. Redundant effort, throwaway artefacts, duplicate integrations, surplus teams and systems — each is a cost; the shape of the work decides how many of them an SDF carries.

And these costs do not stop at go-live. Every system added, every data copy kept, every integration left running becomes permanent operating cost — cloud storage, compute, support, and the complexity of one more system that can fail. A programme judged only by its project budget misses the larger figure: the SDF's cost base, recurring for every year the controls run.

So the technical cost is set by engineering choices, not by procurement choices. What to build, what to integrate, what to leave running — each decision shapes both the project budget and the recurring cost base.

DPDPA's technical work is not a tool stack an SDF assembles. It is a transformation of the engineering that holds every system touching personal data — continuous, infrastructural, written into the controls themselves. And it is one of three: the technical work cannot be designed without the legal transformation that sets what it must enforce, or the AI one that decides whether it can be delivered in time, and all three are bound to one May 2027 deadline.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
The AI Front · DPDPA Transformation

AI reshapes the DPDPA programme, not just accelerates it

It is how the May 2027 deadline is met — and, once it processes personal data, an obligation in its own right.

A Field NoteSource: DPDPA 2023Reading time · 2 min

AI is already remaking how organisations operate, welcome or not. Inside a DPDPA programme1 it arrives from two directions at once: the practical means of doing the work within the May 2027 window, and — as personal data flows into models the SDF runs and models its vendors run — something the programme must itself govern. Most programmes plan for the first and are caught out by the second.

Take the means first. The arithmetic is unforgiving: a single integration change runs about three months, and 200 of them is some 600 integration-months — more than the calendar holds. AI changes that arithmetic. It writes the software the programme needs — consent UIs, rights endpoints, migration scripts — in a fraction of the time; it inspects the UI fields, APIs, databases, logs and files of hundreds of systems to propose and verify the data flow map; and it reconciles DPDPA's erasure duties against the sectoral and tax-retention floors. People alone cannot meet both the depth and the cadence.

This moves the bottleneck. The constraint is no longer competence or compute — it is access: which systems the AI may read, under what governance, with what audit trail. Clearing that perimeter is a security workstream of its own, and it needs top-down sponsorship.

The second direction is newer. The moment personal data flows into a model — for fraud scoring, recommendations, any automated decision — DPDPA's purpose and consent rules govern that processing too. And AI does not forget on command: once personal data is built into a model's learned weights, it cannot be unpicked record by record the way a database row can. An SDF may decline to use AI in its own compliance programme; it cannot decide that AI stops processing the data it already touches.

AI is not a workstream the programme adopts after legal and tech. It is a transformation that runs through the programme — both the means by which the technical work meets the calendar, and a processing purpose the legal work must declare and govern. And it is one of three: AI does not queue behind the others, it is already inside both, and all three are bound to one May 2027 deadline.

Footnotes & Sources
  1. The Digital Personal Data Protection Act, 2023. Ministry of Electronics and Information Technology, Government of India. meity.gov.in/data-protection-framework
Corporate Transformation

The seventy per cent problem

Three decades after the figure first entered the management lexicon, large-scale corporate transformations still fail at roughly the same rate. The patterns of failure, however, are now uncomfortably well understood.

A Briefing NoteSources: McKinsey · BCG · HBRReading time · 4 min

The statistic has the durability of a cliché, which is partly why it works. Roughly seven in ten large-scale corporate transformations fail to meet their objectives — a figure first popularised by John Kotter in the Harvard Business Review in 19951 and since echoed, with remarkable consistency, by McKinsey2, the Boston Consulting Group3 and a long line of subsequent studies. What is striking is not that the number exists, but that it has barely moved.

Boards have spent a generation rebuilding operating models, layering in change-management offices and commissioning culture surveys. Spending on digital transformation alone is now projected to exceed three trillion dollars a year11. And yet BCG's most recent global analysis finds that only one in four transformations delivers value-creating, enduring change3. The arithmetic of failure is unforgiving — and oddly stable.

70%
Of transformations fail
to meet objectives2
1in 4
Deliver enduring,
value-creating change3
30%
Meet their stated
objectives4

Where the seventy per cent figure came from

The seventy per cent figure was, by Kotter's own framing, an estimate drawn from observation of more than a hundred companies attempting to remake themselves1. Beer and Nohria reinforced it five years later in their HBR essay Cracking the Code of Change, calling the failure rate “the brutal fact” of corporate reinvention5. McKinsey's practitioners — Harry Robinson and Jon Garcia among them — have subsequently treated the figure as the operating premise of an entire consulting practice26.

Sceptics rightly point out that the original number was never peer-reviewed. But the directional finding has held up across two decades of follow-up work, including studies by the Business Transformation Alliance, Towers Watson and Bain — the last of which puts the figure as high as 88 per cent7. Whether the true rate is sixty-five or seventy-five, the policy implication is the same: most attempts do not work.

The brutal fact is that about 70 % of all change initiatives fail.
— Beer & Nohria, Harvard Business Review, 2000

How transformations fail

Across the three principal sources, the recurring causes of failure converge on a small set of organisational pathologies. They are notable less for their novelty than for their persistence.

№ 01

Aspirations set by consensus, not data

Leaders default to numbers the executive team can agree on, rather than fact-based stretch targets grounded in the firm's full potential.6

№ 02

No compelling ‘why’

Protecting the bottom line rarely motivates the tens of thousands of employees who must change behaviour for the effort to take hold.6

№ 03

A weak guiding coalition

Chief executives fail to build conviction within their own teams, or model the new behaviours they ask of others.2

№ 04

Capability sat in the wrong seats

The people best placed to drive the work remain trapped in their day jobs and are never properly seconded to the transformation.2

№ 05

Activity mistaken for outcomes

Programme management becomes an end in itself; teams track milestones rather than the value those milestones were meant to create.6

№ 06

Underinvestment in behaviour

Budgets flow disproportionately to technology while the harder, slower work of culture and capability is treated as overhead.8

№ 07

Change fatigue

By the time the next initiative is announced, middle managers — having seen several before it — quietly disengage.9

№ 08

Treating it as an IT project

Digital transformation is, in McKinsey's formulation, 20% technology and 80% organisation. Most firms invert the ratio.8

№ 09

Communication that does not land

Inconsistent messaging across levels and the assumption that one announcement constitutes a strategy.10

№ 10

Quick-wins displacing endurance

Senior leaders declare victory at month nine on a programme that needed three years. The reversion is rapid.3

What the number really tells us

The persistence of the seventy per cent figure is itself the diagnosis. If three decades of frameworks, books and consulting hours have not moved the rate, the constraint is unlikely to be a missing methodology. It is, more plausibly, that transformation requires sustained executive attention — McKinsey finds transformations around two and a half times more likely to succeed when leaders spend more than half their time on the work10 — and that this is the single resource most chief executives are least willing, or able, to commit. The companies that beat the odds are not those that find a new model. They are those that take the old one seriously.

Footnotes & Sources
  1. John P. Kotter, “Leading Change: Why Transformation Efforts Fail,” Harvard Business Review, May–June 1995. hbr.org/1995/05/leading-change-why-transformation-efforts-fail-2
  2. Harry Robinson, “Why do most transformations fail? A conversation with Harry Robinson,” McKinsey & Company, 2019. mckinsey.com/capabilities/transformation/our-insights/why-do-most-transformations-fail
  3. Boston Consulting Group, “How CEOs Can Beat the Transformation Odds,” 2024. bcg.com/publications/2024/how-ceos-can-beat-the-transformation-odds
  4. McKinsey & Company, “The science behind successful organizational transformations.” The ~30% success rate against original objectives is the inverse of the 70% failure finding. mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations
  5. Michael Beer & Nitin Nohria, “Cracking the Code of Change,” Harvard Business Review, May–June 2000. hbr.org/2000/05/cracking-the-code-of-change
  6. Jon Garcia, “Common pitfalls in transformations: A conversation with Jon Garcia,” McKinsey & Company, 2022. mckinsey.com/capabilities/transformation/our-insights/common-pitfalls-in-transformations
  7. Bain & Company, “88% of business transformations fail to achieve their original ambitions; those that succeed avoid overloading top talent,” press release, April 2024. Based on Bain's database of more than 24,000 transformation initiatives. bain.com/about/media-center/press-releases/2024/88-of-business-transformations-fail-to-achieve-their-original-ambitions
  8. Paul A. Argenti and Jenifer Berman, “The Secret Behind Successful Corporate Transformations,” Harvard Business Review, September–October 2021. On the disproportion between technology investment and the organisational behaviour change that determines transformation outcomes. hbr.org/2021/09/the-secret-behind-successful-corporate-transformations
  9. Boston Consulting Group, “Changing Change Management: A Blueprint That Takes Hold.” bcg.com/publications/2012/change-management-postmerger-integration-changing-change-management
  10. McKinsey & Company, “The science behind successful organizational transformations.” Successful transformations report consistent communication around the changes being made and clearly defined roles and responsibilities; organisations with such disciplines are up to eight times more likely to succeed. mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations
  11. International Data Corporation, Worldwide Digital Transformation Spending Guide; see also Statista, “Worldwide digital transformation market size,” projecting global investment of around three trillion US dollars in 2025 (up from 1.8 trillion in 2022). statista.com/statistics/870924/worldwide-digital-transformation-market-size