Risk registers accumulate items. Most organisations have a process for adding items to a risk register, a cadence for reviewing them, and a framework for scoring them. What they often lack is a clear rule for what happens when a scored risk is not acted on — when it sits in the register at a known severity level, week after week, as the organisation continues to operate the system it describes.
The Equifax breach of 2017 is the most consequential documented case of that gap. The Apache Struts vulnerability CVE-2017-5638 was disclosed publicly on 7 March 2017 and a patch was made available the same day. Equifax's internal scan on 15 March 2017 identified the vulnerability in their systems. The breach began on 13 May 2017. The vulnerability was in the register. The register did not drive remediation.
For enterprise AI teams, the Equifax case is not primarily a cybersecurity lesson. It is a governance lesson about what a risk register is and is not. It is not a risk management system. It is an inventory. The risk management system is the set of processes that turn items in the inventory into decisions with owners, timelines, and consequences for non-compliance. Without that system, the register grows, the risk does not reduce, and the accountability for non-action belongs to everyone and therefore to no one.
What the FTC consent order established
The FTC's 2019 consent order with Equifax, which included a settlement of up to $700 million, established several findings relevant to any organisation operating AI systems that process personal data. The most significant for governance purposes: Equifax had knowledge of the vulnerability, had the means to remediate it, and did not remediate it in a timeframe that was proportionate to the risk it represented.
The consent order required Equifax to implement a comprehensive information security programme with specific structural requirements — not a stronger risk register, but a programme with named accountability, mandatory remediation timelines, and independent verification that remediation had occurred. The FTC's finding was not that Equifax lacked risk awareness. It was that risk awareness without a remediation obligation is not a control.
"Equifax failed to implement a process to ensure that security patches were applied to its systems in a timely manner. Despite having identified the vulnerability and having access to a patch, Equifax failed to patch the affected system. This failure allowed attackers to access Equifax's network for approximately 78 days before the intrusion was detected."
The EU AI Act's Article 9 applies the same logic to AI systems. It requires not just that risks be identified, but that risk management measures be implemented — meaning that identified risks must produce actions, not just entries in a register. An AI system with a documented known risk that has not been structurally mitigated is not a system with a risk management programme. It is a system with a risk list.
Why AI systems are especially exposed to this pattern
AI systems create a specific variant of the Equifax backlog problem. The risk register for a deployed AI system is populated continuously: new bias findings from fairness audits, new failure modes identified in production monitoring, new regulatory guidance that creates compliance gaps, new data quality issues surfaced by upstream changes. Each item is scored. Many are not acted on within any defined timeframe.
The reason is structural. Remediating a known issue in a deployed AI system is more costly and disruptive than remediating a software vulnerability. Retraining a model, updating a feature pipeline, or revising a risk management measure requires coordination across multiple teams and often requires taking the system offline or running parallel versions. The friction is real. But the friction of remediation is not a justification for non-remediation — and under Article 9, it is not a defence.
The specific addition Article 9 requires
The addition is not a different risk scoring framework. It is two fields that must accompany every item in the register: a named individual who is accountable for remediating the risk by a defined date, and a verification step that confirms the remediation has been implemented before the item is closed.
Without the named owner, the risk belongs to everyone and therefore to no one. Without the deadline, the risk is acknowledged but not scheduled for action. Without verification, the remediation is assumed rather than confirmed. All three conditions were absent from Equifax's patch management process for CVE-2017-5638. All three conditions are absent from most enterprise AI risk registers today.
For every item currently in your AI system's risk register that has been open for more than 30 days without a named owner and a remediation deadline, add three fields this week:
Owner: the named individual accountable for remediation — not the team, not the function, one person.
Deadline: a specific date by which the remediation will be implemented, proportionate to the severity of the risk.
Verification: the evidence that will confirm the remediation has been implemented — not "owner confirms", but an independent check.
A risk register item without all three fields is an item that describes a risk you know about and have not decided to act on. The FTC's consent order is precise about what that constitutes under data protection law. Article 9 of the EU AI Act is equally precise about what it constitutes for AI systems. In both cases, the answer is the same: awareness without action is not risk management. It is documented negligence.