In short: Lessons learned after an IT incident means: after technical closure, everyone involved sits down together, reconstructs the sequence of events, names without blame what went well and what did not, and derives actions with owners and deadlines. This also applies to near misses such as a PHP2Shell week that passed without harm. What matters is not the record but the later check on whether the actions were implemented.
Why the week after the incident is so important
When the server is running again and the patches are installed, the temptation is great to return quickly to everyday business. That is exactly when the most valuable knowledge is lost: who noticed what and when? Where was information missing? Which decision took too long? In a few weeks nobody will know exactly.
The October week of 2026 is a good example. Many companies patched PHP servers, wrote to hosts, took websites offline as a precaution or preserved logs. Even if no break-in was found, there is a lot to learn from it. How long did it take to establish which systems were affected? Who had to approve the shutdown, and was that person reachable?
The technical steps after an attack itself are covered by the checklist after a hack. This article picks up afterwards: what do we learn from it?
Lessons learned in an IT incident: ground rules for the review
A review is not a tribunal. Anyone who fears that mistakes have personal consequences tells only half the story. The principle therefore is: we look for causes in procedures, tools and information, not for culprits. People acted on the knowledge they had at that moment.
Invite everyone who was involved, including externals such as the host, agency or service provider, as far as possible. Allow two hours. Ask beforehand for material: tickets, chat histories, emails, notes, log extracts. From these the timeline emerges, the backbone of the meeting. How to build it cleanly is described in Creating the timeline of an incident.
The facilitation should not be taken on by the person who ran the incident operationally. They would otherwise be assessing their own decisions. Someone from another department or an external partner is neutral, for example.
The process in six steps
- Present the timeline: What happened when, from the first alert to closure? Mark gaps in the timeline, do not guess.
- What went well? Deliberately start with the positive. It shows what should be kept and relaxes the group.
- Where did it stall? Every delay, every missing piece of information, every uncertainty is collected, at first without discussing solutions.
- Clarify causes: For the most important points, ask “why” repeatedly. “The patch came late” is a finding; “nobody knew that PHP was still running on the old server” is a cause.
- Define actions: For each cause, one concrete action, one responsible person and one deadline.
- Agree a follow-up check: A date in four to eight weeks at which what has been implemented is reviewed.
Typical questions and actions after a PHP situation
The following table shows questions that are often asked after a situation like PHP2Shell, and possible answers in the form of actions. Not every one suits every company; it is meant to sharpen the view.
| Question in the review | Typical finding | Possible action |
|---|---|---|
| How did we learn of the vulnerability? | By chance from the news | Subscribe selectively to security alerts from php.net and the BSI |
| Did we know which systems were affected? | List incomplete, legacy system forgotten | Inventory of all websites and servers with PHP version |
| Who was allowed to decide on the shutdown? | Unclear, decision delayed | Write decision authority into the emergency plan |
| Did the host confirm the patch? | Only verbally or not at all | Request written confirmation, add to the contract |
| Were all PHP processes restarted? | Not checked | Make restart and verification a fixed step |
| Were logs available from 20 October? | Partly already overwritten | Extend the retention period, back up logs centrally |
| How did communication go internally and externally? | Staff learned of it from the press | Prepare an initial internal notice |
Also record what you deliberately do not change. Sometimes a finding is known but the action would be disproportionate. A documented decision is better than quiet forgetting.
In the record, separate proven facts, probable assumptions and open questions. This separation matters especially after PHP2Shell, for which there are no published, confirmed indicators of compromise.
From record to change
The most common failure of lessons learned is mundane: the record is sent round, and then nothing happens. Three habits help. First, every action belongs in the system in which work is done anyway, that is, the ticketing system or task list, not in a separate document. Second, the follow-up check gets a fixed date in management’s calendar. Third, the results feed into the emergency plan, contact list and exercises.
Anyone who wants to test the findings without waiting for the next real incident can play them through in a tabletop emergency exercise. And where the review shows that updates depended too much on chance, converting to patch management as a process is worthwhile.
The final report is also an important document for data protection, insurance and, where applicable, authorities. The legal assessment, for example whether a notification under Art. 33 GDPR was necessary, belongs with the data protection officer or a lawyer, however, not in the technical review.
How does PHP SOS help?
- From logs, tickets and notes, we create a timeline of the incident and mark gaps.
- We facilitate the review as a neutral party and make sure that causes are sought rather than culprits.
- We translate technical findings into actions with effort estimates and priority.
- We accompany the follow-up check and, on request, implement technical actions ourselves, as provided for in our incident response.
Conclusion
An incident is expensive enough. Anyone who does not evaluate it pays again the next time. An honest review without blame, a clean timeline and actions with names and deadlines turn a difficult week into a lasting gain in security.
Frequently asked questions
When should the lessons-learned meeting take place?
When the incident is technically closed but memories are still fresh. In practice, a date about one to two weeks after closure has proven its worth. Before that there is often no distance, and later the details fade.
Should a review also be held after a near miss?
It is worthwhile. A situation like PHP2Shell, where in the end nothing happened, still shows where procedures stalled. These findings are especially valuable because they came about without damage.
Who leads the review?
Ideally someone who did not run the incident operationally. That keeps the facilitation neutral, and nobody has to defend their own decisions. It can also be an external service provider.
What happens to the results?
Each finding becomes an action with a responsible person and a deadline. The emergency plan, contact list and documentation are adjusted. After a few weeks, someone checks what was actually implemented.