Every obligation needs a path to the ground.
The governance chain traces a regulation through eight links: policy, risk, failure scenario, weakness, controls, indicators, and the evidence that proves it all works. When a major failure makes the news, the chain shows which link gave way and what would have held.
Eight links, one line of sight
Each link answers one question. Skip a link and the chain still looks complete on paper, but nobody can show how a rule turns into proof. Select a link to see what it holds and how it usually fails.
A line on the page, a graph underneath
Drawn as a line, the chain is one path through a network. One control usually serves many obligations, and one obligation needs several controls. Store every link as a node and every mapping as a connection, and the chain becomes something you can query: which rules depend on this control, which obligations have no evidence, what breaks if this vendor fails.
Grey lines are the full set of mappings. The highlighted route is one chain read from rule to proof.
Explore the case library as a graph
It is a loop, not a ladder
A red indicator, a failed test or an audit finding goes back up the chain as a new or reopened control weakness, with an owner and a due date, until the control is fixed and the evidence shows it. Most failures in the case library happened in that loop: the warning was seen and nothing came back up.
How this differs from what you already have
- Risk and control self-assessment
- Starts from business processes and rates risks and controls. It rarely traces back to the specific rule or forward to evidence an examiner would accept.
- Obligations register
- Lists rules and owners. It usually stops once a rule is mapped to a policy.
- Issues log
- Tracks findings and remediation, but often without the link to the obligation or the indicator that should have caught the problem.
- The governance chain
- Connects all three in one structure, from obligation to evidence and back through the loop, so any link can be traced in both directions and every gap shows up as a missing connection.
Real failures, link by link
Each case maps a well-documented public event through all eight links using enforcement orders, investigations, and the firms' own disclosures. Red marks the links that broke. New events are added as they happen.
Where chains break
A caution on reading this chart: breaks are assigned after the fact from public records, which are mostly written by regulators, courts and investigators. Those sources rarely fault the rules themselves, so a low count at the regulation link says as much about the sources as about the rules.
The bar on each row is the chain from regulation (left) to evidence (right). Red segments are the links that failed.
The cases as a graph
No failure is unique. Each case shares common threads with others: the same control themes, the same rules, the same risk areas. This picture draws those threads, so you can see which weak spots keep coming back.
- 1Each small grey dot is one case.
- 2Each larger shape is a common thread that several cases share.
- 3Click or tap either one to see what it connects to.
Show as a table
Risk areas and the control themes behind them
Each number is how many cases share that risk area and that control theme. Darker cells are the control themes that keep coming up for a risk area. Select a number to see the cases.
Each case is tagged from its public record: the rules cited, the control themes behind the weakness and the controls that would have held, and the authorities and courts named in the outcome. A thread appears only when at least one case connects to it.
Stress-test the chain
Pick a case to load the chain as it stood when the event hit, or build your own. Strengthen or weaken any link, then run a thousand simulated events to see how often the chain holds, how fast trouble is caught, and where your next dollar of control spend would do the most.
Set up the chain
Results
Run the simulation to see how this chain performs.
How the method works
The chain is a way of reading any risk program the way an examiner will: from the outside rule inward to the proof.
Most control environments are built bottom-up. Teams inherit controls, write procedures around them, and map them to regulations afterward. The result is coverage that looks complete in a spreadsheet and comes apart under a single hard question: show me how this rule is met.
The governance chain runs the other way. It starts with the obligation and refuses to move on until each link names something specific. A policy that meets the rule. A place in the risk taxonomy that gives it an owner. A concrete loss event. The weakness that would let it happen. The controls aimed at that weakness. An indicator that warns before the control fails. Evidence that a third party could check.
Read across enough failures and a pattern shows up. Chains break in the middle and lower links: weaknesses that were known and tolerated, controls that existed on paper, indicators that were red for months with no one obliged to act. That reading has a limit worth stating. Each break is assigned with hindsight, from records written after the event, mostly by the people who enforce the rules.
The chain is drawn as a line for clarity, but in practice it is a graph. Obligations, policies, controls, indicators and evidence connect many to many, and each chain is one path through them. Held that way, the structure can be queried and kept current as rules and the business change, which is where knowledge graphs and ontologies come in.
It is also a loop. Indicators, tests and audits send findings back up as control weaknesses with owners and due dates. A chain that only runs downward documents controls; one that loops back improves them.
The stress test is a teaching model, not a forecast. Severity, speed, and the strength of each link are judgment calls informed by the public record, and the results show direction and relative effect rather than real dollar amounts.
Recent additions
Library last updated .