The Thomson Reuters C-Track breach shows why vendor backups are a blind spot

The data that leaked in the Thomson Reuters C-Track breach was not sitting in the live court case management system. It was sitting in backup copies that courts had handed to the vendor's support staff so the vendor could reproduce a bug, and those copies were still there months after the tickets that created them were closed.

That is the whole lesson, and it is the part most third-party risk programmes miss. Thomson Reuters' West Publishing unit has confirmed that an unauthorized party had access to data in Thomson Reuters' own cloud environment from March 1 to June 29, 2026, that it detected the activity on June 30, and that it went public on September 2. The Hacker News reported that the compromised material came from database backups courts supplied for application troubleshooting, citing a statement from the Montana Supreme Court. Thomson Reuters has said the incident happened inside its environment and "was not caused by the networks, systems or data security of the affected courts," according to The Record.

If you are an IT manager or security lead at a mid-sized company, you probably have no C-Track deployment and no court records. You almost certainly have the same exposure. Somewhere in a vendor's cloud there is a copy of your database, or a chunk of it, that your support engineer exported eighteen months ago to help a vendor debug a sync failure. This page lays out what is confirmed about the C-Track incident, what is still unknown, and how to find your own version of that copy before someone else does.

C-Track is a court case management platform: the system a court clerk uses to record parties, dockets, filings and case status. It is sold by West Publishing Corporation, a Thomson Reuters unit.

When a court reports a defect that support cannot reproduce on a test dataset, the normal fix is for the court to send real data. That is the mechanism here. Courts supplied database copies to Thomson Reuters for troubleshooting, the copies lived in Thomson Reuters' cloud, and the intruder reached the copies. Thomson Reuters has repeatedly said there was "no operational disruption to C-Track as a result of this incident," and that is consistent with the rest of the picture: the platform kept running because the platform was not what was hit.

What was in those copies varies by court, and this is where the coverage diverges. National reporting lists names, addresses, Social Security numbers, driver's license numbers, dates of birth, medical and health insurance information, case numbers, docket entries and, at some courts, sealed, redacted or confidential filings. Montana's own review, reported by KPAX, was narrower: case numbers, party names, addresses and phone numbers, some driver's license numbers and some dates of birth mostly belonging to people charged with crimes, plus docket entry descriptions, and it states court documents themselves were not in Montana's backups.

Both things can be true. The exposure is whatever each court put in the copy it sent, which is exactly the problem with support extracts: nobody maintains an inventory of what went out.

One detail you should treat as unsettled. Tech-Insider notes that some characterisations of the incident touch production systems as well as support copies. The courts' own statements and the Montana Supreme Court's account point to backup and troubleshooting data only. Thomson Reuters has not published a technical root cause, has not named the initial access vector, and has not attributed the intrusion to anyone. Until it does, treat the production question as open and the backup question as confirmed.

The Hard2Bit analysis of the incident calls this the support copy problem, and puts it bluntly: the worst-governed data in an organisation tends to sit outside production, in the copies that went out to a supplier. That is a blog's framing rather than a vendor or regulator finding, so weigh it as analysis. But it matches what the courts described, and it matches what most security teams find when they go looking.

The dates matter because they are the part you can benchmark your own contracts against.

March 1, 2026. Unauthorized access to backup data in Thomson Reuters' cloud environment begins. Hard2Bit counts the window to June 29 as 121 days.

June 30, 2026. West Publishing detects the activity. Thomson Reuters engages external cybersecurity experts and notifies law enforcement.

July 23, 2026. Montana's Office of Court Administrator is notified, per the Daily Montanan, as is Ontario's Ministry of the Attorney General. That is 23 days after detection. Courts were notified across a window of roughly July 23 to 27.

August 31, 2026. The Ohio Supreme Court is formally notified, according to Tech-Insider. That is two months after detection, and five weeks after the first states were told.

September 2 to 3, 2026. Public disclosure. Sources split on the date: The Hacker News, KPAX and Tech-Insider say September 2, while The Record and Help Net Security say September 3. The difference is likely notice postings versus press pickup, and it does not change anything material.

September 4, 2026. The contact centre for affected individuals opens, per Insurance Business America.

Two gaps stand out. The first is the 121-day dwell time: someone was in a cloud environment holding court data for four months before anyone noticed. The second is that even after detection, individual customers learned at different times, from July 23 to August 31. If your vendor contract says notification happens "promptly" or "without undue delay," that second gap is what those words can mean in practice.

This is an audit of data you already gave away, not a procurement exercise. A two-person team can get through the first four steps in a week for a vendor estate of twenty or thirty SaaS products. Do them in order, because step one determines how much of the rest matters.

1. Build the list of extractions you have already sent. Search closed tickets for the last two years for exports, dumps and attachments. Record the vendor, the date, the ticket, what was in the copy and whether it contained personal data. Expect half a day of work per support team and expect the number to be higher than anyone guessed. Success looks like a spreadsheet with a row per extraction and no blank cells in the 'what was in it' column.

2. Ask each vendor, in writing, where that copy is now. One email per vendor, referencing the ticket numbers. Ask three things: is the copy still in your possession, where is it stored, and can you provide dated written confirmation of deletion. Give a deadline. Success is a dated confirmation naming the storage system. A vendor that cannot tell you where a two-year-old export went has answered the question anyway.

3. Make deletion confirmation a condition of closing a ticket. This is your own process, so you can change it this week. Hard2Bit's recommendation after C-Track is that no support ticket closes until the vendor confirms deletion of anything you sent. Cost is a checkbox in your ticket template and an argument with whoever owns the workflow. Success is that next quarter's version of step one finds nothing new.

4. Stop sending whole databases. The same analysis recommends limiting extracts to the specific failing case or records, and using a temporary reproduction environment instead of a persistent copy where you can. This is slower for your engineers, by hours rather than minutes per ticket. That is the trade: the C-Track copies were whole database backups, which is why the exposure spans Social Security numbers, driver's licence numbers and medical information rather than one broken case record.

5. Encrypt anything that does leave, with keys you hold. If the vendor needs the data decrypted to work on it, you have learned something about the arrangement. Success is that the copy in the vendor's storage is inert without your involvement.

6. Read your penetration test scope, not the summary. Most reports cover the production application and its login path. Very few cover the vendor's backup storage, because you cannot test someone else's cloud. What you can do is ask each material vendor whether its own testing covered the support and backup storage tier, and ask for the scope statement rather than a certificate. Success is a written answer either way; a refusal is data.

7. Find the notification clause and time it. Look for a number of hours or days between vendor discovery and vendor notification to you. If the clause says 'promptly' or 'without undue delay', mark it as unpriced risk and put a number in it at renewal. Use the C-Track figures as your benchmark: 23 days from detection to the first customer notifications, and about two months before at least one customer judiciary was formally told.

8. Ask who at the vendor can reach the copies, and whether the logs are exportable to you. Named access, not role access. Hard2Bit's recommendation is that access logs at the vendor's storage destination should be auditable and exportable to the customer. Few vendors will offer this. The ones that do are telling you something about their internal controls.

9. Check your insurance before you need it. Insurance Business America used the C-Track incident to remind brokers to confirm that client policies explicitly cover vendor and supply chain breach events, and to check for sublimits, rather than assuming blanket coverage. Read your own schedule for a third-party sublimit. That is a phone call with your broker, not a project.

10. Decide now who makes the notification call when the vendor's list is wrong. In this incident the affected jurisdiction list moved after disclosure. Write down who in your organisation owns the decision to notify your own customers when a vendor's scope statement changes a week later, and what evidence they need. Doing this while calm takes an hour. Doing it during an incident takes a day you will not have.

11. Put a quarterly re-run in the calendar. The whole point of step one is that it goes stale the moment a new support ticket is opened.

Reading "no operational disruption" as "no data loss." Thomson Reuters has said consistently that C-Track remained fully operational and was safe to use. Both statements appear to be accurate and neither tells you anything about exfiltration. When a vendor's first statement is about availability, the question you still have to ask is about confidentiality. Recognise it by the absence of the words: no mention of what data was accessed, only of what kept running.

Trusting the first list of affected customers. The Hacker News reported that Minnesota courts were affected but were left off West Publishing's initial jurisdiction list. The Record and Gblock list Oregon and Ohio's ten district courts of appeals in counts that ran to twelve or more states, while other coverage settled on eleven. If you are on a vendor's list, assume the list is provisional. If you are not on it, ask in writing whether your tenant was in scope of the investigation, and keep the answer.

Assuming the copy the vendor holds looks like your production data. Montana found no court documents in its backups. Other jurisdictions had confidential, redacted or sealed filings in theirs. Neither court could have told you which without checking. You cannot answer 'what was exposed' from your production schema; you have to know what was in the extract.

Thinking fault and responsibility are the same thing. Montana Chief Justice Cory Swanson said the breach was not the fault of Montana or any other state court system, and Thomson Reuters agreed in its own statement. The courts still ran the victim communications, still coordinated a multi-state response, and still had to tell their residents. Being blameless does not move the work.

Waiting to be told. Ohio was formally notified on August 31, roughly two months after West Publishing detected the intrusion. If your monitoring of vendor incidents consists of waiting for the vendor's email, your first knowledge of an incident can lag detection by weeks.

Planning against an initial access vector nobody has published. Thomson Reuters has not disclosed how the intruder got in, who they were, or why the activity ran undetected for about three months. Help Net Security flags all three gaps explicitly. You cannot harden against an unknown technique. You can reduce what is sitting there when it happens, which is what the support copy inventory does.

You have people on both sides of a border. The remedies split by country here. US and Virgin Islands residents were offered twelve months of Experian IdentityWorks with enrolment open until December 31, 2026. Canadians were offered TransUnion myTrueIdentity. If your affected population spans both, your communications need two enrolment paths and two deadlines, and one of them will be the one people miss.

The data includes material that is not about money. Sealed, confidential and redacted court filings were in scope at some jurisdictions. That exposure does not resolve with credit monitoring, because the risk is not a fraudulent account. Help Net Security makes the point that sealed judicial records can carry protected witness, juvenile or victim information. If your vendor extracts contain anything with a comparable protection status in your sector, credit monitoring is not a remedy and you should not present it as one.

Your affected population is bigger than your customer list. Insurance Business America notes that people merely mentioned in court documents, not only parties to proceedings, had data exposed. The equivalent in a commercial dataset is the third party in a support ticket: the reference, the emergency contact, the beneficiary. They are in your extract and they are not in your CRM.

More than one system feeds the vendor. Montana's exposure covered C-Track and e-filing backup data. Where a vendor supports two integrated products, the support extracts can come from both, and your inventory has to walk both ticket queues.

You have no industry body to coordinate with. The state courts had one. Chief Justice Swanson publicly thanked other state supreme courts and the National Center for State Courts for rapid support. Most mid-sized private companies sharing a compromised SaaS vendor have no such channel and find out what peers know from a news article. If you run a vendor with many customers like you, find the user group or the peer Slack before you need it.

Set the IBM average against what the audit above costs you. Steps one and two are a week of two people's time. Step three is a workflow change. Step four costs your support engineers hours per ticket, forever, and that is the only line item anyone will argue about. Steps six through nine are emails and one call to a broker.

The return is not that you stop a vendor being breached, because you cannot. It is that when the notice arrives and the vendor cannot yet tell you what was in the copy, you already know. In this incident, the courts that could describe their exposure precisely, as Montana did within weeks, were in a better position than those still waiting to be added to a list.

One figure that does not exist yet: Thomson Reuters has not disclosed a total count of affected individuals, and had not as of early September 2026. Any number you see attached to this breach is an estimate by someone other than the company.