In short: An IT incident timeline arranges all observations, decisions and measures chronologically in one consistent time zone, ideally UTC. Each line names the source, the observation, the evidence and a rating as documented, probable or unknown. This produces a traceable picture of when the attacker was in the system, what they could reach and when you became aware of it.
Why everyone asks "when" in the end
After an incident the questions come from all directions. The data protection officer wants to know since when personal data was reachable. The insurer asks when the damage was discovered and reported. Management wants to know whether the vulnerability was already open before the last update. All these questions have one thing in common: they revolve around points in time.
Without a timeline, everyone answers these questions from memory, and the answers contradict each other. With a properly kept timeline there is a shared basis that all parties refer to. It is also the framework for the final report.
With PHP2Shell the timeline is particularly informative because the public key dates are well documented. They can be placed beside your own observations as anchor points. The guide PHP2Shell: the chronology describes the full sequence of public events.
The structure: which columns a timeline needs
A table is enough, whether in a spreadsheet or a shared document. What matters are fixed columns that are filled in for every line. The following template shows the public PHP2Shell key dates as anchors and, below them, typical entries of your own in placeholder form:
| Time (UTC) | Source | Observation | Evidence | Rating |
|---|---|---|---|---|
| 17 October 2026 | Media reports | first observed attack attempt on PHP2Shell | press report | documented as a media report |
| 20 October 2026 | php.net | advance notice of the security updates | announcement on php.net | documented |
| 21 October 2026, 14:00 | php.net | release of 8.5.12, 8.4.27, 8.3.36, 8.2.35 | announcement on php.net | documented |
| own time | Access log | cluster of 500 errors on normal pages | log excerpt, line number | probably relevant |
| own time | File system | new PHP file in the upload folder | copy with checksum | documented, time uncertain |
| own time | internal | incident noticed, management informed | email, meeting note | documented |
| own time | internal | update applied, all workers restarted | package log, process list | documented |
The Rating column is the most important part. It separates what is proven, what seems plausible and what remains open. Later readers can immediately see where the timeline holds and where gaps exist.
IT incident timeline: merging the sources
The entries come from many sources, each with its own formats and time zones. Proceed in this order:
- Fix the time zone: Keep everything in UTC. The switch to winter time on 25 October 2026 shifts German local times by one hour in the middle of the period. Anyone who mixes local times shifts events unnoticed.
- Check clocks: Was the server's clock right? A comparison with a known event, such as your own login, shows deviations.
- External sources first: Logs from CDN, WAF, hoster or firewall are outside the server and hard to manipulate. They form the framework.
- Add server logs: Web server, PHP-FPM, logins, system journal. The method for this is described in Analyzing web server logs after an attack.
- Place the file system: Add the timestamps of new and changed files as hints.
- Enter internal events: When was something noticed, who was informed, which decision was made when?
What file timestamps reveal and what they don't
Linux stores several points in time for each file, including the last change of the content (mtime) and the last change of the metadata (ctime). Both can be output read-only, here as a list of PHP files changed since a cutoff date, sorted by time in UTC:
# Content changes since 17 October 2026, sorted, in UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# All timestamps of a single file
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Work only on a copy or a secured image here, as described in Preserve evidence before you rebuild the server. Keep two limits in mind. First, an attacker can reset a file's modification date with simple means; an unremarkable mtime is not an acquittal. Second, copy operations and some tools change timestamps. That is why the rule is: file times are hints, log entries from outside are evidence.
Enter the time at which your company learned of a possible data breach. Under Art. 33 GDPR, the 72-hour deadline for a notification generally starts with awareness. The assessment is for your data protection officer or a lawyer.
Typical mistakes and how to avoid them
The most common mistakes are unspectacular. The timeline is reconstructed from memory only at the end instead of being kept as you go. Entries contain conclusions instead of observations, for example "attacker came through the form" instead of "POST request to the form, then a new file". And evidence is missing because nobody noted which log file and which line an entry came from.
So appoint one person to keep the timeline, and enter events as soon as they occur. Conclusions belong in a separate column or in the report, not in the observation.
Also treat the timeline as a confidential document. It often contains IP addresses, user names and hints about weaknesses. Define who may read and change it, and keep earlier versions. When an assessment changes, for example because a new log excerpt turns up, the old line is not overwritten but supplemented. That way it stays traceable what was known at which time and on what basis decisions were made.
How does PHP SOS help?
- We keep the timeline continuously from the first contact and in UTC, with source and evidence for every entry.
- We evaluate external logs, server logs and file system together and mark every statement as documented, probable or unknown.
- If needed, we carry out IT forensics with specialized partners for an analysis suitable for use in court.
- We hand over the timeline as part of a report for management, data protection and insurance.
Frequently asked questions
Why do I need a timeline after a security incident?
It puts all observations in sequence and shows when the attacker was in the system, what they could reach and when you learned of it. Data protection officers, insurers, authorities and management need this information for their decisions.
Which time zone should I keep the timeline in?
Consistently in UTC. Servers, services and reports use different time zones, and the switch to winter time at the end of October shifts local times further. Anyone who converts everything to UTC and only adds the local time avoids errors when comparing.
Can I rely on the timestamps of files?
Only to a limited extent. The modification date of a file can be forged with simple means. Entries in logs are more reliable, especially logs outside the affected server. File timestamps are hints that should be confirmed by other sources.
What belongs in the timeline besides technical events?
Also decisions and communication: when the incident was noticed, who was informed, when the server was taken off the network, when patching happened. The time of awareness in particular matters for notification deadlines.