Capturing consent is easy to demonstrate.
Put a notice on the screen. Add a control. Record the response. Store the timestamp.
That is why many privacy implementations focus heavily on the moment consent is given.
But the difficult work begins after the click.
Consent is an event. Consent management is a lifecycle.
Stage 1: before consent — define what is actually being asked
A valid consent journey begins before the interface is designed.
The organisation needs to identify the purpose, determine the personal data necessary for that purpose, decide whether consent is the appropriate basis, draft the notice, establish the systems involved and define what will happen if the individual refuses or later withdraws.
If these questions are unresolved, the checkbox only digitises ambiguity.
Stage 2: at consent — capture context, not only status
At the moment of consent, organisations often record a boolean value and timestamp.
A richer record should preserve enough context to reconstruct the decision later: the individual, purpose, relevant data categories, notice version, channel, timestamp, language where relevant, and the exact state of the decision.
Why? Because six months later the organisation may need to answer not just whether consent existed, but what the person was told when it was given.
Stage 3: after consent — make the permission operational
Once consent is active, the organisation has to ensure that processing follows the boundaries that were communicated.
This is where the privacy system needs to connect with operational systems. If a purpose is active, relevant processing can proceed. If a purpose is declined, the affected workflows should know. If consent is limited to one purpose, another team should not treat the same data as universally available.
The consent state has to become usable by the systems that actually process the information.
Stage 4: change — consent does not remain frozen
People change their preferences. Organisations change their services. Purposes evolve. Notices are updated. New processors are added. Applications are replaced.
Every one of these changes can affect the consent relationship.
The system should therefore preserve history rather than overwriting the previous state. A current "withdrawn" status does not explain that consent was active for eight months before withdrawal. An audit trail should.
Stage 5: withdrawal — the real test of the architecture
The DPDP Act gives Data Principals the right to withdraw consent with ease comparable to the way it was given. The 2025 Rules require the notice to provide a communication link or other means through which withdrawal can be exercised.
From an interface perspective, withdrawal can be one button.
From an enterprise perspective, it is an orchestration event.
The system must identify which purposes are affected, determine which processing based on that consent should stop, propagate the change to relevant systems or processors, preserve activity required for legitimate continuing obligations, and record evidence that the change was actioned.
A withdrawal workflow therefore tests whether the organisation has truly connected privacy with its technology stack.
Stage 6: retention and deletion — consent withdrawal is not always equivalent to deleting everything
One of the most common conceptual errors is to treat withdrawal as automatic destruction of every record relating to the person.
In practice, an organisation may have other legal or operational reasons to retain certain information. What changes is the authority for particular processing activities.
This is why systems need to distinguish purpose, basis, retention obligation and data state rather than applying one blanket action to the whole customer record.
Stage 7: evidence — could you reconstruct the lifecycle?
Imagine an auditor asks: What did this customer agree to on 4 February? Which notice did she see? When did the purpose change? When did she withdraw? Which systems received the withdrawal? What processing continued afterwards and why?
If answering those questions requires manually searching email chains, logs and spreadsheets, the organisation has records but not a lifecycle.
A mature consent-management platform should make the lifecycle reconstructable.
The lifecycle is where scale becomes difficult
At one hundred customers, manual tracking may appear manageable. At one million customers, with multiple products, channels, purposes and systems, it becomes an architecture problem.
The number of relationships grows far faster than the number of customers because every person can have several purpose-level permissions that change over time.
What iConsent is designed to do
iConsent treats consent as a managed lifecycle rather than a collection event.
The platform is designed to connect notice, purpose, data, consent state, change history, withdrawal and evidence, while integrating those decisions with the broader enterprise environment.
The quality of a consent programme is not proven when someone clicks "Agree". It is proven by what the organisation can do after that click.
That is the shift from consent capture to consent management — and it is where privacy technology starts becoming operational infrastructure.
