Boston Scientific identified a cybersecurity incident on 25 August 2026 and filed an 8-K the next day. Its follow-up filing, signed 8 September, reported what had been restored, said it had "not identified evidence of ongoing unauthorized access" and called the timeline for full operational recovery "uncertain". It also named a date for the next update, its 28 October earnings call.
Strip away the securities law and that is a good model for any small company. Say what you know. Say what you do not. Say when you will speak again.
What's affected
Every audience in an incident needs a different message at a different time: staff, customers, partners, regulators, your insurer, and sometimes the press. Writing those from scratch while systems are down is how guesses become promises.
The templates below are plain-text starting points. Have counsel review the customer and regulator versions before you ever need them.
How to check if you're exposed
Search your shared drive for an "incident" folder. Does it contain:
- A holding statement for customers that is already approved?
- A status page update draft?
- A short regulator notice draft?
- Staff guidance on what not to say or post?
- A review template for after the incident?
If not, the five blocks below are your starting set.
What to do now
Adapt these and store them with your incident plan.
1. First customer notice (within hours, only after you have confirmed impact)
Subject: Security incident affecting ___ service
On ___ (UTC) we identified ___ affecting ___. We have ___ (contained / begun
investigating) and engaged ___ (outside specialists / our security team).
What we know: ___.
What we do not yet know: ___.
What you should do now: ___ (for example rotate API keys created before ___).
We will update you by ___ (time and date) even if there is no change.
Contact: ___.
2. Update notice
Update ___ on the ___ incident, ___ (UTC)
Since our last update: ___.
Current status: ___ restored, ___ still affected.
What we have confirmed about data: ___ (or "we have not identified evidence of
data access, and the investigation continues").
Next update: ___.
3. Staff message
We are responding to a security incident. Please do not discuss it on social
media or with customers outside the approved script. Send customer questions
to ___. If you receive a suspicious call or message, report it to ___ at once.
Do not delete anything. Access to ___ is limited until ___.
4. Regulator or authority first notice (adapt to the specific law)
To ___. We are notifying you of a personal data security incident discovered
on ___. Nature of the incident: ___. Categories and approximate numbers of
people and records: ___. Likely consequences: ___. Measures taken or proposed:
___. Contact for further information: ___. We will provide further information
in phases as our investigation proceeds.
5. Media holding line
We identified a security incident on ___ and are investigating with outside
specialists. We have notified ___ and will share further information when we
can confirm it. Customers can find updates at ___.
Rules for every message
- Use plain verbs and dates. Put a time zone on every time.
- State only what you have confirmed. The Boston Scientific filing says "has not identified evidence of ongoing unauthorized access", which is narrower than saying access has stopped.
- Do not name an attacker or cause until you are certain.
- Promise the next update time, then keep it.
- Keep one approved version and a log of what was sent, to whom and when.
Post-incident review format
Hold the review within two weeks, with everyone who touched the incident. Make it blameless, which means you examine the system and decisions, not people. A one to two page document is enough.
- Summary. Three sentences: what happened, impact, current status.
- Timeline. UTC times from the scribe's log: first signal, detection, declaration, containment, recovery, each notification sent.
- Impact. Systems, customers, records, hours of downtime, money spent.
- Causes. The trigger, the missing or weak controls that let it spread, and why detection took as long as it did. Ask "why" until you reach something you can change.
- What went well. Keep these on purpose.
- What went badly or was slow. Decisions that were hard to make, tools you could not reach, unclear ownership.
- Measures. Time to detect, time to contain, time to recover, time to first customer notice.
- Actions. Each with an owner, a date and a way to confirm it is done. Limit to what you will really finish.
- Follow-up. Date to review the action list, and which tabletop will test the fixes.
REVIEW HEADER
Incident ID ___ Severity ___ Date range ___ to ___ (UTC)
Lead ___ Scribe ___ Reviewed on ___ Attendees ___
Detect ___ min | Contain ___ min | Recover ___ min | First customer notice ___ min
How to avoid this trap
The trap is writing under pressure and being forced to retract.
- Pre-approve templates, with names of approvers and backups.
- Separate facts from guesses in the first draft. Anything unconfirmed waits for a later update.
- Use a single channel and owner for outbound statements.
- Revisit statements at each update. Boston Scientific's second filing added specific restoration facts and said plainly that the full timeline was still unclear.
- Feed the review into the plan, so each incident improves the templates.
Why it matters
Silence and contradictions tend to hurt more than a clear, honest update. A steady cadence of accurate updates is easier to run than a heroic rewrite, and it gives your legal, insurance and security teams a single record.
The review matters for the same reason. Without it, the same slow approval, unreachable credential or unclear owner shows up in the next incident.
Try it yourself
Take the first customer notice and fill it out for a made-up incident in your own product. Time yourself. Then ask a colleague outside engineering to find the sentence that tells a customer what to do next. If they cannot, rewrite it.
Click through it at your own pace, or open it full screen.
Quick check
Why say "has not identified evidence" instead of "no data was accessed"?
Early in an investigation you cannot prove a negative. The first phrase is accurate and leaves room for what you learn later.
What makes a post-incident review blameless?
It examines systems, decisions and information available at the time, not individuals. People then share what happened without fear, which gives better causes and actions.
What should every action item have?
An owner, a due date and a way to check that it is done.
