A year ago, the DPDP Act rules were still new territory for India's BFSI sector. Institutions were scrambling to interpret obligations, legal teams were rewriting policies overnight, and "DPDP readiness" was a phrase that meant different things depending on who you asked. Twelve months on, the dust has settled enough to see real patterns emerge — who built lasting infrastructure, who patched together a quick fix, and where the gap between "compliant on paper" and "compliant in practice" is showing up hardest.
This is a good moment to take stock. Not to point fingers, but because the second year of DPDP enforcement is going to be far less forgiving than the first. Here's what a year of consent management under DPDP has actually taught the sector.
What BFSI got right
Give credit where it's due — a lot changed and changed fast. Most large banks, NBFCs, and insurers moved quickly on the visible, high-priority items. Consent notices were rewritten in plain language. Privacy policies were updated to reflect the Act's requirements around purpose limitation and data minimization. DPO roles got staffed internally or brought in through managed service arrangements, often for the first time.
Perhaps the bigger shift was structural, not procedural. A year ago, DPDP was a legal-team conversation, buried in policy documents and compliance checklists. Today, it's a boardroom conversation. Risk committees are asking about consent architecture. Audit committees want to know how data principal rights requests are being tracked. That elevation — from back-office compliance task to board-level risk item — is genuine progress, and it's the foundation everything else gets built on.
There's also been real investment at the front end of the data lifecycle. Loan origination systems, insurance underwriting flows, account opening journeys — many of these now capture consent with specificity that simply didn't exist before. Purpose-specific consent, rather than blanketing "I agree to terms" checkboxes, is becoming more common across digital onboarding journeys. That's not a small thing. It's the difference between consent that looks compliant and consent that would hold up to scrutiny.
What BFSI got wrong
Here's where the story gets more complicated. The institutions that treated DPDP as a one-time project — rewrite the notices, update the policy, call it done — are now discovering that consent isn't a document. It's an operational system that has to run continuously, and continuous systems break in places that one-time projects don't.
The first crack is in what happens after consent is captured. Plenty of institutions can now prove they asked for consent in the right way. Far fewer can prove they're honoring the boundaries of that consent afterward — tracking which data is used for which purpose, managing withdrawal requests within mandated timelines, or producing a tamper-proof audit trail of consent history when a regulator asks for one. Consent management, in practice, has often stopped at capture and never extended into governance.
Retrospective consent is where the gap is widest. Every BFSI institution is sitting on years — sometimes decades — of legacy customer data collected long before DPDP existed. The Act's Section 5(2) requires a structured one-time notice process to bring that legacy data into compliance. In year one, a lot of institutions treated this as a checkbox: send a mass notification, log it, moved on. That approach doesn't hold up. A retrospective consent process needs to be trackable, auditable, and capable of demonstrating — line by line — which data principals were notified, when, and what response was recorded. Most institutions don't have that infrastructure yet.
DSAR handling is the other consistent soft spot. Data principal rights requests — access, correction, erasure, grievance redressal — are still being routed through manual, email-based workflows at a large number of BFSI institutions. That approach survives at low volume. It does not survive once awareness spreads and request volumes climb, which is exactly the trajectory year two is expected to bring. Manual DSAR handling doesn't just create operational strain; it creates compliance risk, because missed timelines under DPDP carry real regulatory consequences.
Then there's the question of proof. This might be the single biggest miss across the sector. Many institutions have built compliance processes that work — but can't be evidenced. A tamper-proof consent ledger, a documented Records of Processing Activities register, an audit trail that shows exactly how a breach was assessed and reported — these are the artifacts that turn "we're compliant" into "we can prove we're compliant" in front of the DPBI. Year one was about building the process. Year two is about proving it.
Where DataRakshaq fit in
This is exactly the gap DataRakshaq was built to close, and it's why the platform has found traction across BFSI, NBFC, and fintech environments in exactly the areas where the sector is struggling most.
DataRakshaq isn't a GDPR toolkit retrofitted for India — it's built DPDP-native, from the ground up, for the operational realities of regulated financial institutions. The Consent Management module replaces fragmented, spreadsheet-driven consent tracking with a tamper-proof, audit-ready consent ledger — the exact kind of evidence institutions are finding they lack when scrutiny arrives. The DSAR and Data Principal Rights module automates the request-handling workflow end-to-end, so rights requests move through defined timelines instead of sitting in someone's inbox. The Retrospective Consent module turns the Section 5(2) one-time notice obligation into a structured, trackable rollout rather than a one-off mass mailer — with a clear record of who was notified and how they responded.
Underneath all of it sits the Privacy Programme Design module, with 45+ pre-loaded BFSI-specific processing activities and an audit-ready RoPA — so institutions aren't starting from a blank page when they need to demonstrate governance maturity.
What differentiates CERF's approach is that it doesn't stop at advisory recommendations. The engagement model runs end-to-end — Discover, Design, Implement, Operate — from the initial gap assessment and readiness audit, through policy design and consent architecture, into live deployment of the CMP and rights desk, and finally into ongoing managed compliance, audits, and regulatory monitoring. Institutions get a partner that stays through implementation and operation, not just a report that recommends what to build next.
The year ahead
DPDP enforcement is only going to tighten from here. The DPBI's expectations in year two will be higher than they were in year one, and the institutions that treated the first twelve months as a compliance sprint — get the notices out, update the policy, move on — are going to find themselves playing catch-up against institutions that built real infrastructure: automated, auditable, and built to scale with growing data principal request volumes.
Consent isn't a form you fill out once. It's a system you have to maintain, evidence, and continuously operate. That's the shift BFSI needs to make as it moves into year two of DPDP — and it's the shift that will separate institutions that merely survived their first regulatory audit from institutions that are genuinely ready for what comes next.