On 25 August 2026 Boston Scientific identified a cybersecurity incident. It filed an 8-K the next day, 26 August, and filed another under Item 1.05, signed 8 September, reporting a network outage that disrupted manufacturing and the processing and shipping of customer orders. The company said the timeline for full recovery was uncertain and that it would give an outlook update on its 28 October earnings call.
Most small companies will never file an 8-K. The shape of that timeline still applies to you: a fast first notice, a second one with more facts, and a long tail of recovery. A one-page plan has to cover all three.
What's affected
Everything that depends on a few shared systems. In the Boston Scientific filing, the outage touched "certain operating systems and business applications," which in turn stopped orders and production. For a software company the equivalent is identity, source control, CI/CD, the production control plane and the billing system.
The filing does not say how the attacker got in. That is normal early on, and your plan should not depend on knowing it.
How to check if you're exposed
Open your current incident plan, if you have one, and answer five questions in ten minutes:
- Does it name one person who can declare an incident at 2 a.m., without asking permission?
- Does it list your three most important systems in the order you would restore them?
- Does it say who talks to customers, who talks to regulators and who talks to staff?
- Does it set a time for the next update, even when there is nothing new?
- Does it live somewhere you can reach if your identity provider and chat are down?
Each "no" is a gap. Fix them on one page, not in a forty-page document nobody opens.
What to do now
- Write the page below and print it. Keep a copy outside your normal cloud accounts.
- Pick severity levels with one test each. For example: Sev 1 means customers cannot use the product or their data may be exposed. Sev 2 means a single internal system is down. Sev 3 means a suspicious event with no impact so far.
- Assign roles by name and give each a backup: incident lead, tech lead, scribe, communications, executive sponsor.
- Decide your update cadence now. Hourly for internal, every four hours for customers during a Sev 1, and a fixed time even if the message is "no change".
- Add a decision log with three lines: who declared, who decided to contain, and who decided on outside notification. Record the time for each.
INCIDENT ONE-PAGER (review every quarter)
Declare: anyone raises it, the on-call lead confirms severity
Severity: Sev1 customer impact or data exposure | Sev2 internal outage | Sev3 suspicious, no impact
Roles: Lead ___ / Tech ___ / Scribe ___ / Comms ___ / Exec ___ (backups listed)
First hour: open channel and call bridge, start the log, preserve logs,
isolate affected hosts and accounts, reset exposed credentials,
confirm backups are untouched, brief the exec sponsor
Restore order: 1 ___ 2 ___ 3 ___
Updates: internal every 60 min, customers every 4 h in Sev1, fixed times
Decision log: declared ___ at ___ | contain ___ at ___ | notify ___ at ___
Out-of-band: phone tree, off-platform chat, printed contacts for counsel,
forensics, insurer, regulators
How this could have been avoided
The filing gives no root cause, so this is about limiting how long and how far an outage runs, not about one missing control.
- Separate the systems that run production from the ones that run the business, so one network event does not stop both.
- Write the restore order in advance. Boston Scientific's update reported restoring a substantial part of its distribution network while manufacturing resumed across most facilities. Which systems come back first is a decision best made before the incident.
- Keep a clean, offline contact list and runbook. You will want it when single sign-on is the thing that is down.
- Rehearse the updates, not just the technical fix. A second statement with new facts is easier when the template and approver already exist.
Why it matters
Recovery is rarely a single moment. The first filing says "something happened". The second says what is back and what is not. The third arrives with the quarter's numbers.
For a small company the audience is customers, your insurer and sometimes a regulator, and they all want the same thing: a calm, regular, accurate update. A plan that fixes the timing and the owner of those updates will help more than a long document of controls you will not read mid-incident.
Try it yourself
Take your three most important systems and write the restore order on a card. Then ask one engineer and one executive to read it and say where they would find the credentials needed to start. If either hesitates, that is your first fix.
Click through it at your own pace, or open it full screen.
Quick check
Why decide the update cadence before an incident?
Because during an incident nobody has time to negotiate who writes the update, when it goes out or who approves it. A fixed time and a named owner keep communication steady even when there is no news.
What does the decision log record?
Who declared the incident, who decided to contain it and who decided on outside notification, each with a time. It later feeds the review and any regulator or insurer questions.
