TL;DR

• This week PHP2Shell went to number one in the news, and many security leaders got the same message from the boardroom: have you seen this, are we vulnerable? It is a fair question, and the first hour decides whether the answer is calm or chaotic.
• A simple structure helps: name one incident lead, log the question, check what you run, check what your vendors have said and confirm it applies to you, and send a short, honest update with a time for the next one. Practising it beforehand matters. The Cyber Security Breaches Survey 2025/26 found only 25% of businesses that reported breaches have a formal incident response plan.
• AI may be shortening the clock between disclosure and exploitation, but the evidence is mixed. We look at what it shows, and whether this is the calm before the storm. A companion article covers getting board buy-in before the next headline.

The Message Everyone Dreads and Everyone Gets

It usually arrives as one line from a board member or CEO: “Have you seen the news? Are we affected?” This week it was PHP2Shell, two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619) that reached the top of the news within hours. If you were one of the people who opened that message and started checking servers, you are in good company. Almost every security leader we work with has been there.

The question is reasonable. Directors are being told cyber is their responsibility, and a headline feels like a test. What helps is a way to answer that is quick, honest and the same every time.

The Four Questions Behind “Are We Vulnerable?”

Although it sounds like one question, there are really four, and they have different answers and different owners:

The question	What they really want to know	How you answer it
Are we vulnerable?	Do we run the affected software?	Inventory and scanning: where it runs, and which versions
Are we at risk?	Can an attacker actually reach it?	Exposure: is it internet-facing, and what protections sit in front of it
Are we being attacked?	Has anyone tried, or succeeded?	Logs, alerts and threat intelligence since the flaw became known
What are we doing?	Is someone in charge, and when will we know more?	A named lead, a plan and a time for the next update

Splitting it this way stops “we’re checking” being the only answer you can give for hours.

A First-Hour Playbook

When	What to do	Who
First 15 minutes	Log the question and the time. Name one incident lead. Let the sender know you are on it and when they will hear back	CISO, CIO or CITO
By one hour	Establish what you run that could be affected, and whether it is exposed to the internet. Read what your vendors have said (we track this in our PHP2Shell vendor article)	Security and IT operations
By four hours	Decide: patch, mitigate or isolate. Put protections in place where patching will take longer. Start looking at logs	Incident lead with system owners
By 24 hours	Update leadership with what you know, what you don’t and what is next. Keep monitoring for new guidance	Incident lead
By 72 hours	Confirm what is fixed, what is outstanding and who owns it. Capture lessons while they are fresh	Incident lead and CISO

The NCSC’s own incident planning steps follow the same shape: triage and categorise, analyse, contain, remediate, recover, then learn and practise. The point of writing it down is that nobody has to invent it at 7pm.

What a Good First Update Looks Like

You rarely have all the answers in the first hour, and that is fine. Boards tend to cope well with “we don’t know yet” when it comes with a plan and a time. A short, plain message does the job:

“We have seen the news about the PHP flaws. We are checking where we run PHP and whether any of it is reachable from the internet. We expect to confirm that by 3pm, and will update you then. Nothing we know of suggests we have been affected so far.”

• Say what it is in one sentence, with no jargon.
• Say what you are doing and who is leading it.
• Give a time for the next update, and keep to it.
• Be clear about what you don’t yet know.

“We’ve Got This Covered”: How Far Can You Rely on Vendor Reassurance?

When a flaw makes the news, many of the larger vendors respond quickly with a version of the same message: you may be exposed, but we have it under control. That reassurance is often justified, and it saves everyone time. Your board will still ask how you know, and the honest answer is that trust works best when you can check it. The aim is not to doubt your vendors. It is to confirm where you stand, quickly and calmly.

Question to ask	Why it matters	What a good answer looks like
Are we running the affected product or version?	Vendor reassurance only covers what the vendor knows you use	A current inventory, including cloud services and embedded components
Does the protection apply automatically, or do we need to switch something on?	Many fixes need a setting, a policy or an update from your side	A named person has confirmed it in your environment, with the date
Does the vendor’s statement cover this specific flaw?	General messages about being protected do not always name the issue	A published advisory that names the CVE, with a link
Who is responsible if the fix is not enough?	Shared responsibility models vary by service	Clear ownership in the contract or support agreement, and a contact to call
How would we know if it was exploited anyway?	Prevention and detection are different things	Logging, alerting and a way to search back through activity

A short, practical checklist you can reuse for any headline:

• Find the vendor’s advisory and note its date and version number.
• Match it against your own inventory, not just the vendor’s customer list.
• Confirm in writing who applied or enabled each protection, and when.
• Check logs from before the disclosure date, since exploitation can start early.
• Record anything you are relying on the vendor for, and review it after the incident.
• Tell your leadership which parts you have verified and which you are still taking on trust.

That last point is worth saying out loud. “Verified” and “relying on the vendor’s word” are both acceptable positions, as long as everyone knows which is which. Building trust in vendors is a long game: ask for advisories in a consistent format, include response times in contracts, and review how each one performed after every incident.

If it would help to have a second view on a specific vendor statement, we are happy to talk it through. We are also independent of any single vendor, so you will get a view that is not trying to sell you something.

Why the First Hour Feels So Hard

• The inventory is incomplete. Almost every estate has systems nobody remembered, especially supplier-hosted and embedded ones.
• Vendors respond at different speeds. Some had guidance within hours of PHP2Shell, others had nothing public yet, which is normal but unsettling.
• Everything arrives at once. The same week brings the flaw, the patching, the board questions and the day job.
• Plans are untested. The Cyber Security Breaches Survey 2025/26 found only 25% of businesses that reported breaches have a formal incident response plan. The NCSC puts it well: the first time you test your plan should not be the day you are attacked.

The NCSC’s free Exercise in a Box and its nine-step guide to creating cyber exercises are a good way to practise a headline scenario in an hour or two, with the people you would actually call.

Is AI Shortening the Clock?

A fair question is whether first-hour playbooks still work if attackers are getting faster. The evidence points in different directions, so we would rather share both sides:

Signal	What it suggests
Wiz on PHP2Shell	Flaws that had sat in PHP for decades were turned into working attacks far more easily with AI help
Mandiant M-Trends 2026, as summarised by the Cloud Security Alliance	A mean time to exploit of negative seven days, meaning attacks often begin before a patch exists (we would check the original report before relying on it)
VulnCheck, first half of 2026	Only about 1% of vulnerabilities found with AI tools have been exploited so far, so the effect is not yet universal
Amazon’s threat team on PHP2Shell	An exploit attempt on a honeypot four days before public disclosure

So is this the calm before the storm, or is the pace simply the new normal? Honestly, nobody knows yet. What we can say is that a rehearsed first hour matters more, not less, if the time between disclosure and attack keeps shrinking.

What We’re Seeing in Practice

What we hear most often from security leaders in this situation:

• The hardest part is the unknown. “Are we affected?” is easy to ask and hard to answer when nobody has a full list of what is running.
• Many have a plan on paper that has never been tried, and feel unsure who should do what.
• The messages that land best with boards are short, calm and have a time attached.

UK & New Zealand Perspective

The principles are the same in both markets, with some local help:

• UK: NCSC guidance and exercise tools are free, and the Cyber Security and Resilience Bill, which has been moving through Parliament, proposes a 24-hour initial and 72-hour full incident report for in-scope organisations. Check its current status and whether it applies to you.
• NZ: NCSC NZ publishes its own incident management guidance, “Be resilient, be prepared“, and the same first-hour structure applies.

ITogether’s Independent Verdict

A headline vulnerability is stressful, and it is also one of the best chances to show your board what good looks like. The goal is not to have every answer in an hour. It is to answer the four questions in order, keep people informed and keep calm.

If your first hour felt messy this week, that is normal, and it is a useful signal about what to fix. We are working through the same questions alongside our customers, and we are happy to help you build and rehearse a plan. Our companion article looks at turning moments like this into board support for the budget and risk appetite you need.

👉 Would it help to rehearse your first hour before the next headline? Get in touch.

📞 UK +44 (0) 113 341 0123

📞 NZ +64 (0)9 802 2444

📧 hello@itogether.com

FAQs

What Should I Do First When a Vulnerability Hits the News?

Log the question, name one incident lead, and tell the person asking when they will hear back. Then establish what you run that could be affected and whether it is reachable from the internet.

How Do I Answer “Are We Vulnerable?” if I Don’t Know Yet?

Say what you are checking, who is leading it and when you will update them. Boards generally cope well with “we don’t know yet” when it comes with a plan and a time.

Do We Need a Formal Incident Response Plan?

It helps a great deal. The Cyber Security Breaches Survey 2025/26 found only 25% of businesses that reported breaches had one. The NCSC’s step-by-step guidance and Exercise in a Box are good places to start.

Is AI Making Attacks Faster?

Some evidence says yes, such as reports of exploitation before patches, while other data suggests AI-found flaws are rarely exploited so far. Either way, a rehearsed first hour is good insurance.