India's DPDP Act Compliance Problem Is No Longer Legal. It's an Engineering Shortage.
Reporting on 14 September says India's DPDP Act compliance bottleneck moved from lawyers to engineers. The Rules explain why the gap is structural.
#India's DPDP Act Compliance Problem Is No Longer Legal. It's an Engineering Shortage.
Reporting published on 14 September 2026 makes a claim that should worry every board that has been treating DPDP Act compliance as a legal workstream: India has plenty of people who can tell you what the law requires, and almost nobody who can make a twenty-year-old core banking system forget a customer. The shortage is not of privacy lawyers. It is of engineers who can trace personal data through enterprise systems, wire consent withdrawal into every downstream process that consumed it, and produce machine-generated evidence that the deletion actually happened.
That distinction is not a talent-market curiosity. It is the difference between a compliant organisation and one facing penalties of up to ₹250 crore, because the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 were drafted in a way that makes most of the substantive obligations verifiable only in code.
#What the 14 September reporting actually found
A Times of India piece titled "From policy to code: DPDP creates new privacy roles," syndicated on 14 September and summarised the same day, quotes practitioners describing a transition that has caught Indian enterprises mid-stride.
Sachin Salian, Senior Vice President at Writer Information, framed it as organisations "moving from legal and advisory work to putting structured policies and controls in place" — a shift, in his words, from regulatory compliance to technical compliance. Srinivas L, Joint CEO and Managing Director at 63SATS Cybertech, was blunter about the supply side: "Most people are offering advisory services... but what is very scarce is engineering."
The most interesting observation came from Kapil Mahajan, Global CIO at Allcargo Group, who argued that AI has changed the underlying question. Access control asks who can read this record. Model governance asks what are we permitted to infer from it — a question that no access-control list answers and no privacy policy resolves.
The reporting carried no industry-wide headcount estimate, and the job-board numbers floating around should be read with caution: Glassdoor listed roughly 10,100 privacy roles in India as of September 2026, and foundit surfaced over 5,700 postings specifically naming DPDP Act expertise. Aggregator counts double-count and decay slowly. What they do reliably indicate is direction, and the direction is that demand has outrun the advisory-shaped supply.
#Why DPDP Act compliance is an engineering problem by statutory design
This is not a case of industry over-engineering a paperwork law. Read the operative provisions and the engineering burden is explicit.
Section 8(7) makes erasure a distributed-systems problem. The text obliges a Data Fiduciary, unless retention is legally required, to "(a) erase personal data, upon the Data Principal withdrawing her consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier; and (b) cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing to such Data Processor."
Clause (b) is the one that breaks architectures. It is not enough to delete the row in your primary database. You must cause erasure at every processor you handed the data to — the analytics vendor, the cloud CRM, the outsourced KYC agency, the marketing automation platform. In practice that means an erasure event has to fan out across system boundaries you do not control, and come back with an acknowledgement you can show a regulator. Very few Indian enterprises have built that fan-out. Almost none have built it for the derived copies: the data lake extract, the nightly backup, the feature store that trained last quarter's credit model.
Rule 6 turns security into a logging obligation. The reasonable security safeguards prescribed under Rule 6 are not aspirational language. They enumerate encryption in storage and transit, access controls, masking or anonymisation where contextually appropriate, monitoring of access and processing, documented incident response, contractual pass-through of equivalent safeguards to processors — and, critically, retention of logs and associated data for one year for the purpose of detecting, investigating and remediating unauthorised access. A one-year log retention mandate is a storage-and-pipeline design decision, made by an engineer, with a budget line.
Rule 13(3) asks for something the industry has no accepted method to produce. The additional obligations of a Significant Data Fiduciary include due diligence "to verify that technical measures including algorithmic software adopted by it for hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing of personal data processed by it are not likely to pose a risk to the rights of Data Principals."
Consider what that sentence actually demands. An SDF must audit its own algorithmic software for risk to data principal rights. There is no notified methodology. No Board-issued standard. No safe harbour. The obligation lands squarely on whoever can read the model, understand the training pipeline, and reason about what the system infers — which is an engineering skill set that Indian compliance teams largely do not employ, and Indian law firms cannot supply.
#The DPIA is an audit, not a document
Rule 13(1) requires a Significant Data Fiduciary to undertake a Data Protection Impact Assessment and an audit once every twelve months from the date it is notified as an SDF. Rule 13(2) then requires that the person carrying out that DPIA and audit furnish a report of significant observations to the Data Protection Board of India.
That second clause is the one that converts the DPIA from an internal memo into a regulatory filing. An assessment whose findings go to the regulator has to be defensible, and a defensible finding about whether consent withdrawal propagates correctly is not an opinion — it is a test result. You either have logs showing the erasure cascade completing across processors, or you have a paragraph asserting that it does.
Failure to observe the Section 10 obligations of a Significant Data Fiduciary attracts a penalty of up to ₹150 crore. Failure to maintain reasonable security safeguards under Section 8(5) attracts up to ₹250 crore. Failure to notify a personal data breach, and failures relating to children's personal data under Section 9, each attract up to ₹200 crore. These are the numbers that make the staffing question a board question.
#Two clocks, 59 days and 240 days
The urgency is arithmetic. From today, 15 September 2026:
- 13 November 2026 — 59 days away. The consent manager provisions take effect, opening registration with the Data Protection Board for entities that want to operate as consent managers. Registration requires India incorporation and a minimum net worth of ₹2 crore, which structurally excludes foreign privacy platforms from holding the registered role. This is also the date most advisers treat as the practical deadline for SDF-adjacent governance appointments, including a India-based Data Protection Officer, regardless of when the government formally notifies the SDF list.
- 13 May 2027 — 240 days away. The end of the eighteen-month transition that began when the DPDP Rules were notified on 13 November 2025. Notice, consent, security safeguards, data principal rights, breach notification and the associated penalties all become enforceable.
Eight months is not a long runway for building consent propagation into a mainframe. It is, however, exactly long enough for an organisation to discover in month seven that its erasure workflow silently fails against a processor contract signed in 2019.
#The regulator-shaped hole in the middle of this
There is a real asymmetry worth naming. While enterprises are being told to engineer for a May 2027 deadline, the body that will judge their work does not yet exist in operational form.
MeitY invited applications for the Chairperson and Members of the Data Protection Board of India by notification dated 6 May 2026, followed by a further communication on 6 June 2026. As of mid-September 2026, the search-cum-selection committees appear to remain at the stage of soliciting names, and no Chairperson or Member has been appointed. No adjudicatory orders exist. No Board-issued technical standards for consent managers have been published.
This cuts both ways for Indian businesses. The absence of enforcement in 2026 is why a compliance-as-documentation posture has survived this long. It is also why the engineering backlog has been allowed to accumulate unpriced — and why the organisations that wait for the Board to publish a methodology before hiring will be starting their build after the clock runs out.
The one substantive piece of technical guidance the government has issued, the Business Requirement Document for consent management systems released by MeitY through the National e-Governance Division, is expressly non-binding. It is a blueprint, not a standard. It covers consent lifecycle management, the data principal dashboard, notifications and grievance redress — useful scaffolding, and a reasonable place for an engineering team to start, but it does not tell you how to prove to an auditor that a withdrawal propagated.
#What this means if you run an Indian business
The practical reading of the last 48 hours is that the compliance gap has relocated, and the hiring plan most organisations wrote in 2025 is now aimed at the wrong role.
Four things are worth doing before November:
- Find out whether your erasure actually works. Not whether you have a policy. Run a consent withdrawal for a real test identity and trace where the record survives — backups, warehouse extracts, vendor systems, training datasets. The output of that exercise is your Section 8(7) exposure, quantified.
- Instrument before you attest. Rule 6's one-year log retention and Rule 13(2)'s report-to-the-Board requirement both assume machine-generated evidence. If a control cannot emit a log, it cannot survive an audit whose findings go to the regulator.
- Inventory your inference surface, not just your data stores. Mahajan's point about governing intelligence rather than protecting data is the sharp end of Rule 13(3). Every model that consumes personal data is in scope for algorithmic due diligence, including ones that were deployed before anyone read the Rules.
- Decide your consent manager posture now. With registration opening on 13 November, the choice between building an in-house consent management system, integrating with a registered consent manager, or doing both is an architecture decision with a two-month lead time, not a procurement question for next year.
For citizens, the practical effect is less abstract than it sounds. The rights the DPDP Act grants — to withdraw consent, to have data erased, to get a grievance addressed — are only as real as the systems behind them. A right to erasure that a company cannot technically execute is a right that fails quietly, without a denial letter, which is precisely the failure mode that produces no complaint and therefore no enforcement.
#The gap is real, and it is not going to be advised away
The most useful thing about the 14 September reporting is that it names a problem the compliance market has an incentive to obscure. Advisory work scales; engineering does not. A firm can produce fifty gap assessments in the time it takes one team to make consent withdrawal propagate correctly through a legacy estate. The result is an Indian market with an oversupply of documents describing what DPDP Act compliance requires and an undersupply of systems that do it.
Nothing in the Act or the Rules will close that gap for you. Rule 13(3) will not acquire a methodology before May 2027. The Board will not publish a reference implementation. The organisations that end the transition period compliant will be the ones that treated the last eight months as a build, and staffed it accordingly.
Working through DPDP Act compliance? Our resources library breaks down the DPDP Rules 2025 obligation by obligation, with the operational questions each one actually asks of your systems. If consent architecture is your immediate problem, start with the consent manager guide — the 13 November registration window is 59 days out, and the design decisions you make now determine what you can prove in 2027.
Sources: Times of India, "From policy to code: DPDP creates new privacy roles" (14 September 2026, syndicated); DPDP Rules 2025, Rule 6; DPDP Rules 2025, Rule 13; MeitY Business Requirement Document on Consent Management Systems; nasscom on DPBI appointments; LiveLaw on the Board's status.