The DPDP Operating Model

Most organisations have approached the Digital Personal Data Protection Act, 2023 the way they approach any new regulation. They appoint a lead, commission a gap assessment, draw up a plan, and work through it until the deadline. That approach is sensible for getting started. It is a poor way to stay compliant.

The DPDP Act is written around ongoing conduct. Consent has to be given, recorded and withdrawn as people change their minds. Rights requests arrive every week. Breaches have to be reported as they happen. Personal data has to be erased when the purpose ends, which is a different date for every record. None of this finishes on 13 May 2027. That is the date it starts.

Organisations that treat DPDP as a project tend to follow a familiar pattern. The register is built, the notices are written, the consent screens go live, and the programme team moves on. Within a year, the register no longer matches the business. New products collect data the notices don't mention. Vendors have changed. The person who knew how the rights process worked has left. The organisation is less compliant than it was on the day the project closed.

This paper sets out an alternative: an operating model that runs data protection as a standing function, with clear capabilities, owners, records and metrics. It is written for the people who have to make it work: Chief Information Security Officers, Data Protection Officers, General Counsel, Chief Risk Officers and the business leaders who own the data. It draws on the text of the Act and the DPDP Rules, 2025, on the practical experience of DPDP assessments and implementations in regulated Indian enterprises, and on what has been published about the Act's rollout up to October 2026.

The paper is not legal advice. Where a point depends on specific facts, organisations should take advice on their own situation.

The Act received Presidential assent on 11 August 2023. Its operation was left to be switched on in stages by notification. The DPDP Rules were notified on 13 November 2025, and the notification set out three phases.

Three features of the current position shape how organisations should plan.

The date is holding. In August 2026, reporting on remarks by the MeitY Secretary said there would be no extension for startups. Around the same time, the Cabinet Secretary put Union ministries and state governments on compliance timelines. Large private organisations are planning accordingly. In September 2026, Business Standard reported that the State Bank of India had procured the software and hardware it needs and expects to be compliant by the end of December 2026.

The Board is not yet staffed. The Data Protection Board of India exists in law. On the public record as of September 2026, it has no appointed Chairperson or Members. MeitY began the appointment process in May 2026. The gap affects when the Board can begin hearing complaints. It does not affect when the obligations apply, and conduct from 13 May 2027 can be examined whenever the Board begins work.

The market is crowded and uneven. Platforms, consultancies and training providers have launched DPDP offerings at pace, and many publish guidance. Some of it is accurate. A good deal repeats errors carried over from the GDPR or from the draft Rules of January 2025, such as penalties calculated on turnover, a seventy-two-hour deadline for telling affected customers, or a right to data portability. Organisations need to check the readings their programmes are built on.

An operating model is needed because the conditions that make an organisation compliant change constantly. Five sources of decay show up in almost every enterprise.

Processing changes. New products are launched, old ones retired, journeys redesigned. Each change can add a purpose, a data category or a recipient that the processing record and the notices don't reflect. In a large organisation, this happens every week.

Systems change. Data is migrated to new platforms, copied into analytics environments, exported for one-off projects and left in shared folders. The places where personal data sits multiply faster than any manual inventory can follow.

Vendors change. Contracts are renewed, renegotiated or replaced. New software brings new sub-processors. A processor that was compliant last year may now process data in a different country, or through a new partner.

People change. Data owners move roles. The privacy lead leaves. Front-line staff who were trained on the new notices are replaced by staff who weren't. Knowledge held in people's heads leaves with them.

The law moves. The Rules can be amended. The government can notify restrictions on transfers to particular countries under Section 16. The Board will issue directions and decisions that clarify how the Act is read. Sector regulators issue their own rules on top.

An organisation that does nothing to counter these forces will drift out of compliance at a steady rate, whatever state it was in on the day its project closed. An operating model is the set of routines that pushes back against that drift.

The obligations of the DPDP Act can be organised into six capabilities. Each is a set of routines that runs continuously, with a clear owner, a defined output, and records that show it is working.

The capabilities form a loop. Assurance feeds back into knowing the data, because every review finds something the inventory missed.

1. Know the data

What the Act requires. Lawful processing under Section 4 depends on knowing what is processed and why. Section 8(7) requires erasure when the purpose ends, which depends on knowing where the data sits. Section 11 requires an organisation to tell a person what data it holds about them and who it has shared it with. None of these can be met without an accurate picture of the data.

What runs. Discovery scans of systems that hold personal data, repeated on a schedule, to find where identifiers sit, including copies in exports, backups, file shares and laptops. A processing record that lists every activity with its purpose, data categories, populations, systems, recipients, cross-border flows and retention rule. Registers of systems and of third parties. A change routine that brings new products, systems and vendors into the record before they go live.

Who owns it. Data owners in each business function own the activities they run. The privacy office maintains the framework and challenges gaps. IT and security own the discovery tooling.

What proves it. A versioned processing record, with each change dated and attributed. Scan results showing coverage of systems and what was found. Evidence that new products passed a privacy review before launch.

The common failure. Building the record from interviews alone. People describe the systems as they believe them to be. Scans find what is actually there, including data nobody remembers putting in.

2. Justify each use

What the Act requires. Every processing activity needs one lawful ground: consent under Section 6, a legitimate use under Section 7, or an exemption under Section 17. There is no legitimate interests ground. Data obtained before the Act needs a fresh notice under Section 5(2).

What runs. A lawful-basis register that assigns exactly one ground to each activity, with the reasoning recorded. Rules that prevent common errors, such as marketing claiming a legitimate use or employment processing being stretched to cover non-employees. A review whenever an activity's purpose changes. Reconciliation of retention against sector laws that require records to be kept longer.

Who owns it. Legal and compliance decide the basis. Data owners confirm that the description of the activity is accurate. The privacy office keeps the register consistent.

What proves it. The register itself, versioned, with each decision dated and signed off. A record of activities that were found without a lawful basis and what was done about each.

The common failure. Copying a register built for the GDPR. Activities filed under legitimate interests, or under "contract" in ways the DPDP Act doesn't recognise, need to be moved to consent or to a specific Section 7 use.

3. Inform and record choices

What the Act requires. Section 5 and the Rules require a notice, given with or before a request for consent, that itemises the data and the purposes, explains how to withdraw consent and exercise rights, and tells the person how to complain to the Board. The notice must be available in English or any of the twenty-two languages in the Eighth Schedule, at the person's choice. Consent under Section 6 must be free, specific, informed, unconditional and unambiguous, and withdrawal must be as easy as giving it. Section 6(10) puts the burden of proving notice and consent on the Data Fiduciary.

What runs. A library of notices, versioned, with translations reviewed by a person before publication. Consent capture in every channel where data is collected: web, app, branch, call centre and partner journeys. A record for each choice, holding the person, the purpose, the notice version, the exact text shown, the language, the channel and the time. Withdrawal that takes effect at once and reaches every system and processor that uses the data. Re-consent when a notice changes materially. Re-notice campaigns for legacy data.

Who owns it. Product and channel owners own the journeys. Marketing owns the purposes that rely on consent. The privacy office owns the notice library. Technology owns the records and the integrations.

What proves it. Consent records that cannot be edited after the fact, linked to the notice version shown. Logs showing when a withdrawal reached each connected system. Campaign records for legacy re-notices, including every answer received.

The common failure. Treating consent as a screen rather than a record. A consent banner proves nothing if the organisation cannot show what a specific person saw and chose, or that processing stopped when they withdrew.

4. Respond to people

What the Act requires. Section 11 gives a right of access, including the identities of every Data Fiduciary and Data Processor with whom data has been shared. Section 12 gives rights of correction, completion, updating and erasure, subject to retention required by law. Section 13 requires a grievance mechanism, and people must use it before complaining to the Board. Section 14 gives a right to nominate. The Rules set an outer limit of ninety days for responses, and the organisation must publish its own timeline.

What runs. A channel through which people can make requests, in their language, with identity verification before anything is disclosed or changed. Routing of each request to the owners of the systems that hold the person's data. Clocks that warn before the published timeline lapses. A way to decline erasure where law requires retention, with the reason explained to the person. A grievance process with escalation and a record of each resolution.

Who owns it. The DPO or designated contact owns the process and its timeliness. System owners fulfil the requests for their systems. Customer service handles the conversation with the person.

What proves it. A record of each request from receipt to closure, with the actions taken in each system and the response sent. Statistics on volumes, response times and overdue items. Evidence that grievances were resolved within the published timeline.

The common failure. Answering access requests from memory or from one system. Section 11 requires a complete answer, including recipients, which depends on the processing record and the third-party register being accurate.

5. Protect and report

What the Act requires. Section 8(5) requires reasonable security safeguards to prevent personal data breaches, and failure to take them carries the highest penalty in the Schedule, up to ₹250 crore. Rule 6 sets out what reasonable safeguards include, among them encryption, obfuscation or masking, access controls, logging and monitoring, and backups, with logs retained for one year. Section 8(6) and Rule 7 require breaches to be reported to the Board and to affected people without delay, with a detailed report to the Board within seventy-two hours. Section 8(2) requires processors to be engaged under a valid contract.

What runs. Safeguards applied wherever personal data sits, verified by testing rather than assumed. Monitoring that can detect unauthorised access to personal data. An incident playbook that runs the CERT-In six-hour clock, the DPDP clock and any sector regulator's clock from the same moment, with named decision-makers and approved templates. Regular tabletop exercises. Processor contracts with DPDP terms, questionnaires on each processor's safeguards, and reviews when vendors change.

Who owns it. The CISO owns safeguards and incident response. Procurement and legal own processor contracts. The DPO owns notifications to the Board and to people.

What proves it. Test results showing safeguards are in place on systems holding personal data. Incident records with timestamps for each notification. Exercise reports and the changes made afterwards. Signed processor contracts and completed questionnaires.

The common failure. Assuming that existing security certifications cover the DPDP Act. They help, but they are organised around information security in general. The DPDP question is narrower and harder: wherever personal data sits, is it protected there, and could the organisation report a breach of it within the required windows?

6. Assure

What the Act requires. Section 8(1) makes the Data Fiduciary responsible for compliance, including for processing carried out by its processors. Section 8(4) requires appropriate technical and organisational measures to ensure effective observance of the Act and Rules. Significant Data Fiduciaries must carry out periodic impact assessments and audits under Section 10. Section 33(2) makes mitigation a factor in every penalty decision.

What runs. Periodic testing of controls against the Act's obligations, graded by the evidence behind each result. Tracking of findings to closure, with owners and dates. Reporting to senior management and the Board. For Significant Data Fiduciaries, an annual impact assessment and independent audit. A record of the organisation's compliance effort that can serve as evidence of mitigation if it is ever needed.

Who owns it. The DPO or privacy office owns the assurance programme. Internal audit provides independent challenge. The Board receives the results and holds management to account.

What proves it. Assessment reports with findings graded by evidence, the remediation record, and the history of Board reporting.

The common failure. Relying on self-assessment. Questionnaires answered by the people responsible for a control tell the Board what those people believe. Testing on real records tells it what is true.

An operating model only works if responsibilities are clear. The DPDP Act names some roles directly and leaves others to the organisation.

The Board. Directors are not named in the Act's obligations, but the Data Fiduciary is accountable, and the Board oversees the Data Fiduciary. For a Significant Data Fiduciary, the Act requires the Data Protection Officer to be responsible to the Board of Directors or a similar governing body. In practice, the Board should approve the data protection policy, receive regular reporting, and ensure the function has the resources it needs.

The Data Protection Officer or contact person. Every Data Fiduciary must publish the business contact details of a person who can answer questions about its processing of personal data, under Section 8(9). For a Significant Data Fiduciary, that person is a Data Protection Officer based in India. Either way, this role owns the relationship with Data Principals and, in time, with the Board.

The privacy office. A small central team designs the framework, maintains the registers and notice library, runs assurance, and challenges the business. It cannot own every activity. Its job is to make sure owners do.

Data owners. Each business function owns the processing it carries out: the purposes, the data, the systems and the vendors. Only owners can keep the processing record true, because only they know when their processing changes.

Technology and security. IT owns the systems, integrations and records that make the model work. Security owns safeguards and incident response.

Procurement and legal. Procurement brings new vendors into the third-party register and ensures DPDP terms are in contracts. Legal owns lawful-basis decisions, notices and the reading of the law.

The DPDP Act shifts the question from "do you have a policy?" to "can you show what happened?". Two provisions make this explicit.

Section 6(10) provides that where consent is the basis for processing, the Data Fiduciary must prove that a notice was given and consent was given in accordance with the Act. If a person says they never agreed, the organisation has to show otherwise.

Section 33(2) requires the Board, when deciding a penalty, to have regard to factors including the nature, gravity and duration of the breach, the type of data affected, whether the breach was repeated, and the action taken by the Data Fiduciary to mitigate its effects, including how timely and effective that action was.

Both reward organisations that keep records as a matter of routine. An evidence layer is the set of records each capability produces, designed so that they can be relied on later.

Four properties make records reliable.

They are created as a by-product of the work. Evidence assembled after the fact is weaker and more expensive. A consent record created at the moment of choice is better evidence than a log compiled for an investigation.

They cannot be quietly changed. Consent records should be append-only, with corrections recorded as new entries. Registers should keep every version. Where it matters, records can be linked so that any alteration is detectable.

They carry their context. A record of consent is only useful if it shows which notice was displayed. An assessment result is only useful if it shows what was tested and how.

They say how they were established. Some facts are observed directly, some are inferred, and some rest on what someone said. Records should make the difference visible, so that nobody mistakes an assertion for a tested fact.

Boards need a small number of measures that show whether the function is working. The most useful ones measure coverage and speed, because those are what the Act tests.

Two cautions apply. First, metrics should come from the operating records, not from separate reporting exercises, or they will drift from reality. Second, a metric that is always green deserves scrutiny. A rights process with no overdue requests and no grievances may be working well, or it may be invisible to the people it is meant to serve.

Organisations don't move from nothing to a fully embedded operating model in one step. It helps to describe the stages in between, so that progress can be measured and the next step is clear.

Most Indian enterprises in late 2026 sit between the first and second stages. Some have completed a gap assessment and are documenting. Few are operating. The thirty-week plan later in this paper is designed to reach the third stage by 13 May 2027, with the fourth following in the first year of enforcement.

The distinction between the second and third stages is the one that matters most. A documented organisation can describe its compliance. An operated organisation can show it, for a specific person, on a specific date. That is the standard the Act sets.

The DPDP Act applies across sectors, but every regulated sector adds its own requirements. The operating model has to reconcile the two, not run them as separate programmes.

Banking and NBFCs. KYC and transaction records must be kept for the periods the PMLA and the RBI's KYC directions require, which overrides erasure requests for those records under Section 8(7). Co-borrowers, guarantors and nominees are Data Principals in their own right. The RBI's digital lending directions restrict what lending apps may collect, and the DPDP Act adds purpose-specific consent and withdrawal on top. The RBI's FREE-AI committee report of August 2025 adds expectations on AI governance and explainability.

Insurance. Health data in proposals and claims needs careful safeguards. Third-party administrators, agents and brokers are part of the processor chain. Policy records are often kept for long periods, which has to be reconciled with erasure.

Capital markets. SEBI's cybersecurity and cyber resilience framework overlaps with Rule 6. Record-keeping obligations run for long periods. SEBI expects regulated entities to take responsibility for the AI tools they use.

Healthcare. Health data is processed in volume and is highly sensitive, although the Act doesn't treat it as a special category. The Rules exempt certain healthcare processing from the verifiable parental consent requirement for children's data, and these exemptions need to be applied precisely.

Education. Many learners are children, so verifiable parental consent and the bar on tracking and behavioural monitoring are central. The Rules exempt certain processing by educational institutions, again within limits.

Public sector. Section 17 exempts certain processing by the State and its instrumentalities, but the exemptions are specific. A public sector company is not automatically the State for this purpose, and the Cabinet Secretary's push in August 2026 signals that government bodies are expected to comply where the Act applies.

From 13 November 2026, companies can register with the Board as Consent Managers under the conditions set in the Rules. A Consent Manager acts on behalf of Data Principals. It gives them one place to give, manage, review and withdraw consent across many Data Fiduciaries, through a platform that must be accessible, transparent and interoperable.

Consent Managers will not replace an organisation's own consent records. A Data Fiduciary still has to give notice, record consent and stop processing on withdrawal, whether the choice arrives through its own channels or through a Consent Manager. What changes is that some choices will arrive from outside.

The operating model should be ready for that in three ways.

Accept choices from more than one route. The consent record should be able to show whether a choice was made directly or through a registered Consent Manager, and which one. A withdrawal received through a Consent Manager must take effect exactly as a direct withdrawal would.

Keep the terms straight. A consent management platform that an organisation uses to collect its own customers' consent is not a Consent Manager in the Act's sense. It works for the Data Fiduciary, not for the Data Principal. Procurement documents, notices and marketing should keep the two roles separate.

Watch the first registrations. The practical shape of the Consent Manager ecosystem will become clearer once registrations begin. Sectors with existing account aggregation frameworks, such as financial services, may see early activity. Integration work should be planned once there is something to integrate with, rather than speculatively.

An operating model needs supporting technology. The choice of tools matters less than a few principles that determine whether the tools help or create new risk.

Keep personal data where it is. Discovery and assessment should work by reading data in place, with read-only access, rather than copying it into another platform. Every copy is another place where data has to be protected.

Keep data in India where you can. The Act doesn't require localisation in general, but sector rules sometimes do, and keeping compliance records and evidence in India avoids questions about transfers.

Make records append-only. Consent records, request histories and incident timelines should be written once and never edited. Corrections should be new entries.

Keep identity with the organisation. A compliance platform should record proof of a person's choices without becoming the source of truth for their identity. The organisation's own systems should assert who the person is.

Keep everything exportable. Registers, records and reports should be exportable in open formats, so that the organisation is never locked into a tool and can respond to the Board in whatever form it asks.

Keep humans in charge of AI. AI can draft findings, translations and notices, and can help classify data at scale. A person should approve anything that leaves the function, and client data should not be sent to external AI services without clear terms.

Programmes that start well tend to share a few early moves. In the first thirty days, an organisation can put in place the foundations that everything else depends on.

Week 1: name the sponsor and the owners. The sponsor is an executive with authority across business lines. Owners are named for every function that processes personal data. Publish the list, so everyone knows who answers for what.

Week 2: agree the reading of the law. Legal and compliance settle the interpretive questions in writing: which activities will rely on consent and which on a legitimate use, how sector retention rules interact with erasure, and whether the organisation is likely to be designated a Significant Data Fiduciary. Open questions are listed with an owner and a date.

Week 3: start discovery on the biggest systems. Choose the five to ten systems that hold the most personal data about the most people. Begin scanning them with read-only access. Results will start to feed the processing record within days.

Week 4: set the rhythm and the first Board report. Establish a fortnightly steering meeting with a decision log. Agree the metrics the Board will see. Send the Board a short first report: the plan, the owners, the open questions, and the date of the next update.

None of these steps needs a large budget or a finished platform. Together, they remove the most common causes of delay later: unclear ownership, unresolved legal questions and a programme that nobody at the top is watching.

For an organisation starting in October 2026, the operating model has to be built and running within about thirty weeks. The plan below follows the order the Act's dependencies impose.

Weeks 1 to 8: Know. Appoint owners for each business function. Scan the systems that hold the most personal data. Build the processing record and the registers of systems and third parties. Decide whether the organisation is a likely Significant Data Fiduciary. Set up the governance described in this paper, including Board reporting.

Weeks 9 to 16: Decide. Assign lawful bases and have them signed off. Draft notices for each purpose and start translations. Design consent journeys for each channel. Define the rights process and publish its timeline. Write the retention schedule, reconciled with sector laws. Write the incident playbook covering every clock. Draft DPDP terms for processor contracts.

Weeks 17 to 24: Build. Put consent and withdrawal into every channel, including branches and call centres. Stand up the rights and grievance channel with routing to owners. Issue contract updates to processors. Begin legacy re-notice campaigns. Connect discovery to the processing record so that new findings flow into it. Plan around financial year-end change freezes.

Weeks 25 to 30: Rehearse and evidence. Run a breach exercise with leadership. Send test requests of every type through the rights process. Trace a withdrawal through every connected system. Close remaining processor contracts. Train front-line staff. Run a first assessment of controls, graded by evidence. Report to the Board.

Each stage ends with tests rather than activities. The register is done when every activity has a signed-off basis. Consent is done when a withdrawal is traced through every system. The rights process is done when a test request of each type closes end to end. These tests are also the first entries in the evidence layer.

Once the obligations apply, the operating model settles into a rhythm.

Continuously. Consent is captured and withdrawn. Rights requests and grievances are received, routed and answered. Incidents are detected and handled.

Monthly. Data owners review changes to their processing. New products and vendors pass privacy review. The DPO reviews request statistics, overdue items and open findings.

Quarterly. Discovery scans are repeated and compared with the last run. Senior management and the Board receive the metrics. Controls are spot-checked. Training gaps are closed.

Annually. A full assessment measures the posture against the previous year's baseline. Significant Data Fiduciaries complete their impact assessment and independent audit. The data protection policy is reviewed and approved again. The incident playbook is exercised in full.

The steady state is less dramatic than the run-up to May 2027, and more important. It is what keeps an organisation compliant in its second year, when the programme team has moved on and the Board's attention has turned elsewhere.

Experience with DPDP and comparable regimes shows a small number of patterns that reverse progress after go-live. Each has a countermeasure in the operating model.

The register nobody owns. The processing record was built by the programme team, who then moved on. Within months it no longer matches the business. Countermeasure: ownership by data owners, a monthly change review, and discovery scans that flag differences.

Consent that stops at the screen. Consent and withdrawal are captured, but the choice never reaches the systems that use the data. Customers who withdrew keep receiving marketing, and the first complaint exposes it. Countermeasure: propagation to every connected system, with logs, and a metric for how long it takes.

The vendor nobody reviewed. A new tool is bought by a business team, connected to customer data and never assessed. Countermeasure: procurement steps that bring every new vendor into the third-party register and require DPDP terms before data flows.

The playbook nobody has used. The incident playbook was written and approved, but never rehearsed. When a real incident happens, the first six hours are spent working out who decides. Countermeasure: tabletop exercises at least once a year, with decisions pre-authorised and templates ready.

The metric that is always green. Reports show no overdue requests and no grievances, and nobody asks why. Often the reason is that the channel is hard to find or the routing is broken. Countermeasure: test requests sent through the public channel on a schedule, and scrutiny of any metric that never moves.

Directors can test whether the operating model is working by asking a small number of questions and expecting evidence in reply.

1. Who owns each business function's processing, and when did they last confirm their records?
2. Does every processing activity have a lawful basis that legal has signed off, and how many were found without one this quarter?
3. If a customer withdraws consent today, how long does it take to reach every system and processor that uses their data, and how do we know?
4. What is our published timeline for rights requests, what is our median, and how many are overdue?
5. When did we last rehearse a personal data breach, and what did we change afterwards?
6. What share of our processors are under contracts that meet Section 8(2)?
7. How much of our reported posture rests on tested evidence, and how much on what people have told us?
8. Are we likely to be designated a Significant Data Fiduciary, and if so, is our Data Protection Officer in place and reporting to us?

The DPDP Act asks organisations to do something most compliance regimes do not: to run data protection every day, for every person whose data they hold, and to be able to show that they did. A project can get an organisation to 13 May 2027. Only an operating model keeps it there.

The model in this paper is deliberately practical. Six capabilities cover the Act's obligations. Clear roles put ownership where the knowledge sits. An evidence layer turns routine work into proof. A small set of metrics tells the Board whether the function is working. A thirty-week plan sets the order in which to build it.

The organisations that will be in the strongest position aren't the ones with the longest policies or the most elaborate frameworks. They are the ones that can answer a specific person's question quickly and with evidence: what data do you hold about me, why, who has it, and what did you do when I asked you to stop?

This paper was prepared by the Data Protection and Privacy Practice of SARC, drawing on the text of the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025, on DPDP assessments and implementations in regulated Indian enterprises, and on public reporting up to 1 October 2026. Developments after that date, including appointments to the Data Protection Board and any amendments to the Rules, are not reflected. The paper is not legal advice.