The Uncomfortable Truth About Third-Party Data Governance
Banks outsource. That's not a surprise. What is a surprise to examiners, to risk committees, and sometimes to the banks themselves, is how many governance obligations travel with that outsourcing and never arrive at the destination.
When a Tier 2 bank contracts a third-party data provider, a loan servicing vendor, or a cloud-based analytics platform, it doesn't contract away regulatory responsibility. OCC Bulletin 2013-29 was explicit: the bank is accountable for the risk, regardless of who performs the function. FDIC guidance echoes this. The FFIEC Outsourcing Handbook dedicates entire chapters to it.
Yet walk into most banks' vendor management programs and you'll find: signed contracts, periodic SLA reviews, and annual questionnaires. What you won't find is anyone certifying that the vendor's data governance meets the bank's own standards.
Why It Matters
Third-party data isn't "other data." It feeds your risk models, populates your regulatory reports, and supports the decisions your executives make. If a vendor's data lineage is opaque, your lineage is opaque. If a vendor can't demonstrate data quality controls, you can't demonstrate data quality controls. The examiner doesn't care whose system the data lived in. They care whether you can prove it's right.
In Tier 2 banks, this cuts particularly deep. You're working with fewer resources and leaning harder on vendors to fill capability gaps. That means more third-party dependencies and less internal capacity to monitor them. The math doesn't work in your favor.
The Wrong Approach
The standard response to vendor governance risk is the questionnaire. Send a long form once a year. The vendor fills it out. Someone reviews it. File it.
Questionnaires are compliance artifacts, not governance. They capture a snapshot. They rely on self-reporting. They don't certify continuous compliance. And they create a false sense of assurance; the checkbox is checked, so the risk is managed.
Another common mistake: treating vendor risk as a procurement concern. Procurement negotiates the contract. Risk signs off on the SLA. Nobody certifies the data.
The Right Approach
Treat vendor data governance the same way you treat your own, because regulators already do.
First, extend your critical data element framework to vendor-sourced data. If a vendor provides data that feeds your regulatory reporting, that data is critical. Full stop. It needs the same ownership, certification, and lineage standards as anything you produce internally.
Second, require vendors to demonstrate, not assert, governance. That means certifications, not questionnaires. Evidence of data quality controls, not promises. Audit trails, not descriptions. If a vendor can't provide this, that's a finding, not a forgivable gap.
Third, build vendor data governance into your examination readiness. When examiners ask to see your data lineage for a risk data element, "our vendor handles that" is not an acceptable answer. "Here's how our vendor certifies it, and here's how we validate their certification" is.
The CoComply Angle
CoComply's certification framework doesn't stop at your organizational boundary. When a data element is certified, the certification captures the full chain of custody, including who produced it, whether that's internal or a vendor. If the vendor can't provide evidence that meets your certification standard, the element can't be fully certified. That gap is visible. That visibility forces the conversation.
It also creates a shared language. When you tell a vendor "we need this data element to meet our certification standard," you're not making a custom request. You're applying a consistent framework. Vendors either meet the standard or they don't. That clarity is worth more than any questionnaire.
The Test
Pick your top three data vendors. Ask: "Can we produce, right now, a certified data lineage from the vendor's source system to our regulatory reporting output?" If you can't, your vendor governance isn't governing. It's filing.