What Consent Collection Means
PracticeConsent collection is the specific moment and interface where a Data Principal is asked for consent — a signup form, a cookie banner, an in-app permission prompt, a call-centre script. It's not a separate legal requirement from Section 6's consent standard (covered in the parent Consent Management chapter); it's the practical design problem of making that standard actually hold up at the one moment it's tested.
Why It Matters More Than It Looks
Everything downstream — the record you store, the withdrawal flow, the audit trail you'd show a regulator — inherits whatever happened at collection. If the consent captured wasn't actually valid (bundled, pre-ticked, or unclear about purpose), no amount of good record-keeping afterward fixes that. This is the single highest-leverage place to get right, and also the place most likely to be quietly undermined by ordinary conversion-rate optimisation instincts that push toward fewer clicks and less friction than the standard actually allows for.
How a Compliant Flow Works
- Notice first, or alongside — the plain-language explanation of what's collected and why appears at or before the point of consent, not just linked from a footer.
- One control per purpose — if you collect an email for order updates and also want to use it for a newsletter, that's two consents, not one.
- Unticked by default — every optional consent starts unchecked; the Data Principal has to actively check it.
- A real choice to say no — "reject" or "skip" should be at least as visible and as easy to select as "accept."
- Timed to actual processing — don't collect consent for a purpose you might use "someday"; ask again when that purpose is real.
A signup form collects name and email for account creation (no consent needed beyond the notice, since this is necessary for the service requested). Below that, two separate, unticked checkboxes: "Send me product updates by email" and "Share my usage data with analytics partners," each with a one-line plain-language explanation. A visible, equally-styled "Continue without marketing" option sits next to "Continue."
A prominent, brightly coloured "Accept All" button paired with a small, grey-text "Manage preferences" link that takes three more clicks to actually decline anything. This is a well-documented consent dark pattern, and it undermines the "free" and "affirmative action" requirements even though a technically compliant-looking checkbox exists somewhere in the flow.
Language and Accessibility
LawSection 5 permits notices in English or any language listed in the Eighth Schedule to the Constitution. For a genuinely national audience, offering the notice and consent flow in the visitor's selected language — not just English — is closer to what "clear and plain language" is meant to achieve, even though the Act doesn't mandate every language be offered simultaneously.
Practical Implementation Checklist
- Notice text is shown at or immediately before the consent request, not just linked separately.
- Each purpose has its own, individually unticked control.
- Non-essential cookies/scripts are blocked from firing until consent is given, not fired first and reconciled after.
- Declining is at least as visually prominent as accepting.
- The exact notice text and purpose shown is stored alongside the consent record (see the parent chapter's "Consent Records" section) — not just a true/false flag.