The Court Wasn’t Breached. Its Vendor Was. The Consequences Were the Same.

The distinction sounds reassuring.

The court’s network was not breached. Its systems were not compromised. Its security controls were not responsible.

The incident happened at a vendor.

But the information at risk still belonged to the court’s operational environment. The people potentially affected still interacted with the court system. The courts still had to investigate, communicate, assess exposure, and answer questions about what happened.

That is the uncomfortable reality of third-party cyber risk:

The breach can belong to the vendor while the consequences belong to you.

The Incident

Thomson Reuters disclosed last week that an unauthorized party obtained files associated with its C-Track court case-management platform, which is used by courts across multiple U.S. states, the U.S. Virgin Islands, and Canada.

The unauthorized access occurred in March 2026. Thomson Reuters detected suspicious activity on June 30 and subsequently determined that certain C-Track files had been obtained. Some affected court records contained names and other personal information. (⁠Reuters)

The incident illustrates the reach a technology provider can have across otherwise independent institutions.

Ohio provides a particularly useful example.

The Supreme Court of Ohio said it was notified by West Publishing Corporation, a Thomson Reuters subsidiary, on July 24. C-Track is used by 10 of Ohio’s 12 courts of appeals. On August 31, the vendor informed the court that the unauthorized access had occurred on the production platform hosting filing-system data for those appellate courts. (⁠Supreme Court of Ohio)

At the time of its September 2 disclosure, the Ohio court said it had not yet determined the extent to which personal information had been exposed or the identities of all affected individuals. (⁠Supreme Court of Ohio)

Nevada’s circumstances were different.

The Nevada judiciary said its investigation had found no evidence that Nevada’s individual C-Track environment had been accessed or compromised. Instead, the incident involved a separate vendor-owned system containing selected database backup files. No service disruption resulted. (⁠Nevada Judiciary)

That distinction matters technically.

From a governance perspective, however, another distinction matters more.

The incident originated outside the courts.

The accountability did not.

Third-Party Risk Does Not End at the Contract

Organizations have spent years building vendor-risk-management programs.

Vendors complete questionnaires. Contracts contain cybersecurity clauses. SOC reports are reviewed. Insurance requirements are established. Security certifications are requested.

Those controls are important.

But they can create a dangerous illusion: that once the vendor has been assessed and the contract signed, the cyber risk has somehow transferred with the service.

It has not.

The vendor may operate the technology.

The vendor may host the data.

The vendor may maintain the infrastructure.

The vendor may even be contractually responsible for securing it.

But the organization remains dependent upon the outcome.

That is why third-party cyber risk is fundamentally a governance problem rather than simply a procurement problem.

Accountability Follows the Dependency

Consider what happens after a material vendor incident.

Leadership must determine what information was involved.

Legal counsel must determine which notification obligations apply.

Security teams must understand how the incident occurred.

Privacy teams may need to determine whose information was affected.

Communications teams may need to explain the event publicly.

Executives may need to brief governing authorities.

Customers, citizens, regulators, insurers, auditors, or litigants may eventually ask what the organization knew about the vendor’s security posture before the incident occurred.

None of those responsibilities disappears because someone else’s network was compromised.

This produces an important governance principle:

Accountability follows the business dependency, not merely the technical boundary.

If an organization depends upon a third party to perform a material function, maintain important information, or operate critical infrastructure, the governance system must extend across that dependency.

The Assurance Problem

There is another issue buried inside third-party incidents that receives far less attention.

After the breach, the vendor will investigate.

The vendor will determine scope.

The vendor will implement remediation.

The vendor may engage forensic specialists.

The vendor may tell customers that the environment is secure.

But how much evidence does the customer receive?

That question matters.

A statement that remediation has been completed is not the same thing as evidence demonstrating what was remediated.

A statement that systems are secure is not the same thing as independent validation.

A statement that particular information was not accessed is only as defensible as the forensic evidence supporting it.

Third-party governance therefore requires more than a contractual right to be notified of an incident.

It requires an assurance architecture.

The lifecycle should look something like this:

Due Diligence → Data Entrustment → Continuous Assurance → Incident Notification → Evidence Access → Remediation Verification → Residual Risk

Each stage should have an owner.

Each material decision should have authority behind it.

And each assertion that affects the organization’s risk posture should have evidence capable of supporting it.

The Notification Gap Matters Too

The timeline deserves attention.

The unauthorized access occurred in March.

Thomson Reuters detected the activity on June 30.

Ohio says it was notified July 24.

The broader public disclosures came September 2.

Those dates do not, by themselves, establish that anyone acted improperly. Complex forensic investigations take time, and determining which customers and records were affected can be difficult.

But the sequence exposes an important governance question:

What happens inside your organization while your vendor is still trying to determine what happened?

Vendor incident-response provisions frequently concentrate on notification deadlines.

That is necessary but insufficient.

Organizations should also understand what information the vendor must provide as the investigation develops, how frequently updates must occur, who has access to forensic findings, what evidence must be preserved, and what happens when the vendor cannot yet determine the scope.

The first notification may begin the governance process.

It rarely completes it.

What Leadership Often Misses

Third-party cyber governance frequently concentrates on the probability that a vendor will be breached.

Leadership should spend equal time considering the consequences if that happens.

Those are different questions.

A highly capable technology provider may still experience an incident. The governance objective is not to establish an impossible standard under which vendors never fail.

It is to ensure that the organization can remain informed, make decisions, obtain evidence, verify remediation, and manage residual risk when they do.

That means vendor governance should answer questions before an incident occurs:

Who owns the vendor relationship?

Who owns the associated cyber risk?

What data and operational dependencies exist?

What evidence of security performance is required?

What events trigger escalation?

How quickly must the vendor notify us?

What information must accompany that notification?

Do we have rights to relevant forensic findings?

Who determines whether remediation is sufficient?

Who has authority to accept continued residual risk?

And under what circumstances can we suspend or terminate the dependency?

If those questions are first being answered during the breach, the organization does not have mature third-party governance.

It has third-party paperwork.

Questions Every Executive Should Ask

1. Which vendors hold information or operate systems whose compromise could create a material consequence for us even if our own network remains untouched?
2. Can we map critical business services to the third parties, platforms, data stores, subcontractors, and cloud environments supporting them?
3. What evidence do we receive that critical vendors continue to operate required security controls after the initial assessment?
4. Do our contracts establish rights to timely incident information, forensic evidence, remediation details, and independent validation?
5. Who has authority to decide that a vendor’s remediation is sufficient for us to continue accepting the dependency?

Those are governance questions.

The answers cannot live exclusively in procurement.

Governance Takeaway

The Nevada judiciary made an important distinction in its public response: the incident did not originate in its networks or systems.

It also made an equally important governance statement.

While the incident originated outside its court systems, the judiciary said it holds itself and its vendors to a high standard of accountability. (⁠Nevada Judiciary)

That is the lesson.

Organizations should absolutely determine whose technology failed, where unauthorized access occurred, and which controls were involved.

But governance cannot stop at the technical boundary.

The more important questions are:

Whose information was entrusted?

Whose operations depended on the system?

Who must explain the consequences?

Who must determine whether remediation is sufficient?

Who ultimately accepts the remaining risk?

A vendor can operate your technology.

A vendor can store your information.

A vendor can suffer the breach.

But if the consequences return to your organization, so does the accountability.

You can outsource the system. You cannot outsource the governance.