1. Executive Summary
With the rapid digitalization of the financial sector, the Reserve Bank of India (RBI) has issued the draft ‘Guidance on Regulatory Expectations for Data Governance’. This framework aims to ensure data remains accurate, secure, and fit for purpose, mitigating operational, compliance, and reputational risks. The guidance mandates a structured Data Governance Framework (DGF), defined organizational roles, strict lifecycle management, and robust third-party data sharing protocols, aligning closely with the DPDP Act, 2023.
2. Applicable Entities
This guidance is uniformly applicable across a wide spectrum of Regulated Entities (REs), acknowledging the systemic importance of data across all financial tiers:
Commercial Banks (incl. Foreign)
Small Finance Banks (SFBs)
Payments Banks
Local Area Banks
Regional Rural Banks
Urban Co-operative Banks
Rural Co-operative Banks
All India Financial Institutions
NBFCs (All Layers: BL, ML, UL, TL)
Asset Reconstruction Companies
Credit Information Companies
3. Detailed Analysis & Management Action Plans
Amendment 1: Board Oversight and Data Governance Framework (Chapter II)
Specific Changes Required
- Implementation of a comprehensive Data Governance Framework (DGF) aligned with DPDP Act, 2023.
- Establishment of a Board-level Data Governance Committee (DGC) to oversee policy formulation and review reports.
- Formation of an Executive-level Data Governance Committee comprising IT, IS, Business, and Risk heads to operationalize the DGF.
- Integration of Data Risk Management into the overall enterprise risk management framework.
Management Action Plan
- Board Restructuring: Modify the terms of reference of the existing Board Risk Management Committee to explicitly include “Data Governance” if a separate committee is not feasible.
- Drafting the DGF: Engage external legal and compliance consultants to draft the DGF, ensuring cross-mapping with DPDP Act 2023 requirements.
- Executive Committee Setup: Issue an immediate internal mandate establishing the Executive DGC, scheduling monthly review meetings on data breaches, exceptions, and quality metrics.
- Audit Readiness: Empanel a CERT-In certified auditor specifically for an initial gap analysis of the current data risk landscape.
Real-World Example
A Middle-Layer NBFC offering digital loans currently manages risk via a general risk committee. Under this regulation, they establish a specific “Data Risk Executive Committee”. During their first meeting, they identify that their mobile app collects user location data continuously without explicit DPDP-aligned consent. The committee immediately drafts an action item to update the app’s consent architecture and classifies this location data as a ‘high-risk’ data asset in their new DGF.
Amendment 2: Organisational Structure & Roles (Chapter III)
Specific Changes Required
- Creation of a central Data Function headed by an officer not below the rank of Chief General Manager (CGM) or equivalent.
- Appointment of Data Owners (accountable for business logic and data quality in their domain).
- Designation of Data Stewards (embedded in business units to operationalize governance).
- Designation of Data Custodians (IT personnel responsible for technical management, access controls, and backups).
Management Action Plan
- Leadership Appointment: HR to identify and elevate a suitable candidate (e.g., Chief Data Officer) to CGM equivalent status to head the Data Function.
- Role Mapping Matrix: Create a RACI (Responsible, Accountable, Consulted, Informed) matrix mapping every major dataset to an Owner, Steward, and Custodian.
- KRA Updates: Update the Key Result Areas (KRAs) of business heads (Owners) and operational leads (Stewards) to include data quality and compliance metrics.
- Training: Roll out specialized training for Data Stewards on maintaining data lineage and metadata documentation.
Real-World Example
In a Commercial Bank, the Head of Retail Banking is designated as the Data Owner for Savings Account data. A branch operations manager is designated as the Data Steward, ensuring KYC data entered into the system meets validation rules. The bank’s Database Administrator (DBA) acts as the Data Custodian, ensuring the database is encrypted and backed up daily. If a data quality issue arises (e.g., missing PAN cards), the Data Owner is held accountable by the Board, not just the IT department.
Amendment 3: Data Lifecycle Management (Chapter IV)
Specific Changes Required
- Governance must span from data origination to disposal.
- Data capture must align with approved business purposes and include DPDP consent frameworks.
- Implement strict controls for data processing, sharing, and transformation (e.g., encryption, tokenization).
- Formulate a formal Data Retention and Archival Policy with secure, verifiable disposal mechanisms.
Management Action Plan
- Origination Audit: Review all customer-facing forms (digital and physical) to ensure metadata attributes (purpose, consent, ownership) are captured at the source.
- Transformation Logic Review: IT teams to document and assess all scripts/ETL (Extract, Transform, Load) processes to ensure data doesn’t lose its meaning or classification when moved from operational systems to data warehouses.
- Archival Implementation: Deploy automated archival tools that move data to cold storage after the regulatory retention period (e.g., 5-10 years post-account closure) without losing metadata.
- Secure Disposal: Establish standard operating procedures (SOPs) for cryptographic erasure of digital data and secure shredding of physical data.
Real-World Example
A Payments Bank collects customer biometric data during e-KYC. Under the new lifecycle rules, the system must tag this data at origination with metadata: [Owner: Compliance Head, Classification: Highly Sensitive, Retention: 10 years]. When the 10-year period expires for a closed account, an automated script securely purges the biometric record from both the primary database and disaster recovery backups, generating a verifiable disposal certificate for the auditor.
Amendment 4: Data Architecture & Single Source of Truth (Chapter V)
Specific Changes Required
- Establish a Single Source of Truth (SSOT) for all data elements to prevent parallel, conflicting data silos.
- Maintain foundational Metadata and Data Lineage so data can be traced from its origin through all transformations to its final reporting destination.
- Implement a Data Classification Framework based on criticality, sensitivity, confidentiality, and regulatory impact.
- Develop Data Quality Management metrics, reported quarterly to the DGC.
Management Action Plan
- SSOT Designation: Conduct a system inventory and formally document which system serves as the SSOT for specific data (e.g., Core Banking System for account balances, HRMS for employee data).
- Master Data Management (MDM): Invest in or upgrade MDM solutions to enforce SSOT across the organization.
- Data Dictionary Creation: Build a centralized data dictionary defining metadata attributes for all critical data elements.
- Classification Tagging: Run a data discovery exercise to tag existing databases based on the new classification framework (e.g., Public, Internal, Confidential, Restricted).
Real-World Example
An Urban Co-operative Bank frequently faced discrepancies in monthly NPA (Non-Performing Asset) reports because the Loan Origination System and the Core Banking System (CBS) showed different outstanding balances. The Executive Committee officially designates the CBS as the SSOT. They implement an API ensuring the Loan system reads data exclusively from the CBS. A “Data Lineage” map is created to prove to RBI inspectors exactly how the final NPA figure is derived directly from the CBS SSOT.
Amendment 5: Third-Party Arrangements & Data Sharing (Chapter VI)
Specific Changes Required
- REs remain fully accountable for the governance of data shared with third parties (including group entities).
- Data sharing must be strictly on a ‘need to know’ basis and tied to defined, approved purposes.
- Mandatory inclusion of non-disclosure clauses and controls to prevent unauthorized reuse or duplication.
- Periodic IT and security audits of third-party systems, potentially utilizing CERT-In empanelled auditors.
Management Action Plan
- Contract Renegotiation: Legal team to review all existing third-party vendor contracts to insert stringent data usage, non-disclosure, and right-to-audit clauses.
- Anonymization Protocols: Implement data masking, tokenization, or anonymization tools before data is pushed to external vendors for non-core functions (like marketing analytics).
- Vendor Risk Assessment: Establish a continuous vendor monitoring framework. Tier vendors by data criticality and schedule annual CERT-In audits for ‘High-Risk’ vendors.
- API Gateway Security: Secure all data sharing channels using modern API gateways with authentication, rate limiting, and auto-deletion capabilities.
Real-World Example
A Small Finance Bank uses a third-party FinTech company for AI-based credit scoring. Previously, raw customer transaction data was sent via SFTP. Under the new guidance, the bank modifies the process: the data is now tokenized (PII like names and account numbers are replaced with tokens) before transmission. The contract is updated to legally prohibit the FinTech from reusing this data to train their generic models, and the bank initiates an annual CERT-In audit of the FinTech’s cloud environment to ensure data deletion post-scoring.
Strategic Imperative: The RBI’s shift from mere ‘data management’ to comprehensive ‘data governance’ signifies a structural change in regulatory supervision. Regulated Entities must view data not just as an IT operational byproduct, but as a heavily regulated enterprise asset requiring Board-level accountability.