Chapter 9 — Notice and Consent Experience Design

Under DPDP, consent is not a UI element — it is a purpose-scoped, evidenced grant that a Data Principal can give, manage, review and withdraw (Section 6; the Section 2(g) Consent Manager frame of Chapter 11). The legal requirements are strict and cumulative (Section 6(1)):

The primary text requires free, specific, informed, unconditional and unambiguous consent, with a clear affirmative action, agreement for the specified purpose, and limitation to the personal data necessary for that purpose (ACT:206–209).[1]

The following design checks operationalise those requirements. They are not seven separately prescribed tests or a claim that a stored receipt proves each quality:

Free — assess pressure and unwanted bundling; do not claim that the Act contains an illustration about exclusion from an essential service. Its actual illustrations here address unnecessary phone contacts and an invalid complaint waiver (ACT:210–224).[1]
Specific — tied to a stated purpose, not “our business purposes generally.”
Informed — accompanied or preceded by a notice that meets Section 5 and Rule 3 (below).
Unconditional — not “we will provide the service only if you also let us market,” where the second grant is not necessary for the first.
Unambiguous — the affirmative action must leave no interpretive doubt; silence, pre-ticked boxes, and “continue to agree” patterns all fail.
Clear affirmative action — an act, not an omission: the toggle flipped, the box ticked, the “agree” pressed. Scroll-past and session-continuance are not actions.
Limited to necessary data — the telemedicine illustration (§2.3) makes this an element-level constraint, not a policy sentiment.

The idea worth building the chapter around follows directly: notice and consent are not a legal formality to be passed; they are a versioned evidence chain — a reconstructible record linking the notice version, the itemised data, the specific purpose, and the affirmative action — which the organisation must be able to reproduce when a principal exercises rights (Ch.4/12) or withdraws (Ch.10). This reframing is why the engineering evidence matters here: the artefact links a user action to a later processing decision. It cannot by itself establish comprehension, voluntariness or the identity of whoever controlled a compromised session.

2. The statutory requirements, precisely

A request for consent under Section 6 must be accompanied or preceded by a notice that informs the principal of (Section 5(1)):

(i) the personal data and the purpose for which it is proposed to be processed;
(ii) the manner of exercising her rights (Section 6(4) withdrawal; Section 13 grievance); and
(iii) the manner of complaining to the Board.

The notice must be presented so it is understandable independently of any other information (Rule 3(a)) — the anti-buried-leverage clause: the principal must be able to understand what she is agreeing to without reading the terms of service, the contract, or any other document — and must give, in clear and plain language, a fair account of the details needed for specific and informed consent, including at minimum an itemised description of the personal data and the specified purpose or purposes, including the specific description of goods/services to be provided or uses enabled. Rule 3(c) additionally requires the particular website/app communication link and other means, if any, for withdrawal, rights and Board complaint (RULES:1020–1037).[3] “Your data for our business” supplies neither itemisation nor an intelligible use.

Legacy consent. Where consent was given before commencement, Section 5(2) requires notice as soon as reasonably practicable and allows processing to continue until and unless consent is withdrawn. It does not prescribe a fixed refresh period or automatically expire the consent after a year (ACT:182–205).[1] An author-recommended campaign records which legacy purpose was authorised, the notice version, delivery attempts and the withdrawal route. A returned email is a delivery problem to address, not a fabricated statutory expiry. Prepare cessation capability in parallel with the campaign; neither batch completion nor an old database flag proves valid original consent.

Must be free, specific, informed, unconditional, unambiguous, by clear affirmative action, for the specified purpose, and limited to necessary data (Section 6(1)).
Any part of consent that constitutes an infringement of law is invalid to that extent (Section 6(2)) — the Act’s insurance illustration: a consent clause that waives the right to complain to the Board is void as to that clause, and the design must be able to sever it without losing the rest. Consent artefacts therefore need clause-level validity, not document-level.
Sections 5(3) and 6(3) give the principal the option to access the notice/request in English or any language specified in the Constitution’s Eighth Schedule; Section 6(3) also requires the DPO, where applicable, or authorised-person contact (ACT:203–205,225–231).[1] A business-selected Hindi-plus-regions rollout does not itself establish that this statutory option is available.
Withdrawal has comparable ease, not a literal same-screen or identical-step mandate (ACT:232–249).[1] Steps, channel reachability, waiting and accessibility are useful design measurements; matching tap counts alone proves little.

2.3 The necessity anchor

The telemedicine illustration in the Act is decisive for design: where X consents to (i) telemedicine services and (ii) accessing her phone contact list, but the contact list is not necessary for the telemedicine service, the consent is limited to the necessary data (Section 6(1)). The practical consequence: every data element in a consent flow must map to a stated purpose it is actually necessary for — pulling the Chapter 8 necessity attribute into the consent UI. The design implication is mechanical, not aspirational: the consent screen’s data-item list should be generated from the purpose matrix, so the interface cannot ask for an element the matrix does not justify. Hand-written consent screens can drift; generated ones still require semantic review of their source matrix (ACT:206–215).[1]

3. Tension: granularity that satisfies the statute vs simplicity a user will accept

Here is the tension the design must hold: DPDP demands granular, purpose-bounded, itemised consent (Section 6(1); Rule 3), which pushes toward many separate consent decisions; but users have bounded attention, and an over-granular 40-consent gating flow degrades comprehension — which then undermines the very “specific and informed” quality the law is trying to protect. The statute is not unaware of this: Rule 3’s “fair account” and “understandable independently” requirements are comprehension tests, so a consent design that technically itemises but practically overwhelms fails the very rule it cites.

The failure modes:

The everything checkbox (fails specificity): one “I accept” covering all purposes and all data. It is not “specific” and exceeds the necessary-data scope — so the consent is legally questionable and fails the necessity anchor. This is a design risk to assess against the actual DPDP consent scope, not a claim about comparative litigation outcomes.
The consent wall (fails comprehensibility): so many granular gates that the principal can no longer meaningfully give “informed” consent — the interface crowds out the information it is meant to convey. Do not assume that adding more dialogs improves comprehension; test the actual journey.
The dark middle (fails both silently): the pattern that looks granular but is not — purposes named separately but all required to proceed; withdrawal reachable only through a support ticket. Each dark pattern converts a compliant-looking flow into an evidentiary exhibit.

The reconciliation is not “fewer gates.” It is good information architecture: group purposes into transparent, necessary-data-scoped decisions; make each decision’s purpose

data legible at the point of choice; and make withdrawal the mirror. This is a design-and-test problem, and that is why the chapter’s deliverable is a set of consent journey tests (§6), not just a copy template — the tests are what stop the dark middle from shipping.

4.1 The evidence chain (what must be reconstructible)

For each consent the organisation must be able to reproduce, on demand:

notice version (s.5/r.3) → consent request (data items + purpose, s.6(1))
  → affirmative action → link to the principal's record

The fiduciary’s Section 6(10) proceeding-specific proof burden covers notice and valid consent (ACT:264–268).[1] Store controlled evidence references and hashes, not unnecessary copies of the personal payload. Retention of the evidence itself needs its scoped rule and purpose, including applicable Rule 6/Rule 8 and other-law obligations; “audit trail” is not a licence to retain everything indefinitely (RULES:1101–1106,1153–1166).[3] Query by subject, purpose and grant, without merging a representative’s identity into the data subject.

4.2 Versioning

Versioning is the recommended mechanism for preserving what was presented. Distinguish a spelling/accessibility repair that leaves purpose, items and scope unchanged from adding a new purpose or data category. Neither a new version number nor a refreshed notice grants authority. For a material expansion beyond existing consent, block that expansion until valid new authority exists; review genuinely applicable Section 7 routes on their own facts rather than describing every text edit as mandatory re-consent.

In the synthetic release below, NOTICE-001 v1.1 corrects formatting without enlarging scope; its old grants remain tied to the v1 content they actually saw. Proposed v2 adds PUR-003 model training. DEC-001 keeps that release’s training path stopped because no grant exists. A release manifest therefore maps changed purpose/items and proposed migration, not just a new document checksum.

Beyond being a record, the consent state should be an enforceable attribute on the data: an entitlement that gates access/use to the consented purpose (Ch.8 runtime enforcement). When consent is withdrawn, the attribute flips and the runtime stops processing for that purpose (Ch.10). This is where the consent record stops being documentation and becomes a control — and it is the design choice that makes the rest of the book’s machinery (purpose-block, propagation, drift detection) possible at all. A consent platform that only writes records for legal review is a filing cabinet; the attribute-backed one is a policy engine.

5. Design principles (grounded + UX)

Clarity over completion: meet the Rule 3 itemised-data + specific-purpose bar in plain language; do not bury it in a terms document.
Granularity with legibility: separate purposes and necessary data so consent is specific, but present the grouping so the user grasps each purpose. The grouping decision is an information-architecture artefact, reviewable like any other design.
Necessity check: include only data necessary for the stated purpose (the telemedicine illustration) — generated from the Chapter 8 matrix, not hand-written.
Language option: preserve the statutory English/Eighth Schedule option; a language rollout decision is implementation evidence, not an exemption.
Comparable ease: build withdrawal alongside giving consent. Matching navigation depth is one recommended heuristic; evaluate actual effort, waiting, channel access and comprehensibility rather than prescribing identical screens as law.
Accessible channels: test the channels the service actually offers, including assisted paths. Cross-channel failure should remain a launch defect, not vanish in an aggregate pass.

The statutory anchors are Section 5, Section 6 and Rule 3; generated screens, grouping choices, equal-step heuristics and release gates are author recommendations. No UX study has been conducted for this book.

The following are proposed product acceptance specifications, not already-executed journeys:

Test	What it verifies	Pass criterion
Positive	a principal completes notice + granular consent	consent record + proof reconstructible (notice v + items + purpose + affirmative action)
Negative	consent attempted for data not necessary	not permitted (Section 6(1) necessity) — the screen cannot request it
Language	requested English/Eighth Schedule option actually works	missing requested language fails launch; a recorded limited rollout is insufficient
Withdrawal	comparable ease in practice	no added wait/support barrier; evaluate path effort, not identical-screen dogma
Legacy	pre-commencement consent receives Section 5(2) notice	notice served; processing continues only until withdrawal
Multichannel	web, mobile, agent, multilingual	journey works everywhere, per channel
Forged/reuse	new use without applicable authority	denied, including PUR-003 with only a PUR-001 grant
Severance	infringement invalid to its extent under Section 6(2)	valid scope is separately assessed, not automatically erased or expanded
Version	change classified as material or nonmaterial	expansion cannot use old grant; cosmetic revision retains original evidence chain

The local checks test the specimen’s structure and decision branches. The companion HTML journey supplies English/Hindi selection and a visibly blocked missing-language branch, separate optional choice and withdrawal; browser results are in out/remediation/Q03/notice-browser-results.json. Translation accuracy, assistive technology, real identity assurance and user comprehension remain unverified.

7. Worked designs (illustrative)

NOTICE-001 v1 — a complete synthetic screen-copy specimen

This is an author-written English notice and separate optional choice for CASE-001/ENT-001, not a deployed page or legal certification. The paths use the reserved .invalid domain so no reader mistakes them for a live Company or Board portal. Product owns the copy; DPO reviews scope; production release remains blocked until contact details, translations and official complaint information are verified.

The Company: your loan application and optional messages

We use your name, contact address and phone, the loan amount and term you request, income and repayment information you provide, and identity-document type, verification reference and verification result to assess and handle your requested loan application. This enables application assessment and communication about that application (PUR-001). This specimen does not collect a document image, document number or phone contact list. A real application needing additional verification data requires an itemised revised notice and separate necessity/legal review.

Separately, if you choose optional messages (PUR-002), we use your chosen contact channel, adult-customer eligibility flag and marketing preference to send information about the Company’s offers. We do not use your transaction history or consultation/health category for this optional choice. Declining it does not prevent you submitting the requested application. Neither choice authorises model training (PUR-003) or an insurance referral (PUR-010).

Choose English or any Eighth Schedule language at https://company.invalid/privacy/language. The English copy below and companion Hindi notice are teaching specimens only; other translations are not delivered, so the full language-option acceptance gate is not passed.

Review or withdraw each consent at https://company.invalid/privacy/choices; use the same page for a withdrawal request without calling support. Withdrawal stops the relevant consent-based use subject to legally required or authorised processing. Data that must be retained is restricted; withdrawal does not promise immediate destruction of every record. Withdrawal of application consent may affect the requested service; optional-message withdrawal does not withdraw application consent.

Request access, correction, erasure or nomination at https://company.invalid/privacy/rights. Submit a grievance at https://company.invalid/privacy/grievances; this illustrative service publishes a 30-calendar-day grievance response period, not a statutory deadline for every right. After exhausting the grievance opportunity, the Board complaint instructions are at https://company.invalid/privacy/board-complaint. That instruction page must be populated from the verified official channel before launch, not from a guessed regulator URL.

Processing and rights contact: Company Privacy Office, privacy@company.invalid, through https://company.invalid/privacy/contact. This is the authorised-person contact specimen, not an assertion that the Company is designated SDF or has a statutory DPO appointment.

[ ] I agree to processing the listed application data for my requested loan application. Submit application / Do not submit.

Optional, initially off: [ ] Send me Company offers using my chosen channel and preference. Save optional choice / Continue without optional messages.

Hindi illustrative choice labels (full companion notice: out/remediation/Q03/NOTICE-001-v1-hi.md): “वैकल्पिक संदेश स्वीकार करें” / “वैकल्पिक संदेशों के बिना आगे बढ़ें”. Withdrawal label: “वैकल्पिक संदेशों की सहमति वापस लें”. Translation accuracy and accessibility require human review; neither these labels nor the two-language companion establishes the complete statutory language option.

The mapping is explicit: the first two paragraphs supply Rule 3(b)‘s data, purpose and goods/services/use description; the separate display supports Rule 3(a); the particular choices/rights/complaint paths and other contact means implement Rule 3(c). Sections 5 and 6 supply the notice timing, language, contact and consent-quality anchors (ACT:167–231; RULES:1020–1037).[1][3] Entity-specific identity requirements, invalid endpoints and undelivered translations remain named production review items. A useful completed teaching specimen can expose those release failures instead of pretending to be deployable copy.

Receipt, failed expansion and conditional Section 7(a) counterexample

At EVT-003 (1 June 2027, 09:00 +05:30), the synthetic SUB-001 chooses both separate options. The populated receipts in out/remediation/Q03/consent-events.json record CONSENT-001/PUR-001 and CONSENT-002/PUR-002, subject SUB-001, actor SUB-001, notice NOTICE-001 v1, language English, displayed item list, distinct affirmative actions, timestamp, source SYS-001 and integrity/provenance fields. Stored notice and receipt hashes are calculated from actual local specimen bytes. They prove those bytes are linked, not that a real customer clicked or understood them.

At WITHDRAW-001 the marketing receipt becomes withdrawn; the lending receipt is not overwritten. A stale old grant arriving at EVT-007 must not reverse the newer withdrawal. A proposed NOTICE-001 v2 training expansion remains rejected by DEC-001. The specimen language gate also fails when a requested Eighth Schedule translation is missing; that failure is retained in the pack rather than counted as a completed multilingual journey.

A separate retail counterfactual, CASE-101, may use Section 7(a) only where the principal voluntarily supplies her own data for the specified requested transaction and has not indicated non-consent. Fulfilment is not unconditionally exempt from consent just because it appears in a notice; imported contact data or an objection defeats the assumed Section 7(a) facts (ACT:271–284).[1] The Company’s base loan application remains consent-based PUR-001, not relabelled retail fulfilment. In a telemedicine counterexample, unnecessary contact-list access fails the Act’s own illustration; ordinary treatment is not automatically a medical-emergency ground, and sensitive consultation categories are not silently reused for marketing (ACT:210–215,316–320).[1]

8. Residuals requiring counsel / verification

Validate the listed fields against the actual application and replace reserved endpoints with reviewed contact and verified complaint instructions before production use.
Provide and test the statutory language option, translations, assistive technology and assisted-channel handling; the English/Hindi specimens do not close the full statutory language-option or human translation-review work.
Verify any later Board/sector guidance and the actual CM onboarding boundary without treating this bounded source search as proof of absence.
Determine actual legacy-consent evidence and delivery scope; maintain withdrawal readiness and visible failed delivery. No fixed legacy refresh expiry is invented.

Question for the next chapter

If consent is a versioned, purpose-scoped, evidenced grant that the runtime enforces, then the natural next question is: what happens when the principal reverses that grant? Withdrawal is not the inverse of consent as a UI event — it is the start of a cessation and erasure state machine that must propagate across the estate and its processors. That is the subject of Chapter 10 — Consent Withdrawal and Downstream Cessation.

Evidence and reusable artifacts

The primary-text line keys ACT, COMM, RULES and CORR resolve to the retained files below. Line numbers count physical newlines, not PDF form feeds. The canonical provision register supplies actor, trigger, conditions, exceptions and effective dates; chapter recommendations and synthetic examples are not statutory forms. The Q03 source manifest preserves URL, retained retrieval metadata and recalculated hashes.

Completed chapter fragments, before/after evidence and actual local checks: out/remediation/Q03/. Blank operating templates remain under research/operations/templates/; The reconciled integrated dossier is the reader working copy; these chapter fragments preserve the earlier bounded examples and their run evidence.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — ACT [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — COMM [3] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — RULES [4] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — CORR

Contents · Reader guide and citation conventions · Artifact index