RBI Just Made Data Governance a Board-Room Problem

For years, data governance at Indian banks and NBFCs lived where most institutions were comfortable leaving it: with IT, with a compliance checklist, with a policy document that got dusted off once a year. On July 15, the Reserve Bank of India ended that arrangement.

The RBI released draft norms on a Data Governance Framework (DGF) for all regulated entities — commercial banks and NBFCs alike — and the message is unambiguous: data is now a board-level risk discipline, not a back-office function. Named accountability, board oversight, and audit-grade traceability are no longer best practices. They’re about to be requirements.

Here’s what’s in the draft, why it’s arriving now, and what it will actually take to comply.

Why now?

The timing isn’t an accident. This draft lands roughly nine months before the Expected Credit Loss (ECL)framework takes effect on April 1, 2027 — a fundamental shift in how banks provision for loan losses. Where the current incurred-loss model relies on relatively coarse, backward-looking triggers, ECL demands forward-looking, probability-weighted estimates built on granular, historical, and behavioral data across the entire loan book.

You cannot run a credible ECL model on data you don’t trust. The RBI clearly sees this: if institutions don’t fix their data foundations now, the ECL transition will expose every crack — inconsistent definitions, untraceable third-party feeds, stale records, and ownership gaps that nobody can explain to an examiner.

The regulator’s own framing captures why this has become urgent: the growth of digital financial services, interconnected technology ecosystems, and automated decision-making has expanded the volume, velocity, and complexity of data far faster than most governance structures have kept up.

What the draft actually requires

Strip away the language and the DGF comes down to five structural demands:

1. Board-level ownership.Regulated entities must establish a board-level Data Governance Committee — or explicitly assign the mandate to an existing committee. This committee doesn’t just rubber-stamp a policy; it reviews governance metrics and reports on an ongoing basis and is accountable for the framework’s effectiveness.

2. A named, senior data function.The draft requires a data function headed by an officer of no rank lower than Chief General Manager (or equivalent), with real authority and the competence to implement the DGF. This function acts as the central coordination point across business, risk, and technology — meaning data governance can no longer sit in a silo disconnected from how the institution actually makes decisions.

3. Clear accountability at the domain level. Every data domain needs a designated data owner — accountable for how data in that domain is defined, classified, and used — and a data custodian, responsible for enforcing access controls and entitlements according to that classification. This is a meaningful departure from the diffuse, shared-responsibility model most institutions run today.

4. Third-party data discipline.Perhaps the most operationally demanding piece: regulated entities remain fully responsible for governance of data shared with third parties, including group entities. That means data can only move for defined, approved purposes, through designated personnel, with customer consent factored in wherever customer data is involved. Crucially, the draft requires that shared data stay traceable back to a single source of truth, with metadata and lineage capturing exactly how far it has traveled — and explicitly prohibits unauthorized reuse, duplication, or re-sharing.

5. Proportionate but comprehensive scope.The RBI isn’t asking a small NBFC to build the same apparatus as a large private bank — the framework must be proportionate to size, complexity, business model, and IT/security maturity. But “proportionate” doesn’t mean partial: the DGF still has to span the full data lifecycle, from architecture and classification to risk management, security, and audit, and it has to be reviewed at least annually.

Underpinning all of it, the framework must align with the DPDP Act, 2023 and DPDP Rules, 2025 — so data governance and data privacy compliance are now explicitly the same conversation, not two separate workstreams run by two separate teams.

The gap between where most institutions are and where this points

Talk to almost any mid-sized bank or NBFC today and you’ll hear a familiar story: data ownership is informal, lineage is reconstructed manually when an auditor asks for it, and third-party data flows are governed more by contract boilerplate than by real-time controls. That’s not a criticism — it’s simply where the industry has been, because until now, nothing forced it to be otherwise.

The RBI’s draft closes that gap deliberately. Three areas will likely cause the most friction in implementation:

• Lineage and traceability.Proving that data shared externally maps back to a single source of truth requires metadata infrastructure most institutions haven’t built — this isn’t a policy fix, it’s an engineering one.
• Consent-aware access.Governing third-party data sharing “taking into account… customer consent” means access controls have to be consent-aware in practice, not just in a privacy policy PDF.
• Named accountability.Assigning a real data owner to every domain forces institutions to actually define what their data domains are — a surprisingly hard exercise for organizations that have grown through mergers, legacy systems, and years of point solutions layered on top of each other.

What institutions should be doing right now

This is still a draft — the RBI has opened it for comment, and the final rules may shift in scope or sequencing. But waiting for the final text before acting would be a mistake. A few things are worth starting immediately:

• Map your data domains and propose ownership before it’s mandated, so the eventual rollout is a formalization exercise rather than a scramble.
• Audit existing third-party data-sharing arrangements against the traceability and consent standards in the draft — most institutions will find gaps here first.
• Start building the metadata and lineage layer now. This is the piece with the longest lead time and the least room for shortcuts.
• Bring DPDP compliance and data governance into one workstream. Treating them separately will only mean redoing work later.

The bigger picture

What’s notable about this draft isn’t any single requirement — it’s the shift in framing. Data governance has moved from an operational hygiene issue to a named, board-accountable risk discipline, with real consequences tied to how well institutions can implement ECL, defend their numbers to examiners, and demonstrate control over where customer data actually goes.

Institutions that treat this as a paperwork exercise will find themselves exposed when the ECL deadline arrives and their data can’t support the models they need to build. Institutions that treat it as a genuine infrastructure investment — starting now, ahead of the final rules — will have a real head start.

At Cerf Solutions, we’re helping clients turn drafts like this into concrete data architecture and governance roadmaps: domain mapping, lineage design, and third-party controls that hold up under audit. If your institution is starting to think through what a board-ready DGF looks like in practice, we’d welcome the conversation.

Where do you see the biggest implementation gap — lineage, ownership, or third-party controls? Curious to hear how other institutions are reading this draft.