For years, digital consent has been represented by one of the smallest elements on a screen: a checkbox.
I agree.
That interaction made sense when consent was treated primarily as a moment of collection. A user saw a notice, selected an option, and the organisation recorded the response.
But modern data processing does not end at the point of collection. Data moves across systems, departments, vendors, analytics environments and increasingly AI workflows. A single decision made at 10:32 a.m. can influence processing activity for months or years afterwards.
The real object being managed is therefore not the checkbox. It is the relationship between an individual, a piece of data, a purpose, and the processing activities that follow.
Consent has four dimensions
A useful way to think about consent is as a relationship with at least four connected dimensions.
Who gave the permission? The organisation must be able to associate the decision with the right Data Principal.
What data does the permission cover? A consent decision should not become an unlimited authorisation for every piece of information the organisation holds.
Why is the data being used? Purpose is the boundary that gives consent meaning.
For which processing activity does that permission apply? Marketing, identity verification, service delivery, profiling and analytics may involve the same person and the same data while representing very different uses.
When these dimensions are separated, organisations often end up with a binary record that says only "consent = yes". That record is easy to store but weak as governance evidence because it does not explain what the individual actually agreed to.
The DPDP framework makes purpose central
India's Digital Personal Data Protection Act, 2023 establishes consent as one basis for processing personal data and requires consent to be free, specific, informed, unconditional and unambiguous, with clear affirmative action. The Act also states that withdrawal should be possible with ease comparable to giving consent.
The Digital Personal Data Protection Rules, 2025 deepen the operational significance of that principle. Rule 3 requires the notice to provide an itemised description of the personal data and the specified purpose of processing, along with a means for the individual to withdraw consent and exercise rights.
This means consent cannot be separated from purpose. The permission is meaningful only when the organisation can connect the individual's decision to the specific use that was communicated.
A checkbox does not travel with the data
Suppose a customer agrees to receive a service update using her mobile number. That number enters the CRM. The CRM synchronises with an ERP. A communication platform receives the number. An analytics team later copies customer data into another environment.
The consent event happened once. The data movement happened many times.
If the organisation stores consent only inside the original web form, the downstream systems may know the phone number but not the conditions attached to its use. This creates a disconnect between the data and the permission governing it.
A mature privacy architecture should therefore allow relevant consent context to remain linked to the data as it moves across the organisation.
The relationship changes over time
Consent is not static. A person may withdraw one permission while retaining another. A purpose may expire. A new purpose may require a fresh decision. A notice may be updated. A new system may begin consuming the data.
This makes consent closer to a living data relationship than a one-time transaction.
The organisation needs to know the current state of that relationship, its history, and what changed when.
The useful unit is not "customer" — it is customer x purpose
Enterprises often organise privacy records at customer level. But one customer can have several independent relationships with the same organisation.
A customer may permit service notifications, decline promotional communication, provide information for identity verification, and later agree to participate in a research programme.
Treating all of this as one master consent record destroys important context. A better model considers each combination of person, purpose and relevant data as a separate governance relationship.
What iConsent is designed to manage
This is the principle behind iConsent: consent should not sit as an isolated yes-or-no record. It should be connected to the notice, purpose, personal data, system activity, version history and subsequent lifecycle events.
That allows an organisation to move from asking "Did this user click agree?" to asking more useful questions:
What exactly did the individual agree to? Which data was involved? Which purpose does the decision cover? Where is that data being processed? Is the permission still active? What changed after a withdrawal?
Consent is not the click. The click is only the beginning of the relationship.
As privacy programmes mature, that distinction will become critical. The strongest consent systems will not simply capture decisions. They will preserve the context that makes those decisions meaningful.
