One master switch cannot express different preferences by purpose

What it is

Purpose-specific consent binds authorization states to distinguishable data purposes instead of representing an account as “privacy consent on/off.” A person can permit processing necessary for a requested service while declining advertising, cross-service profiling, or model training. Granularity is not just more switches; the backend must separately store basis, version, scope, and withdrawal state.

Why it happens

A master switch compresses multidimensional intention into one bit, obscuring what acceptance covers and allowing new purposes to inherit old authorization. Purpose-level state links a choice to executable work: rejecting or withdrawing one purpose blocks only its jobs while independent functions continue. If processing still reads an account-wide boolean, detailed interface controls are a representation the system cannot honor.

Studying it

Card sorting, interviews, or discrete-choice tasks can identify purposes people understand as joint or separable, followed by tests of expression accuracy, stability, and configuration error. System audits should run accounts with different purpose combinations through real queries and jobs. Option count is not the only variable; distinguishability, consequence explanations, and functional dependencies shape whether choices remain coherent.

Where it stops holding

Purpose should not fragment down to every database access, which exposes implementation rather than a meaningful decision. Inseparable steps delivering one explicit request may form a functional unit, but marketing, public display, or third-party reuse does not become necessary merely because it shares a field. Applicable processing basis also matters: not every operation should be disguised as a consent option.

Applying it

• Map purpose, data, processing job, recipient, and authorization version, giving each optional purpose its own state.
• Name purposes by outcomes people can foresee and specify exactly which function a refusal changes.
• Enforce authorization at job execution rather than saving a display-only settings value.
• Test every relevant allow/decline combination against traffic, queues, and outputs; a disabled purpose that runs, or an unrelated function that fails, exposes false granularity.

Related

• Same group: O1.10.2 Withdrawal should be no harder than giving consent · O1.10.3 Withdrawal cannot necessarily reverse prior processing outcomes · O1.10.4 Granularity adds interface complexity that needs careful presentation
• Adjacent: O1.05 The usability dilemma of informed consent · O1.03 Purpose limitation
• Search terms: purpose-specific consent · consent state model · granular consent