In short: An IT emergency plan for web servers determines in advance who decides in an emergency, whom to reach, which systems may be affected and which steps follow in which order. Anyone who wants to create an IT emergency plan does not need a thick manual, but a few up-to-date pages that are reachable even without working IT. The PHP2Shell situation is a good occasion to do it now.
Why an emergency plan saves time and damage
In an emergency, the first hours are often lost to searching: who has access to the host? Where are the backups? Who decides whether the shop goes offline? Who needs to be informed? An emergency plan answers these questions beforehand, in peace.
PHP2Shell has shown how short the time can be. On 20 October 2026, php.net announced the patches, on 21 October at 4 p.m. German time they were published, and the BSI (German Federal Office for Information Security) recommended an immediate update or temporary shutdown. Companies with a plan knew whom to call and which servers to check. Others first had to find out where PHP runs at all.
Creating an IT emergency plan: the building blocks
A practical plan for web servers includes these parts:
1. Roles and decisions. Who leads in an emergency, who is the deputy, who may shut systems down, who speaks externally? Record names and deputies.
2. Contact list. Internal contacts, host, agency, IT service provider, data protection officer, legal advisers, cyber insurance with policy number, the competent data protection supervisory authority, the central contact point for cybercrime (Zentrale Ansprechstelle Cybercrime) of your federal state. This list must be available on paper.
3. System inventory. Every website, shop and portal with server, host, operating mode, PHP version, application, responsible person and type of data processed.
4. Decision rules. Under what conditions do we take a system off the network? Who may decide that? What applies at night and on weekends?
5. Procedures. Short sequences of steps for typical cases: critical vulnerability known, suspected break-in, website defaced, data leaked, extortion.
6. Reporting channels. Who assesses a reporting obligation under Art. 33 GDPR, where possible within 72 hours of becoming aware? Who reports to the BSI if NIS2 applies? Who informs the insurer?
7. Recovery. Where are the backups, who can restore them, how long does that take, when was it last tested?
Example: the "critical PHP vulnerability" procedure
This is what a procedure as needed for PHP2Shell can look like:
| Step | Who | Result |
|---|---|---|
| Assess the report (php.net, BSI) | IT managers | affected systems according to the inventory |
| Apply the update, restart all workers | Admin or service provider | Evidence with package state and process time |
| Where no update is possible: interim measures or off the network | Management decides | documented decision |
| Preserve logs, check for traces | Admin or forensics | finding or no finding |
| If there is a finding: start the incident procedure | Emergency lead | check reporting channels |
What matters here: a patch closes the vulnerability but does not remove malware that was planted beforehand. That is why searching for traces is a fixed part of the procedure.
Define how long web server logs are kept and where they are stored outside the server. For PHP2Shell, the trade press recommended keeping logs from 20 October 2026 onward. Anyone who keeps logs for only a few days cannot implement such recommendations.
Precautions that make the plan effective
A plan is only as good as the prerequisites behind it. Check whether backups following the 3-2-1 rule exist and are tested, see Backups following the 3-2-1 rule. Clarify in writing with the host and agency who takes on what in the case of critical vulnerabilities. Keep access credentials for emergencies secure but reachable, for example in a protected password vault with emergency access.
Also prepare text templates: internal information, customer notice, notice on a static maintenance page. Notes on this are under Crisis communication after an attack.
Practicing and keeping it up to date
A plan that has never been practiced almost always contains gaps. Once a year, play through a scenario, such as "critical PHP vulnerability on a Friday afternoon", and note where it gets stuck. A simple test is enough to begin with: can a second person, without the first person's help, reach the host, restore a backup and put the website into maintenance mode? If not, something is missing from the plan, usually an access, a phone number or a description. Exercises are meant to make exactly such gaps visible before things get serious. Update the plan after every exercise and every significant change. The BSI's IT-Grundschutz and BSI Standard 200-4 on business continuity management are suitable as a methodological framework.
Legal questions, such as those on reporting obligations, are not settled conclusively by the plan. It makes sure that the right people are involved in time. This page is general information and not legal advice.
How does PHP SOS help?
- We create the system inventory of your web servers with you, including operating mode and PHP version.
- We write the technical procedures for typical scenarios and coordinate them with the host and agency.
- We carry out an exercise and work the findings into the plan.
- In an emergency, we take over the technical side through incident response, optionally backed by a security maintenance contract.
Frequently asked questions
How extensive does an IT emergency plan have to be?
As short as possible, as detailed as necessary. For web servers, a few pages with contacts, a system list, decision rules and procedures are often enough. More important than the length is that it is up to date and can be found in an emergency.
Where do I keep the emergency plan?
In at least one place that is reachable even without working IT, for example printed out or on a separate device. A plan that exists only on the affected server or in the locked-down company network is no help in an emergency.
How often should the plan be reviewed?
At least once a year and after every significant change, such as a change of host or new software. A short exercise in which a scenario is played through makes sense.
Are there templates from the BSI?
The BSI treats emergency management within the IT-Grundschutz and in BSI Standard 200-4 on business continuity management. These are suitable as a framework; for web servers, a concise, practical version is worthwhile.