# Incident Response for Server Attacks > Incident response for server attacks: we handle triage, containment, cleanup and recovery with clear roles and a documented process. For companies. Source: https://phpsos.de/en/leistungen/incident-response/ As of: 25/10/2026 Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **In short:** When an attack affects more than a single website, you need an incident response provider who works through the incident in a structured way. We take over the situation picture, containment, cleanup and safe recovery, with clear roles and complete documentation. You keep the decisions, we provide the technical foundation. ## What incident response means for server attacks Incident response is the orderly handling of a security incident. Instead of hectic individual actions, the work follows fixed phases: detect and assess, contain, eradicate, recover, follow up. Every measure is recorded with its time and reason. This matters especially for web servers. A server running PHP applications often holds credentials for databases, payment providers, mail servers and interfaces. Whoever has broken in there can move further. The situation after PHP2Shell shows how quickly such a scenario can arise: unauthenticated code execution, more than 22.6 million exposed instances according to Unit 42, and no published, confirmed indicators of compromise. ## When you need an incident response provider - several servers or applications are affected or could be affected - there is a suspicion that personal data or payment data has leaked - an attacker may still be active, for example through ongoing connections or new accounts - there is an extortion attempt or a public announcement of the attack - insurers, authorities or business partners expect a documented process For a single infected website, the [emergency help for a hacked website](https://phpsos.de/en/leistungen/website-gehackt-notfallhilfe/) is often enough. We discuss the transition to full incident handling with you as soon as a larger scope becomes apparent. ## How does PHP SOS help? 1. **Triage and situation picture:** We clarify what was observed, which systems and data may be affected and who needs to be involved internally. The result is an initial written situation picture with open questions. 2. **Preserve evidence and contain:** Logs, file systems and databases are backed up before we intervene. Then we isolate affected systems, block compromised access and cut off recognisable connections of the attacker. 3. **Eradicate:** We close the entry point, for example by patching to the fixed PHP versions and restarting all workers, remove backdoors and replace secrets. For detailed analysis, we involve specialised partners for [IT forensics](https://phpsos.de/en/leistungen/it-forensik/) where needed. 4. **Recover:** Systems return to operation in a controlled way, ideally from clean sources or on freshly set up servers. Afterwards we monitor them more closely for renewed anomalies. 5. **Follow up:** You receive a final report with timeline, causes, measures and recommendations. Together we record what should go faster next time. > **Act now:** > Keep server logs and do not change any systems before they have been backed up. For PHP2Shell, the BSI (German Federal Office for Information Security) recommends temporarily taking web servers that cannot be patched immediately off the network. ## Roles and communication during the incident An incident needs clear responsibilities. A small group has proven its worth: one person with decision-making authority, a technical contact on your side and us as technical lead. Status meetings take place at fixed intervals, and results are recorded in writing. In parallel, there are tasks that we do not take on but for which we supply facts: checking a [GDPR notification duty within 72 hours](https://phpsos.de/en/compliance/dsgvo-meldepflicht-72-stunden/), informing the insurer, a possible report to the police and [crisis communication](https://phpsos.de/en/compliance/krisenkommunikation/) towards customers and partners. ## What we need from you and what you get We need administrative access to the affected systems, an overview of the infrastructure and service providers, a person with decision-making authority and the willingness to shut systems down temporarily if necessary. Existing emergency plans, network sketches and dated backups are helpful. You get a continuous incident log, regular situation reports in plain language, a final report for management, data protection officers and insurers, and a prioritised list of improvements. How to be better prepared for the next incident is described in [Creating an IT emergency plan for web servers](https://phpsos.de/en/compliance/notfallplan-erstellen/). ## Typical mistakes in the first hours Many incidents become worse because, in the excitement, well-intentioned steps happen in the wrong order. We often see these patterns: - **Rebuilding immediately:** The server is wiped and reinstalled before anything was backed up. Afterwards it can no longer be established whether data was taken. - **Changing passwords from the infected system:** If the attacker still has access, they see the new passwords too. - **Deleting only the visible file:** The webshell is gone, but the second backdoor in the cron job remains. - **Patching without a restart:** New PHP files are on disk, but the old workers keep running in memory. - **Nobody keeps a log:** Later, nobody knows who changed what and when. That complicates conversations with insurers and authorities. A coordinated process prevents these mistakes without delaying containment. ## What we do not promise We do not promise that every incident will be fully clarified; without traces, questions remain open, and we write that into the report as well. We do not give legal advice or statements on liability or insurance cover. Our goal is a clear end: we work on the incident until it is closed and documented. ## Frequently asked questions **What is the difference between incident response and IT forensics?** The goal of incident response is to contain the incident and restore operations safely. IT forensics establishes in detail, and in an evidence-grade way, what happened. In practice the two overlap, and forensics often preserves traces in parallel. **When should I bring in an incident response provider?** As soon as you suspect that an attacker had access to systems and you cannot reliably judge the extent. The earlier evidence preservation starts, the more can be proven later. **Who makes the decisions during the incident?** You make the decisions, for example on shutdowns, communication or notifications. We prepare the technical groundwork, show options with their consequences and carry out the decisions. **Do I have to involve the police?** Filing a report makes sense in many cases and matters for some insurers. The police's central contact points for cybercrime are responsible for this. Whether and when you file a report is something you decide with your lawyer. ## Sources - [BSI: German Federal Office for Information Security](https://www.bsi.bund.de/) - [GDPR Art. 33: Notification to the supervisory authority](https://dsgvo-gesetz.de/art-33-dsgvo/) - [Police: Central contact points for cybercrime](https://www.polizei.de/) - [BSI IT-Grundschutz (German IT baseline protection)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)