The Montana Supreme Court put it plainly in its statement of 2 September: the files an intruder reached were "copies of the compromised databases, which had been supplied to TR for the purpose of troubleshooting the applications". TR is Thomson Reuters, whose subsidiary West Publishing operates C-Track, the case management and e-filing platform used by appellate courts in eleven US states and the US Virgin Islands according to the supplier's notice, plus Oregon and Minnesota, which disclosed separately, and by three Ontario courts. The unauthorised access ran from 1 March to 29 June 2026. That is Montana's account; other courts describe the exposure differently, as shown below.
Thomson Reuters detected the activity on 30 June and published its public notice on 2 September, timed to coincide with the courts' own announcements. The records may hold names, Social Security numbers, driving licence numbers, medical and health insurance details and, at some courts, confidential, redacted or sealed material. How the intruder got in, who it was and how much was taken have not been disclosed, a gap that The Record and Help Net Security both highlight.
Strip away the courtroom setting and the case describes something we find in most of the supplier reviews we run at Hard2bit: the worst-governed data in an organisation tends to sit outside production, in the copies that went out to a supplier so a fault could be diagnosed, or in the copies the supplier kept on its own initiative. The C-Track case has both.
Why are troubleshooting copies the least controlled data an organisation has?
A production environment has an owner, access control, activity logging, encryption and a backup schedule with retention periods. A database dump requested by a supplier to reproduce a bug leaves all of that behind. It travels by whichever channel is convenient and sits in supplier storage the customer cannot see, until somebody remembers to delete it, if anybody does.
The dump is also more dangerous than the database it came from, because it holds every record without the restrictions the application enforces on screen. In a court system that means the very material the application hides from almost everyone, the data of sealed cases included (parties, charges, docket entries), and Thomson Reuters acknowledges that such information may have been affected at some courts.
None of the courts did anything out of the ordinary. Sending data to support so a fault can be reproduced is part of almost every software relationship, and that is where the trouble lies: the practice is routine, and in most of the contracts we review the control over it does not exist.
Which European rules apply when a supplier keeps copies of your data?
The incident is North American, but each of its elements has a counterpart in EU and Spanish law, and under every one of them the customer keeps the responsibility.
GDPR: the processor acts on instructions and deletes at the end
Article 28 of the GDPR sets the minimum content of the contract with a processor. Among other things, the processor handles data only on documented instructions, deletes or returns it once the service ends, and makes available whatever the controller needs to demonstrate compliance, including audits. A diagnostic copy still sitting in storage months after the ticket was closed is, unless the contract expressly provides for it, processing with no instruction behind it and no end date.
Article 33(2) adds that the processor must notify the controller of a breach "without undue delay". The controller then has 72 hours from becoming aware to notify the supervisory authority, and that clock does not start until the processor speaks up. The GDPR does not govern this case, but if it did, the 23 days that passed between detection and the notice to Montana and Ontario would sit awkwardly with what the article asks of a processor.
ENS: it binds the supplier and it regulates copies
Royal Decree 311/2022, Spain's National Security Framework, applies under Article 2(3) to private companies that provide services to the public sector, and it requires tender documents to include what is needed for that conformity. Measure mp.info.6 obliges the backup procedure to specify off-site storage requirements and the controls for authorised access to copies; it governs backups, but there is no reason to demand less of any other copy that leaves production.
Measures op.ext.1 and op.ext.3 require a service level agreement with responsibilities and consequences and, in the HIGH category, an analysis of the impact of an incident originating in the supply chain. Measure op.nub.1 requires cloud services used by public bodies to conform to the ENS or to the relevant CCN-STIC guide, covering data jurisdiction among other points. Who falls within the ENS is explained in a separate article.
NIS2 and DORA: the supply chain is a board-level duty
The NIS2 Directive lists supply chain security and relationships with direct suppliers among the minimum measures in Article 21(2), and Article 20 makes management bodies responsible for approving and overseeing them.
For the justice sector there is a caveat: the definition of a public administration entity in Article 6(35) expressly excludes the judiciary, parliaments and central banks. For a Spanish court the applicable framework is therefore not NIS2 but the ENS and the Judicial Interoperability and Security Framework, now regulated under Royal Decree-Law 6/2023. The supplier is a different matter: an ICT service manager like the one in this case can be a NIS2 entity in its own right, under the ICT service management sector in Annex I, even where its judicial customer is not.
In financial services, Article 30 of DORA requires contracts to fix where services are provided and where data is processed and stored, together with the provider's duty to assist when an incident occurs.
The objection: support needs real data, and the contract already settles liability
Two arguments surface almost every time someone proposes restricting support copies. The technical one: some faults only reproduce against real data, at full volume, with the edge cases and inconsistencies that build up over years. A synthetic dataset will not trigger them, and refusing the transfer prolongs incidents that are hurting users.
The contractual one: the supplier is the processor, it signed a data protection addendum, and if it loses the copies the liability is its own. That is what the contract is for.
The contractual argument does not survive the case, as the next section shows. The technical one deserves a technical answer, which comes in the practical section: there is almost always a way to reproduce a fault without handing over the entire database.
The evidence in the C-Track case
121 days unseen, 144 before the customer knew
On the timeline in Montana's statement, the unauthorised access lasted from 1 March to 29 June: 121 days. Another 23 passed between detection on 30 June and 23 July, when Thomson Reuters informed Montana and Ontario's Ministry of the Attorney General. The customer learnt there was a problem 144 days after it began.
Another 41 days passed between the notice to the courts and publication; Montana explains that a simultaneous announcement was agreed and that the access had already ended. Under the GDPR that interval would not fit either. Thomson Reuters words it differently in its notice, saying the intruder "obtained" the files in March. The two accounts are compatible, and the second is the one a board should dwell on: on that reading the exposure window is not 121 days of access but four months with the files already gone.
The customer cannot shorten that interval, because it has no telemetry over the supplier's storage. All it can do is require the supplier to have it, and to prove it.
No fault, all the consequences
Thomson Reuters and the Montana Supreme Court both state that the incident happened inside the company's environment and was not caused by the courts. That is true, and it changes nothing about who carries the consequences.
Montana received a copy of the data the intruder reached and has spent weeks combing it for personal information. The chief justices of three Ontario courts issued a joint statement in which they admit they do not yet know which data or how many people are affected. The Oregon Judicial Department announced its own review and, as Help Net Security reports, is pressing the supplier for answers. More than a dozen jurisdictions are having to explain, to their own citizens, an incident that happened outside their own systems.
Not every court tells the same story, and that matters too. The Alabama Appellate Courts say the supplier later told them it kept a copy of their data in a backup file in its cloud, a copy the courts had neither requested nor known about. The Supreme Court of Ohio states that the supplier informed it on 31 August that the unauthorised access took place on the court's production platform, which the court hosts and the supplier manages.
Copies the customer did not know about and production run by the supplier are two faces of the same problem: data the customer cannot see.
In Europe the imbalance is no smaller, because it is still the controller who has to notify the regulator and the individuals. A liability clause helps you recover costs afterwards. It does not get you out of the notification.
What Montana found in its files
Montana notes that most of the accessed material was already public and that court documents were not included. Even so, its technology team found driving licence numbers and dates of birth in the files, as KPAX and the Daily Montanan report. Exposure differs by jurisdiction, and Nevada cautioned against assuming one state's exposure applies to another, according to The Record.
No known cause, no lessons
Neither the notice nor the court statements explain how the attacker got in. That matches what we measured a few weeks ago: only one breach notice in four explains the cause. For the customer it means no way to check whether another supplier has the same gap, and no way to adjust its own controls. For the sector as a whole, Infosecurity Magazine points out that court records are a standing target for espionage and extortion, and that the US federal case management system suffered attacks in 2025 that led to stronger protection for sensitive documents.
How to handle the copies that leave for suppliers
What follows calls for no new technology. It takes treating any copy of real data outside production as an asset with an owner and an expiry date, with proof of deletion at the end, and writing that down in the two documents that carry weight, the security policy and the contract.
Contract: location, evidenced deletion and deadlines in hours
- Location and protection regime for any diagnostic copy, with the same measures as production, in line with ENS measure mp.info.6 and, where it applies, DORA Article 30.
- Mandatory deletion when the ticket closes, within a maximum period, with a destruction certificate or log the customer can request.
- Notification of incidents affecting copies within hours rather than weeks, with the minimum detail the customer needs to meet its own 72-hour deadline.
- A right to audit the support storage and, for public sector suppliers, an ENS certificate whose scope covers that storage and not only the main service.
Technical: reduce what leaves and protect what does
Before a full dump goes anywhere, exhaust the alternatives, which are the answer to the technical objection above: a subset limited to the failing case, masking of sensitive fields, or a reproduction environment the supplier accesses temporarily and under audit instead of receiving a file.
Where the transfer is unavoidable, the file goes out encrypted with customer-held keys, over a channel that expires, to named users at the destination, with access control and an exportable log of who opened what. Without that log an intrusion can run for months unseen, which is what happened here for 121 days, and the customer only hears about it when the supplier says so.
Inventory: know which copies exist and where
In the supplier reviews we run, few organisations can say how many dumps of their databases their suppliers hold. The starting point is a register of every extraction of production data to the outside: which system, which supplier, which ticket prompted it, who approved it, where it is stored and when it is deleted. Third-party risk management that stops at an annual questionnaire does not see these copies; you have to ask about them specifically.
Operations: the copy expires with the ticket
The cheapest change is procedural: no support ticket that involved a database dump gets closed until deletion is confirmed. It is a tick box in the closure workflow and a quarterly spot check, and it is where copies from years back tend to turn up that nobody remembered.
Who pays if it is not done, and whose decision it is
For a European controller, an incident in a supplier's support copies carries the same obligations as one of its own. If the processor contract also fell short of Article 28, the penalty is not confined to the supplier. Under NIS2, management is answerable for having approved and overseen supply chain measures; what that accountability means for a board is covered elsewhere on this blog.
For a public sector supplier, an ENS certificate whose scope leaves out support storage is a gap an auditor can flag and a tender can demand.
The heaviest cost lies elsewhere: in reviewing files you never chose to lose, and in answering citizens and lawyers without knowing how it happened.
The decision is not technical. It is a house rule, enforced: no copy of real data leaves production for a supplier without an owner, a deletion date and evidence that it was deleted. The rule fits in one line of the security policy and one clause of the standard contract. The hard part is applying it to the suppliers already inside, with years of closed tickets and dumps nobody has ever chased.
That backlog is what this case has forced into the open. At Hard2bit we would rather it were dealt with inside a third-party review that explicitly covers support copies and test environments, before somebody else's notice makes it urgent. The affected court systems are working through it now, under pressure and in public.
On sources and attribution: this article draws on the public notice from Thomson Reuters and C-Track, the Montana Supreme Court's statement, the joint statement by the Ontario courts, the Ohio and Alabama statements and reporting by The Hacker News, The Record, Help Net Security, Infosecurity Magazine, KPAX and the Daily Montanan. The information is as at 4 September 2026, and the courts are named because each has made its exposure public. The company has not explained the entry vector; no mention implies a security flaw in the C-Track product or in the courts' systems, and the scope of the incident may change as the investigation progresses.
This article is for general information and does not constitute legal advice. References to the GDPR, Spain's National Security Framework (ENS), NIS2 and DORA summarise the texts in force at the time of publication and should be checked against each organisation's own legal advice and the interpretation of the competent authorities.