A customer is one person.
But the organisation may have ten different reasons for using that person's data.
Account creation. Identity verification. Service delivery. Billing. Fraud monitoring. Product recommendations. Research. Marketing. Loyalty programmes. Partner offers.
When all of those activities are compressed into a single "I agree" decision, consent becomes simple for the system — but ambiguous for the individual.
One person does not mean one purpose. And one consent should not automatically mean permission for everything.
Why organisations prefer bundled consent
Bundled consent is operationally attractive. One checkbox creates one record, one status and one implementation path.
Granular consent introduces complexity. Different purposes may have different states. Some are active, some declined, some withdrawn, and some may not require consent at all because another lawful ground applies.
But that complexity already exists in the real world. Bundling does not remove it. It merely hides it.
Granularity starts with purpose architecture
Before an organisation can offer meaningful choices, it must define its purposes at the right level.
Too broad, and the choice becomes meaningless. Too narrow, and the user is confronted with dozens of micro-decisions that create fatigue.
The challenge is to identify purposes that represent genuinely distinct uses of personal data and materially different expectations for the individual.
For example, "communicate with customer" may be too broad if it combines mandatory service alerts with optional promotional messages. But creating separate purposes for every individual campaign may be unnecessarily narrow.
Consent should be specific to what the individual can reasonably understand
The DPDP Act describes consent as free, specific, informed, unconditional and unambiguous, with a clear affirmative action. It also limits consent to personal data necessary for the specified purpose.
That idea is important: specificity is not only about the wording of a checkbox. It is about the relationship between the data requested and the purpose presented.
If five purposes are materially different, collapsing them into one decision makes it difficult to demonstrate which use the individual actually intended to permit.
The consent matrix
A useful enterprise model is to stop thinking of consent as a single field on the customer record and instead think of it as a matrix.
Across one axis is the individual. Across another are purposes. Each intersection can have its own state: not requested, active, declined, withdrawn, expired or superseded.
The organisation can then associate relevant data categories, notice versions, channels and timestamps with each purpose-level relationship.
This model is more complex than one master flag. It is also much closer to how permission actually works.
Granularity protects the customer relationship
Consider a customer who no longer wants promotional messages but still needs transaction alerts.
If the organisation uses a single master consent flag, withdrawal may either stop too much or too little. The customer may continue receiving marketing because service consent remains active, or the organisation may mistakenly suppress essential service communication because the customer opted out of promotions.
Purpose-level consent avoids this collision.
Granularity also improves business intelligence
There is a tendency to see granular consent only as a compliance burden. It can also produce better information about customer preference.
An organisation can distinguish between people who want personalised recommendations, people who accept research participation, people who prefer only operational communication, and people who have changed their preferences over time.
That is more useful than a database in which everyone is simply marked "consented".
But more choices are not automatically better
Granularity should not become interface overload.
Ten purposes presented as ten dense legal checkboxes on one screen may technically create separation while producing poor understanding.
Good consent design needs hierarchy and timing. Some choices should be presented at the point of relevance. Some may belong in a preference centre. Some processing should be explained without asking for consent where consent is not the applicable basis.
The goal is not maximum number of toggles. The goal is meaningful control.
The system architecture must support the user experience
A beautiful preference centre is useless if downstream systems still rely on one master marketing flag.
Granular consent needs technical propagation. When one purpose is withdrawn, the organisation must identify which workflows, applications or processors are affected without disrupting unrelated uses.
This is where consent becomes an enterprise architecture problem rather than a front-end design problem.
The iConsent approach
iConsent is designed around purpose-level governance. The platform can associate notices, data categories and decisions with defined purposes, maintain the state of those relationships, and support changes across the lifecycle.
Granular consent is not about asking people more questions. It is about making each answer mean something.
As organisations mature, the most useful consent record will not be "yes" or "no". It will be a clear, current map of what this individual has permitted, for which purpose, under which notice, and with which data.
