Skip to main content
Third-Party Breach Fallout: Six Mistakes Courts Made With C-TrackBreach & Risk Assessment
6 min readFor Data Governance Teams

Third-Party Breach Fallout: Six Mistakes Courts Made With C-Track

When Thomson Reuters disclosed unauthorized access to its C-Track platform in June 2026, three months after the breach began, the incident exposed court records across at least 12 US states, the US Virgin Islands, and Canada. This raised a pressing question for your data governance team: if a vendor's cloud environment gets compromised, who owns the failure?

The answer isn't straightforward, which is why these mistakes keep occurring.

Why These Mistakes Keep Happening

Third-party risk management often suffers from a fundamental attribution error. Your team might treat vendor security as the vendor's problem until a breach notification arrives. By then, you're explaining to affected individuals why their sealed court records or Social Security numbers were exposed in someone else's cloud environment for months.

The C-Track incident shows what happens when governance teams confuse contractual liability with operational control. Thomson Reuters stated the breach "took place within its own (cloud) environment and was not caused by the networks, systems, or data security of the affected courts." Legally accurate, but operationally meaningless. The courts still lost custody of sensitive data they were obligated to protect.

Here's what went wrong and how to fix it before your vendor makes the news.

Mistake 1: Treating Vendor Security Questionnaires as Due Diligence

Why it happens: Your procurement process requires a security questionnaire. The vendor returns it with all the right checkmarks. You file it and move on.

The consequence: Thomson Reuters' customers learned about unauthorized access three months after it began. A questionnaire wouldn't have caught an active intrusion. It wouldn't have revealed detection gaps or shortened that window.

The fix: Replace annual questionnaires with continuous monitoring requirements. Your contract must mandate:

  • Real-time security event notifications within defined severity thresholds
  • Quarterly attestations from the vendor's security team, not their sales team
  • Access to third-party penetration test results and remediation timelines
  • Defined SLAs for breach detection and notification

Insist on evidence, not assertions. If the vendor processes high-risk data under GDPR Article 35 or handles protected health information, you're entitled to verify their controls match their claims.

Mistake 2: Accepting "The Incident Took Place in Our Environment" as Exculpatory

Why it happens: Vendors draft breach notifications to limit liability exposure. Courts and agencies read these statements and assume the vendor has contained the problem.

The consequence: Thomson Reuters correctly noted the breach didn't originate from court networks. But the affected courts still processed personal data through C-Track. Under GDPR Article 28, they remain controllers. Under state breach notification laws, they bear notification obligations. The vendor's statement doesn't transfer your accountability.

The fix: Your data processing agreement must define breach notification content requirements. Specifically:

  • Root cause analysis within 72 hours of discovery
  • Detailed timeline of unauthorized access, not just discovery date
  • Specific data categories and record counts affected per jurisdiction
  • Remediation steps taken and residual risk assessment

The C-Track notification left courts unable to tell affected individuals "exactly what information was compromised or how many people were affected." That's a contractual failure, not just a vendor failure.

Mistake 3: Discovering Scope Through Public Disclosures

Why it happens: Vendors investigate breaches internally, then release a single notification covering all affected customers. Individual organizations learn their exposure by reading the vendor's website.

The consequence: The Oregon Judicial Department confirmed its appellate courts were affected after Thomson Reuters published its disclosure. Courts shouldn't learn about their data exposure from a vendor's public statement. That sequence inverts the notification chain required under most breach laws and destroys your ability to conduct prior consultation with supervisory authorities under GDPR Article 36.

The fix: Your processing agreement must require individualized, private notification before any public disclosure. The contract should specify:

  • Vendor must notify you within 24 hours of confirming your data was accessed
  • Notification must include your specific record counts and data categories
  • You retain approval rights over public disclosure timing and content
  • Vendor provides a dedicated incident response contact, not a general inbox

If the vendor resists these terms, they're telling you they'll prioritize their disclosure timeline over your regulatory obligations.

Mistake 4: Assuming Cloud Environments Mean Better Detection

Why it happens: Cloud providers market advanced threat detection and security monitoring. Your team assumes the vendor inherits these capabilities automatically.

The consequence: The C-Track breach went undetected from March through June 2026. Cloud environments offer security tools, but vendors must configure, monitor, and act on them. Thomson Reuters' statement that "additional security measures that were reviewed and approved by outside experts have been added" suggests those measures weren't in place during the breach window.

The fix: Your Technical and Organisational Measures audit must verify:

  • Security Information and Event Management (SIEM) configuration and alert thresholds
  • Mean time to detect (MTTD) and mean time to respond (MTTR) metrics from the past 12 months
  • Incident response playbook specifically for your data categories
  • Log retention periods that support forensic investigation

Request evidence of recent tabletop exercises. If the vendor can't demonstrate they've practiced detecting and containing a breach, they won't do it competently when it matters.

Mistake 5: Relying on Post-Breach Credit Monitoring as Adequate Remediation

Why it happens: Offering 12 months of credit monitoring has become standard breach response. It signals the vendor is "doing something" for affected individuals.

The consequence: Credit monitoring doesn't address the exposure of sealed court records, medical information, or confidential case details. It's a remedy for identity theft risk, not privacy harm. For court systems, the exposure of sealed or redacted information creates risks credit monitoring can't mitigate.

The fix: Your processing agreement must define remediation requirements based on actual data sensitivity:

  • For sealed or confidential records: Vendor funds legal review to determine re-sealing or expungement needs
  • For medical information: Vendor coordinates with affected individuals' healthcare providers for fraud monitoring
  • For all categories: Vendor provides detailed exposure analysis so individuals can make informed decisions

Generic credit monitoring is a vendor's cost-containment strategy, not a governance strategy.

Mistake 6: Treating Vendor Breaches as Isolated Incidents

Why it happens: After a vendor breach, your team focuses on immediate response: notifications, call centers, monitoring enrollment. Once that's complete, you return to normal operations.

The consequence: You miss the systemic lesson. If one vendor's cloud environment got compromised, your other vendors face similar risks. The C-Track breach should trigger a portfolio-wide review, not just a C-Track remediation.

The fix: Use every vendor breach as a stress test for your entire third-party ecosystem:

  • Identify all vendors processing similar data categories
  • Compare their contractual breach notification terms against the failures you just experienced
  • Update your vendor risk assessment criteria based on what you learned
  • Conduct tabletop exercises simulating simultaneous breaches across multiple vendors

The courts affected by C-Track likely use other third-party case management, e-filing, or document management systems. Each one represents similar custody risk.

Prevention Checklist

Before you sign your next vendor contract:

  • Contract requires breach notification within 24 hours of vendor's discovery
  • Vendor must provide root cause analysis within 72 hours
  • You retain approval rights over public disclosure content and timing
  • Contract specifies MTTD and MTTR performance requirements
  • Vendor provides quarterly security attestations with supporting evidence
  • You have audit rights to verify security controls, not just review questionnaires
  • Processing agreement defines remediation requirements by data sensitivity level
  • Contract requires individualized notification with your specific record counts
  • Vendor must demonstrate incident response capabilities during procurement
  • You've mapped all vendors processing similar data categories for portfolio risk review

The C-Track breach exposed a governance gap that contracts should have closed. Your vendor's cloud environment isn't your problem until it becomes your notification obligation. Close the gap before you're the one explaining a three-month detection window to affected individuals.

You Might Also Like