PHP2Shell and Node2Shell showed how untrusted data can reach different business services through components that several teams share and that are often hard to see. This free CISO decision guide turns those two October 2026 cases into a 90-day readiness program, with eight working tools you can fill in for your own services.
Fund the Ability to Answer, Not the Next Scanner
The next serious vulnerability will reach you through a component that several teams share. Readiness means knowing where you process untrusted data, being able to restrict those paths quickly, and proving that the corrected code is actually running. The guide is written for CISOs, CTOs and the AppSec, incident response, third-party risk and GRC teams who work with them.
What Is Inside the Guide
- Three decisions for the next 90 days: scope and ownership, response authority, and evidence-based closure.
- A regulatory map showing where each building block relates to DORA, NIS2, UK operational resilience and MAS rules, and how reporting clocks differ from response clocks.
- Four response clocks with plain definitions and a worked example, so you can see where the waiting happens.
- A field note from Brandefense Atlas: what an outside check could and could not see during both cases.
- Vendor questions and five example contract clauses, including VEX and CSAF status and what the Cyber Resilience Act changes.
- A 90-day program with the people and effort each phase asks for, and one exercise to find the weakest link.
The Three Decisions in Short
- Scope and ownership. Agree a shared dependency and ownership scope for critical services, so the first question in an incident is not who runs what.
- Response authority and engineering capacity. Before an incident begins, decide who may approve a technical control that has business consequences, and on what basis.
- Evidence-based closure. Ask to see unknown scope and accepted exceptions next to completion rates, so nobody gains by leaving difficult assets out of the inventory.
Four Clocks That Show Where the Waiting Happens
The guide measures response capability with four clocks, each with a fixed start and stop:
- Scope clock: from the first recorded signal to a scope picture in which every unknown has an owner.
- Containment clock: from the recorded signal to the selected control verified within the defined scope.
- Fix clock: from the moment the vendor fix is available for your release line to the fix verified on every defined running instance.
- Access clock: used only when credentials may be exposed, from that signal to access revoked and operations verified.
The clocks are definitions, not service levels or benchmarks. Set your own targets by service criticality and decision authority, and report decision delays and unfinished work openly, because they show where to invest next.
Eight Working Tools, Ready to Edit
The toolkit comes as a spreadsheet and a document you can adapt to the records and approvals you already have. It holds eight tools:
- a scope record
- a decision record
- a measurement log that calculates the four clocks
- a readiness check
- an AI pilot sheet
- an exercise kit
- a board view
- vendor questions with example clauses
Start with the four-stamp minimum log on the first day.
Who Should Read It
Boards get the story to tell and the decisions to ask for. CISOs get the capabilities and the 90-day plan. Platform and AppSec teams get the evidence chain behind a “fixed” status. Third-party risk teams get the vendor questions, and GRC teams get the regulatory map. The guide is not legal advice and not a mandatory standard; sources were checked on October 25, 2026.
Fill in the form to get all three files by email: the guide (PDF, 39 pages), the toolkit workbook (Excel) and the clauses and exercise kit (Word).