09 Oct 2026
India’s digital privacy landscape is entering an important implementation phase. With the Digital Personal Data Protection (DPDP) Act, 2023 and the phased commencement of the DPDP Rules, 2025, organisations handling personal data need to look beyond policy documents and consider how privacy requirements will translate into their technology environments.
A significant milestone arrives on November 13, 2026, when Rule 4 of the DPDP Rules, 2025 comes into force, activating the registration framework for Consent Managers.
For software and product teams, this is more than a compliance consideration. Consent management can affect application architecture, APIs, identity and access controls, data flows, auditability, notification systems, and integrations across the technology stack.
With further substantive provisions scheduled to come into force on May 13, 2027, organisations can use the current implementation period to evaluate whether their systems are technically prepared.
The DPDP Rules, 2025 were notified on November 13, 2025, with different provisions coming into force in phases.
One year after publication, on November 13, 2026, Rule 4 comes into effect, enabling the Consent Manager registration framework.
Under the Rules, a Consent Manager must meet specified eligibility requirements, including being a company incorporated in India and maintaining a minimum net worth of ₹2 crore. The framework also requires an independently certified interoperable platform through which Data Principals can give, manage, review, and withdraw their consent.
Further substantive Rules are scheduled to commence on May 13, 2027, covering areas including notices, personal data breach requirements, Data Principal rights, and safeguards relating to children’s personal data.
For technology teams, these milestones make 2026 an important period for assessing how consent and personal-data controls are implemented across existing systems.
In many organisations, consent information may exist across CRM platforms, marketing applications, websites, mobile applications, customer databases, identity systems, and third-party services.
The challenge is not simply recording whether a user has selected a consent option.
Systems also need to understand what that consent relates to, where the associated personal data is located, which applications use it, and how a change in consent should affect subsequent processing.
If these relationships are fragmented across systems, implementing consistent privacy controls can become difficult.
This is why organisations should consider consent management as part of their broader application and data architecture rather than treating it only as a front-end preference-management function.
Traditional consent implementations may rely heavily on CRM systems, preference centres, or periodic synchronisation.
That approach can create challenges when consent changes need to be reflected across multiple applications.
Software teams can consider moving consent validation closer to the point where personal data is accessed or processed. Applications could query a central consent service or use event-driven mechanisms to receive updated consent states.
When consent is withdrawn, relevant systems should be capable of responding appropriately rather than continuing to depend on outdated information until the next scheduled synchronisation.
The exact architecture will vary between organisations, but timely propagation of consent-state changes should be an important design consideration.
As the Consent Manager ecosystem develops, organisations should avoid assuming that one technical implementation will necessarily become the universal model.
Instead of tightly coupling applications to a specific provider, software teams can consider introducing an integration or abstraction layer between business applications and external consent-management services.
Such an architecture could provide standard internal interfaces for retrieving consent status, processing consent updates, recording changes, and connecting with external Consent Manager platforms where applicable.
This approach can provide greater flexibility as interoperability requirements, providers, and implementation standards evolve.
Consent cannot be effectively managed if an organisation does not know where personal data resides or how it moves through its systems.
Teams should establish visibility into:
This data lineage becomes particularly important in organisations operating multiple applications, legacy platforms, cloud environments, and third-party integrations.
Starting this work early can simplify future privacy workflows and reduce the effort required to identify affected systems when a consent status changes or a Data Principal exercises applicable rights.
Several privacy-related processes require coordination across applications, databases, operational teams, and communication systems.
Rather than treating these processes as isolated manual activities, software teams can consider developing reusable technical capabilities such as:
The DPDP Rules include personal data breach-intimation requirements, including providing specified updated and detailed information to the Data Protection Board within 72 hours of becoming aware of a personal data breach, unless a longer period is allowed by the Board.
Reliable logging, incident workflows, data visibility, and notification capabilities can therefore form an important part of technical readiness.
Applications processing children’s personal data require additional consideration.
The Rules contain requirements relating to verifiable parental consent, together with specified provisions and exemptions.
Products that may process children’s data should therefore evaluate age-related workflows, parental verification mechanisms, consent records, and associated data-processing controls separately rather than assuming that a standard adult consent workflow will be sufficient.
The implementation should be evaluated against the organisation’s actual processing activities and applicable requirements.
Organisations should also assess the provisions relating to Significant Data Fiduciaries (SDFs).
Where an organisation is notified as an SDF under the DPDP framework, additional obligations apply. Under the Rules, these include conducting a Data Protection Impact Assessment and an audit once every twelve months, among other requirements.
From a technology perspective, this increases the importance of traceability, documentation, system visibility, audit records, data governance, and measurable privacy controls.
Organisations should work with qualified legal and privacy professionals when determining how particular DPDP obligations apply to their activities.
DPDP readiness will not be achieved through a single consent screen or privacy-policy update.
For organisations operating complex digital environments, it can require coordination across data architecture, APIs, application development, identity and access management, cloud infrastructure, DevOps, security, logging, and operational workflows.
Kryon Knowledge Works can support organisations in evaluating and developing the technical foundations required for privacy-ready systems, including:
The objective is not to prescribe a single architecture, but to help organisations build technology environments that can adapt to evolving privacy and data-governance requirements.
November 13, 2026 represents an important milestone with the commencement of the Consent Manager registration framework. May 13, 2027 marks another significant stage as further substantive provisions under the phased DPDP Rules commencement schedule take effect.
For software teams, the period between these milestones provides an opportunity to review existing data flows, identify architectural gaps, evaluate consent-management capabilities, and establish the technical controls required to support privacy operations.
Organisations that begin this work early can approach DPDP implementation as a structured engineering programme rather than a last-minute compliance exercise
2026 © Kryon Knowledge Works. All Rights Reserved