The FBI says the breach of its systems, which reportedly exposed data on thousands of employees, traces back to a contractor who "failed to implement a security patch explicitly issued to secure the platform." The fix existed. It was not installed. For a small or mid-sized business, the lesson is not really about the FBI. It is about the gap between "our IT provider handles patching" and a written patch SLA that says how fast, for which systems, and how you will know.

A patch SLA (service level agreement) is the part of your IT contract that sets deadlines for installing security fixes and requires proof that they were installed. Most SMBs in the US and Canada have a contract with their provider. Far fewer have one that answers those three questions.

What Happened in the FBI Breach?

On October 6, 2026, FBI cyber chief Brett Leatherman said the bureau's review had found the incident was "the result of a security failure of a platform managed by a third-party organization," after a contractor failed to apply an available patch, and that the FBI had removed the contractor. His statement was reported by Nextgov/FCW and SecurityWeek.

What else has been reported, each attributed:

  • The claim: The cybercrime group ShinyHunters announced on September 22 that it had hacked FBI systems through the agency's jobs website, SecurityWeek reported.
  • The platform and the contractor: Reuters, citing people familiar with the matter, reported that the system was Oracle's PeopleSoft human resources platform and the contractor worked for Accenture. The FBI has not publicly named either. Accenture said it was "proud to support the mission of the FBI and will continue to do so."
  • The data: Nextgov/FCW reported that the stolen data included employees' addresses, phone numbers and information on their spouses.
  • What is still unknown: Nextgov/FCW noted that the FBI's remarks do not address why the patch was missed or how the bureau monitored the contractor's work.

Which patch was missed has not been confirmed. The likely candidate is well documented. On June 10, 2026, Oracle issued a security alert for CVE-2026-35273, a flaw in PeopleSoft PeopleTools 8.61 and 8.62 that can be exploited remotely without a login and may allow remote code execution. Oracle rated it 9.8 out of 10 and recommended immediate action. In late September, Google's Mandiant reported that ShinyHunters had resumed exploiting it, according to The Record. SC Media noted that it was unclear whether the FBI attack was related to the techniques Google described.

Who Was Actually at Risk?

Directly, organizations running unpatched PeopleSoft PeopleTools 8.61 or 8.62. Mandiant said the renewed campaign deployed web shells on dozens of systems in higher education, technology, IT services, healthcare, agriculture, transportation and government, The Record reported. Most small businesses do not run PeopleSoft.

Indirectly, almost everyone. Nearly every SMB has systems that someone else patches: the firewall, the VPN, a line-of-business application, a hosted server, a vendor-managed appliance. The FBI case is a clear example of what happens when the person responsible for a patch does not apply it and nobody else checks.

Why Is a Missed Patch a Contract Problem?

Because the accountability stays with you even when the work does not. The Canadian Centre for Cyber Security's patching guidance (ITSM.10.096) says that even when using cloud or managed services, "your organization is still legally responsible and accountable for securing its data." The same guidance says to ensure patch management requirements and emergency patching are included in your service agreements.

The PeopleSoft campaign adds a second lesson. Mandiant said ShinyHunters "adapted to published defensive guidance," targeting organizations that applied the recommended workarounds but did not install the patch, according to The Record. A workaround bought time. It did not close the hole. The Cyber Centre's guidance makes the same point: workarounds are not a permanent solution, and once a patch is available it should be applied as soon as possible.

Small businesses rarely get to rewrite a provider's paper. As our look at third-party vendor risk notes, SMBs typically accept standard terms without much negotiating power. A patch SLA is one of the few clauses worth asking for anyway, because it is specific, measurable and cheap for a competent provider to agree to.

What Should a Patch SLA Include?

Five things: deadlines by severity, a defined start to the clock, a written exception process, evidence, and escalation. Two public benchmarks help set the deadlines. The Cyber Centre's ITSM.10.096 recommends patching extreme-risk vulnerabilities within 48 hours, high-risk within two weeks, medium-risk at the next major update or within three months, and low-risk at the next major update or within one year.

In the US, CISA's Binding Operational Directive 26-04, issued June 10, 2026, sets deadlines for federal civilian agencies based on whether a system is publicly exposed, whether the flaw is on CISA's Known Exploited Vulnerabilities (KEV) catalog, whether exploitation can be automated, and how much control an attacker gains. The shortest timeline is three days, with a forensic check for signs of compromise when the flaw is known to be exploited and gives total control. The directive binds federal agencies, not private businesses, but it is a useful model.

A reasonable starting point for many SMBs, drawn from those two benchmarks:

  1. Emergency: internet-facing systems with a flaw on the KEV catalog or flagged by the vendor as exploited. Patch within 48 to 72 hours, or take the system off the internet until you can, then check for signs of compromise.
  2. Critical and high: everything else rated critical or high. Within 14 days.
  3. Medium: within 90 days, or the next scheduled update if sooner.
  4. Low: the next scheduled update.

Then put the mechanics in writing:

  • Scope: a list of every system covered, including cloud services and vendor-managed appliances, with a named owner for each. If a system is patched by a software vendor instead of your IT provider, the contract should say so.
  • When the clock starts: the vendor's release or the KEV listing, whichever comes first. BOD 26-04 starts the clock when CISA adds a flaw to the catalog.
  • Exceptions: when a patch cannot be applied, a written exception with the workaround used, who approved it and the date it expires.
  • Evidence: a regular report with version numbers or scan results, not just a statement that systems are patched. Monthly or quarterly reporting on patching status is standard practice, as our guide to evaluating a managed IT provider explains.
  • Escalation: a commitment to tell you, before the deadline passes, when a patch will be late and why. Our guide to what to check in a managed security provider covers the related contract terms, including turnaround times and escalation steps.

How Fast Is Fast Enough in 2026?

For internet-facing systems, faster than a monthly cycle. Exploit-intelligence data suggests the time from vulnerability disclosure to working exploit has dropped to roughly 10 hours, as we covered in our analysis of the shrinking CVE-to-exploit window. The PeopleSoft flaw is a second data point: Oracle shipped the fix on June 10, and according to SC Media, ShinyHunters was exploiting unpatched systems again by late September.

Speed is only half of it. The FBI case suggests the harder problem is verification. A patch that is "scheduled," "in progress" or "handled by the vendor" protects nothing until someone confirms it is installed.

Questions to Ask Your IT Provider This Week

  1. Can you show me our patch deadlines in writing? If there are none, that is the first thing to fix.
  2. Which of our systems face the internet, and when was each last patched? You want a list with dates, not a reassurance.
  3. Which systems do you not patch, and who does? Vendor-managed appliances, line-of-business software and cloud services are where ownership gets fuzzy.
  4. When a fix cannot be applied, what is the workaround, and when does it expire?
  5. How will I know a critical patch was installed? Ask what the evidence looks like and how often you will see it.

The Durable Lesson

You can outsource the work of patching. You cannot outsource the accountability. The FBI, with more resources than any small business, still ended up explaining a missed patch after the fact. The one question to put to your IT lead or provider this week: "If a critical patch were released today, when would it be installed on our internet-facing systems, and how would I know?"

If you are not sure how your business would answer, start with our free quick security assessment. It takes under five minutes and shows which of 22 security areas need attention first.


This article is intended for general informational purposes only and does not constitute professional security, legal, or compliance advice. Details about the FBI breach, the contractor and the PeopleSoft vulnerability are based on public statements and reporting as of October 10, 2026, and may change as the investigation continues. Patch deadlines described here are general benchmarks, not contractual or regulatory requirements for any specific business. Organizations should consult qualified cybersecurity professionals before making operational or contractual changes based on this article.