5 Key DPDP Act Rules Every Data Fiduciary Must Follow

5 Key Rules Under the DPDP Act That Every Data Fiduciary Must Follow

India’s Digital Personal Data Protection Act, 2023 changes how businesses need to think about personal data. For a Data Fiduciary, DPDP Compliance is not simply about publishing a privacy policy or placing a consent checkbox on a website.

The real challenge is operational.

How will a customer exercise their rights? How will valid consent be captured? How easily can consent be withdrawn? What happens in other business applications after withdrawal? And how can the organization demonstrate that the required action actually happened?

The DPDP Act requires consent to involve clear affirmative action, gives Data Principals the ability to withdraw consent, and requires processing based on withdrawn consent to cease within a reasonable time, including processing by Data Processors, unless processing without consent is otherwise required or authorised by law. MeitY

Here are five important rules and implementation principles every Data Fiduciary should understand.

1. Provide Data Principals an Accessible Mechanism to Exercise Their Rights

DPDP Compliance does not end when personal data is collected.

Data Principals have rights under the DPDP framework, including access to information about their personal data, correction and erasure in applicable circumstances, and grievance redressal.

The final DPDP Rules also provide for website/app-based mechanisms through which a Data Principal can withdraw consent, exercise rights and make complaints. MeitY

This does not mean that every Data Fiduciary is specifically required to build a dedicated “Data Principal Portal.” However, businesses need an accessible mechanism for applicable rights, and a dedicated portal can be an effective way of implementing this operationally.

Consider what happens without one.

A customer wants to correct personal information. They email customer support. Support forwards it to IT. IT asks another department. Nobody knows the current status.

For a few requests this might be manageable. At scale, it becomes difficult.

How Consent Server Helps

Consent Server provides a centralized Data Principal Portal through which organizations can structure workflows around Data Principal requests.

Depending on the configured workflow, requests such as access, correction and erasure can be captured and tracked, while grievance handling and request history can also be managed centrally.

This helps move organizations away from scattered emails and spreadsheets toward a structured DPDP Compliance process.

2. Consent Must Require Clear Affirmative Action

A common mistake is assuming that displaying a checkbox automatically creates valid consent.

It does not.

Section 6 of the DPDP Act says consent must be free, specific, informed, unconditional and unambiguous, with clear affirmative action, and it must relate to the specified purpose and necessary personal data. MeitY

This has an important implication for website and application design.

If a consent checkbox is already selected when the page loads, the user has not performed the affirmative action of selecting it.

Businesses therefore should not rely on pre-ticked checkboxes as the mechanism for obtaining consent under this standard.

Instead:

The user sees the purpose.

The user understands what they are agreeing to.

The relevant option begins unselected.

The user actively makes the choice.

The system records the consent event.

Purpose-Based Consent Is Also Important

Imagine a business asking:

“I agree to the processing of my data.”

What exactly does that mean?

• Order processing?
• Promotional SMS?
• Email marketing?
• Personalized offers?
• Product updates?

Different purposes should not automatically be bundled into an unclear permission.

A mature Consent Management Platform should allow businesses to configure consent around defined purposes.

How Consent Server Helps

Consent Server supports purpose-based consent management.

Organizations can create consent forms for defined purposes and maintain records of what the Data Principal selected.

Consent Server can maintain information such as consent state, timestamp, purpose, applicable version and consent lifecycle history.

This gives businesses considerably more visibility than a basic checkbox stored as a database value.

3. Withdrawing Consent Must Be as Easy as Giving Consent

This is one of the clearest consent requirements in the DPDP Act.

Where consent is the basis of processing, a Data Principal has the right to withdraw it at any time, and the Act says that the ease of withdrawal must be comparable to the ease with which consent was given. MeitY

If giving consent requires two clicks, withdrawing it should not involve an unnecessarily difficult process involving phone calls, paperwork and multiple support emails.

This means businesses should think about the entire consent lifecycle, not simply consent collection.

A typical lifecycle might include:

• Consent granted
• Consent updated
• Consent withdrawn
• Consent renewed
• Consent expired

Your compliance infrastructure should know the current state while also maintaining relevant historical evidence.

How Consent Server Helps

Consent Server manages the complete consent lifecycle from one centralized DPDP Consent Management Platform.

A Data Principal can be provided with mechanisms for managing applicable consent preferences, while Consent Server maintains the resulting consent event and history.

This makes withdrawal a structured digital workflow rather than a manual support request.

4. Withdrawal Must Be Acted Upon Across Relevant Processing

This is where DPDP Compliance becomes more than a front-end problem.

Suppose a customer withdraws consent for promotional communication.

Your website successfully records:

Marketing Consent: Withdrawn

But your CRM still says:

Marketing Consent: Active

And your marketing application continues sending messages.

From an operational perspective, recording the withdrawal in only one system has not solved the problem.

Section 6 provides that following withdrawal, the Data Fiduciary must, within a reasonable time, cease and cause its Data Processors to cease processing based on that consent, unless processing without consent is otherwise required or authorised under the Act, Rules or another applicable Indian law. MeitY

Notice the wording carefully.

The Act does not specifically say that every CRM must be updated “in real time.”

But the organisation needs to ensure the underlying processing based on the withdrawn consent ceases within the required framework.

For modern businesses, that can involve several systems:

• CRM
• Marketing automation
• SMS gateway
• Email platform
• Mobile application
• Internal databases
• External Data Processors

This is why centralized consent management becomes valuable.

How Consent Server Helps

Consent Server provides APIs and webhooks that allow consent events to be communicated to configured business applications.

For example:

Data Principal Withdraws Consent --> Consent Server Records Withdrawal --> Relevant Event Generated --> CRM/Marketing System/Data Processor Receives Event --> Processing Workflow Updated

This helps businesses operationalize consent changes across connected systems instead of maintaining isolated consent records.

5. Build a Traceable Mechanism for Consent Updates and Downstream Actions

There is an important correction to the wording of this fifth point.

It would be inaccurate to say:

“The DPDP Act requires every consent update to have a real-time API acknowledgement record.”

Neither the Act nor the Rules prescribe a universal requirement to use APIs, webhooks or real-time acknowledgements for every consent update.

However, this is where good compliance engineering becomes important.

A Data Fiduciary remains responsible for compliance regarding processing undertaken by it and processing undertaken on its behalf by Data Processors. A business therefore benefits from having reliable mechanisms for ensuring consent changes are actually acted upon.

Consider this situation:

• A customer withdraws consent at 10:00 AM.
• Your consent system sends a webhook.
• The CRM endpoint is unavailable.
• The request fails.
• What happens next?

If the organisation has no retry, acknowledgement, failure monitoring or escalation mechanism, the consent state could remain inconsistent between systems.

This creates an important operational compliance risk.

Delivery Is Not the Same as Completion

Suppose a webhook returns HTTP 200.

That may demonstrate that the endpoint received the request.

It does not necessarily demonstrate that the downstream business action was completed.

A stronger compliance architecture can distinguish between:

Event Created --> Sent --> Delivered --> Acknowledged --> Action In Progress --> Completed --> Evidence Recorded

These technical states are not themselves mandated DPDP terminology. They are an implementation approach that can help businesses build stronger operational control and evidence.

How Consent Server Helps

This is one of Consent Server’s important differentiators.

Consent Server's event architecture can support:

• Webhook/API event generation
• Target-level delivery tracking
• Acknowledgement tracking
• Automatic retries
• Failure monitoring
• Escalation
• Action status tracking
• Completion evidence
• Audit history

This means a business can gain visibility beyond simply knowing that a webhook was sent.

For example:

Consent Withdrawn --> Webhook Sent --> CRM Delivered --> CRM Acknowledged --> Action Completed --> Evidence Stored

If delivery fails:

Consent Withdrawn --> Delivery Failed --> Retry --> Retry Failed --> Escalation --> Manual Review

That provides a much stronger operational compliance architecture.

Why a Basic Consent Checkbox Is Not Enough

These five points demonstrate an important distinction.

A website consent checkbox can collect a choice.

But a complete DPDP Consent Management Platform needs to help organizations manage what happens before and after that choice.

Businesses need to think about:

• How consent is obtained
• What purpose it covers
• How the Data Principal manages it
• How withdrawal works
• What happens in connected applications
• What happens when an integration fails
• How Data Principal requests are handled
• What historical evidence exists

That is the difference between consent collection and consent management.

How Consent Server Brings These Requirements Together

Consent Server is designed as a comprehensive DPDP Compliance Software and consent management solution for Indian organizations.

Instead of solving only one part of the problem, it provides a centralized architecture covering the broader consent lifecycle and related operational workflows.

Consent Server includes purpose-based consent, consent grant/update/withdrawal/renewal/expiry, Data Principal Portal, Data Principal request workflows, grievance management, notice versioning, APIs and webhooks, processor event workflows, acknowledgement tracking, retries, escalation, completion evidence, audit-ready records, RBAC, reporting and hash-based tamper detection.

For organizations that require greater control over their privacy infrastructure, Consent Server also supports self-hosted and on-premise deployment.

Consent Server vs a Basic Consent Tool

The difference becomes clearer with a practical example.

A basic consent tool may tell you:

“Customer withdrew consent.”

Consent Server is designed to help answer the questions that follow:

• When was it withdrawn?
• Which purpose was affected?
• What was the previous consent state?
• Which version applied?
• Which connected systems were notified?
• Was the event delivered?
• Did the target acknowledge it?
• Did delivery fail?
• Was it retried?
• Was escalation required?
• Where supported, was the downstream action completed?
• What evidence is available later?

That is the level of visibility organizations should consider when evaluating DPDP Compliance Software.

From Legal Requirement to Operational Compliance

DPDP Compliance cannot live only inside a privacy policy.

It ultimately needs to work across technology and business processes.

A Data Principal should have an accessible mechanism for exercising applicable rights.

Consent should involve clear affirmative action.

Withdrawal should be as easy as giving consent.

Processing based on withdrawn consent should cease within the legally required framework.

And organizations should build reliable mechanisms for propagating and tracking consent changes across relevant systems.

Consent Server helps bring these components together into one centralized platform.

For businesses comparing a Consent Management Platform, DPDP Consent Management Platform, DPDP Compliance Software or Consent Management Software in India, Consent Server provides a comprehensive solution designed around these operational requirements.

Is Your Business Ready?

Ask your organization five questions:

1. Can Data Principals easily exercise applicable rights?
2. Are we obtaining consent through clear affirmative action rather than relying on pre-selected choices?
3. Can users withdraw consent as easily as they provide it?
4. Can consent withdrawal be acted upon across relevant systems and Data Processors?
5. Can we track what happened after a consent change?

If any answer is unclear, that is an area worth reviewing as part of your DPDP readiness program.

Consent Server – A Complete DPDP Compliance and Consent Management Platform