# Promiz

> Promiz is a consent and privacy management platform for India's Digital Personal Data Protection (DPDP) Act 2023 and DPDP Rules 2025, built by Pentafox Technologies. This file is the full text of https://promiz.in in one document. The short index is https://promiz.in/llms.txt.

Promiz is software run by the Data Fiduciary. It is not a registered Consent Manager and it does not give legal advice.

## Modules

### Consent notices

No-code notices for your website, forms and email.

- Cookie banner, form panel, email request
- Versioned, per-purpose choices
- Live preview while you edit

Page: https://promiz.in/solutions/consent-notices/

### Cookie scanner & trackers

Find what runs on your site and file it under the right purpose.

- Scan history for every run
- Auto-filing by cookie category
- Tags blocked until allowed

Page: https://promiz.in/solutions/cookie-consent/

### Consent records & proof

A permanent, chained record of every grant, change and withdrawal.

- One-click integrity check
- Snapshot of the screen shown
- PDF notice and receipts

Page: https://promiz.in/solutions/consent-records/

### Privacy portal & requests

A branded self-service site and a request queue for your team.

- OTP sign-in, no password
- Access, correction, erasure, grievance
- Nominations

Page: https://promiz.in/solutions/privacy-portal/

### Obligations & retention

Deadlines for stopping processing and for erasing data.

- Separate withdrawal and erasure queues
- Legal holds at three levels
- 48-hour pre-erasure notice

Page: https://promiz.in/solutions/obligations-retention/

### Breach management

Log, track and report a breach against the clock.

- 72-hour countdown
- Severity and people affected
- Structured Rule 7 report

Page: https://promiz.in/solutions/breach-management/

## DPDP key dates

- 13 Nov 2025: Rules notified. Data Protection Board set up.
- 13 Nov 2026: Consent Manager provisions start.
- 13 May 2027: Notice, consent, rights, security, breach and erasure duties apply in full.

## DPDP duties and how Promiz covers each

- Clear, itemised notice before processing (S. 5 · Rule 3): Versioned notices in 23 languages, with shown-notice snapshots
- Free, specific consent for each purpose (S. 6): A separate choice per purpose; required and optional handled apart
- Withdrawal as easy as consent (S. 6(4)): One-click withdrawal in the banner and the privacy portal
- Stop processing after withdrawal (S. 6(6)): A stop-processing task per withdrawal, with overdue alerts
- Erase when the purpose ends (S. 8(7) · Rule 8): Per-purpose retention, legal holds, 48-hour notice and confirmed deletion
- Access, correction, erasure, grievance, nomination (S. 11–14 · Rule 14): Self-service portal and a request queue with deadlines
- Report a personal data breach (S. 8(6) · Rule 7): Breach log, 72-hour countdown and a structured report
- Verifiable consent for children's data (S. 9 · Rule 10): Guardian verified as an adult through DigiLocker; child-restriction flags
- Exempt classes for children's data (Rule 12 · Fourth Schedule): Recorded for the organisation and applied per purpose

## Who is who under the DPDP Act

- Data Principal: The individual the personal data is about. For a child it includes the parent or lawful guardian, and for a person with disability it includes their lawful guardian.
- Data Fiduciary: Any person or organisation that decides why and how personal data is processed, alone or with others. Most businesses that collect customer data are Data Fiduciaries, and the duties in the Act fall on them.
- Significant Data Fiduciary: A Data Fiduciary the Central Government notifies as significant, based on factors such as the volume and sensitivity of data it handles and the risk to Data Principals. It carries extra duties, including a Data Protection Officer based in India and periodic independent audits.
- Consent Manager: A company registered with the Data Protection Board that gives Data Principals one place to give, review, manage and withdraw consent across Data Fiduciaries. Promiz is not a Consent Manager; it is software a Data Fiduciary runs for its own consent and rights processes.
- Data Protection Board: The Data Protection Board of India, the adjudicating body set up under the Act. It receives breach reports and complaints, directs remedial action and imposes monetary penalties under the Schedule to the Act.
- Verifiable consent: The consent a Data Fiduciary must obtain from a parent or lawful guardian before processing a child's personal data, after checking that the adult is who they say they are. The DPDP Rules, 2025 allow the check against identity details the Data Fiduciary already holds or through a token from a Digital Locker service provider.
- Legitimate use: A ground in section 7 of the Act that lets a Data Fiduciary process personal data without consent in listed situations, such as data a person gives voluntarily for a stated purpose, employment, medical emergencies and compliance with a law. The list is closed; confirm with your legal team before relying on it.
- Personal data breach: Any unauthorised processing, or accidental disclosure, use, alteration, destruction or loss of access, that compromises the confidentiality, integrity or availability of personal data. A Data Fiduciary must inform affected Data Principals and the Board without delay and file a detailed report within 72 hours.
- Erasure: Deleting personal data, and having your processors delete it, once its purpose is served or consent is withdrawn, unless a law requires you to keep it. Rule 8 sets retention periods for some classes of Data Fiduciary and requires at least 48 hours of notice to the Data Principal before erasure.
- Legal hold: A flag that stops erasure because a law, regulator or court requires the data to be kept, for example RBI record-keeping rules. A withdrawal still stops other processing; it does not override the hold. The term comes from practice, not from the Act.
- Nomination: The right of a Data Principal under section 14 to name another person who can exercise their rights on their behalf if they die or become incapable of doing so.
- Grievance officer: The person whose contact details a Data Fiduciary must publish so Data Principals can ask about processing and raise grievances. Grievances must be answered within the period the Data Fiduciary publishes, which Rule 14 caps at 90 days.

## Frequently asked questions

### When does the DPDP Act come into force?

In phases. The DPDP Rules, 2025 were notified on 13 November 2025, when the Data Protection Board was set up. Consent Manager provisions start on 13 November 2026. The duties on notice, consent, rights, security, breach and erasure apply in full from 13 May 2027.

### Does the DPDP Act apply to my business?

If you process digital personal data in India, yes. It also applies to processing outside India when it is for offering goods or services to people in India. There is no turnover or headcount threshold. The Central Government can exempt some classes of Data Fiduciary (section 17) and can notify large or high-risk ones as Significant Data Fiduciaries; confirm your position with your legal team.

### How long do we have to report a personal data breach?

You must inform each affected Data Principal and the Data Protection Board without delay, and send the Board a detailed report within 72 hours of becoming aware of the breach (Rule 7). The Board can extend the 72 hours on a written request.

### What happens if we do not comply with the DPDP Act?

The Data Protection Board can impose a monetary penalty for each instance of non-compliance, up to the amount in the Schedule to the Act: ₹250 crore for failing to keep reasonable security safeguards, ₹200 crore for failing to notify a breach or for breaching the duties on children, and ₹50 crore for other duties.

### Do existing customers need to consent again?

For consent given before the Act started, the Act asks you to send a notice as soon as reasonably practicable. Ask your legal team whether you also need fresh consent. Promiz can send consent requests by email link.

### Is Promiz a registered Consent Manager?

No. Promiz is software that you, the Data Fiduciary, use to run your own consent and rights processes. A Consent Manager is a separate role registered with the Data Protection Board.

### Do we need consent for cookies?

If a cookie identifies or profiles a person, treat it as personal data. The website script blocks each tag until its purpose is allowed and records the choice.

### Which languages are supported?

English and the 22 languages of the Eighth Schedule. Translate by hand or with background auto-translation. Customers can switch language inside the notice.

### How do our systems learn about a withdrawal?

By signed webhook, sent at once. Failed deliveries are retried, then held for review. Your system confirms back to Promiz to close the task.

### Does Promiz give legal advice?

No. Promiz supports your compliance programme. Your legal team decides purposes, legal bases and retention periods.

## Industries

### Banking

Why is DPDP consent hard in banking?

A bank meets the same customer at a branch counter, in a mobile app, at a call centre and through a relationship manager. Each channel collects personal data under a different mix of consent and legal obligation. RBI record-keeping directions require some of that data to stay for years after an account closes. The DPDP Act asks you to stop processing on withdrawal and erase once a purpose ends. You can only reconcile the two when every purpose carries its own legal basis and retention clock.

Regulators: RBI directions on record retention apply alongside the DPDP Act 2023 and DPDP Rules 2025. Confirm retention periods for each purpose with your legal team.

- Legal-obligation purposes stop use on withdrawal, but are not erased: Each purpose is tagged with its legal basis and retention clock. Withdrawal stops consent-based use, and legal-obligation records stay untouched.
- Legal holds freeze erasure during disputes: Legal holds pause the erasure queue for a disputed account. Promiz logs who placed the hold and why.
- Branch staff send consent links by email: Branch and call-centre staff send single-use consent links by email. The record stores the exact notice version shown.

### NBFC & lending

Why is DPDP consent hard in NBFC lending?

Lending runs on a chain of processors: sourcing partners, bureaus, KYC vendors, co-lenders and collection agencies. Borrower data leaves your systems on day one. A withdrawal is only complete when every processor has stopped too. Digital lending journeys also collect consent fast, on a phone, often in a regional language. Proof of the notice shown is harder to keep than the signature.

Regulators: RBI digital lending and outsourcing directions apply alongside the DPDP Act 2023 and DPDP Rules 2025. Confirm your processor obligations with your legal team.

- Every partner system must hear about a withdrawal: Signed webhooks push each withdrawal and erasure to partner systems at once, and Promiz waits for their confirmation.
- A partner does not confirm the stop: Each stop-processing task has a deadline. An overdue alert fires when a partner has not confirmed the stop.
- Consent on loan forms is fast and hard to prove: Loan forms capture OTP-verified consent per purpose, with a snapshot of the notice in the language the borrower saw.

### Insurance

Why is DPDP consent hard in insurance?

Insurers collect some of the most sensitive personal data in the market: health history, family details, income and nominee information. Agents and brokers gather much of it on paper or over a phone, long before the customer uses a portal. When a customer later asks what they agreed to, the proposal form rarely shows the notice that was read out. Quotes, underwriting, claims and marketing are often bundled under one signature.

Regulators: IRDAI regulations on policyholder data and outsourcing apply alongside the DPDP Act 2023 and DPDP Rules 2025. Confirm sector requirements with your legal team.

- Offline customers never see the notice: Agents send a single-use email link, so offline customers read and accept the notice themselves. The record is theirs, not the agent’s.
- No proof of the exact notice shown: Every consent record stores a snapshot of the exact notice text and language shown at that moment.
- One signature covers every purpose: Quotes, claims servicing and marketing are separate purposes, each with its own consent, retention and withdrawal.

### Healthcare

Why is DPDP consent hard in healthcare?

Hospitals, clinics, labs and digital health apps hold records that clinicians must reach in an emergency. The same systems hold data used only for research, wellness programmes or marketing. Patients include minors and people who cannot consent for themselves. A single withdraw-everything switch is unsafe for care. A single keep-everything policy is unlawful for the rest.

Regulators: The DPDP Act 2023 and DPDP Rules 2025 apply, with the children’s data provisions (S. 9, Rule 10). Confirm any sector-specific record-keeping duties with your legal team.

- Care and non-care data live in the same systems: Each purpose has its own legal basis and retention period.
- Essential care purposes must stay on: Withdrawal and erasure queues work per purpose, so a research opt-out never touches the clinical record.
- Minors need a guardian’s consent: Guardian consent for minors is verified through DigiLocker and recorded against the child’s purposes.

### E-commerce & retail

Why is DPDP consent hard in e-commerce and retail?

Retail sites change all the time: a new ad pixel, an A/B testing script, a chat widget, a payments SDK. Each one can set cookies and read personal data before compliance hears about it. Shoppers arrive from every state and expect a notice they can read. Marketing teams need consent that survives the next campaign tool.

Regulators: The DPDP Act 2023 and DPDP Rules 2025 apply to online and offline retail data. Confirm consumer-protection overlaps with your legal team.

- Your tracker list is out of date: The cookie scanner re-crawls your site on a schedule and flags every new tracker, so the notice matches reality.
- Tags fire before consent: Every tag stays blocked until the shopper allows its purpose. The choice is stored in a chained, tamper-evident record.
- Shoppers read different languages: Notices are served in 23 languages (English and the 22 Eighth Schedule languages), with a version history per language.

### Education & ed-tech

Why is DPDP consent hard in education and ed-tech?

Schools, coaching platforms and ed-tech apps process data about learners who are mostly under 18. The DPDP Act requires verifiable parental consent for a child’s data. It bans tracking, behavioural monitoring and targeted advertising directed at children, with narrow exemptions in the Fourth Schedule. Product analytics that is routine for adults becomes a compliance question here.

Regulators: DPDP Act 2023 S. 9 and DPDP Rules 2025 Rule 10, Rule 12 and the Fourth Schedule govern children’s data. Confirm which exemptions apply to you with your legal team.

- The guardian must be a verified adult: A guardian is verified as an adult through DigiLocker before consent is recorded for the child.
- Tracking and targeted ads are banned for children: Child-restriction flags on a purpose block tracking and targeted-advertising tags for that learner.
- Exemptions are narrow and must be justified: The Fourth Schedule exemptions your organisation relies on are recorded once and applied per purpose.

### Travel & hospitality

Why is DPDP consent hard in travel and hospitality?

A single stay creates data at the online travel agent, the booking engine, the front desk, the loyalty programme and often a third-party check-in kiosk. Staff collect passport and ID scans at the desk and rarely tie them to a consent record. When a guest asks for erasure, most properties cannot say where all the copies are.

Regulators: The DPDP Act 2023 and DPDP Rules 2025 apply to guest data. Confirm identity-document retention rules with your legal team.

- Guest data sits in many channels: Web, forms and front-desk capture write to one consent record per guest, so every channel sees the same status.
- Nobody knows when to erase: Each booking purpose has its own retention clock. Erasure starts when the purpose ends, after the 48-hour notice.
- Guest requests arrive by phone: A branded self-service portal lets guests view consents and raise access, correction or erasure requests.

### SaaS & technology

Why is DPDP consent hard for SaaS and technology companies?

A software company is a Data Fiduciary for its own users and a Data Processor for the personal data its customers load into the product. Rights requests arrive in both roles. Engineering must wire consent into sign-up flows, settings pages and back-end jobs without building a compliance system from scratch.

Regulators: The DPDP Act 2023 and DPDP Rules 2025 apply to you as a Data Fiduciary for your own users, and through contracts as a Processor. Confirm your processor terms with your legal team.

- Many products under one company: Multiple applications and brands sit under one login, each with its own notices, purposes and records.
- Engineering needs consent in code: A REST API and Python SDK let your back end record consent, check status and receive withdrawal events.
- Rights requests have deadlines: Rights requests land in a queue with tracked deadlines. Processor requests can be routed to the customer who owns the data.

## Illustrative scenarios (not named customers)

### A withdrawal that reaches every partner

Sector: NBFC & lending. A lending NBFC whose borrower data flows to co-lending partners and collection agents, with no way to confirm a withdrawal reached any of them.

Borrower data left the NBFC the moment a loan was approved: to a co-lending partner for its share of the book, to a collection agency once an EMI slipped, and to a marketing tool that pushed top-up offers. Consent was a single checkbox on the loan form, so "marketing", "collections" and "underwriting" were one purpose. When a borrower withdrew, the only lever was an email to each partner asking them to stop - and nobody could say when, or whether, they had.

RBI record-keeping made it worse. Loan files must be retained after closure for as long as the applicable rules require, so the operations team was afraid to act on any withdrawal at all: deleting the wrong record was a regulatory breach, keeping the wrong one was a DPDP breach. Section 6(6) asks the fiduciary to stop processing after withdrawal, and Section 6(4) asks that withdrawing be as easy as consenting. Neither could be shown.

What was set up:

- Purposes split on the loan form, with OTP-verified consent: Underwriting and RBI record-keeping became legal-obligation purposes. Collections, partner offers and top-up marketing became separate consent purposes, each with its own choice. The borrower confirms with a one-time code, and the shown notice is snapshotted onto the record.
- Signed webhooks to every partner system: Each co-lender, collection agency and marketing tool receives a signed webhook the moment a purpose is withdrawn. The payload names the borrower reference and the purpose, nothing more.
- A stop-processing task per withdrawal: Every withdrawal opens a task with a confirmation deadline. The task closes only when the partner system calls back to confirm it stopped. Anything past its deadline shows as overdue on the obligations queue.
- Legal-obligation purposes stop use, never erase: Withdrawal on a legal-obligation purpose stops marketing use but keeps the loan file. Legal holds freeze any erasure clock for accounts in dispute or under recovery proceedings.
- Receipts for the borrower and the Board: The borrower receives a receipt naming what was withdrawn and when. The same chained record, with the partner confirmations, is what the compliance team exports when asked for proof.

What changed:

- Every partner system now receives the withdrawal and confirms it, and the confirmation is on the record.
- The operations team can see which withdrawals are still open and which partner has not answered, instead of guessing.
- RBI retention and DPDP withdrawal no longer conflict: the loan file stays, the marketing use stops.
- A borrower’s receipt and the compliance export come from the same record, so the two never disagree.

Page: https://promiz.in/scenarios/nbfc-withdrawal-across-partners/

### Proof of notice for consent collected in person

Sector: Insurance. An insurer whose agents collect health and family details face to face, with no record of the notice the customer actually saw.

Most policies were sold by agents sitting across a table. Health history, family details and nominee information were written onto paper proposal forms and keyed in later by a back office. The consent line on the form was generic, the language was English regardless of the customer, and nothing recorded which version of the privacy notice had been in front of the person. If a customer later disputed what they had agreed to, the insurer had a signature and nothing else.

Quotes, claims and marketing also shared one consent. A person who asked for a quote and never bought a policy kept receiving renewal-style outreach, and there was no clock on when that enquiry data should go. Section 5 asks for a clear, itemised notice before processing, and Section 8(7) asks that data be erased when its purpose ends. Paper forms and a single checkbox could satisfy neither.

What was set up:

- One notice, three modes: The privacy notice was built once in Promiz and published in the cookie-banner, form and emailed-request modes. Agents no longer improvise wording; the binding text is versioned and fingerprinted.
- Single-use email links for offline customers: After a face-to-face meeting, the agent sends the customer a single-use consent link by email. The customer reads the notice in their own language, chooses per purpose and confirms. The link expires once used.
- Separate purposes for quotes, claims and marketing: A quote enquiry, a policy under claim and marketing outreach each got their own purpose with its own legal basis and retention period. Claims processing stays on for the life of the policy; a lapsed quote enquiry has a short retention clock.
- Snapshot of the exact notice on each record: Every consent record carries the version and the rendered view of the notice the customer saw, in the language they saw it. Assisted withdrawal lets branch staff withdraw on a customer’s request, with a reason logged.
- Receipts in the customer’s language: The customer receives a receipt listing each purpose and choice. The compliance team can pull the notice PDF and the chained record for any policy in one step.

What changed:

- For every policy sold offline, the insurer can now show the exact notice the customer saw, in the language they saw it.
- Quote enquiries that do not convert now run down a retention clock and are erased with a confirmed deletion, rather than living on in the outreach list.
- Agents send a link instead of explaining a privacy notice from memory, so the wording is the same for every customer.
- A dispute about "what did I agree to" is answered from the record, not from the agent’s recollection.

Page: https://promiz.in/scenarios/insurer-offline-consent/

### Verifiable guardian consent for learners under 18

Sector: Education & ed-tech. An ed-tech platform where many learners are under 18, and the sign-up flow could not tell a guardian from a child.

Learners signed up with an email address and a date of birth that nobody checked. A large share were minors, but the same analytics pixels, ad-retargeting tags and engagement nudges ran for every account. Parents sometimes created the account, sometimes the child did, and the platform had no record of which. When a school asked how the platform handled children’s data, the honest answer was that it handled it the same way as everyone else’s.

Section 9 requires verifiable consent from a parent or guardian before processing a child’s data, and forbids tracking, behavioural monitoring and targeted advertising directed at children. Rule 10 sets out how the guardian is verified. Rule 12 and the Fourth Schedule exempt certain classes of processing, such as some educational activities, but the exemption has to be claimed for a purpose and recorded. The platform had no mechanism for any of this.

What was set up:

- DigiLocker guardian check at sign-up: When a learner’s date of birth shows they are under 18, the flow asks for a guardian. The guardian is verified as an adult through DigiLocker before any purpose beyond account creation is enabled.
- Child-restriction flags on every purpose: Each purpose in the notice carries a child-restriction flag. Analytics, retargeting and behavioural nudges are marked restricted, so they never activate on an account flagged as a child’s, regardless of what the guardian ticks.
- Cookie scanner and tag blocking: The scanner keeps the list of pixels and tags on the learning site current. Each tag is mapped to a purpose and stays blocked until that purpose is allowed, which for a child account means the restricted ones never fire.
- Fourth Schedule exemptions recorded per purpose: Purposes that fall under an educational exemption are recorded as such at the organisation level and applied per purpose, so the platform can show which processing rests on the exemption and which on guardian consent.
- A privacy portal for guardians: Guardians sign in with a one-time code, see every purpose for the child’s account, withdraw any of them, and raise access, correction or erasure requests that land in a queue with a deadline.

What changed:

- Every child account now has a verified adult guardian on the record before optional processing begins.
- Tracking and targeted advertising cannot run on a child account, because the restriction is enforced at the purpose and tag level rather than by policy.
- The platform can answer a school’s question with the consent record, the exemption register and the tag map, instead of a statement of intent.
- Guardians manage the child’s consents and requests themselves, with a clock on each request.

Page: https://promiz.in/scenarios/edtech-guardian-consent/

## Articles

### Can you prove your users said yes? Consent under India's DPDP Act

The DPDP Act requires provable consent, not just a checkbox. Six requirements, six common gaps, and how Promiz records consent with tamper-evident proof.

Published 2026-09-25. https://promiz.in/blog/dpdp-consent-proof/

Most Indian websites collect consent with a checkbox and a line in the database. Under the Digital Personal Data Protection (DPDP) Act, 2023, that is not enough. When a customer complains or the Data Protection Board asks, you have to show what the person was told, what they agreed to, and when.

The DPDP Rules were notified in November 2025, and most obligations apply from mid-2027. That leaves a short window to fix consent before it becomes a legal risk. Penalties under the Act go up to ₹250 crore per breach.

We built Promiz to close that gap. It is a consent management platform made for the DPDP Act, not adapted from a European GDPR tool.

#### What the DPDP Act asks of you

If your website or app collects personal data from people in India, the Act expects six things.

- A clear notice (Section 5). Tell people what data you collect, why, and how they can complain, in English or any of the 22 scheduled Indian languages they choose.
- Valid consent (Section 6). Consent must be free, specific, informed and unambiguous, given for each purpose. Pre-ticked boxes do not count.
- Easy withdrawal. Withdrawing consent must be as easy as giving it.
- Children's data (Section 9). For users under 18, you need verifiable consent from a parent or guardian.
- User rights (Sections 11 to 14). People can ask to see, correct or erase their data, raise a grievance, and nominate someone to act for them.
- Proof. You must be able to show all of this happened, long after the click.

#### Where most consent setups fall short

Ask any compliance team how consent works on their website today, and the same gaps come up.

- No proof of what was shown. The database says "consented: true", but nobody can show the notice text or screen the person saw.
- One checkbox for everything. Marketing, analytics and service are bundled into one "I agree", which fails the specific-purpose test.
- English only. Notices are not available in the languages customers actually read.
- Withdrawal buried in an email address. Saying no takes far more effort than saying yes.
- Records that can be edited. If an admin can quietly change a consent row, the record is weak evidence.
- Children treated like adults. A "Yes, I am 18" checkbox is not verifiable parental consent.

#### How Promiz covers each requirement

Promiz handles the whole consent lifecycle, from the first banner to the day a user asks you to delete their data.

- Clear notice: Versioned notices in Indian languages, translated through the government's Bhashini service. Each one lists purposes, data collected, retention and the grievance contact.
- Valid consent: Separate choices for each purpose. Non-essential purposes can never start switched on; the server rejects them.
- Easy withdrawal: A preference centre where users change or withdraw consent in one click, any time.
- Children's data: Server-side age checks, verification through DigiLocker, and verified guardian consent linked to the child's record.
- User rights: A self-service portal for access, correction, erasure, grievance and nomination requests, each tracked against a 30-day deadline.
- Proof: Every consent is stored with a fingerprint of the exact notice and screen the user saw, in a tamper-evident, append-only record. Any later change is detectable.

Consent does not last forever either. Promiz tracks expiry and asks users to renew before consent lapses.

#### Getting started takes one line of code

You do not need to rebuild your website to use Promiz.

1. Set up your notice. Add your purposes and the data you collect in the Promiz console, and pick your languages.
2. Design your banner. Choose the layout and colours, and preview the banner and preference centre before going live.
3. Add one script tag. Paste the Promiz snippet into your site. The consent banner appears and every choice is recorded from that moment.

From then on, your compliance team works from one dashboard: consent records, rights requests, grievances and deadlines, all in one place.

The DPDP deadline is closer than it looks. Consent you collect today, with proof, is consent you will not have to collect again.

Want to see Promiz on your own website? Visit www.promiz.in to book a demo, and we will set up a working banner with you.

### DPDP Consent Without the Drop-Off: How to Design a Notice That Still Converts

How BFSI and digital teams collect valid consent under India's DPDP Act 2023 without losing sign-ups. The rules that make consent valid, and the design that keeps both.

Published 2026-09-24. https://promiz.in/blog/dpdp-consent-notice-design/

You need consent under the DPDP Act. You also need customers to finish the sign-up. Most teams treat this as a trade-off — a long legal checkbox that scares people off, or a quick vague tick that a regulator can throw out. Both lose. This guide shows how to collect valid consent with low friction, and how [Promiz](https://promiz.in/) ships it in a no-code notice.

#### First, the hard truth: you cannot “optimise” your way to consent

Reducing friction is good. Reducing choice is not. Under the DPDP Act, consent must be free, specific, informed and unambiguous, given by a clear affirmative action. The moment your design pushes a customer toward “yes”, the consent stops being free — and unfree consent is invalid.

So four common “conversion” tricks are off the table:

- Pre-ticked boxes. The customer took no action, so there is no consent.
- A single “accept all” that bundles service data with marketing. It is not specific.
- A reject option that is hidden, greyed out or three taps away.
- A withdrawal link the customer can never find later.

The real win is not a smaller checkbox. It is a clearer one. Clarity and low friction lift completion and keep the consent lawful.

#### What makes consent valid under the DPDP Act

Before you design the box, know what the box must do. A valid notice and consent flow does five things.

[Figure: Five things that make consent valid under the DPDP Act: itemised data, specific purpose, plain language in English and 22 Indian languages, clear affirmative action with nothing pre-ticked, and easy withdrawal plus a grievance route.]

*Design the box to satisfy these five, and the friction takes care of itself.*

#### Why the “big checkbox” tanks conversion

Some teams answer the law with a wall. Every purpose, every data field, one long list, one “I agree”. It is legal-looking, and it drives customers away. Each avoidable friction point is a drop-off.

[Figure: A funnel showing customers dropping off at the consent step: they see the notice, read it, make a choice, then submit. People leave because of a wall of legal text, no clear reject, and the wrong language or too many clicks.]

*Three friction points, three leaks. Each one is a design choice you can undo.*

#### The design that keeps consent valid and friction low

You do not choose between the law and the conversion. You get both by making the choice fast and honest.

##### 1. Give a real choice per purpose — nothing pre-ticked

Show each purpose on its own line, off by default. Required purposes carry their own basis and are marked as required. This is specific consent, and it is what the Act asks for.

[Figure: Left: one vague pre-ticked checkbox that bundles everything is not valid consent. Right: a separate choice per purpose with nothing pre-ticked is valid consent.]

*Same screen space. One version is unlawful, the other converts and holds up.*

##### 2. Collapse to one tap — keep the detail underneath

Most customers want to decide in a second. Give them three clear buttons and let the granular choices sit below for those who want them. Reject must be as easy as accept, or the choice is not free.

[Figure: A consent footer with three equal buttons: accept all, accept selected, and reject all. One tap to decide, granular choices underneath, and reject as easy as accept.]

*Speed for the many, detail for the few — without pushing anyone toward “yes”.*

##### 3. Speak the customer’s language

A notice in English only excludes most of India. The Act lets you serve the notice in English or any Eighth Schedule language. Offer a language switch inside the notice, so the customer reads the choice before they make it.

##### 4. Separate required from optional

In BFSI this matters most. Account opening and KYC run on a legal obligation and are marked required. Marketing and analytics are optional and need a free, specific choice. Never make the optional a price of the service.

#### Mistakes that void consent

| The shortcut | Why it fails under the DPDP Act |
| --- | --- |
| One “I agree” for everything | Not specific. Each purpose needs its own choice. |
| Pre-ticked boxes | No affirmative action, so no consent. |
| Marketing bundled with the service | Consent is not free if the service depends on it. |
| Hidden or greyed-out reject | A pushed choice is not a free choice. |
| No way to withdraw later | The Act requires withdrawal as easy as giving consent. |
| English-only notice | Most customers cannot read the choice they are making. |

#### Measure the right things

A good consent flow is a number you can watch, not a one-time build. Track four:

- Completion rate at the consent step. A drop here points to friction, not to the law.
- Reject rate per purpose. A high reject on one purpose means your ask is too broad or unclear.
- Withdrawal rate over time. A rise can mean the first notice over-promised.
- Language mix. If most customers switch language, English-first was costing you.

> The test that matters.
>
> Could a customer, in ten seconds, see what you collect, why, and how to say no — in their language? If yes, you have low friction and lawful consent at the same time.

#### How Promiz ships this

Promiz turns these principles into a no-code notice you publish once. You write the binding consent text and set a purpose, a legal basis and a retention period for each choice. Promiz serves it as a banner, a form panel or an emailed request, in English and 22 Indian languages, with the customer able to switch language inside the notice.

Every opt-in stores the notice version, a text fingerprint and a snapshot of the screen the customer saw — so you can always show what they agreed to. Withdrawal sits in the banner and in a self-service privacy portal, and a withdrawal opens a stop-processing task that reaches your other systems by signed webhook. That is a consent flow that converts, and that holds up when the Data Protection Board asks.

> Key dates.
>
> The DPDP Rules, 2025 were notified on 13 November 2025. Notice, consent, rights, security, breach and erasure duties apply in full from 13 May 2027. Confirm the dates that apply to your firm with your legal team.

#### Questions teams ask

##### Can I use a single “I agree” checkbox?

No. Consent must be specific. One checkbox that bundles many purposes fails that test. Give a separate choice per purpose.

##### Can boxes be pre-ticked?

No. Consent needs a clear action from the customer. A pre-ticked box is not their action, so it is not consent.

##### Does cutting friction risk invalid consent?

Only if you cross from clarity into pressure. Fewer clicks and plain language are safe and help. Pre-ticking, bundling, a hidden reject or a buried withdrawal are not.

##### Which languages must the notice support?

English or any Eighth Schedule language. Promiz covers English and 22 Indian languages, with an in-notice switch.

##### Do I have to offer a reject button?

You must not force a customer to accept optional purposes to use the service, and declining must be as easy as accepting. In practice, that means a clear way to say no.

### How to Classify Personal Data Under the DPDP Act: A BFSI Guide

A practical guide for banks, NBFCs and insurers on how to classify personal data under India's DPDP Act 2023. Learn what counts as personal data, why the Act has no 'sensitive' category, and how purpose drives classification.

Published 2026-09-24. https://promiz.in/blog/dpdp-data-classification-bfsi/

Every bank, NBFC and insurer in India holds personal data. Under the Digital Personal Data Protection Act, 2023 (DPDP Act), you must know what that data is and why you hold it. If you classify it wrong, you process data without a lawful basis, you fail an audit, and you risk a penalty. This guide shows BFSI teams how to classify data the way the Act expects — and how [Promiz](https://promiz.in/) turns that classification into working controls, with every field tied to a purpose, a lawful basis and proof you can export on demand.

#### What counts as personal data under the DPDP Act

The DPDP Act uses one clear test. Personal data is any data about an individual who can be identified by that data, or in relation to it. If a field points to a real person, alone or in combination, it is personal data.

Some data is personal on its own:

- Name, phone number and email address
- PAN, Aadhaar number and customer ID
- Bank account number and card number
- Photograph and biometric records

Other data becomes personal only in combination. A single row in a report may look harmless. Join it to a name, a branch or a timestamp, and it identifies a customer. A loan amount, a device ID or a location trail all become personal data the moment they can point back to a person.

[Figure: Three harmless-looking fields (loan amount, branch, timestamp) combine to identify one customer, making the data personal data under the DPDP Act.]

*No single field names the customer. Joined together, they do — so all of it is personal data.*

> Rule of thumb.
>
> If you can link the data to one identifiable person — today or later, alone or joined to another field — treat it as personal data and protect it.

#### The point most guides get wrong: there is no “sensitive data” category

Many articles tell BFSI teams to sort data into “sensitive” and “non-sensitive” buckets. That advice comes from GDPR and from India’s older SPDI Rules, 2011. It does not match the DPDP Act.

The DPDP Act does not create a separate legal class for sensitive personal data. It treats all personal data under one definition. Financial data, health data and biometrics get no special statutory tier of their own. This is a deliberate change from the earlier regime.

[Figure: GDPR and the older SPDI Rules split data into a personal-data layer and a separate sensitive-data tier with extra rules. The DPDP Act uses one flat definition of personal data, treated uniformly.]

*The DPDP Act drops the separate “sensitive data” tier that GDPR and the SPDI Rules use.*

So does sensitivity stop mattering? No. It still shapes two things:

- Significant Data Fiduciary (SDF) status. The Act uses the sensitivity and volume of the data you hold to decide if you are an SDF, which carries extra duties.
- The size of a penalty. After a breach, the type of data involved is a factor in how large the penalty is.

The takeaway for BFSI: do not build your programme around “sensitive vs non-sensitive” labels. Build it around one question — is this personal data, and what is my lawful basis for it? Then apply strong security to the data that would cause the most harm if it leaked.

#### Purpose drives classification

Under the DPDP Act, the same field can carry different duties, based on why you hold it. Purpose, not the field name, decides how you handle the data.

Take a mobile number. As a KYC field, you hold it on a legal obligation, and a customer cannot ask you to erase it while the law makes you keep it. As a marketing contact, you hold it on consent, and the customer can withdraw at any time. Same number, two purposes, two sets of rules.

[Figure: One mobile number carries different DPDP duties by purpose: as KYC data it is held on legal obligation and must be kept; as marketing data it is held on consent and can be withdrawn.]

*Same field, two purposes, two sets of duties. Purpose — not the field name — decides how you handle it.*

This is why every data set needs three things tied to it: a clear purpose, a lawful basis, and a retention period. Without them, you cannot prove the data is lawful when the Data Protection Board asks.

#### How this looks in BFSI: five real cases

| Data set | Why it is personal data | Typical basis & note |
| --- | --- | --- |
| Account opening / KYC (PAN, Aadhaar, address) | Directly identifies the customer | Legal obligation (KYC/AML). Withdrawal stops other uses, but RBI rules make you keep the record. |
| Loan processing (income, employer, references) | Joined to name and contact, it identifies the applicant | Consent or contract. Data often flows to partners, so a withdrawal must reach them too. |
| Mobile app analytics (device ID, location, behaviour) | Can profile and identify a user | Consent. Analytics needs its own purpose — it is not covered by the account-opening notice. |
| Event leads / visiting cards (name, phone, company) | Identifies a named person | You still need a lawful purpose before you market to them. |
| Marketing lists (email, preferences) | Identifies a subscriber | Consent. Must be free, specific and easy to withdraw. |

Notice the pattern. The hard part is not spotting a name. It is proving why you hold each field, and keeping that proof current as purposes change.

#### What misclassification costs

Under-classify a data set — treat personal data as harmless — and you skip the notice, the consent and the security you owe. That is unlawful processing. Under the DPDP Act, penalties can reach ₹250 crore for a failure to keep reasonable security safeguards. Failures around breach reporting and children’s data carry their own high penalties.

> The Board looks for proof, not policy.
>
> A retention policy in a PDF is not evidence. You must show the notice a customer saw, the consent they gave, and the date you erased their data when the purpose ended.

#### A practical way to classify your data

1. Map every field. List each data field, where it comes from, and which system holds it.
2. Apply the identifiability test. Can it point to a person, alone or combined? If yes, it is personal data.
3. Tie each set to one purpose and one lawful basis. Keep required purposes and optional purposes apart.
4. Set a retention period per purpose. Decide when the data must stop being used, and when it must be erased.
5. Flag children’s and guardian data. Data of a person under 18 needs verifiable guardian consent and limits on tracking.
6. Keep the proof. Store the notice version, the consent record and the deletion evidence for every data set.

When in doubt, classify up, not down. It is cheaper to hold a borderline field to a higher standard than to explain to the Board why you left it out.

#### Classification is step one. Promiz runs the rest.

Getting the labels right is the easy part. The legal risk sits in what happens next — proving what you showed, acting on a withdrawal across every system, erasing on time, and answering a rights request before the deadline. This is where most tools stop, and where Promiz is built to work.

[Figure: Data flow through Promiz: consent is collected from the website, forms and KYC, back-end API and email links; Promiz holds one chained consent record tied to notice, purpose and deadline; on any change it syncs by signed webhook to CRM, ad tools, partners and core systems. The lifecycle runs notice, consent, withdraw, stop, erase, prove.]

*Consent flows in from every channel, lives on one Promiz record, and syncs out to every system the moment a customer’s choice changes.*

Consent comes in from every channel — your website, forms, KYC desks, back-end API and email links. Promiz holds it as one chained, tamper-evident record, with each choice tied to a notice, a purpose and a deadline. When a customer withdraws, Promiz opens a stop-processing task and fires a signed webhook to your CRM, ad tools and partners at once, so no system keeps using data it may no longer touch. Retention clocks run per purpose. A breach starts a 72-hour countdown that ends in a structured report. When the Data Protection Board asks for proof, you export it the same day — the notice a customer saw, the consent they gave, and the date you erased their data.

[Figure: DPDP compliance timeline: 13 November 2025 rules notified and Board set up; 13 November 2026 Consent Manager provisions start; 13 May 2027 all core duties apply in full.]

*Where DPDP compliance stands, and the date every Data Fiduciary is working toward.*

> Key dates.
>
> The DPDP Rules, 2025 were notified on 13 November 2025. Notice, consent, rights, security, breach and erasure duties apply in full from 13 May 2027. Confirm the dates that apply to your firm with your legal team.

#### Questions teams ask

##### Does the DPDP Act have a category for sensitive personal data?

No. The Act treats all personal data under one definition. Sensitivity still matters, but only as a factor for Significant Data Fiduciary status and for the size of a penalty after a breach.

##### Is financial or KYC data classed as sensitive?

Financial and KYC data is personal data under the DPDP Act. The Act does not label it “sensitive” as a separate class. You must still protect it with strong security, because the harm and the penalty are higher if it leaks.

##### Do we need consent for KYC data?

Often no. Much KYC and AML data runs on a legal obligation, not on consent. A person cannot withdraw data the law makes you keep. You must still show a clear notice and record why you hold it.

##### When must we comply?

The DPDP Rules, 2025 were notified on 13 November 2025. The core duties apply in full from 13 May 2027.

### 13 May 2027: a working plan for Data Fiduciaries

The DPDP Rules were notified on 13 November 2025 and apply in full on 13 May 2027. What to have in place each quarter between now and then.

Published 2026-09-18. https://promiz.in/blog/countdown-to-13-may-2027/

#### What are the dates?

The DPDP Rules, 2025 were notified on 13 November 2025, and the Data Protection Board was set up. Consent Manager provisions start on 13 November 2026, with an earlier date proposed for Significant Data Fiduciaries. On 13 May 2027 the notice, consent, rights, security, breach and erasure duties apply in full to every Data Fiduciary.

Confirm the dates that apply to you with your legal team, and check whether the proposed Significant Data Fiduciary date has been notified.

#### What should be done first?

Start with the inventory: every purpose you process personal data for, the legal basis for each, the retention period, and where the data flows. This list drives everything else - the notices, the consent choices, the retention clocks and the systems a withdrawal has to reach.

Then fix the record. Decide where consent will be stored, in what form, and how you will prove later what was shown. If the answer is a database table someone can edit, that is the first thing to change.

#### What comes next?

Publish the notices and collect consent per purpose across web, forms and any offline channel. Wire withdrawals to every downstream system and make each one confirm. Turn retention periods into clocks with legal holds where RBI, IRDAI or a dispute require data to be kept. Open the rights portal and the request queue with deadlines.

Set up the breach log before you need it. The 72-hour clock does not wait for a process to be written.

#### What should be ready by May 2027?

Evidence for each duty, ready to hand over: the notice versions and snapshots, the consent records and their integrity check, the closed withdrawal tasks with confirmations, the retention log with deletions confirmed, the rights requests with reply dates, and the breach log even if it is empty.

The readiness check on this site walks the twelve questions the Board would ask. Take it now and again a quarter before the deadline.

### Stop processing vs erase: two duties teams keep confusing

"Stop using it" and "delete it" are different duties under the DPDP Act, with different triggers, deadlines and exceptions. Mixing them up erases data the law says you must keep.

Published 2026-09-18. https://promiz.in/blog/stop-processing-vs-erase/

#### What does “stop processing” mean?

Section 6(6) requires a Data Fiduciary to cease processing personal data within a reasonable time once consent is withdrawn, unless processing is required by law. The trigger is the withdrawal; the duty is to stop using the data for that purpose and to make your processors stop too.

Stopping does not mean deleting. A borrower who withdraws marketing consent still has a loan, and the loan file still has to exist.

#### What does “erase” mean?

Section 8(7) and Rule 8 require erasure once the purpose is served, or once consent is withdrawn and no legal obligation requires retention. The trigger is the end of the purpose or the end of a retention period; the duty is to delete, and to have processors delete, with a notice before the erasure happens.

Erasure is the irreversible one. That is why it needs a countdown, a warning and a confirmation - not a nightly script.

#### Where do the two collide?

Legal-obligation purposes. RBI record-keeping, IRDAI claims history, tax records: a withdrawal on these must stop non-essential use and must not trigger deletion. A dispute or an investigation adds a legal hold on top, freezing any erasure clock until it is lifted.

A tool that treats every withdrawal as a delete request will erase data the law says you must keep. A tool that never erases will fail Section 8(7). The queues have to be separate.

#### What does a correct setup look like?

Two queues. A withdrawal opens a stop-processing task with a confirmation deadline, delivered to every connected system. A purpose ending opens an erasure task with a 48-hour notice, a legal-hold check, and closure only when your system confirms the deletion. Legal-obligation purposes are marked as such at setup, so a withdrawal on them stops use and nothing more.

Both tasks write to the same record as the original consent, so the whole story - given, withdrawn, stopped, erased - sits in one chain.

### The five duties after the banner: where DPDP compliance actually fails

Collecting consent is the step every tool covers. The DPDP Act adds four more - prove it, act on withdrawals, erase on time, answer requests - and that is where the risk sits.

Published 2026-09-18. https://promiz.in/research/five-duties-after-the-banner/

#### Why is collecting consent the easy part?

A cookie banner or a consent checkbox is a one-time interaction. The DPDP Act treats it as the start of a relationship: the Data Fiduciary must be able to show what was agreed, stop when the person changes their mind, delete when the purpose ends, and answer the person when they ask. Section 6 covers the consent; Sections 6(4), 6(6), 8(7) and 11–14 cover what happens afterwards.

Most consent tools stop at the banner. They record a click and hand the rest to spreadsheets and email. The four duties that follow are the ones the Data Protection Board will ask about, because they are the ones that leave a trail - or fail to.

#### What does "prove it" require?

Section 5 and Rule 3 require an itemised notice before processing; Section 6 requires free, specific consent per purpose. Proving either later means keeping the notice version, the language it was shown in, the exact choices made and when. A record that can be edited afterwards proves nothing, which is why a chained, append-only record matters more than a nicely designed banner.

The practical test: for any consent given last year, can you produce the screen the person saw, in the language they saw it, with the version number? If the answer involves a developer and a database query, the proof does not yet exist.

#### Why do withdrawals fail silently?

Section 6(4) makes withdrawal as easy as consent; Section 6(6) requires processing to stop once it is withdrawn. The failure is rarely the withdrawal button. It is the CRM, the ad platform and the collections partner that never hear about it. Each keeps processing because nobody told it to stop, and nobody can show that anyone confirmed.

The control is a stop-processing task with a deadline, opened per withdrawal, delivered to every downstream system as a signed event, and closed only when that system confirms. An unconfirmed task is a visible overdue item, not an unread email.

#### Why is erasure a clock, not a policy?

Section 8(7) and Rule 8 require personal data to be erased once its purpose is served. A retention policy in a PDF states an intention; it does not count down, and it cannot show when deletion happened. Some purposes - RBI record-keeping, a live dispute - must not be erased on schedule, so the clock also needs legal holds.

The record that satisfies the Board is per-purpose: a retention period, a notice sent before erasure, a hold where the law requires one, and a confirmation from the system that actually deleted the data.

#### What do rights requests need?

Sections 11–14 and Rule 14 give the Data Principal access, correction, erasure, grievance and nomination. Each request needs a published route in, a deadline, a reply and a log. A shared inbox provides the route and nothing else.

One queue with a clock on every request, reminders before it is due, and a logged reply to the person is the minimum that survives an audit. It is also the part that customers notice first.

### DPDP penalties, mapped to the control that prevents each one

The Schedule to the DPDP Act sets penalties up to ₹250 crore. Each band points at a specific duty, and each duty has a specific control. A working map from fine to fix.

Published 2026-09-18. https://promiz.in/research/penalties-mapped-to-controls/

#### What are the penalty bands?

The Schedule to the DPDP Act, 2023 sets maximum penalties by breach type: up to ₹250 crore for failing to take reasonable security safeguards (Section 8(5)); up to ₹200 crore for failing to notify a personal data breach (Section 8(6)) and for breaching the duties around children's data (Section 9); and up to ₹50 crore for most other obligations, including notice, consent, withdrawal, erasure and rights requests.

The Board decides the amount within those ceilings, and the Act lists factors such as the nature and duration of the breach and the steps taken to mitigate it. Being able to show the control existed, and ran, is part of that mitigation.

#### Which control answers the ₹250 crore band?

Security safeguards under Section 8(5) and Rule 6 cover encryption, masking or tokenisation, access control, and logs of who accessed personal data kept for at least one year. For consent data specifically, the control is encryption at rest, one-way identifiers, masked display with logged reveals, and a tamper-evident audit trail of every administrative action.

Your own systems still need their own safeguards. A consent platform reduces the surface area - it does not cover the CRM or the data warehouse.

#### Which controls answer the ₹200 crore band?

Breach notification (Section 8(6), Rule 7) requires telling the Board and affected people without delay, and sending a detailed report within 72 hours. The control is a breach log that starts the clock the moment a breach is recorded, tracks each notice, and assembles the structured report from what was logged.

Children's data (Section 9, Rule 10) requires verifiable consent from a parent or guardian and bars tracking and targeted advertising. The control is a guardian check through DigiLocker recorded on the consent, with child-restriction flags applied per purpose and the Fourth Schedule exemptions (Rule 12) recorded for the organisation.

#### Which controls answer the ₹50 crore band?

Everything else: an itemised notice in a language the person reads (Section 5, Rule 3); free, specific consent per purpose (Section 6); withdrawal as easy as consent and processing that stops afterwards (Sections 6(4) and 6(6)); erasure when the purpose ends (Section 8(7), Rule 8); and the five rights with their deadlines (Sections 11–14, Rule 14).

These are the duties most likely to be tested first, because they are visible to every customer. The controls are versioned notices with snapshots, one choice per purpose, stop-processing tasks, retention clocks with confirmed deletion, and a rights queue with a clock on each request.

## Contact

- Book a demo: https://promiz.in/demo/
- Email: promiz@pentafox.in
- Phone: +91 90037 91579
- Company: Pentafox Technologies - https://pentafox.in/