TechCrunch reported on June 5, 2026 that a former IBM cybersecurity executive has accused IBM and a major telecom customer in an unsealed lawsuit of concealing multiple historical breaches tied to IBM networks, subsidiaries, and government-related systems. IBM told TechCrunch that the complaint was filed six years ago, that the U.S. Department of Justice declined to intervene, and that IBM is confident its actions followed the law.
The allegations are still allegations. For business owners, the practical lesson is not to decide the lawsuit from a headline. The lesson is that vendor security answers need proof, especially when the vendor manages infrastructure, cloud services, telecom access, healthcare data, financial systems, or sensitive customer records.
Why this matters beyond IBM
Most small and midsize organizations depend on outside providers. A managed IT provider may run backups and endpoint tools. A software vendor may hold client data. A telecom or cloud provider may control access to systems the business cannot inspect directly. When one of those providers says an incident was contained, not material, or not reportable, the owner is often asked to accept that answer without seeing much evidence.
That is a weak position. The FBI's 2018 APT 10 case described how attackers targeted managed service providers to reach customer environments indirectly. The SEC's cybersecurity disclosure rules also show how much attention regulators now place on incident scope, timing, impact, governance, and management oversight. Even when a smaller private company is not subject to public-company disclosure rules, those same concepts are useful for vendor management.
The business decision
The decision for an owner is whether to renew, approve, or trust a vendor relationship without documented incident-response expectations. A vendor's reputation is not a control. A contract, evidence trail, logging standard, notification timeline, and escalation path are controls.
Before approving a renewal or accepting a security explanation, owners should ask whether the vendor can show how it would prove what happened. That includes what systems were reviewed, what logs were available, who performed the investigation, whether customer data was involved, who made the disclosure decision, and what the business would receive if the incident affected its data or operations.
Questions to ask your IT provider or vendor
- What incident notice do we receive? Ask how quickly the vendor must notify your business after a suspected or confirmed incident, and whether the timeline is written into the contract.
- What evidence supports your conclusion? If a vendor says an incident is contained or did not affect your data, ask what logs, forensic review, or third-party assessment supports that statement.
- How long are logs retained? If logs are missing or retained for only a short period, the vendor may not be able to prove who accessed what.
- Who decides whether an incident is reportable? Clarify whether legal, security, executive leadership, or a third-party investigator makes that call.
- What customer systems or data are in scope? Make sure the vendor can identify which accounts, tenants, applications, networks, or data sets connect to your business.
- What happens if a subcontractor is involved? Many services rely on downstream providers. Ask whether the same notice and evidence obligations apply to them.
A practical next step
Pick your three most important technology vendors and review the incident language in each agreement. Look for notice timing, logging expectations, audit rights, subcontractor language, breach support, data-return terms, and who pays for response work if the vendor is at fault.
If those terms are missing or vague, ask for a written addendum before the next renewal. This is not about treating every vendor as untrustworthy. It is about making sure that when something goes wrong, your business is not left with only a verbal assurance and no usable record.
Sources and further reading