Communicating Through a Live Security Incident: A Field Guide

When a website security incident goes badly, the technical recovery is rarely the reason. The reason is almost always the communication. A site can be contained in an hour and the relationship can still take months to repair, because of what was said, what wasn’t said, and when.

This is the part of incident response that most agencies never write about, because most agencies are not good at it. We are, and the previous three posts in this series are why we can say that. We’ve covered the architecture that keeps attackers out, the monitoring that catches the ones who get in, and the verification standard that confirms the response is finished. This post is about the part that runs alongside all of it: what you tell the people who are counting on you, while the incident is still live.

This is a field guide. If you are an IT director, a marketing lead, a COO, or anyone who will be in the room when something happens to a website that matters, this is what good communication looks like in real time.

The first hour sets the tone for everything after

The clock that matters in incident communication is not the technical clock. It’s the trust clock. The moment a client learns something is wrong, they start forming a judgment about whether the people handling it have it under control. Everything you say in the first hour either builds that judgment or erodes it.

Here is the cadence we run. Detection and internal verification happen first, fast, before any external communication. We covered the 10-minute detection standard in the second post in this series. Verification comes before outreach for a specific reason: you do not contact a client to tell them something might be wrong. You contact them to tell them what is wrong and what you have already done about it.

Within the first hour, we reach the client’s primary technical contact to confirm scope. Not to alarm them. To align with them. The first contact is a working conversation: here is what we have confirmed, here is what we have already done, here is what we need from you, here is what happens next.

The sequence matters. Verify internally. Contain what can be contained immediately. Then reach out, with actions already taken in hand.

Lead with confirmed facts and completed actions

This is the single most important principle in incident communication, and it is the one most often violated under pressure.

When you reach the client, lead with what you have confirmed and what you have already done. Not with theories. Not with what you are about to do. With completed actions.

A first response to a client during an incident should read something like this in substance: admin passwords have been reset, two-factor enforcement has been initiated, login attempt limits are active, suspicious IPs are blocked, and a full security scan is underway. Those are completed actions and actions in progress. They tell the client that the situation is being handled by people who know what they are doing, before anyone has even discussed how it happened.

What that first message does not do is speculate about cause. “We think it might have been a plugin vulnerability” is a sentence that feels helpful and is actually a liability. If you turn out to be wrong, you have spent credibility you cannot get back. The client now remembers that you said one thing and it turned out to be another, and that memory colors every update after it.

The discipline is to separate two categories explicitly: what we have confirmed, and what we are still investigating. “We have confirmed unauthorized administrative activity and we have contained it. We are still investigating the specific entry point and will not speculate until we have evidence.” That is a sentence you can stand behind no matter what the investigation finds. It is honest, it is calm, and it does not write a check your investigation might not cash.

State what was NOT affected as clearly as what was

This one is specific to high-stakes environments, and it is the difference between a contained incident and a panicked board meeting.

For a financial institution, the website running on WordPress is a completely different system from online banking, account systems, and core banking infrastructure. A compromise of the marketing website is not a compromise of the systems that hold customer money and customer data. That distinction is obvious to the technical team and completely non-obvious to an executive reading a one-line alert that says “our website was hacked.”

So we state it explicitly, every time. Here is what was affected: the WordPress content management system, specific pages, the following components. Here is what was not affected: online banking, customer account data, payment systems, the core banking platform. We say it in plain language, because the people who most need to hear it are not technical, and they are the people who will be answering to a board, a regulator, or a customer base.

Stating what was not affected is not spin. It is scope. An incident that is allowed to feel unbounded becomes a crisis regardless of its actual severity. An incident with clearly stated boundaries stays an incident. The boundary statement is one of the most valuable things you can give an executive during a stressful event, and it costs nothing but the discipline to say it.

The post-incident report is a deliverable, not a courtesy

When the incident is closed, the work is not done. The post-incident report is its own deliverable, and for a regulated-industry client it is one of the most important artifacts the entire engagement produces.

The report is a standalone document with a classification, a version, and a date. It contains a full timeline with timestamps, a clear statement of what was compromised and what was not, the root cause analysis with an explicit separation between what has been confirmed and what cannot be confirmed, the actions taken, and any items still pending. It is delivered after the independent third-party audit closes the incident, not before, because a report delivered before verification is a report that may have to be retracted.

The reason this matters: the report will be read by people who were not in the loop during the incident. Auditors. Regulators. Board members. The client’s own leadership. It becomes the documentation of record, and it has to stand on its own without anyone present to explain it. A good post-incident report is the difference between a client who can confidently tell their board “here is exactly what happened and here is how it was handled” and a client who has to say “the vendor told us it’s fine.”

We write the report to be handed to the most skeptical reader in the client’s organization. That is the standard. If it satisfies the person whose job is to find the gap, it satisfies everyone.

Use the channels and people the client already knows

A live incident is not the moment to introduce a new communication tool, a new point of contact, or a new process. It is the moment to use everything the client already knows.

Same email thread. Same Slack channel. Same names. The client should not have to learn anything new to stay informed during the worst moment of their month. Every new tool you introduce mid-incident is cognitive load added to someone who is already stressed, and it reads as disorganization even when it is not.

This is also why the relationship work done before an incident pays off during one. If the client already knows who their point of contact is, already has the communication channel set up, already trusts the cadence of how you communicate, then the incident communication slots into an existing relationship instead of trying to build one under pressure. The first incident is the worst possible time to be meeting the team.

What not to do

The principles above invert into a clear list of mistakes. These are the things that turn a contained incident into a damaged relationship.

Do not speculate about root cause before you have evidence. Saying “we think it was X” early creates anchoring. If you are wrong, your credibility erodes, and every subsequent update gets read with more doubt. Say what you have confirmed and say what you are still investigating. Nothing more.

Do not promise 100% prevention. It is not credible, and the moment you say “this will never happen again,” you have set a standard you cannot guarantee. The honest framing is detection, response, and continuous improvement. Our job is to make a site hard to attack, fast to detect, and faster to recover. That is a promise you can keep.

Do not introduce new tools or contacts mid-incident. Use the channels and people the client already knows. The incident is not the time to onboard anyone onto anything.

Do not deliver the formal report before the independent audit closes. A report delivered on speculation is a report that may need to be retracted, and a retracted report does more damage than a slightly later one. Wait for verification. Then write it once, correctly.

Do not go quiet. The fastest way to lose a client’s trust during an incident is silence. Even “no new developments, next update at 2pm” is a message worth sending. A client who does not hear from you assumes the worst. Regular updates, even when there is nothing new, keep the trust clock on your side.

“I always knew where things stood”

“I could tell my board exactly what was happening because they told me exactly what was happening.”

Quotes from a recent incident response thread.

The point

Technical recovery and communication are two different jobs, and a team can be excellent at one and terrible at the other. The teams worth working with are good at both, because during a live incident the client experiences the communication far more directly than they experience the technical work. They cannot see the rollback or the file integrity check or the CDN purge. They can see whether they were kept informed, whether they were told the truth, and whether the people handling it sounded like they had it under control.

Get the communication right and a serious incident can actually strengthen a client relationship, because the client learns, under real pressure, that the team handles hard things well. Get it wrong and the cleanest technical recovery in the world will not save the relationship.

That is the whole series in one idea. The architecture, the detection, the verification, and the communication are not four separate things. They are four parts of one job: being the team a client can trust with the thing that matters.

Frequently Asked Questions

How quickly should you notify a client about a security incident?

After internal verification and immediate containment, within the first hour. The sequence matters: verify what is actually happening and contain what can be contained before reaching out, so that the first communication leads with confirmed facts and completed actions rather than with an alarm and no answers. Contacting a client to say “something might be wrong” before you know what is wrong erodes trust rather than building it.

What should the first communication during an incident include?

Confirmed facts and completed actions. What you have verified is happening, and what you have already done about it (passwords reset, access restricted, scans underway, suspicious activity blocked). It should explicitly separate what has been confirmed from what is still under investigation, and it should not speculate about root cause before there is evidence.

Should you tell clients what was NOT affected?

Yes, and as clearly as what was affected. Especially in regulated industries, where a compromise of the public website is a completely different thing from a compromise of core systems like online banking or customer data. Stating the boundaries of an incident explicitly keeps it contained in the minds of executives who will be reporting to boards, regulators, or customers. An incident that feels unbounded becomes a crisis regardless of its actual severity.

When should the post-incident report be delivered?

After the independent third-party audit closes the incident, never before. A report delivered on speculation may have to be retracted, and a retracted report does more damage than a report delivered slightly later. The report should be a standalone document with classification, version, date, full timeline, confirmed root cause, a clear statement of what was and was not affected, and any pending items, written to stand on its own for auditors, regulators, and board members who were not involved during the incident.

What is the biggest mistake in incident communication?

Two compete for the title. Speculating about root cause before you have evidence, which costs you credibility if you turn out to be wrong. And going silent, which lets the client assume the worst. Both are failures of discipline rather than failures of capability, which is what makes them so common: the technical team is heads-down on the recovery and the communication slips. The fix is to treat communication as a parallel workstream with its own owner, not as an afterthought to the technical work.

This is part four of a series on running WordPress like enterprise infrastructure. If your site is more important than your current security setup reflects, book a free 30-minute strategy session. No pitch. Just clarity on what’s actually protecting you and what isn’t.

Part one: The Six-Layer WordPress Security Model for Sites That Matter

Part two: We Detected a Live WordPress Attack in Under 10 Minutes. Here’s How.

Part three: Why a Standard WordPress Malware Cleanup Often Isn’t Enough