DPDP Act Compliance Checklist for Software Teams in 2026

A practical DPDP Act compliance checklist for software teams in 2026 should focus on readiness: map personal data, define processing purposes, design consent and withdrawal, prepare user-rights workflows, set retention rules, tighten access, plan breach response, review processors, and document evidence before the main operational provisions take effect.

There is an important timing detail. As of October 15, 2026, most of the core obligations in Sections 3 to 17 of the Digital Personal Data Protection Act, 2023 are scheduled to commence 18 months after publication of the November 13, 2025 Gazette notification. The government did not make every provision operational at once.

That makes 2026 less of a waiting period and more of an engineering window.

Quick Summary: Key Takeaways

• The Digital Personal Data Protection Act was enacted in 2023, while the final DPDP Rules were notified in November 2025. Their commencement is phased rather than immediate across all provisions.

• The Data Protection Board of India has already been established. MeitY was recruiting its Chairperson and members in May 2026.

• Most business-facing obligations around scope, notice, consent, security, breach reporting, children's data, user rights, Significant Data Fiduciaries, and related matters belong to the later commencement group.

• Rule 4, covering Consent Manager registration and obligations, is scheduled to commence one year after publication of the Rules. Rules 3 and 5 to 16, which contain many of the operational requirements software teams care about, are scheduled for the 18-month stage.

• The October 2026 Removal of Difficulties Order made two textual changes to Sections 9 and 10. It did not create a new compliance deadline or a new general duty.

• Software teams should map where personal data enters, moves, gets copied, is logged, is shared, and is erased.

• Consent should be treated as a product event with evidence, not merely a checkbox on a registration page.

• Withdrawal should be designed alongside consent. Section 6 says withdrawal should be as easy as giving consent once that provision becomes operational.

• Final Rules specify minimum security measures including access controls, encryption or similar protections, logs, monitoring, recovery measures, processor contract provisions, and technical and organizational controls. These rules sit in the later commencement phase.

• The breach rules contemplate notices to affected individuals and notification to the Board, with further information to the Board within 72 hours of awareness. That requirement is also part of the later operational phase.

• Children's data needs separate product design. Section 9 addresses verifiable parental consent, detrimental processing, tracking, behavioral monitoring, and targeted advertising directed at children, subject to statutory exemptions and conditions.

• Privacy engineering works better when legal requirements become requirements, architecture decisions, acceptance criteria, and test cases rather than remaining inside policy documents. Research published in 2026 supports this requirements-led approach.

This guide is an engineering-oriented interpretation, not legal advice. Product, security, and engineering teams should validate their final compliance position with qualified legal counsel.

At Deuex Solutions, our cybersecurity services support businesses working through security architecture, application security, access controls, vulnerability management, and the technical side of regulatory readiness.

The Ticket Said: “Add a Consent Checkbox”

The ticket looked harmless.

Four words.

Add marketing consent checkbox.

A fictional SaaS team estimated it at two hours.

Then the product manager asked a question.

“What happens if the user unticks it six months later?”

Silence.

The frontend developer could remove the check.

The backend still had the user profile.

The CRM contained another copy.

The email platform had its own audience record.

Analytics had stored campaign events.

A CSV export from last quarter sat in an operations folder.

The sales team had synchronized a phone number into another application.

Suddenly, the checkbox was not the feature.

The data flow was.

That is the part of DPDP readiness software teams should pay attention to.

A privacy notice can be rewritten in an afternoon.

Changing how six production systems collect, store, share, and remove personal information can take months.

What Is the Current DPDP Status in 2026?

This deserves a clear answer because a lot of commentary blurs together enactment, notification, and commencement.

The DPDP Act received presidential assent in August 2023. Final DPDP Rules were notified in November 2025. The government then established a phased commencement structure.

DPDP Timeline Software Teams Should Know

The official Act commencement notification (G.S.R. 843(E)) places Sections 3 to 5, most of Section 6, Sections 7 to 17, most of Section 27, Sections 28 to 34, Sections 36 and 37, and Section 44(2) in the 18-month group.

The final Rules (G.S.R. 846(E)) use a similar phased structure. Rules 1, 2 and 17 to 21 began on publication; Rule 4 begins one year later; Rules 3, 5 to 16, 22 and 23 begin after 18 months.

So 2026 is the year to build the machinery before the obligation reaches the machinery.

DPDP Act Compliance Checklist for Software Teams

Here is the engineering checklist I would work through.

Now comes the useful part.

How do you actually build those things?

Checklist 1: Build a Real Personal Data Inventory

Start with the product, not the privacy policy.

Map every place personal data enters.

That may include:

• Registration forms

• Checkout

• Mobile applications

• CRM

• Support tickets

• Analytics

• Chatbots

• Cookies

• Payment workflows

• HR software

• Email platforms

• Cloud logs

• Uploaded files

• Third-party SDKs

• APIs

• Data warehouses

• Backups

Section 3 of the Act defines its intended scope around digital personal data processed in India, including information first collected offline and later digitized, and also reaches processing outside India tied to offering goods or services to people in India once that section commences.

A useful data map looks like this:

Signup Form

    ↓

Application Database

    ├── CRM

    ├── Analytics

    ├── Email Platform

    ├── Support System

    └── Backup Storage

Do this field by field.

email

phone

date_of_birth

location

device_id

support_message

uploaded_document

The more generic your inventory is, the less useful it becomes.

Checklist 2: Ask Why Every Field Exists

Here is a surprisingly powerful privacy question:

What breaks if we stop collecting this field?

The consent provision in Section 6 says consent is to be limited to personal data necessary for the specified purpose. That provision is in the later commencement phase, but it gives software teams a clear architecture signal now.

Suppose a fitness application requests:

• Name

• Phone

• Email

• Employer

• Contacts

• GPS

• Date of birth

Which fields are necessary to create an account?

Which enable an optional feature?

Which were simply added because someone thought they might become useful later?

Data teams like optional information.

Privacy engineering asks whether collecting it creates a responsibility without a corresponding product benefit.

Checklist 3: Turn Consent Into an Event, Not a Boolean

A column called:

consent = true

is rarely enough for a serious consent architecture.

Software teams may need evidence showing:

• Who consented

• What they were shown

• What purpose applied

• Which data was covered

• When consent occurred

• Which notice version was displayed

• Which language was used

• Whether consent was later withdrawn

• When withdrawal occurred

The final Rules say notices are to stand independently, use clear and plain language, identify the personal data and purposes, and provide a route for withdrawal, rights requests, and complaints when Rule 3 comes into effect.

The Act also says withdrawal should be as easy as giving consent.

That changes UI and backend architecture.

If signing up requires one click but withdrawing requires emailing support, printing a form, and waiting seven days, the product team should revisit the flow before launch.

Checklist 4: Build Withdrawal as a Workflow

What happens after a user presses:

Withdraw marketing consent

A mature system should know.

Perhaps:

Consent withdrawn → Consent record updated → Marketing audience removed → CRM preference updated → Email queue blocked → Audit event written

Do not rely on a support employee to remember four applications.

If a workflow can be automated safely, automate it.

If human review is required, create an owned task with an auditable status.

This is where DPDP compliance software may become useful internally, whether through a dedicated privacy platform or product functionality built into the company's own systems.

Checklist 5: Prepare Access, Correction and Erasure

Sections 11 to 14 create rights relating to access, correction and erasure, grievance redressal, and nomination once those provisions commence. Section 12 specifically provides for correction, completion, updating, and erasure subject to the Act's conditions.

Do not wait for the first request to find out where the data lives.

Test a fictional user.

Can your team find that person's information across:

• Primary database

• CRM

• Support system

• Analytics

• Marketing

• Search index

• File storage

• AI knowledge store

• Exports

Then ask the uncomfortable question.

Can it be corrected or erased where required without damaging another customer's records?

That is a software problem.

Not a policy-writing problem.

Checklist 6: Design Retention Into the Data Model

The final Rules contain specific retention mechanics for certain classes and purposes, plus a general one-year retention requirement for certain processing records and logs described in Rule 8.

Do not translate that into:

Keep everything for one year.

Retention requirements depend on the relevant provision, purpose, class of Data Fiduciary, applicable schedules, and other legal obligations.

Instead, build the ability to express retention deliberately.

For example:

Retention should be executable.

A PDF saying “delete when no longer necessary” does not delete anything.

Checklist 7: Put Security Controls Behind the Privacy Promise

Section 8 calls for reasonable security safeguards once it comes into effect. Rule 6 is more specific and lists measures such as encryption, obfuscation, masking or tokenization, access controls, logging and monitoring, recovery measures such as backups, appropriate processor contract provisions, and technical and organizational measures.

Software teams should review:

• Encryption in transit

• Encryption at rest where appropriate

• Secrets management

• Role-based access

• Privileged accounts

• Service accounts

• MFA

• Admin access

• Database permissions

• Log exposure

• Backups

• Recovery testing

• Monitoring

• API authorization

• Production access

Privacy and cybersecurity overlap here.

They are not identical.

If you are designing these controls, our cybersecurity services cover application, infrastructure, testing, and security practices that support stronger data handling.

For more on embedding controls inside software delivery rather than waiting until release, see our DevSecOps guide for secure software development.

Checklist 8: Create a Breach Workflow Before You Need It

Rule 7 describes breach notification requirements that include information for affected Data Principals and reporting to the Board. It also provides for additional information to the Board within 72 hours of becoming aware of a breach, unless a longer period is permitted.

Again, this rule belongs to the later commencement group.

Still, the engineering capability takes time to build.

During an incident, can you answer:

• What data was affected?

• Which users were involved?

• When did it happen?

• Which services were involved?

• Was the data encrypted?

• Who accessed it?

• Which processor was involved?

• Can the affected group be contacted?

• Are logs trustworthy?

• Has the access path been closed?

If the answer depends on three weeks of forensic reconstruction, the system is not ready.

Checklist 9: Review Every Data Processor

Section 8 states that processing by a Data Processor on behalf of a Data Fiduciary for activities tied to goods or services is to be under a valid contract once the provision comes into force.

Create a vendor register.

Include:

• Cloud providers

• CRM

• Analytics

• Customer support

• Email

• SMS

• AI model providers

• Payment tools

• File storage

• Marketing platforms

• Monitoring

• Error tracking

For each vendor, understand what personal information it receives.

“We use AWS” is not a data-flow answer.

Which service?

Which region?

Which fields?

Which logs?

Which employees can access them?

Those are engineering questions procurement forms often miss.

Checklist 10: Treat Children's Data as a Separate Product Path

The Act defines a child as an individual under 18. Section 9 addresses verifiable parental consent and restricts certain processing involving children, subject to exemptions and conditions.

The 2025 Rules describe technical and organizational steps around verifiable parental consent and also specify exemptions for certain classes or purposes.

If your software may be used by children, ask:

• Do we know the user's age?

• Do we need age assurance?

• How will parental consent work?

• How is the parent connected to the child record?

• What evidence is retained?

• Can consent be withdrawn?

• Are analytics tracking children?

• Does advertising behavior change?

Do not bolt this onto a product after acquisition campaigns begin.

Checklist 11: Decide Whether AI Features Need Their Own Privacy Review

AI creates unusual data paths.

A customer writes information into a chatbot.

The prompt may be sent to a model provider.

A copy may appear in application logs.

Another copy may enter observability tooling.

The response may become support history.

If RAG is used, the user's query may also search internal documents.

Before enabling an AI feature, map:

User input → Application → Model provider → Logs → Knowledge retrieval → Response history

Ask what is stored at every step.

This is a practical form of privacy by design India teams can use long before formal compliance review.

What Does Research Say About Privacy by Design?

A 2026 Information and Software Technology paper, “Privacy by design: Aligning GDPR and software engineering specifications with a requirements engineering approach”, by Oleksandr Kosenkov, Ehsan Zabardast, Davide Fucci, Daniel Mendez, and Michael Unterkalmsteiner examined privacy requirements and system specifications.

The researchers found that privacy requirements work better when legal concepts can be traced into requirements and technical specifications rather than remaining disconnected from software design. Their work was focused on GDPR, not India's DPDP Act, so it should not be treated as interpretation of Indian law. The engineering lesson is still highly relevant: legal requirements need traceability into system requirements.

A second paper, “From Perception to Implementation: A Case Study of the Relationship Between Team Privacy Climate and Privacy Practices”, was published online in August 2026 by Micha Prudjinski, Irit Hadar, and Gil Luria and examined 212 developers and 30 managers across 50 software teams. It found a positive association between team privacy climate and managers' assessment of the privacy mechanisms implemented by software teams. It was a single defense-sector case study, so the result should not be generalized blindly.

Those studies suggest something we see in practice.

Privacy does not improve because a company creates one compliance role.

Developers need requirements they can actually build.

Checklist 12: Put Privacy Acceptance Criteria Into Tickets

Instead of:

Build account deletion.

Write:

Acceptance criteria

• User can request deletion from account settings.

• Identity is verified before destructive action.

• Deletion workflow records request time.

• Downstream processors are notified where required.

• Records subject to lawful retention are separated.

• User receives workflow status.

• Failed downstream deletions create an alert.

• Audit evidence is retained according to policy.

Now QA can test it.

Engineering can estimate it.

Security can review it.

Legal can confirm the requirement.

This is what privacy by design looks like when it leaves PowerPoint.

Checklist 13: Protect Test and Development Environments

Production is not the only place personal data can escape.

Software teams commonly create risk through:

• Database copies

• Debug logs

• Screenshots

• QA exports

• Developer laptops

• Staging environments

• Support reproductions

Use synthetic or masked data where practical.

Restrict access to non-production environments.

Set expiry rules for test datasets.

Do not copy millions of real customer records into staging because it makes testing easier.

If your mobile application handles customer, financial, retail, or healthcare information, our guide to building secure mobile applications covers related security design concerns.

Checklist 14: Prepare for Significant Data Fiduciary Duties Without Assuming You Are One

Section 10 allows the Central Government to notify a Data Fiduciary or a class of them as a Significant Data Fiduciary based on factors including data volume and sensitivity and risk to Data Principals.

The additional framework includes:

• An India-based Data Protection Officer

• Independent data auditor

• Data Protection Impact Assessments

• Periodic data audits

Rule 13 adds further detail, including a twelve-month cycle for DPIA and audit after designation, plus due diligence around algorithmic software and possible restrictions on certain specified data transfers.

The October 2026 Removal of Difficulties Order changed the wording from “periodic audit” to “periodic data audit.” It did not introduce a new general audit duty for every business.

Do not label your company an SDF simply because it is large.

The statutory mechanism is government notification.

Checklist 15: Build a DPDP Evidence Folder

Compliance needs evidence.

Maintain records showing:

• Data inventory

• Data-flow diagrams

• Consent design

• Notice versions

• Processor register

• Processor contracts

• Access reviews

• Retention rules

• Deletion tests

• Security architecture

• Incident playbooks

• Breach exercises

• Test results

• Privacy decisions

• Training

• Release controls

Call it governance.

Call it compliance evidence.

Call it whatever your organization will actually maintain.

Just make sure it exists.

What About DPDP Penalties?

The Act's Schedule specifies ceilings that include up to ₹250 crore for failure to observe the security-safeguard obligation, up to ₹200 crore for breach-notification failures, up to ₹200 crore for children's-data obligations, up to ₹150 crore for Significant Data Fiduciary obligations, and up to ₹50 crore for other breaches covered by the residual category. These are statutory maximum ceilings, not automatic fines.

The enforcement timing matters here too.

Do not publish a sentence claiming companies are already being fined under obligations that have not yet commenced.

That is exactly the kind of compliance claim this article is trying to avoid.

A Practical 90-Day DPDP Readiness Plan

Do not try to make every system perfect in 90 days.

Find the dangerous gaps first.

A forgotten analytics export may deserve attention before a beautifully formatted privacy dashboard.

The Consent Checkbox Ticket Was Closed Three Months Later

Not because the UI took three months.

That took half a day.

The team spent the rest of the time deciding what that checkbox actually controlled.

Marketing subscriptions.

CRM preferences.

Email campaigns.

Product analytics.

Customer profiling.

Withdrawal.

Logs.

Documentation.

Testing.

By the time the feature shipped, the checkbox was almost boring.

Good.

The important part was underneath it.

That is what a DPDP Act compliance checklist should do for a software team.

Move the conversation away from legal wording alone and toward the architecture that makes the wording true.

Use 2026 to Remove the Surprises

A compliance deadline is a bad time to discover that nobody knows where customer information goes.

Map it now.

Test withdrawal now.

Find the unmanaged exports.

Review vendor access.

Check what your logs record.

Try to erase one test user from the entire product.

Run a breach simulation.

That work will tell you far more about readiness than a policy document with a new date on the footer.

At Deuex Solutions, our cybersecurity services help organizations review software security, data exposure, access controls, application architecture, cloud environments, and technical controls that form part of a wider compliance program.

You can also explore related software, security, testing, and privacy content on the Deuex Solutions blog.

DPDP readiness becomes manageable when every legal requirement can be traced to an owner, a system, a control, and a test.

Sanket Shah

CEO & Founder

I am Sanket Shah, founder and CEO of Deuex Solutions, where I focus on building scalable web mobile and data driven software products with a background in software development. I enjoy turning ideas into reliable digital solutions and working with teams to solve real world problems through technology.