Building DPDP Act compliance that survives an audit

The Digital Personal Data Protection Act, 2023 places duties on systems, and most organisations' systems fall short of the documents written about them. Closing that distance properly is a structured piece of work.

A complete compliance programme runs in phases. Each phase is defined by what it examines and what it produces, and the phases fit together into a result that can stand up to a regulator, an independent auditor or a client doing due diligence.

One standard runs through all of it, and that standard is demonstrability. A compliance position that survives an audit is one where every claim the organisation makes can be shown. The record of processing activities matches the systems it describes. A rights request can be fulfilled on demand within the published period. The timeline of any breach can be rebuilt from logs, without relying on anyone's memory. Every phase of the programme exists to move the organisation towards that standard, and every deliverable earns its place by adding evidence towards it.

The buyer of this work may be a compliance head running the programme in-house or a founder choosing an outside partner. Organisations preparing for the main duties, which apply from around 13 May 2027 under the DPDP Rules, 2025 as notified, unless amended, face a market whose offerings range from template libraries to full engineering programmes. The differences are not always visible in a proposal. Knowing how a proper programme is put together lets a buyer examine what is actually on offer, ask the questions that reveal depth, and tell a programme that will hold from one that will need to be done again.

The four phases are assessment, design and documentation, implementation, and sustained adherence. They come in sequence because each one uses the output of the one before. The most common failures in compliance programmes are failures of sequence: documents produced before the systems they describe exist, or implementation started before anyone measured the gap it is meant to close. A programme that respects the sequence produces an organisation that is compliant in how it actually operates. This is a practitioner's account of the Act and the Rules. It is not legal advice.

What an audit actually examines

The standard of demonstrability

An audit, whatever form it takes, is an exercise in checking.

The examiner does not ask whether the organisation has a privacy notice. They ask whether the notice describes the processing that actually happens, and then look at the processing. They do not ask whether a retention policy exists. They pick a data category whose retention period has passed and ask to see evidence that the data was erased. They do not ask whether the organisation can handle rights requests. They open the register of requests received, pick one, and follow its record from intake to response against the published timeline. Each time, the question moves past the claim to the evidence underneath it, and the organisation's real position is whatever that evidence shows.

This standard explains why a sound programme is built the way it is. Every control is built together with the evidence trail that proves it runs, because under examination a control without evidence looks exactly like no control at all.

• Deletion jobs write completion records.
• Consent checks write decision logs.
• Rights requests move through a tracked workflow that timestamps every step.
• Deletion instructions to vendors generate confirmations, which are filed against the instruction.

None of this evidence can be created after the event. That is why demonstrability has to be a design requirement from the first day of the programme. Adding it at the end is too late.

Three kinds of examiner

It helps to be precise about who does the examining, because there are three examiners and each arrives by a different route.

The first is the Data Protection Board. It inquires into complaints and breaches, works as a digital office, and holds the penalty powers of the Act. The provisions setting it up applied from 13 November 2025. Organisations should plan on the basis that it will act.

The second is the independent data auditor. If the Central Government notifies an organisation as a Significant Data Fiduciary, it must appoint one, along with a Data Protection Officer based in India. It must also carry out a Data Protection Impact Assessment and an audit at least once every twelve months, and check that algorithmic software it uses does not put Data Principals' rights at risk.

The third examiner is commercial, and it arrives before the other two. Enterprise clients, especially those governed by the GDPR, HIPAA or their own sector regulators, examine the data protection posture of their Indian suppliers as a condition of doing business. They do it through security questionnaires, contract terms and audits of their own. A Pune software services firm processing customer records for a European bank, to take an illustration, meets this examiner every quarter.

The third examiner changes the economics of the work in a way many organisations have not yet noticed. A programme built to be demonstrable reduces penalty exposure after May 2027, and it also answers the due diligence of every prospective enterprise client from the day it is in place. That makes it an asset that can shorten sales cycles as well as a cost of avoiding harm. For firms that sell software services, platforms or data handling to regulated buyers, the commercial case for the programme often arrives before the regulatory one.

Phase one: assessment

Scoping and discovery

A proper programme begins with a scoping questionnaire, whose purpose is to fix the boundaries of the work before anyone estimates it. It records:

• what the organisation does, and which products and services process personal data;
• whose data is involved: customers, employees, patients, students, dealers or others;
• whether children's data or health data appears anywhere, remembering that under the Act a child is anyone under eighteen;
• which places the organisation operates in, and whether the section 17 exemption for processing non-residents' data under a contract with a foreign party could apply to any part of it (security safeguards still apply there);
• which other frameworks already apply, such as RBI, IRDAI or SEBI directions, or a client's GDPR requirements;
• which systems, teams and vendors are in scope.

The answers shape everything that follows, including whether the organisation could plausibly be notified as a Significant Data Fiduciary. An estimate made before these answers exist is a guess.

Discovery comes next, and it is the fieldwork of the assessment. The assessment team builds the data inventory by examining the systems themselves, alongside interviews with their owners. It lists the vendors and the outbound data flows. Then it traces the Act's duties through what it has found. It submits an access request and follows it to completion or failure. It withdraws consent on a test account and watches what changes. It runs a tabletop breach exercise and measures the time from first signal to a draft report for the Board. The traces turn the organisation's readiness from a matter of opinion into a set of located, checkable findings.

The gap assessment report

The deliverable of phase one is the gap assessment report. Its quality sets the quality of the whole programme, because every later phase is built on it.

A good report contains:

• the data inventory as discovered;
• the map of processing purposes, with the ground for each, whether consent or a legitimate use under section 7;
• the vendor register, with the contract status of each relationship;
• the findings from every trace, each stated specifically enough that an engineer could act on it without further investigation.

Against each finding, the report records a severity weighted by the penalty Schedule, an effort estimate ranging from configuration change to schema-level engineering, and the dependencies that decide what must come first.

The report ends with the remediation sequence, which is the document leadership actually runs the programme by. It states what will be fixed, in what order, by whom, with what effort and by when, against the calendar running towards May 2027.

A buyer comparing assessment offers can apply a simple test: ask to see the table of contents of a past gap assessment report, with the client's details removed. A report organised around traced findings and a sequenced remediation plan reflects work done inside the systems. A report organised around a scored questionnaire reflects a method that never touched the systems, and the difference will show up in phase three, when the programme runs into the findings the questionnaire could not see.

Phase two: design and documentation

Designing controls before writing documents

The second phase turns findings into designs, and the order inside the phase matters as much as the order between phases. Each area gets a control design before any policy describing it is drafted.

• Consent is designed first, as a system: the structure of the consent record, the purposes it governs, the notice versions it links to, the systems that will enforce it, and the path a withdrawal travels. If the organisation expects to receive consent through registered Consent Managers, the interface for that is designed here too.
• Retention is designed as a schedule tied to execution, with a retention period and a named deletion method for every data category in the inventory.
• Rights handling is designed as a set of processes with owners, intake channels, fulfilment steps and timelines, including the published grievance response period, which Rule 14 caps at ninety days.
• Incident response is designed around the breach duties in Rule 7, with roles, escalation paths, evidence needs and report templates for the Board and for affected people prepared in advance. Where CERT-In's six hour reporting direction also applies, the two reporting tracks are designed together.

Designing controls before documents reverses the order most failed programmes follow, and the reason is practical. A policy written before the control exists describes an intention, and intentions drift, which is how organisations end up with a gap between documents and systems. A policy written from a control design describes a mechanism. It names the systems involved and states periods and procedures that the implementation phase will make true. The resulting documents are shorter, more specific and far easier to defend, because every sentence corresponds to something the organisation is actually building.

The document set and its instruments

A compliance programme's documents use standard instruments, and the standard names matter, because examiners and enterprise clients expect them.

• The record of processing activities describes every processing operation: its purpose, its ground, the data categories involved, the systems that carry it out and the recipients of the data. It is the master document, and the inventory feeds it.
• The Data Protection Impact Assessment evaluates high-risk processing. For Significant Data Fiduciaries it is a yearly duty, and for others it is good practice wherever processing is large or sensitive.
• The data processing agreement governs each vendor relationship, carrying the deletion duties, breach notification duties and processing limits that the Act expects the fiduciary to impose.
• The privacy notices, generated from the inventory, carry the itemised disclosures to Data Principals, with the option to read them in English or any of the languages in the Eighth Schedule to the Constitution.
• The internal policy set covers retention, access control, incident response and grievance handling, and each policy describes the control designed in this phase.

Two properties separate a document set produced this way from a template pack with the same file names. The first is correspondence: every statement in every document maps to a system, a schedule or a procedure that exists or is being built, so an examiner moving from document to evidence finds the two agree. The second is maintenance: every document names its owner, its review cycle and the events that trigger a revision, so the set stays true as the organisation changes. A template pack has neither property. That is why it costs so little, and why it gives so little protection in front of any of the three examiners.

Phase three: implementation

Engineering the controls into the systems

The third phase is where the programme spends most of its budget and most of its calendar, and a buyer should expect that.

The consent design is built and integrated, so that the systems processing personal data either check consent or only receive data already filtered against it, and so that a withdrawal reaches them within a set period, with a record that it did. The rights features are built as a product roadmap: gathering one person's data for an access request, pushing corrections to every copy, erasing across live systems with the backup and restore procedures that complete the job, and a tracked grievance workflow. Retention schedules are wired to deletion jobs that log their completion. Access logging is switched on across every system holding personal data at the earliest date the programme allows, kept for at least the one year Rule 6 requires, with alerts and escalation set up around it.

The vendor work runs in parallel through this phase, because part of its timetable belongs to other companies. Data processing agreements are signed or renegotiated against the register the assessment produced. Deletion and notification paths are set up with each vendor holding personal data. The integrations discovered during assessment that no document described are either brought under contract or removed.

A plan that starts the vendor work in the last few weeks of implementation has misjudged how long counterparties take. A buyer reviewing a proposed plan can check this one detail as a quick sign of whether the provider has run such programmes before.

Verification: testing the way an examiner would

Implementation ends with verification, which repeats the assessment traces against the finished controls.

• An access request is submitted and fulfilled within the published period, and the fulfilment record shows every system searched.
• Consent is withdrawn on a test account, and the downstream systems change behaviour within the set period, with the change logged.
• A retention category is allowed to expire, and the deletion job runs and writes its completion record.
• A breach drill is run against the rehearsed procedure, and the draft Board report is produced within seventy-two simulated hours, from logs that hold what the report needs.

Where a trace fails, the failure goes back on the implementation backlog, and the trace is run again after the fix. Where possible, the traces should be run by someone other than the engineer who built the control, using test records set up for the purpose, so that the check resembles what an outside examiner would do and nobody is marking their own work.

The verified traces become part of the programme's permanent evidence, filed alongside the documents they confirm, and their value lasts well beyond the programme itself. When the Board asks how the organisation knows its erasure works, the answer is a dated verification record. When an enterprise client's security review asks whether rights requests are answered within the stated periods, the answer is the request register plus the verification trace. When the independent auditor of a Significant Data Fiduciary begins the yearly audit, the starting point is a set of controls that were tested the same way the auditor will test them.

Verification is the step that turns an implemented programme into a demonstrable one. A buyer should confirm it is present, explicitly and with named methods, in any proposal under consideration.

Phase four: sustained adherence

Compliance as an operating state

A programme that ends at verification starts to expire the day it ends, because the organisation keeps changing. Take a hospital chain, as an illustration. A year after its programme closes, it adds a teleconsultation feature, a new diagnostic lab partner starts receiving test reports, and the patient app gains a feedback form. Each change moves the systems away from the documents unless something holds them together.

Sustained adherence is that something. It is a small set of recurring routines, with a modest cost:

• A checkpoint in the release process updates the inventory, the vendor register and any affected notices whenever data collection or data flows change.
• A fixed review cycle walks the record of processing activities against the systems.
• Rights request timings are reviewed against the published periods.
• Deletion job completions are reviewed against the retention schedule.
• A breach drill runs at set intervals, so the response stays practised and nobody has to rely on memory.

An organisation can finish a careful programme and drift quietly out of compliance within two years. These routines are the specific answer to that drift. Once the programme has been built properly, they take a set number of hours each month. Their absence is expensive in a particular way, because drift stays invisible until an examiner measures it. An organisation deciding whether to treat adherence as a standing operation or a future project is choosing between a small known cost paid continuously and the full cost of assessment and remediation paid again later. Done properly, that arithmetic favours the first choice.

Keeping pace with the regulator

The rules around the Act will keep developing after the main duties apply. The Data Protection Board will build its practice through the inquiries it runs and the penalties it sets, and those decisions will show how the general language of the Act applies to specific situations. The government keeps its power to make and amend rules. The phased start, with Consent Manager provisions around November 2026 and most fiduciary duties around May 2027, shows that the framework arrives in stages. A January 2026 proposal to shorten the transition period was consulted on and has not been notified, which is a reminder that dates can still move.

Organisations near the likely thresholds for Significant Data Fiduciary status carry a particular duty to watch, because notification brings the yearly Data Protection Impact Assessment and audit, the independent data auditor, the Data Protection Officer and the algorithmic due diligence duties with it.

Sustained adherence therefore includes a regulatory watch. In practice that means a named person responsible for tracking Board decisions, rule amendments and guidance, and a set path by which a relevant development becomes a change in the organisation's controls and documents. This is the part of the programme most naturally shared with an outside partner, because a partner watching for many clients spreads the cost of watching. That is why mature programmes in this field often end in a retainer. A well run retainer leaves the organisation in control of its own programme and keeps it current against a regulator that is still writing its own precedents.

Selecting a partner for this work

Questions that reveal depth

Knowing how a proper programme is put together gives a buyer questions that separate providers.

• Ask to see the method behind the gap assessment report, and specifically whether findings come from traces through systems or from questionnaire scores.
• Ask who does the implementation. A provider that designs controls and hands the engineering back to your product roadmap has sold an advisory engagement dressed as a programme, and the engineering is where programmes succeed or fail.
• Ask what verification consists of, with named tests and named evidence.
• Ask how the document set is produced and maintained, and whether the record of processing activities comes from a discovered inventory or is filled into a template.
• Ask what the sustained adherence offer contains, month by month.

The answers are hard to improvise, which is what makes the questions useful. A provider that has run the full sequence describes it concretely, friction included, because the friction is where experience shows. A provider selling documents describes outcomes in general terms and steers the conversation back to deliverables and timelines. Under specific questioning, neither position stays hidden for long. An hour spent asking these questions before selection is the cheapest risk reduction available anywhere in the programme.

A commercial structure that fits the work

The shape of the programme suggests the commercial structure that suits it. Each phase has a defined scope, defined deliverables and a defined completion state, so each phase can be priced as a fixed commitment against outcomes.

• The assessment is a fixed piece of work ending in the gap assessment report and the remediation sequence.
• Design and documentation is a fixed piece of work ending in the control designs and the document set.
• Implementation is scoped from the remediation sequence itself, which the buyer holds before committing to it, and verification closes the phase against named tests.
• Sustained adherence is a defined monthly scope.

At every boundary, the buyer holds completed deliverables and a precise view of what comes next, and can go ahead, pause or change providers without losing the work already done.

This structure protects the buyer. An engagement sold as one undifferentiated block, priced on time, with deliverables described in general language, hands the definition of success to the provider and the risk of drift to the buyer. An engagement priced phase by phase against named deliverables keeps the definition of success with the buyer throughout. When reviewing proposals, check whether the phase boundaries, the deliverables at each boundary and the completion tests are written into the commercial terms. If they are missing, that tells you how the engagement will be run.

The engagement from the client side

What your organisation contributes

A compliance programme runs on the client's systems and inside the client's processes, so no provider can deliver it alone. An account of the work has to include what the client brings.

The programme needs access, granted early, to the systems, code repositories and vendor records in scope, because discovery done through intermediaries produces incomplete inventories. It needs decisions, made at set points, on questions only the client can answer: retention periods for business records, what to do with legacy data whose purpose has lapsed, and where to land when the law leaves room for judgement. And it needs an internal owner senior enough to book engineering time and to hold the release checkpoint once it exists. A programme whose internal owner cannot command a sprint slips one quarter at a time.

The engineering time itself should be planned openly. Even when an outside team carries the implementation, changes land in the client's codebase, pass through the client's review and release processes, and touch systems the client's engineers know best. The realistic pattern is joint implementation: the provider supplies the compliance engineering capacity, and the client supplies review, context and integration, in a proportion agreed during planning. Programmes that agree this split up front stay on schedule. Programmes that assume the client's engineers will be found when needed end up competing with the product roadmap for the same people, and the roadmap usually wins until the calendar makes that expensive.

What finished looks like

The programme ends in a state that is simple to describe.

The organisation holds a data inventory that matches its systems, and a record of processing activities generated from it. Every processing purpose rests on a recorded ground, and where that ground is consent, the systems enforce it as well as capture it. A Data Principal exercising any right gets a complete answer within the published period, through a workflow that records its own operation. Personal data that reaches the end of its retention period is erased, with evidence, from live systems, backups and processors. A breach, if one happens, is detected quickly, intimated to the Board and to affected people without delay, followed by the detailed report within seventy-two hours, and its whole timeline can be rebuilt from logs. The documents describe all of this accurately, and an examiner moving from any document to the evidence beneath it finds that the two agree.

That state is what it means to treat the DPDP Act as an engineering discipline. For the organisations that reach it, it is a settled foundation, kept current by the modest routines of sustained adherence, and available as evidence to every regulator, auditor and enterprise client who asks. The distance between most organisations and that state is real. Any organisation that starts with a thorough assessment and follows this sequence can close it in the time left before May 2027.

Conclusion

Three questions lead to this point, in order. The first is what the Digital Personal Data Protection Act, 2023 requires, and the answer is that its duties turn into system requirements: consent records, versioned notices, rights workflows, retention that actually runs, and rehearsed breach reporting. The second is where organisations actually stand against those requirements, and the answer is a gap between documented and implemented compliance across the data, application, infrastructure and vendor layers, which can be measured with a defined method. The third is how the distance is closed, and the answer is a four phase programme: assessment, design and documentation, implementation, and sustained adherence, each defined by what it examines, what it produces and the evidence it leaves behind.

The common thread is demonstrability: an organisation's compliance position is defined by what it can show. That is the standard the Data Protection Board will apply in its inquiries, the standard independent auditors will apply to Significant Data Fiduciaries, and the standard enterprise clients already apply in due diligence today. Meeting it is a bounded, sequenced and well understood piece of work, and there is enough time before the main duties apply for organisations that start now. The decision to start is the one part of the programme no method can supply.

TrustOS is built to hold that evidence: each duty as assigned work with an owner, an action, a completion and proof, alongside the inventory, the record of processing and the request registers. This order of work is what makes the evidence meaningful, whichever tools you use. Code Colonies consulting runs programmes in this sequence, from assessment to sustained adherence, and implementation work can be delivered on 2good terms, where you pay after you accept the work. You can reach the team at consulting@codecolonies.com. For how the Board decides penalties, see the guide to DPDP penalties.