A data governance framework for banks is the written structure of policies, roles, and controls that keeps customer and risk data accurate, secure, and available on the timelines regulators expect. Building one that survives federal examination means satisfying several overlapping rules at once, assigning clear ownership over every data element, and proving through documentation and audit that the controls actually work. What follows is what the framework must contain and how the pieces fit together.
The Regulations the Framework Must Satisfy
You can’t design the framework without first knowing which mandates it has to meet. Four bodies of law and guidance do most of the work.
BCBS 239 Risk Data Aggregation Principles
The Basel Committee’s Principles for Effective Risk Data Aggregation and Risk Reporting, known as BCBS 239, require banks to aggregate risk data quickly and accurately enough to produce reliable reports during periods of financial stress. The principles initially applied to globally systemically important banks with a January 2016 compliance deadline, and national supervisors are encouraged to extend the same expectations to domestically systemically important banks within three years of designation.1Bank for International Settlements. Principles for Effective Risk Data Aggregation and Risk Reporting
Even banks outside the formal scope treat BCBS 239 as a practical benchmark. The core expectations: reconcile data across business units without manual intervention, generate ad-hoc risk reports on short notice, and demonstrate that aggregated figures match the underlying source data.
Gramm-Leach-Bliley Act
The Gramm-Leach-Bliley Act imposes a continuing obligation on every financial institution to protect the security and confidentiality of customers’ nonpublic personal information.2Office of the Law Revision Counsel. 15 USC 6801 – Protection of Nonpublic Personal Information Administrative, technical, and physical safeguards must cover everything from how loan applications are stored to who can view account balances. GLBA also carries criminal penalties for anyone who fraudulently obtains customer financial information, and banking regulators enforce the privacy provisions through their existing supervisory authority, up to civil money penalties and consent orders.3Office of the Law Revision Counsel. 15 USC 6823 – Criminal Penalty
Interagency Information Security Guidelines
The Interagency Guidelines Establishing Information Security Standards at 12 C.F.R. Part 30, Appendix B translate GLBA into operational requirements. Every national bank and federal savings association must implement a comprehensive written information security program scaled to its size and complexity.4eCFR. 12 CFR Part 30 Appendix B – Interagency Guidelines Establishing Information Security Standards The program must address four objectives: keeping customer information secure, protecting against anticipated threats, preventing unauthorized access, and ensuring proper disposal of customer and consumer information.5Federal Financial Institutions Examination Council. IT Examination Handbook – Information Security Booklet
The board of directors must formally approve the program and receive a status report at least annually covering risk assessment, control testing, security breaches, and third-party arrangements. Federal examiners evaluate these capabilities during safety and soundness examinations to confirm that data practices do not threaten the Deposit Insurance Fund.6Federal Deposit Insurance Corporation. Risk-Focused, Forward-Looking Safety and Soundness Supervision
Bank Secrecy Act Recordkeeping
The Bank Secrecy Act layers on its own governance requirements. Banks must maintain procedures for collecting and reporting information that guards against money laundering and terrorist financing.7Office of the Law Revision Counsel. 31 USC 5318 – Compliance, Exemptions, and Summons Authority Most BSA-related records must be retained for at least five years and stored so they’re accessible within a reasonable time.8eCFR. 31 CFR 1010.430 – Nature of Records and Retention Period The five-year clock runs from different starting points depending on the record type, so retention schedules must map each type to its correct trigger.9Federal Financial Institutions Examination Council. Appendix P – BSA Record Retention Requirements
Computer-Security Incident Notification
Under 12 C.F.R. Part 53, a banking organization must notify its primary federal regulator as soon as possible and no later than 36 hours after determining that a notification incident has occurred.10eCFR. 12 CFR Part 53 – Computer-Security Incident Notification The clock doesn’t start at the breach. It starts when the bank concludes the incident meets the threshold: a computer-security incident that has materially disrupted or is reasonably likely to disrupt the bank’s ability to carry out operations, deliver products to a material portion of its customer base, or continue a business line whose failure would cause material revenue or franchise loss. Your framework needs a pre-built escalation process that gets incident reports from the security team to the person authorized to notify the regulator inside that window.
Roles That Have to Exist
A framework is only as effective as the people executing it. The interagency guidelines require banks to designate at least one information security officer responsible and accountable for the program.5Federal Financial Institutions Examination Council. IT Examination Handbook – Information Security Booklet Most banks build a multi-layered structure around that minimum.
Chief Data Officer
The Chief Data Officer holds executive-level responsibility for the data strategy and the effectiveness of the governance program overall. The CDO works directly with the board to align data policies with the bank’s risk appetite and business objectives, and bridges IT and the business lines that depend on accurate data for lending, regulatory filings, and customer reporting. Without a CDO or equivalent executive sponsor, governance efforts usually stall because no one has the authority to enforce standards across departmental boundaries.
Data Owners and Data Stewards
Data Owners are senior leaders within specific business lines who hold ultimate accountability for the data their departments generate. A commercial lending executive who owns the loan portfolio data approves who can access it, defines quality requirements, and answers for errors or breaches within that domain. Data Stewards sit below the Owners and handle the daily work: monitoring quality metrics, resolving discrepancies, maintaining metadata, and serving as the first point of contact when something looks wrong. The Owner sets the standard, and the Steward enforces it.
Data Governance Council
The Data Governance Council is the formal body that coordinates the framework and resolves conflicts between business units. It typically includes representatives from risk management, legal, compliance, and information technology. The council approves standards for metadata management, reviews data quality reports, and prioritizes technical projects that improve the bank’s information infrastructure. When two departments disagree about who owns a shared data element or which system is the authoritative source, the council decides.
Written Policies the Framework Must Contain
Roles without policies produce inconsistent results. Certain standards need to be in writing.
Data Classification and Access Control
A classification schema categorizes every type of information by sensitivity and regulatory requirement. Most banks use tiers such as public, internal, confidential, and highly restricted, with each tier carrying specific requirements for encryption, access control, and retention. Customer Social Security numbers and account details land in the most restrictive tier, while public marketing materials flow freely. The classification drives everything downstream: who can see the data, how it’s encrypted, and how long it’s kept.
Data Lineage and Quality Metrics
Lineage documentation traces every piece of information from its source through each system it touches to its final destination in a report or regulatory filing. When a number on a call report looks wrong, lineage tells you exactly where to look. Quality metrics provide quantifiable measures of accuracy, completeness, and timeliness. If loan-to-value ratio calculations depend on appraisal data that’s only 85% complete, the quality metric flags the gap before it contaminates a risk report.
Data Dictionary
A data dictionary defines every primary data element: field name, definition, allowed data types, and business rules. An interest rate field might be defined as a decimal value with a maximum of six decimal places that cannot exceed a specified ceiling. Without this specificity, different systems interpret the same field differently and reconciliation becomes manual. The dictionary is the reference that keeps applications, departments, and reports speaking the same language.
Data Retention and Secure Disposal
Knowing when to keep data and when to destroy it is a governance function banks routinely underestimate. The BSA’s five-year retention sets the floor for most transaction and customer identification records.8eCFR. 31 CFR 1010.430 – Nature of Records and Retention Period Litigation holds, state consumer protection laws, and contractual obligations can extend that period. A retention schedule must identify the longest applicable period for each record type.
Secure disposal at the end of retention is just as regulated as storage. NIST Special Publication 800-88 Revision 1 defines three escalating methods. “Clear” overwrites user-accessible storage locations using standard read/write commands. “Purge” uses physical or logical techniques that make recovery infeasible even with laboratory equipment. “Destroy” renders the media itself unusable through shredding, pulverizing, or incineration.11National Institute of Standards and Technology. Guidelines for Media Sanitization – NIST SP 800-88 Rev 1 Customer financial records on a decommissioned server typically require purging or destruction, not simple overwriting.
Third-Party and Cloud Data Oversight
Outsourcing data processing to a cloud provider or fintech partner does not outsource the regulatory responsibility. Interagency guidance on third-party risk management directs banks to scale their oversight to match the risk and criticality of the activity the third party supports.12Office of the Comptroller of the Currency. Third-Party Relationships – Interagency Guidance on Risk Management A cloud vendor hosting core banking data gets far more scrutiny than a vendor supplying office supplies.
The information security guidelines reinforce this by requiring banks to exercise due diligence in selecting service providers, contractually require them to implement appropriate safeguards, and monitor their compliance through audits, test results, or equivalent evaluations.4eCFR. 12 CFR Part 30 Appendix B – Interagency Guidelines Establishing Information Security Standards Vendor contracts must specify data handling standards, breach notification timelines, and the bank’s audit rights. If a third party stores customer data in a jurisdiction with weaker privacy laws, the bank still bears the consequences of a breach.
Model and AI Data Governance
Banks increasingly rely on quantitative models for credit scoring, fraud detection, and anti-money laundering surveillance. The Federal Reserve’s supervisory guidance on model risk management defines a model as any quantitative method that applies statistical, economic, or financial theories to process inputs into estimates, and requires banks to validate that these models perform as expected.13Board of Governors of the Federal Reserve System. Supervisory Guidance on Model Risk Management Validation includes evaluating conceptual soundness, comparing outputs to real-world outcomes, and ongoing monitoring for model deterioration as market conditions change.
For data governance, every model is only as reliable as its training data and ongoing inputs. The framework must define quality standards for model inputs, document the lineage of training data sets, and establish processes for identifying bias or drift over time. The OCC issued revised model risk management guidance in 2026, though it explicitly excludes generative AI and agentic AI systems from its scope, noting that the agencies plan to issue a separate request for information addressing AI-specific risks.14Office of the Comptroller of the Currency. Model Risk Management – Revised Guidance Banks using generative AI tools can track the NIST AI Risk Management Framework for voluntary guidance on trustworthiness while binding regulatory expectations develop.15National Institute of Standards and Technology. AI Risk Management Framework
Employee Training
The interagency guidelines require banks to train staff to implement the information security program.4eCFR. 12 CFR Part 30 Appendix B – Interagency Guidelines Establishing Information Security Standards Not just IT personnel. Tellers who handle customer identification documents, loan officers who enter financial data, and operations staff who process wire transfers all need to understand the governance policies that apply to the information they touch.
Management is expected to establish a security culture that promotes understanding of every employee’s role in protecting the institution’s data.5Federal Financial Institutions Examination Council. IT Examination Handbook – Information Security Booklet Training should be tailored to each role. A branch manager needs to know how to handle a customer’s request for account records. A database administrator needs to understand the technical controls for access logging. One-size-fits-all training checks a box but doesn’t reduce risk.
Building the Framework
Before drafting policies or selecting technology, you need a clear picture of what’s being governed. Start with a data inventory identifying every repository, database, and application that stores or processes information. For each system, document the location, format, and sensitivity of the data. The inventory shows which system is the authoritative source for each data element and exposes the redundant copies that create reconciliation problems. If customer address data lives in six different applications with no clear master, risk reports are only as good as whichever copy someone happened to pull.
Map data ownership to specific business units during this phase. Every data set needs one accountable owner. When a quality issue surfaces or someone requests access, there should be no ambiguity about who approves the fix or grants permission. Ownership mapping also exposes political realities: two departments that both claim ownership of a shared data element need the governance council to resolve the dispute before implementation begins.
Document the existing IT architecture and create current data flow diagrams showing how information moves between applications and where manual interventions occur. If diagrams are outdated, technical teams should interview system administrators to reconstruct the flows. Those diagrams identify the points where data is most vulnerable to corruption, duplication, or unauthorized access. Build the data dictionary and classification schema during preparation as well. The phase usually takes months, and cutting it short creates problems that compound later.
Implementation and Ongoing Oversight
With preparatory documentation complete, the finalized framework goes to the board of directors for formal approval. That step provides the institutional mandate needed to enforce standards across departments. After board endorsement, the bank issues a formal policy statement to all employees and begins the technical rollout.
Technical work starts with migrating metadata and data definitions into a centralized governance tool that serves as the single source of truth for the bank’s data standards. Employees use this tool to access the data dictionary, view lineage maps, and submit quality issues. Technical teams then deploy automated monitoring throughout the IT environment to track data quality in real time. Monitors flag values that fall outside established thresholds: missing fields, format violations, or values that break business rules defined in the dictionary.
Post-implementation oversight is where most frameworks either prove their value or quietly atrophy. Internal auditors should conduct periodic reviews of data sets and governance processes to verify that Stewards and Owners are fulfilling their responsibilities. The interagency guidelines require regular testing of key controls, with the frequency set by the bank’s risk assessment and the tests conducted or reviewed by parties independent of those who built the controls.4eCFR. 12 CFR Part 30 Appendix B – Interagency Guidelines Establishing Information Security Standards Audit findings feed back to the Data Governance Council and the board to drive continuous improvement.
The bank must also be able to demonstrate data integrity and governance maturity during federal examinations. The FDIC, OCC, and Federal Reserve all use a risk-focused examination approach that evaluates whether a bank’s data practices could threaten institutional stability or the Deposit Insurance Fund.6Federal Deposit Insurance Corporation. Risk-Focused, Forward-Looking Safety and Soundness Supervision Deficiencies identified during examinations can lead to formal enforcement actions, consent orders, or restrictions on business activities. Consistent documentation, regular audit cycles, and a governance council that actually meets and makes decisions are what separate banks that pass examinations smoothly from those that spend months remediating findings.