The Backup Copy You Did Not Know Your Vendor Kept

On Wednesday, Thomson Reuters disclosed that someone had been inside its C-Track court case management platform from March through the end of June, and had walked off with files belonging to appellate courts in eleven states and the U.S. Virgin Islands, plus three Ontario courts. Minnesota and Oregon courts have since said separately that they were affected too.

The records may contain names, Social Security numbers, driver's license numbers, dates of birth, medical information, and health insurance information. Some of what was taken may have been sealed, redacted, or confidential court information — the material a judge specifically ordered kept out of public view.

That is a serious breach on its own. But the detail I want boards to notice came from Alabama, and it was one sentence long.

The Courts Did Not Know the Copy Existed

Alabama's appellate courts use C-Track for case management, e-filing, and public access. Their statement on Wednesday said the courts' own systems were never touched. Court data, they said, is kept in a secure cloud environment separate from the vendor's.

Then came the correction. West Publishing, the Thomson Reuters unit that sells C-Track, later told the courts that a copy of some Alabama appellate court data had been sitting in a backup file inside the company's cloud environment. That copy is what may have been accessed.

The Alabama courts said they had not asked West Publishing to keep a backup copy of their data, and they had not known one existed.

Montana filled in how such a copy comes to exist. Chief Justice Cory Swanson's release said the compromised files were copies of Montana's databases that had been "supplied to TR for the purpose of troubleshooting the applications." Somebody had a support ticket. Somebody sent the vendor a database copy so the vendor could reproduce the problem. The copy stayed on the vendor's servers, and it was still there in March when the unauthorized party arrived. Minnesota's courts described the same thing: backup data the courts had provided to the vendor.

In my experience, this is how most vendor-held data actually gets there. Not through the contract. Through a troubleshooting session, a migration, a proof of concept, a data extract somebody emailed to make a demo work. The contract describes the data flow the lawyers negotiated. The backup describes the data flow that happened.

Two Courts, Two Different Answers About Where the Data Was

It gets less tidy. The Supreme Court of Ohio, whose C-Track installation serves ten of the state's twelve courts of appeals, said its platform is hosted by the court itself and managed by Thomson Reuters. On August 31 — five weeks after Ohio was first notified — the vendor told the court that the unauthorized access took place on the court's production platform, not a backup.

So Alabama was told the exposure was a backup copy it never knew about. Ohio was told it was the live production system. Thomson Reuters' own notice says only that an unauthorized party "obtained certain C-Track files" and that the incident was not caused by the courts' networks or security. As of Thursday, nobody had published how the attacker got in, who was responsible, how much was taken, or how many people are affected.

I am not going to reconcile those accounts, because I cannot. What I can say is that if you are a customer of a breached vendor and you cannot get a straight answer to "which copy of our data, sitting where," you are not in a position to make a single decision about notification, regulatory reporting, or what to tell your own board. Ohio said it still has not received comprehensive details of the enhanced security measures the vendor says it deployed. Ohio is still using the platform.

The Timeline Is Longer Than the Headline

Here is the sequence, as reconstructed from the vendor's notice and the courts' own statements.

Unauthorized access ran from March 1 through June 29. Thomson Reuters discovered it on June 30. The courts were told between July 23 and July 28 — three to four weeks after discovery, and nearly five months after the intrusion began. Ohio learned the production-platform detail on August 31. Public disclosure came September 2, a date Montana said was chosen so the vendor and the affected states could announce simultaneously.

Four months of undetected access to a system holding sealed court records is the number that will make the headlines. But the number that should worry a board is the gap between June 30 and July 23. For those three weeks, the customers whose data had been taken were operating with no knowledge of it. Their own incident response clocks, their own regulatory obligations, their own notification duties under state law — none of it had started, because none of them knew.

Minnesota's response was to terminate Thomson Reuters' access to its court environments and force password resets for every user of its appellate case management system. That is what a customer does when it decides it can no longer wait for the vendor's version of events.

Three Questions, Pointed at the Copies

What are we protecting? Not "our data in the vendor's system." The copies. Every extract, backup, snapshot, and troubleshooting export that has left your environment for a vendor's and has no scheduled deletion date. If the answer to "what does the vendor hold of ours" is "whatever is in the contract," the answer is wrong, and Alabama just demonstrated why.

What happens if we lose it? For a court, sealed records are the crown jewels. For your business, it is whatever you sent the vendor when the system broke at 2 a.m. and someone needed a full database to fix it. That copy is a snapshot of your most sensitive data, at full fidelity, in an environment you do not monitor and were not told about.

Who decides? When the vendor calls on July 23 to say your data was in the affected files, and then calls again on August 31 to say it was actually the production system, who in your organization is empowered to stop waiting and act — cut access, reset credentials, notify your regulator on your own timeline? Minnesota had an answer. Most companies do not until the second phone call.

What to Ask Your CISO This Week

Ask which vendors have ever received a copy of production data for support, migration, or testing purposes, and whether any of those copies have a confirmed deletion date. Not the vendors who are contractually allowed to. The ones who actually did.

Ask what your critical vendor contracts say about notifying you when the vendor discovers a breach, and whether "promptly" has a number attached. Thomson Reuters took just over three weeks for the first courts it told, four for others. If your contract would have permitted that, you know what to renegotiate.

Ask whether you can independently verify a vendor's account of what was accessed, or whether you are entirely dependent on the vendor's forensics. Montana got a copy of its accessed data and reviewed it with its own team. That is the posture to aim for.

Ask what you would do on day one if a vendor told you a backup you did not know about had been taken. If the honest answer is "ask the vendor what to do," that is the gap.

The courts in this incident did nothing wrong by the vendor's own account. Their systems held. Their data left anyway, in copies at least one of them did not know existed, from an environment none of them controlled. Your vendors have copies too.