Most enterprises still treat data consent as a compliance checkbox a cookie banner bolted onto an existing journey, friction masquerading as protection. Rohith Reji, CEO, Neokred, argues this approach is fundamentally broken. In this conversation, he makes the case for consent architecture built from the data layer up, where every collection point is mapped, every consent record is machine-readable, and revocations cascade automatically across systems in real time. Drawing on Neokred’s Blutic platform, Reji unpacks how privacy-by-design reshapes AI training pipelines, access controls, and CRM integrations under India’s DPDP Act, and why delaying compliance compounds risk across regulatory, architectural, and trust dimensions. His central thesis: consent, done right, is not a wall but a handshake and a competitive advantage.
CEO
Neokred
CISO Forum: How should Indian enterprises architect DPDP-ready consent systems without breaking user experience?
Rohith Reji: The biggest mistake I see enterprises making is treating consent as a compliance checkbox rather than a critical customer touchpoint. The moment a business retrofits compliance onto an existing journey, there’s friction. That jarring pop-up that interrupts an onboarding flow, or a cookie banner that obscures the very content the user wants to see. That is not compliance architecture. It is ‘compliance theater’.
A DPDP-ready consent system must be designed from the data layer upwards. Start by mapping every data collection point across the digital estate, including web apps, APIs, and third-party widgets, and classify data by purpose and sensitivity. Then design consent collection to align with those natural moments of interaction. When a user signs up, that is the right moment to explain what you will do with their contact information. When they browse your website, that is when personalization preferences make contextual sense.
Consent sought in context is consent that converts. For instance, with Blutic, we have architected our platform so that consent notices are rendered dynamically based on user state, jurisdiction, and prior preferences. The system remembers what a user already consented to and doesn’t ask twice. It adapts language to be plain and purposeful, not legalese that users scroll past, but with clear statements like, ‘We use this to show you relevant offers, not share with third parties’. When users understand what they are agreeing to, opt-in quality improves dramatically, even if raw opt-in volume is initially low. The deeper architectural truth is this: consent is not a wall between you and your user. It is a handshake. Build it to feel like one.
CISO Forum: What does “privacy-by-design” look like in real-world product and platform engineering?
Rohith Reji: Privacy by design is one of those principles that sounds straightforward but is genuinely complex when shipping code under a tight deadline. In practice, it means making privacy an engineering constraint, not a review item on the day before the launch. For product teams, it starts with the user storage journey. Before a feature is designed, the team must ask, “What does this feature need, for how long, and who inside the business can access it?” If you can’t answer these questions at the design stage, the business is likely going to overcollect and under-protect. Data minimization is good engineering hygiene. The less data you hold, the smaller the attack surface, the lower the storage costs and the simpler the compliance posture.
From the perspective of platform architecture, privacy-by-design means building consent records into the data schema from day one. Every data entity that maps to a user must carry a reference to the consent record that authorized its collection. When data consent is withdrawn, the cascade must be automatic, not a manual ticket to the data engineering team.
This also means thinking about access controls differently. Purpose-based access is where DPDP pushes engineering teams. A marketing analyst should be able to run campaign analytics but should not be able to export raw PII. A fraud investigator needs behavioral signals but not necessarily names and addresses. Building these access boundaries requires deliberate schema design, not just a permission toggle. The organizations that get this right are the ones where privacy is a product value, not a compliance obligation. And increasingly, it is also a competitive differentiator. We’ve built exactly this kind of consent-linked data lineage into Blutic, where a revocation triggers downstream suppression across connected ecosystems in near real time, removing the added constraint of privacy-by-design from the engineering team’s plate.
CISO Forum: Can consent management be automated at scale across apps, web, and partner ecosystems?
Rohith Reji: Manual consent management is operationally expensive and fundamentally unreliable. When a user opts out of the mobile app, the web portal, CRM, and every partner integration must reflect that within seconds, not days. With Blutic, we solve this with unified consent records across all channels. Every consent touchpoint, be it a cookie preference center, an in-app permission prompt, or an email opt-out, writes a signal to a centralized store, and the platform propagates it via APIs to every connected system in real time.
It automates the consent lifecycle. As consent approaches expiry, the system sends renewal prompts. When a user revokes consent, it flags downstream records and generates an audit trail of what users consented to, when, and how the data was used. DPDP requires easy withdrawals and opt-ins, and with Blutic we’ve proved that this can be scaled quickly.
CISO Forum: How does DPDP change data architecture, storage, and access control for AI-driven platforms?
Rohith Reji: DPDP creates a specific challenge for AI-powered platforms. AI systems are hungry for data. They perform better with more signals, longer histories, and richer contextual patterns. But DPDP places clear obligations around purpose limitation and data minimization. Unless mandated by industry regulators, a business can’t justify retaining three years of granular behavioral data simply because it might improve its recommendation model.
The practical implication for data architecture is a shift towards consent-conditioned data pipelines or solutions that provide it. When data enters your systems, it must be tagged based on why it was collected and the purpose it’s to be used. AI training pipelines must query this layer before consuming data to ensure that data collected for fraud detection is not used to train a personalization model unless there is explicit consent for cross-purpose use.
Storage architecture must also evolve to support what DPDP calls the right to erasure. Traditional data warehouses and data lakes are not designed for selective deletion at the record level. Enterprises will need to introduce consent-aware partitioning either so users’ data can’t be isolated and dropped without corrupting model performance, or implement pseudonymization strategies that preserve analytical signals while severing the identifying link when erasure requests are made.
Access control for AI platforms must move beyond simple authentication. Who can query raw training data versus aggregate statistics? Which model training runs have consent coverage for the data they consumed? Can the business produce an audit trail showing a specific inference result was derived only from data where the relevant consent was active at the time of processing? These are the questions that a mature AI governance framework under DPDP must answer. Businesses that design for this now will have a significant operational advantage when enforcement begins. Retrofitting consent-aware data architecture into a system that was built without it is one of the most expensive and disruptive compliance exercises a technology team can face. It’s always better to adopt consent management platforms that make the job easier.
CISO Forum: What tech debt risks do companies face if they delay DPDP compliance now?
Rohith Reji: Delayed compliance creates tech debt across three dimensions: regulatory exposure, architectural complexity and customer trust. Most businesses fixate on the first and ignore the latter two until it’s too late. Regulators won’t lower the compliance bar for latecomers. They enforce it on a compressed timeline. Companies that wait will attempt the same implementation that early adopters completed methodically, but under pressure, with less time for testing and a higher likelihood of breaking live systems.
The architectural dimension catches teams off guard. Consent management looks like a cookie banner on the surface. In the middle of the project, teams discover it requires a consent datastore, APIs across every data collection point, suppression logic in every downstream system, and a complete audit chain. Retrofitting this onto systems not designed for it means working with unfamiliar code and accepting the risk of breakage. The trust dimension never appears on a risk register, but hits the hardest. When a user requests erasure and your systems respond inconsistently, that’s a reputational event. Leadership teams should remember that preparation has a bounded cost, but unpreparedness does not.
CISO Forum: How can consent platforms integrate with existing CRM, CDP, and marketing stacks?
Rohith Reji: A consent management platform captures preferences but fails to enforce them in CRM, CDP, and marketing tools; it is not a compliance solution. It’s an audit exhibit. Integration is where compliance strategy either becomes operational or falls apart.
That’s precisely why Neokred’s Blutic uses event-driven consent propagation. Every time a user changes their consent state, be it opt-in, opt-out, modification, or erasure, the platform emits a structured event to a webhook or message queue. Every connected system consumes that event and updates its own records: no batch jobs, no overnight syncs.
For CRM teams, this means that when a sales rep opens a contact record, they see the live consent status for each communication purpose, rather than a separate compliance sheet to look up. For the CDR team, it means consent signals flow directly into the identity graph so only eligible audiences reach activation. For marketing stacks, it means suppression lists refresh in real time as opt-outs occur.
CISO Forum: What metrics should CIOs track to prove DPDP compliance without slowing growth?
Rohith Reji: CIOs must run two sets of metrics simultaneously—one for regulators and one for the board. The compliance track and the growth track must reinforce each other. For compliance, track the consent coverage rate (what share of user records carry a valid, current consent basis), consent freshness (whether consents renew before lapsing), and data subject request resolution time (how quickly systems fulfill access, correction, and erasure requests).
Audit trail completeness deserves its own focus. For every data processing activity, CIOs need a timestamped record of the consent basis that authorized it. Teams that track this at the transaction level hold the strongest position under regulatory scrutiny.
For the board, track consent opt-in rates by channel and purpose, as well as the correlation between consent quality and campaign ROI. A great consent management platform like Blutic ensures that audiences engaged through purpose-specific consent consistently deliver higher engagement and lower churn. The metric to measure is the share of activated marketing audiences covered by granular, valid consent. As that number rises, regulatory risk falls, and marketing efficiency improves.
