This site uses essential browser storage to remember this choice. Optional Vercel Web Analytics, when enabled, helps understand which pages are useful. Choose whether to allow optional analytics.
Lineage used to be a governance nicety. In 2026 it is the evidence three separate regimes ask for: BCBS 239, the UK operational resilience framework, and the EU and UK third-party reporting rules. Here is how to capture it once and answer all three.
In brief: three regimes now ask, in different words, for the same thing: a maintained record of which data, systems and third parties sit beneath each number and each service. Capture lineage once, at the grain a control needs, for a capped list of elements and services, and the same record answers the supervisor, the resilience assessment and the third-party register.
For a long time data lineage was the part of governance that everyone agreed was important and nobody funded. It sat in the catalogue business case as a feature, was demonstrated on a handful of pipelines, and was quietly reconstructed by hand every time a regulator or an auditor asked how a number was produced.
That posture is no longer defensible, because lineage has stopped being a governance nicety and become the common evidence base for three regimes that boards are now accountable under.
Three regimes, one record
The Basel Committee's January 2026 newsletter on BCBS 239 named data lineage and traceability first among the areas where supervisors still see gaps, more than a decade after the principles were published and three years after its 2023 assessment found only two of thirty-one global systemically important banks fully compliant. Supervisors want to see how a risk figure travels from source to report, and they want to see it without a project.
The UK operational resilience framework, fully in force since 31 March 2025, asks firms to map the resources that support each important business service, including the data, systems and third parties, and to set impact tolerances for disruption. The map is lineage seen from the service end rather than the data end.
The third-party reporting rules close the triangle. The EU's DORA register of information already requires firms to record the ICT assets, applications and databases associated with each service, and the sub-outsourcing chains beneath them. The PRA's PS7/26 and FCA's PS26/2, published on 18 March 2026 and aligned with DORA, bring an equivalent material third-party reporting regime to the UK, with the FCA rules taking effect on 18 March 2027. The July 2026 designation of the four major cloud providers as Critical Third Parties gives supervisors a direct view of the concentration those registers reveal.
Regime
The question it asks
The lineage it needs
BCBS 239
How was this risk figure produced, and can it be re-cut under stress?
Data-to-report lineage for each Critical Data Element
Operational resilience (SS1/21, PS21/3)
What supports this important business service, and how long can it be lost?
Service-to-resource mapping with impact tolerances
Third-party reporting (DORA, PS7/26, PS26/2)
Which providers and ICT assets sit beneath each service, and who sits beneath them?
Service-to-provider lineage including sub-outsourcing
Read across the rows and the pattern is obvious. Each regime asks for a slice of the same graph: data elements, the systems that transform them, the services they support, and the third parties those systems run on. An organisation that captures the graph once can answer all three. An organisation that runs three programmes captures it three times, inconsistently, and gets found out when the answers disagree.
Capture it once, at the right grain
The failure mode in lineage programmes is grain. Column-level lineage across the whole estate is a research project that never finishes. Diagram-level lineage drawn for a programme board is not evidence. The grain that works is the grain the control needs, applied to a capped scope.
Three rules make it tractable. First, scope to the list: Critical Data Elements on one side, important business services on the other. If an element does not serve a material decision or obligation, and a service is not important, its lineage is optional. Second, capture transformation, not just flow. A supervisor asking how a number was produced wants the rules that changed it, not only the systems it passed through. Third, record the third party at the point of dependency. Every system node on the graph should carry the provider that runs it and the contract that governs it, so that the third-party register is a query rather than a survey.
Where automation helps and where it does not
Modern catalogues can harvest technical lineage from warehouses, pipelines and BI tools, and that harvest is worth having. It does not, on its own, produce a control. Automated lineage does not know which elements are critical, which services are important, or which transformation rule encodes a business decision. It also stops at the boundary of the systems it can parse, which is usually where the spreadsheet begins.
The working model is harvested lineage curated by named stewards: the tool draws the graph, the steward confirms which nodes matter and annotates the transformations a supervisor would ask about. The Basel Committee's own observation that AI adoption in risk data aggregation remains at an early stage is a warning against expecting a tool to do the curation.
The board test
A board can test whether lineage is a control with one question: pick a number in the pack, or a service on the important business services list, and ask for the graph beneath it by the end of the day. If the answer arrives as a maintained record showing data, transformations, systems and providers, the organisation has a resilience control. If it arrives next week as a diagram, it has a project.
Lineage is no longer the feature nobody funded. It is the evidence three regimes now expect to find, and the organisations that capture it once will spend the rest of the decade answering questions their peers are still reconstructing.
