Cutting you off takes 101 minutes; reconnecting you, nine days

On 26 August 2026, at 10:10 in the morning Denver time, Global Healthcare Exchange posted on its status page that it was aware of Boston Scientific's incident and that everything was running normally. By 11:51 that same morning it had cut every one of Boston Scientific's global connections to its platform. One hundred and one minutes. Giving them back took nine days.

There are two public accounts of this incident and they barely overlap. One is the affected company's: two SEC filings and a press release. The other is on systemstatus.ghx.com, the status page of the platform that carries orders between healthcare suppliers and hospitals in North America. Sixteen updates, timestamped to the minute. We read all sixteen, and that is where the part of the incident nobody covered lives: the view from the other end of the cable.

The cut: 101 minutes and one paragraph

Boston Scientific identified its incident on 25 August and disclosed it on the 26th in an 8-K describing "a global disruption to the Company's operations", acknowledging that "the ability to process and ship customer orders" was affected, and adding two sentences more honest than most: "the timeline for a full restoration is not yet known" and "the Company has not yet determined whether the incident is reasonably likely to have a material impact on the Company". In other words: something big happened, we do not know when we will be out of it or what it will cost.

GHX read that announcement, and its first post, at 10:10 MDT that same day, is pure holding pattern: it says its security and operations teams are watching and that "we have not observed any impact to GHX systems, and normal operations continue across the GHX Exchange". One hundred and one minutes later, at 11:51, the second post is no holding pattern:

That last sentence is a small masterpiece of crisis handling: I am disconnecting you and simultaneously putting in writing that disconnecting you is not a judgement about you. And the same message spells out the scope of the cut with welcome precision: GHX ePay payments keep processing normally; credentialing documents uploaded by Boston Scientific reps are quarantined until a security review clears them; and, literally, "we are quarantining email from Boston Scientific and blocking other connections. We plan to force password resets where appropriate". It is not only the order exchange that goes down: email between the two companies goes down and password resets are forced.

Nine days holding the business up with a daily file

The first thing GHX does after cutting is keep the inbound channel alive even though the outbound one is dead: it asks hospitals to keep submitting orders and explains that "GHX continues to receive and queue all orders, but they are not currently being delivered to Boston Scientific". And it adds an operational detail worth its weight in gold: "Customers should not resubmit previously submitted orders unless directed to do so by Boston Scientific". Anyone who has lived through a stuck queue knows why that sentence matters: the nervous customer's natural reflex is to order again, and doubling the queue is the fastest way to turn a backlog into a disaster.

On 29 August at 14:02 MDT comes the sentence we find the most important in the whole timeline: "Through a temporary process, order information for higher-priority customer needs is being sent via a daily file to Boston Scientific, which is selectively processing those orders". A file. Daily. With the priority orders. That is what held up the operations of a pacemaker and defibrillator manufacturer for over a week: not a replica, not a standby site, not a three-hundred-page recovery plan. One file a day, and somebody deciding what goes in it.

The two words doing all the work are higher-priority. Somebody had to decide, every day, which orders went into that file, and they had to decide it without the system that normally makes that call, because the system was down. More than that: GHX says so plainly in the same message — "Because order status information is not currently available through GHX, customers with urgent needs or questions about a specific order or its prioritization should contact their Boston Scientific representative directly". Priority stopped being a field in a system and went back to being a phone call to your rep.

That is the question we always ask when reviewing a continuity plan and which almost never has a written answer: when you can only serve some of your customers, who picks which ones, on what criteria, and with the authority to say no? If it is not decided beforehand, it gets decided in the heat of the moment, and in the heat of the moment the loudest voice wins.

"Sent" stopped meaning sent

On the morning of 2 September, GHX publishes a sentence anyone who has ever built an emergency workaround will recognise: "we have been working with Boston Scientific on a temporary order-information process, but we do not have an active alternative for order processing at this point in time". Translated: we have had a half-working patch for four days and there is still no real alternative process. Six and a half hours later, at 14:40, they turn it on for customers in the United States and Canada.

And with the workaround comes the warning we consider the technical find of this case: "'SENT' indicates that the order information has been delivered to Boston Scientific; it does not confirm that Boston Scientific has processed or fulfilled the order". The status the hospital sees on screen still reads "sent", but for those weeks that status means something else. The screen is not lying because it is broken: it is lying because the meaning of the field changed underneath and the interface never found out.

The same mechanism closes the story. In the final update, the one that resolves the incident, GHX writes: "During this recovery period, the carrier tracking number provides the most accurate delivery information". The source of truth about whether an order arrived stops being the exchange platform and becomes the carrier's tracking number. Write that down for your plan: in degraded mode the source of truth moves, and it pays to know where before it moves. We see this constantly on a smaller scale: an inventory that says the backup exists when what exists is the scheduled job.

Coming back is not a switch: it is a negotiation

From 27 August onwards, GHX repeats the same formula about the return in every update: "When GHX determines it is safe to reconnect, we will engage in a phased and controlled restoration process in cooperation with Boston Scientific. We do not currently have a timeline for that restoration". Read it slowly. When GHX determines. Phased, controlled, in cooperation. No date. Reconnection is not a switch the victim flips: it is a process that starts when the other side is comfortable, and nobody ever rehearses that part. People rehearse bringing up a virtual machine at the secondary site; nobody rehearses convincing a third party's security team.

The connection came back on 4 September at 13:59 MDT — "GHX has re-established Boston Scientific's connections to GHX Exchange" — and the incident closed on 8 September at 17:00 MDT, with transactions processing in real time and, verbatim, "GHX's reconciliation of previously held or queued transactions is complete". From the cut to reconnection: nine days and two hours. From the cut to closure with the queue reconciled: thirteen days and five hours. Neither number appears in an 8-K, neither is measured by any tool of yours, and neither is in the RTO you signed. If you want the long version of why those numbers get signed without ever being calculated, we wrote it up: RTO and RPO are not technical capabilities, they are promises with a price tag.

It is worth saying what that timeline does not prove, because the pretty conclusion would be a false one: the channel was not the final bottleneck. GHX reconnected on 4 September; on the 8th, when Boston Scientific filed its second 8-K (dated the 7th), it was still describing "substantial restoration of its distribution network", and full restoration of manufacturing, fulfillment and shipping was not announced until the 9th. In other words: the partner gave the connection back before the company could fully use it. The lesson is not "third parties slow your recovery down"; it is that your partner's clock runs in parallel to yours, you do not control it, and it can finish before or after yours without warning.

The third clock: the one that sets the price

There is a slower clock that ends up putting a number on all this. On 26 August the company said it had not yet determined whether the incident would have a material impact. On 8 September it files the second 8-K and says "the incident is likely to have a material impact on the Company's results of operations for the third quarter and full year 2026" and that it is unlikely to meet the net sales growth and adjusted EPS guidance ranges "that the Company previously provided on July 29, 2026".

An annual forecast published on 29 July stops being achievable because of something that started on 25 August. You do not need to be listed to take the point: the impact of an IT incident is not measured in hours of downtime, it is measured in the quarter. And the person who ends up writing that number is not the head of systems.

The column missing from your inventory

This is what we are taking into our own reviews after this case. It is not a new plan: it is a new column in the inventory you should already have. For every connection to a third party — electronic order exchange, payment gateway, bank, customs, telco, e-signature provider, the portal of the customer who accounts for 40% of your revenue — five boxes:

• Who decides the cut. It is almost never you. Write down the counterparty and, if they publish it, their criteria.
• Where your people find out. If the counterparty has a status page, subscribe today. GHX asks for it in every message, and in this incident that is where the concrete operational instructions — what to do with your orders — lived, and they were in none of the supplier's announcements.
• What the degraded channel is, and be humble here: the daily file, the emailed PDF order, the phone. Write it down, test it once a year, and make sure somebody can produce it without the main system.
• Which statuses stop meaning what they say once you switch to that channel, and what becomes the source of truth instead. Here it was the carrier's tracking number; in your shop it will be something else, but there will be something.
• What they will ask for to reconnect you. This is the one nobody prepares and the one that takes longest: forensic report, confirmation of containment, third-party certification. Ask beforehand, calmly, and file the answer next to the contract.

And the mirror box, the uncomfortable one: your own criteria for disconnecting a compromised supplier. If tomorrow the one with the incident is your integrator, your payroll provider or whoever manages your endpoints remotely, who in your shop decides to cut that connection, how fast, and at what threshold? GHX needed 101 minutes from its first post. If your answer is "we would deal with it when it happens", you do not have criteria: you have a meeting to schedule.

What this case does NOT prove

We like to be precise about what we do not know. We do not know how they got in, we do not know whether there was encryption or data exfiltration, and to date no group has claimed the attack. Anyone telling you the vector in detail is making it up. Nor does this article prove Boston Scientific did anything wrong: reading both timelines together, what you see is a company communicating with uncommon honesty — including the line that the annual forecast is no longer reachable — and a platform doing its job and documenting it to the minute. In its 9 September note the company also says that independent assessments by CrowdStrike and other third-party experts "have not identified evidence of ongoing threat activity nor evidence of compromise to the Boston Scientific systems or product technologies".

And a warning against the easy conclusion: this is not fixed with more disaster recovery. A second data centre does not reconnect you to your customers' platform; replicating your ERP in another cloud does not change your partner's risk criteria. What covers this gap is well-written, rehearsed paper, not iron. Which is exactly what gets bought least, because it has no datasheet. That was also the point of the continuity plan nobody has rehearsed: the problem is almost never a missing procedure, it is that nobody has ever executed it.

If the problem is that nobody looks at your suppliers' status pages at six in the morning, the fix exists and it is boring: somebody on call with the list in front of them. It is part of what we do in 24x7 support. It does not have to be us, but it has to be someone.

Note on sources

Everything quoted in English comes from three primary sources consulted on 15 September 2026. One: the public GHX status page, incident "Boston Scientific Network Disruption", read not in the web view but in the full dump from that page's own API (systemstatus.ghx.com/api/v2/incidents.json), which returns the incident as opened on 2026-08-26 at 10:10:15 MDT and resolved on 2026-09-08 at 17:00:02 MDT, with its sixteen updates. That is the source of every MDT (UTC−6) timestamp and every GHX quote: the first notice at 10:10, the cut at 11:51 with the line about quarantining email and forcing password resets, the phased-reconnection formula (from 27-08 at 06:00 onwards), the daily file for priority orders (29-08, 14:02), the line about there being no active alternative for order processing (02-09, 08:04), the activation of the temporary process and the warning about the "SENT" status (02-09, 14:40), the "first in, first out" (03-09, 08:18), the re-established connections (04-09, 13:59) and the closure with reconciliation complete and the carrier tracking number (08-09, 17:00). An honest methodological note: the HTML view of that page gave us an incomplete and shifting timeline; the API JSON is the stable source, which is why this article uses it. Two: Boston Scientific Corporation's two Form 8-K filings on EDGAR — the one filed on 2026-08-26 (Item 8.01) and the one filed on 2026-09-08 (Item 1.05, event date 2026-09-07). Three: the "Update on recent cybersecurity incident" note in Boston Scientific's newsroom, dated 2026-09-09. The arithmetic is ours: 10:10 to 11:51 is 101 minutes; from 26-08 at 11:51 to 04-09 at 13:59 is nine days and two hours; to 08-09 at 17:00, thirteen days and five hours. What is our opinion here is stated as such: that GHX's decision looks right to us, that the daily file and the shift in meaning of the "SENT" status are the two operational findings of the case, and that the "who can disconnect you" column is missing from almost every inventory we review. The upstream blackhole analogy describes our practice as a network operator, not something that happened in this incident.

Cover image: "Distribution centre (J Sainsbury's)", by Nick Saltmarsh, via Wikimedia Commons, licensed under Creative Commons CC BY 2.0; cropped and processed for this article.