What Changed
Thomson Reuters disclosed a breach of its C-Track court case management platform on June 30, after unauthorized access persisted from March through June. The incident exposed sealed court information and personal data across at least 12 U.S. states, the U.S. Virgin Islands, and Canadian courts. Court administrators in Montana learned of the breach 23 days after Thomson Reuters discovered it, and Ontario officials received notification on the same delayed timeline.
This breach illustrates a recurring issue: your third-party vendor discovers unauthorized access, investigates internally for weeks, then notifies you almost a month later. By then, sealed case files, Social Security numbers, driver's license numbers, medical information, and health insurance details have been accessible to an attacker for months.
Key Findings
Detection lag exceeded 90 days. Thomson Reuters discovered the breach on June 30, but the investigation found unauthorized access began in March. Montana's Supreme Court stated the access continued through June, meaning the attacker operated undetected in court systems for at least three months. Your vendor contract likely includes security commitments, but those commitments don't guarantee real-time visibility into their environment.
Notification delay compounded the exposure window. Thomson Reuters waited until July 23 to notify Montana's court administrator and Ontario's Ministry of the Attorney General. This 23-day gap between discovery and notification leaves court systems unable to assess their own risk posture, notify affected individuals under applicable breach notification laws, or implement compensating controls. If you're subject to the 72-Hour Notification Requirement under the General Data Protection Regulation or similar state-level breach notification statutes, your vendor's internal investigation timeline doesn't pause your legal clock.
Sealed information lost its protected status. The breach potentially exposed confidential, redacted, or sealed court information. Nevada officials noted that the type of data involved varies by jurisdiction, which means your vendor may not have consistent data classification controls across different client environments. Montana officials said most affected information appeared to be publicly available, but "most" isn't "all." When sealed information becomes unsealed through a breach, you can't retroactively restore its confidentiality.
No attribution, no root cause, no affected count. Thomson Reuters has not disclosed how the attacker gained access, who was responsible, or how many individuals were affected. The company added "new security measures" and said outside experts reviewed those changes, but didn't identify the experts or specify what controls failed. Without root cause transparency, you're left guessing whether the same vulnerability exists in other vendor environments you rely on.
Your vendor's incident didn't disrupt their service. Thomson Reuters emphasized that C-Track remained fully operational throughout the breach. From a vendor's perspective, this demonstrates resilience. From a risk management perspective, it means the breach didn't trigger any service-level alarms that might have accelerated detection. Your uptime monitoring won't catch a data exfiltration event.
What This Means for Your Team
You don't control your vendor's security program, but you own the risk they introduce to your organization. If you're managing judicial systems, healthcare providers, financial institutions, or any entity handling sensitive personal data through third-party platforms, this incident reveals three control gaps worth auditing immediately.
First, your vendor assessment process likely evaluates point-in-time security posture through questionnaires, certifications like SOC 2 Type II, or ISO/IEC 27001 attestations. Those assessments don't tell you whether your vendor can detect unauthorized access within days instead of months. The NIST Cybersecurity Framework (CSF) 2.0 Detect function calls for continuous monitoring and anomaly detection, but your vendor contract probably doesn't specify detection timeframes or require evidence of monitoring effectiveness.
Second, your incident response plan probably assumes your vendor will notify you promptly when they discover a breach affecting your data. The 23-day notification gap in this case suggests you need contractual notification requirements with specific hour-based SLAs, not "reasonable time" language. NIST SP 800-53 control IR-6 (Incident Reporting) requires organizations to report incidents to designated officials, but if your vendor contract doesn't mirror that requirement with penalties for delays, you're relying on goodwill.
Third, you likely lack visibility into how your vendor segments data across different clients. If your vendor stores sealed court records from multiple jurisdictions in shared infrastructure without strict logical separation, a breach in one environment can expose data across many clients. ISO/IEC 27002 control 5.23 addresses information security in cloud services, but implementation varies. Your vendor's architecture documentation should show you exactly how your sensitive data is isolated from other tenants.
Action Items by Priority
Immediate (this week): Pull your vendor contracts for any third party that stores, processes, or transmits sensitive personal data. Search for breach notification language. If the contract says "prompt" or "timely" notification without defining hours or days, you have no enforceable standard. Draft amendment language requiring notification within 24 hours of discovery, not 24 hours of completing an investigation.
Within 30 days: Request evidence of your critical vendors' continuous monitoring capabilities. Ask for documentation showing their detection and response times for the last 12 months. Specifically request: mean time to detect (MTTD) for unauthorized access events, evidence of security information and event management (SIEM) coverage across systems handling your data, and results from their most recent penetration test or red team exercise. If they can't provide this evidence, escalate that vendor to high-risk status in your third-party risk register.
Within 90 days: Conduct a tabletop exercise simulating a vendor breach notification. Assume you receive notification 23 days after the vendor discovered the breach, and the breach window extends back three months before discovery. Walk through your legal obligations, notification requirements to affected individuals, regulatory reporting timelines, and public disclosure decisions. Identify gaps in your incident response plan that assume faster vendor notification. Update IR-6 procedures to account for delayed vendor notifications.
Ongoing: Implement quarterly vendor security reviews for any third party handling data subject to breach notification laws. Reviews should include: evidence of intrusion detection system alerts and response actions, confirmation that your data classification requirements match the vendor's implemented controls, and verification that the vendor maintains cyber insurance with coverage limits appropriate to your potential exposure. Document these reviews as evidence of your due diligence under the NIST Risk Management Framework Categorize step.
