The Mailroom Nobody Mapped: What the Bankruptcy Court Outage Teaches Every Board
Federal bankruptcy courts across the country can't send out notices right now. The reason isn't a hack of the courts themselves. It's a cyber incident at a contractor that runs one piece of the plumbing.
On October 15, the Administrative Office of the U.S. Courts said all access to the Bankruptcy Noticing Center, and the websites BAE Systems operates for it, was unavailable. The Center produces and sends the official notices that tell creditors a bankruptcy case has been filed, when hearings are scheduled, and what deadlines apply. Production and distribution of those notices has stopped. BAE Systems told reporters it is "aware of a security incident that is isolated to the BNC system" and has taken immediate steps to address it.
As of this writing, neither the courts nor BAE has said what happened, when it began, or whether any data was taken.
A Small System With Outsized Consequences
It's easy to dismiss this as a government story. Don't. Look at how it is built.
The Noticing Center is not the court's case management system. It is a service function, closer to a mailroom than a vault. Yet when the mailroom stops, the legal process downstream starts to buckle. Cybernews reported that by Friday evening, bankruptcy courts in 18 states had posted disruption notices, with more appearing each hour. Alaska is postponing certain creditor meetings. The Southern District of New York is warning of delays to notices, orders, and access to creditor lists. Some courts are rescheduling hearings. Others have adopted temporary procedures.
The harm isn't confined to the courts. A creditor who doesn't receive a notice can miss a deadline. A business waiting on a hearing date can't plan. A vendor-run service like this one can quietly become a single point of failure for a national process, and few organizations ever make an explicit decision to accept that risk.
Your company has its own Noticing Center. It might be the vendor that prints your invoices, the platform that sends your customer notifications, or the service that processes your payroll. It's small, it's boring, and nobody has ever asked what happens to the business if it goes dark for two weeks.
The Three Questions, Applied to the Vendor Behind the Process
In Cyber Risk Is Business Risk, I argue that every board should be able to answer three questions. This incident is a clean test of each.
Can we get hit? Yes, and not only through our own systems. The question isn't whether your vendors are well defended. BAE Systems is one of the largest defense contractors in the world, and it was still the point of failure. The question is which of your business processes depend on a vendor you have never mapped. If your CISO can list your applications but not your operational dependencies, you are missing the part of the map where this kind of incident lives.
Would we know? Two days in, the public record is a short notice from the Administrative Office and a brief statement from BAE. Nothing on cause, timing, or data. Ask whether your contracts require a vendor to notify you within a defined window and share what it knows as it learns it, and whether you would hear about an outage from the vendor or from your own customers.
Are we ready? The courts are now improvising. Individual districts are issuing their own orders and workarounds. That is what an unrehearsed continuity plan looks like. For a company, the equivalent is asking whether you could run the process manually for ten days, who would decide how, and whether anyone has ever tried.
Compliance Is Not Resilience
Most vendor risk programs are built around questionnaires and certifications. A vendor attests to its controls, you file the attestation, and the box is checked. That is compliance. It tells you a vendor met a standard on a given day.
It does not tell you what your business does when that vendor stops. As I write in the book, a compliant organization can still be an unprepared one. The contractor involved here is a large, sophisticated defense firm, which is a reminder that vendor size is not a guarantee. The more useful discipline is asking about impact: what is the maximum outage we can tolerate for this service, and what is our plan when the vendor exceeds it?
Where Board Accountability Comes In
Directors are expected to make a good-faith effort to oversee the risks that could seriously harm the company. Operational dependencies on third parties sit squarely inside that duty. "The vendor had an incident" is an explanation. It is not a defense if the board never asked which vendors the business could not operate without.
There is a practical budget point here too. Resilience for a small, unglamorous service rarely wins funding against a flashy new initiative. A tested manual fallback costs far less than the cost of a stalled process, but it only gets approved if someone connects the two in a board-level conversation.
What to Ask Your CISO This Week
- Show me our top ten operational dependencies on outside vendors, ranked by how quickly the business degrades if they go offline. Not the list of vendors by spend. The list by consequence.
- For each, what is our tolerable outage window, and have we ever tested running without the service? A plan that has never been exercised is a hope.
- What does each contract require of the vendor when it has a security incident? Look for notification timelines, cooperation obligations, and the right to information while an investigation is underway. Today's story is a reminder that early facts can be thin.
- Who owns the decision to switch to manual operations, and what triggers it? If the answer is "we'd figure it out," you have your answer.
The Takeaway
The most important detail in this story is one we don't yet have: what happened inside BAE's environment. That will come out, or it won't. What we already know is enough. A single contractor incident, scoped by the contractor to one system, stopped a national legal process and sent courts in a growing number of states scrambling.
Your business has a version of that system. Find it before an incident does.