On a Tuesday in August, everything broke.
You have never mentioned it publicly. One of your competitors did mention theirs, in a short honest post about a bad week, and it won them three deals.
MSP incident communication is the piece of marketing nobody plans for, because planning for it means admitting something will eventually go wrong. So it gets handled in a panic, privately, and then never spoken of again.
Which is a shame, because your prospects have already worked out that outages happen. They are not asking whether. They are asking whether you would tell them.
TL;DR
Publishing an honest account of your own incident is the cheapest trust available to an MSP, because it answers the one question a website full of good news cannot. Write about your own incident only, never a client’s. Sort the legal, contractual and insurance obligations first, then decide what to publish. Keep it plain, specific about what changed, and leave it up.
What is an incident post-mortem?
An incident post-mortem is a short public account of something that went wrong, what the impact was, and what you changed as a result.
Key takeaways
- Buyers assume incidents happen. What they cannot tell from your website is whether you would be honest about one.
- Write about your own incident. A client’s incident is their story and publishing it can breach your own contract.
- Statutory and insurance obligations come first. The marketing decision happens afterwards, never instead.
- Specificity is the whole point. “We have strengthened our processes” reads as a cover-up.
- Publish once, leave it up, and resist the urge to quietly delete it in six months.
- The audience is your existing clients first and prospects second. Get the order wrong and it reads as opportunism.
Why does publishing your own failure win work?
Because it answers a question nothing else on your website can.
A prospect comparing three MSPs already knows all three will have a bad week eventually. They have run a business long enough to know systems fail, suppliers fail, and people occasionally do something daft on a Friday afternoon.
So the real question in their head is not “will this go wrong”. It is “will I find out, or will I be managed?”
Testimonials cannot answer it, because everybody’s testimonials are good. Promising to be transparent cannot answer it, because everybody promises that.
Only evidence can, and the only evidence available is what you did last time.
Which is why one honest post about a bad Tuesday outperforms a year of case studies. It is the cheapest trust you will ever buy, and almost nobody buys it.
The line you must not cross
Write about your incident. Never write about a client’s.
If it happened inside a client’s environment, that is their story. Publishing it without written permission risks the relationship, will often breach the confidentiality clause in your own contract, and can create data protection problems on top.
There is a second boundary, and it is the one MSPs get uncomfortable around.
Marketing transparency is not the same as your legal duties and never replaces them. Where personal data is involved, UK data protection law sets reporting requirements and timescales, including reporting certain breaches to the Information Commissioner’s Office. If you act as a processor for a client, you have a duty to notify them, as controller, without undue delay.
Cyber insurance adds another layer. Many policies require prompt notification, and some contain provisions about public statements made before the insurer has assessed the position. Read your own wording rather than assuming.
We are a marketing company, not lawyers or insurance brokers. The blog post is the last decision in this sequence, not the first.
What to include and what to leave out
| Include | Leave out |
| Plain description of what happened | Client names, sectors or anything identifying |
| A simple timeline: when it started, when it was fixed | Blame aimed at a vendor or a named employee |
| The honest impact, including who was affected | Technical detail that could help someone repeat it |
| Specifically what you changed afterwards | “Lessons have been learned” and similar phrasing |
| Who to contact with questions, by name | Anything unconfirmed, or anything your insurer has not seen |
How do you write a public incident note?
Six steps. The first three are not writing at all, which is rather the point.
- Fix it, then write. Publication should not compete for attention while the incident is live. Clients need the problem solved and a direct update from a human.
- Confirm the facts. Publishing a cause you later have to correct is worse than publishing nothing. Wait for the confirmed root cause, not the plausible early theory.
- Clear it. Contractual obligations, statutory duties where personal data is involved, insurer requirements. Get sign-off in writing.
- Write for the client, not the engineer. They want to know what happened, whether it touched them, and whether it can recur. Failover architecture is not the story.
- Be specific about what changed. “We have added a second monitoring check on that service and moved backups to a different provider” is credible. “We have strengthened our processes” reads as a cover-up, because it usually is one.
- Publish once, and leave it up. One post, on your own site, findable. Deleting it later undoes the entire benefit, and somebody will notice.
Templates you can copy
The client incident email, sent while it is still live
Subject: [Service] issue this morning, and what we are doing
Hi [Name],
You may already have noticed that [plain description of the problem] since around [time]. I wanted you to hear it from us rather than work it out.
What we know: [one or two sentences of confirmed fact. No speculation.]
What it means for you: [specific impact, or “we do not believe your systems are affected, and here is how we are checking”.]
What we are doing: [current action, and who is on it.]
I will update you by [specific time] whether or not there is news. If you need me before then, I am on [direct number].
[Your name], [role]
The public post-mortem structure
What happened on [date]
One paragraph, plain English, no jargon. What broke and when.
Who was affected
Be honest about scale without naming anyone. “Around a third of our clients lost access to [service] for roughly four hours”.
What caused it
The confirmed root cause. If part of it is still under investigation, say so and say when you will update.
What we have changed
Specific, listed changes. Dates where you can. This is the section people actually read.
What we got wrong in how we handled it
Optional, and the most persuasive paragraph in the whole piece if you are brave enough to write it.
Questions
A named person, a direct email, and a real phone number.
Frequently asked questions
Does publishing an incident frighten prospects off?
Some, and usually the ones who were going to choose on price anyway. The buyers who matter read it as evidence of how you behave under pressure, which is exactly the thing they cannot otherwise assess. The bigger risk runs the other way: a website that has only ever contained good news tells a buyer nothing about your worst day, so they assume the worst.
What about insurance and legal exposure?
Deal with both before you write anything. Many cyber policies require prompt notification to the insurer and some restrict public statements before they have assessed the position. Where personal data is involved there are separate statutory duties, including reporting requirements to the ICO and, if you are a processor, a duty to notify your client as controller without undue delay. We are a marketing company rather than legal advisers, so read your own policy wording and take proper advice. The post comes last.
How much technical detail is too much?
Enough that a reasonably informed client believes you understand what happened. Not enough that someone could reproduce it. If a detail only exists to demonstrate competence to other IT people, cut it. If omitting a detail makes the account misleading, keep it and find a way to phrase it safely.
When is it too soon to publish?
While it is still live, and while the cause is still a theory. Days rather than hours is normal, and a week is not unreasonable if the investigation is genuinely ongoing. What matters more than speed is that clients heard directly from you first. A prospect reading your post-mortem before your client heard from a human is the one sequence that does real damage.
What to do this week
You do not need an incident to start. Write the template now, while nothing is on fire, and put it somewhere you will find it at seven on a Tuesday morning.
Decide in advance who signs it off, who contacts the insurer, and who rings clients. Those decisions are much harder to make well on the day.
If writing about your own business is the part that keeps getting postponed, that is a large slice of what we do for MSPs. Book a call and we will talk about it.
Every MSP has a Tuesday in July. The only real difference between firms is whether anybody outside the building ever hears about it, and what they conclude from the silence.
