How to Brief Executives on a Breach You Can't Rule Out
In this blog
Most incident briefings I've seen go wrong in the first sentence. Someone opens with a CVE number (ex: CVE-2026-109618 and CVE-2026-109619), a CVSS score and a patch count. Then they spend ten minutes explaining memory disclosure to people who needed three decisions and a timeline. PHP2Shell is a good test of whether your leadership updates work because this won't be the last time you have this conversation.
These flaws let attackers steal credentials from a PHP process without leaving a file behind. On some systems, you won't be able to prove an attacker was never there. That's an uncomfortable thing to tell an executive team, and it's exactly what they need to hear.
Here's how I'd structure the conversation.
Start with plain language
Your first thirty seconds should make sense to anyone in the room. Something like this:
"A critical flaw in PHP, software behind many of our websites, portals and internal tools, lets attackers take over systems or steal credentials without a password. Attacks began before a fix existed. We're closing exposure and rotating credentials as a precaution, because on some systems we can't prove whether an attacker was already in. We need a few decisions from you today."
That last sentence matters most. It tells leadership why you're in the room.
Answer the same five questions every time
Every update should answer the same five questions, in the same order:
- What happened?
A critical flaw is under active attack, and exploitation started before the patch was public. - What does it mean for us?
Where PHP was reachable from the internet, customer portals, customer data, and the credentials to core systems are at risk. - What have we done?
For example: "[X] of [Y] internet-facing systems are patched or isolated, and secrets are rotated on [X]. We've found no indicators on [N] systems, which is not proof they're clean." - What do we need from you?
Emergency change windows, a decision on systems we may take offline, and an owner for any risk we can't remove. - When will you hear from us next?
Daily at a set time until exposure is closed, then weekly. Immediately if we confirm a compromise or customer impact.
Notice the last line of the third answer. Leadership will treat "no indicators" as "we're fine" unless you tell them otherwise.
Prepare translations
Engineers describe the mechanism, but executives need the consequence. I write the translation out ahead of time so I'm not improvising it in the meeting:
| What the team says | What leadership should hear |
| Unauthenticated code execution | Someone outside the company can run commands on our servers without any credentials. |
| Memory disclosure, no webshell | An attacker could have taken passwords and keys and left no trace. We can't prove a negative, so we rotate. |
| Patch, restart and rotate | Planned disruption now (customers sign in again, integrations get re-keyed) instead of an unplanned breach later. |
| Forensic preservation requires careful order | Patched isn't the same as clean. We're also checking whether anyone got in before the patch. |
| No fix, old or vendor-run PHP | A risk we can't remove this week. It needs an executive owner, compensating controls and an expiry date. |
| Fragile systems we won't scan | We're avoiding actions that could cause an outage, and protecting those systems from the outside first. |
| Third-party PHP | Vendor risk. We're collecting written status from every vendor and escalating any silence. |
| IT/OT boundary | We've confirmed whether anything exposed on the business side has a path to the systems that run operations. |
Bring decisions
CISA added both flaws to its Known Exploited Vulnerabilities catalog on Oct. 26 and gave federal agencies until Oct. 29 to act. That deadline isn't binding on private companies, but it's the yardstick boards and regulators will use. CISA's guidance to take offline any system that can't be patched promptly also backs up the decision on which systems go offline.
An update with no request in it trains leadership to skim. For PHP2Shell, these are the decisions I'd put in front of them:
- Pre-approve emergency change windows, including weekends. Attackers don't observe change freezes.
- Accept planned customer-visible disruption. Forced re-logins and brief portal downtime are far cheaper than a breach notice.
- Decide in advance which systems go offline if they can't be protected, and who makes that call. It shouldn't be the on-call engineer at 2 a.m.
- Name an executive owner and an expiry date for every risk you accept.
- Authorize legal and compliance to start materiality and notification readiness now. Timelines are short across regulated sectors: 36 hours for banks, 24 hours to CISA for TSA-regulated pipelines and rail, as little as one hour under NERC CIP for electric utilities, and four business days after a materiality determination for public companies. Readiness work should start before compromise is confirmed.
Three things not to say
Don't say "we're not affected" until your inventory is done. PHP hides in monitoring tools, phone systems, firewalls, HMIs, historians, and vendor remote-access portals or appliances that never show up as "PHP" on an asset list. Walking that statement back later costs you more credibility than the bad news would have.
Don't use the word 'breach' in writing until counsel has made that call. It's a legal term that can trigger notification obligations, and your daily summaries may be discoverable. Ask legal whether those updates should go through them.
And don't speculate about who the attacker is. Leadership will remember the guess long after you've corrected it. The same goes for vendor headlines. Two major security vendors walked back early PHP2Shell exploitation claims within days.
Consistent format every day
During an extended event, I send the same one-page summary every day. Same layout, same metrics, same position on the page. The numbers change, and the format never does. That consistency lets an executive see progress in about ten seconds.
The metrics I'd track for this one:
- Percentage of known environments examined
- Internet-facing systems patched or isolated, out of the total
- Systems with secrets rotated and sessions reset
- Critical vendors that have confirmed their status
- Confirmed compromises, plus the number under review
- Risk acceptances still waiting for sign-off
- Systems checked for compromise, separate from patched
Put an overall status (green, amber or red) at the top and make the decision behind that color clear.
Set expectations for a long event
The last thing I'd tell leadership is that this will probably get worse before it gets better. It's already happening. Within days of the patch, the PHP team issued a mitigation for a related flaw, CVE-2026-115560, that had no fix yet. Expect more flaws, patch bypasses, and revised fixes. Ask for a standing review cadence instead of treating this as a one-time push. When the next update brings bad news, you'll be reporting something they were already expecting.
Finally, ask for follow-through. Every gap the inventory exposes should become a funded fix with an owner, reviewed once the event closes.
If your team wants to rehearse these conversations before the next event, WWT runs executive-level tabletop exercises on our Cyber Range. We can also review your executive briefings and communications. Your account team can set up either.