India's Digital Personal Data Protection framework treats consent as the primary basis for processing personal data, with limited exceptions. That single sentence has architectural consequences most teams underestimate, because consent is not a checkbox — it is a state that changes over time and must be provable.
Provable means recorded. For each individual you need to know what they agreed to, when, in which language, against which version of the notice, and through which interface. A consent record that says 'accepted' with a timestamp does not survive a question about what exactly was accepted.
Consent is also granular. Bundling marketing communications, analytics and service delivery into one acceptance is precisely what the framework discourages. Separating purposes means your data model needs a purpose dimension, and every downstream system needs to check it before processing.
Withdrawal is where architectures break. The framework requires withdrawal to be as easy as giving consent, and requires processing to stop. If personal data has been copied into a warehouse, a marketing tool, a support system and three exports, honouring a withdrawal means reaching all of them. Teams that never mapped their data flows cannot do this, which is why classification and lineage work turns out to be a prerequisite here too.
Notices must be available in English and the languages in the Eighth Schedule. That is a content and versioning problem as much as a legal one: each translation is a version, and the version the user actually saw is what you must be able to reproduce.
The practical shape of this is a consent service — a single place that records grants and withdrawals, exposes a check for other systems, and keeps an immutable log. Building it early is far cheaper than retrofitting consent checks across a dozen systems later.
