Post

A DPDP consent notice is the document a business shows a person before it asks for permission to use their personal data, and in a B2B SaaS product it usually lives in an onboarding screen rather than a policy page. Getting it right depends on knowing what the law requires the notice to say, who is responsible for giving it, and how the product records the answer.

Our earlier note on DPDP compliance obligations and penalties sets out the wider framework. This piece is narrower and more practical. It looks at notices, consent and withdrawal, and at how a SaaS business divides those duties with its customers.

Key Takeaways

• A notice must itemise the personal data, state the purpose and explain how to withdraw, exercise rights and complain.
• Valid consent is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action.
• Withdrawing consent must be as easy as giving it, and processing must stop within a reasonable time after.
• In most B2B SaaS arrangements the customer is the data fiduciary and the vendor is its data processor.
• Notice and consent should be built into product flows and logs, not left to a policy page.

What the Act Requires a Notice to Say

The Digital Personal Data Protection Act 2023 treats notice as the condition that comes before consent. Section 5 requires every request for consent to be accompanied or preceded by a notice that tells the data principal what personal data is to be processed and for what purpose, how they may exercise their rights, including withdrawal, and how they may complain to the Data Protection Board.

The Digital Personal Data Protection Rules 2025, notified in November 2025, add detail. The notice must be understandable on its own, without the reader having to piece it together from other documents, and written in clear and plain language. It must give an itemised description of the personal data, the specified purpose with a description of the goods, services or uses that the processing enables, and a link or other means by which the person can withdraw consent, exercise rights and approach the Board.

The Act also requires that the notice be available in English or in any language listed in the Eighth Schedule to the Constitution, at the person's option. For a product used across Kerala, offering Malayalam alongside English is a practical way to meet that expectation.

Timing deserves care. The Rules bring their obligations into force in phases, and the government has consulted on shortening the transition window. A business should confirm the operative date for each obligation at the time it plans its work rather than rely on a figure quoted months earlier.

The Standard for Valid Consent

Section 6 sets the test. Consent must be free, specific, informed, unconditional and unambiguous, and it must be signified by a clear affirmative action. It must also be limited to the personal data necessary for the specified purpose. Each word does work in a product design.

Free means the person has a genuine choice. Specific means one purpose per consent, or at least purposes that can be accepted separately. Informed means the notice was shown before the request, not linked from a footer after the fact. Unconditional means access to the core service is not tied to consent for something unrelated, such as marketing.

The clear affirmative action requirement rules out the familiar shortcuts. Prefilled checkboxes, consent inferred from continued use and a single button that accepts terms of service and data processing together are all difficult to defend. An unticked box, a toggle the user switches on, or a separate confirmation step are the safer patterns.

Any part of a consent that infringes the Act is invalid to that extent. A bundled consent can therefore fail in part, leaving the business without a basis for the very processing it most needed. That is a strong reason to separate purposes at the design stage.

Withdrawal, Consent Managers and Legitimate Uses

The Act requires that withdrawal be possible at any time, with an ease comparable to the ease with which consent was given. If consent took one click inside the app, withdrawal should not require an email to a grievance officer and a wait. Once consent is withdrawn, the business must stop processing within a reasonable time and cause its data processors to stop as well, although processing done before withdrawal remains lawful.

Consent managers are a further channel. They are entities registered with the Board through which a person can give, manage, review and withdraw consent across services. The Rules set out how they are registered and what they owe the people who use them, with that part of the framework scheduled to commence ahead of the main obligations. A B2B SaaS product does not need to integrate with one immediately, but an architecture that can accept consent signals from an external source will age better.

Not every processing activity needs consent. Section 7 lists legitimate uses, including where a person voluntarily provides data for a specified purpose and has not objected to its use, compliance with law, medical emergencies and certain employment purposes. These grounds are narrow and specific. They are not a general substitute for consent, and a privacy policy lawyer reviewing a product will usually map each processing activity to one ground or the other.

The mapping itself is the useful document. A short register listing each purpose, the data used, the ground relied on and where the notice appears is what a business will reach for when a customer, auditor or the Board asks how it complies.

Data Fiduciary or Data Processor in a B2B SaaS Stack

The Act distinguishes the data fiduciary, which determines the purpose and means of processing, from the data processor, which processes on the fiduciary's behalf. Section 8 keeps responsibility with the fiduciary regardless of any agreement, and permits it to engage a processor only under a valid contract.

In most B2B SaaS arrangements the customer is the fiduciary. An employer using an HR platform decides why employee data is collected and what is done with it, and the vendor processes it on instructions. The duty to give the notice and obtain consent from employees sits with the employer, not the vendor.

The vendor is still a fiduciary in its own right for some data. Contact details of the customer's administrators, billing contacts, product analytics the vendor chooses to collect, and marketing lists are processed for the vendor's own purposes. Those need their own notice and, where consent is the ground, their own consent.

The line blurs when a vendor uses customer data to train models, benchmark across tenants or build new features. At that point it may be deciding purposes itself. The data processing agreement should say plainly what the vendor may and may not do, and our note on structuring data protection agreements covers the clauses that carry that allocation.

Building Notice and Consent Into Product Flows

For the vendor's own data, the onboarding flow is where notice and consent belong. A short layered notice at sign up, with the itemised data and purposes on the first layer and a link to the full privacy notice, meets the requirement that the notice be understandable on its own better than a long policy accepted with a single click.

For customer data, the vendor's job is to make the customer's compliance possible. Useful features include configurable notice text that a customer administrator can edit, consent capture at the point where the end user first enters data, separate toggles for separate purposes, and an interface through which consent status can be read and updated.

Records are the part most products miss. Each consent event should be logged with the notice version shown, the purposes accepted, the time and the method. Withdrawal should be logged the same way and should trigger downstream deletion or restriction, including in backups and analytics stores within the period the business has committed to.

Language and accessibility belong in the same build. A notice offered in the person's chosen language, readable on a phone and usable with a screen reader, is easier to defend than one that technically exists but cannot practically be read. A matter involving drafting the terms and privacy policy for a fintech app shows how closely product screens and legal text need to align.

Contracts, Records and the Review Before Launch

A B2B SaaS vendor's paperwork should match its product. The master agreement or data processing addendum should record the roles of each party, require the customer to provide notices and obtain consents for the data it uploads, oblige the vendor to act only on documented instructions, and set out how withdrawal and erasure requests will be passed between them.

A review before launch, or before a material change to the product, normally covers the following points.

• Whether each processing purpose is mapped to consent or a legitimate use
• Whether the notice is itemised, plain and available in the required languages
• Whether consent is unbundled and given by a clear affirmative action
• Whether withdrawal is as easy as consent and flows through to processors
• Whether contracts with customers and sub processors reflect the actual roles

A data privacy lawyer will also look at what the sales team promises. Security questionnaires and enterprise contract riders often commit the vendor to more than the product does, and those commitments become the standard against which the vendor is judged.

Conclusion

The DPDP framework asks for notices people can read and consents people can withdraw. For a B2B SaaS business that is as much a product question as a legal one, and the clearest compliance comes from deciding roles early, separating purposes in the interface and keeping records that show what each person saw and chose.

Customers and vendors should review their notices, flows and contracts together, since a gap in any one of them undermines the others. The data privacy practice page sets out how such a review is normally scoped.