In short: A patch management process defines how updates run from arrival to evidence: which class a patch falls into, in which window it is installed, how it is tested and rolled back, who restarts and how success is proven. Routine updates run predictably on a schedule, emergency patches follow a fast track agreed in advance. This turns firefighting into a repeatable procedure.
When every patch is an emergency
On the evening of 21 October 2026, the same pattern played out in many companies. The patches were available, the BSI (German Federal Office for Information Security) was pressing, and the questions began: may we just update now? Who tests? Who restarts the services? Who tells management that the shop will be briefly unavailable? And how do we prove afterwards that it worked?
In companies without a process, all of this has to be settled on the spot. In companies with a process, the answers are already fixed. The difference lies not in the technology but in agreements made beforehand.
The building blocks of a patch management process
A workable process first distinguishes how urgent a patch is. Three classes are usually enough:
| Class | Typical trigger | Window | Test | Approval |
|---|---|---|---|---|
| Routine | bug fixes, security updates with low risk | fixed monthly date | staging, standard tests | IT, according to plan |
| Urgent | high rating, system publicly reachable | brought forward at short notice | shortened, most important workflows | head of IT |
| Emergency | critical vulnerability, attacks reported, e.g. PHP2Shell | immediately | smoke test after installation | emergency approval granted in advance |
Who assigns which class should be settled just as firmly as the criteria for it. The assessment itself belongs to the preceding step, see Vulnerability management for mid-sized businesses.
The emergency approval granted in advance is important. Management decides once, calmly, that emergency patches may be applied immediately, even if that means a brief interruption. In an emergency, nobody then has to obtain approval in the middle of the night.
Roles are just as important. For each system it should be settled who installs updates, who tests from a business perspective whether the shop or portal works afterwards, and who is informed. For outsourced systems, the host and agency explicitly belong here, with names and contact details. The fixed maintenance window should be known internally, so that sales and customer service know when brief interruptions are possible.
Also measure how long your process actually takes: from the release of a patch to proven completion, broken down by class. These figures of your own show where things stall and make improvements visible. A process whose duration nobody knows is hard to steer.
The life of a patch in eight steps
Every patch, whatever its class, goes through the same stations. Only speed and depth of testing differ.
- Intake: the alert or available update is recorded, with date and source.
- Classification: determine the class, identify the affected systems from the inventory.
- Preparation: backup or snapshot, describe the rollback, inform those involved.
- Test: in staging or on a less critical system first.
- Installation: in the agreed window, system by system.
- Restart: all affected services and processes, not just the packages.
- Evidence: record the package level, changelog entry and process start.
- Check: verify function; for security vulnerabilities, also look for traces of an earlier intrusion.
Step 6 is forgotten surprisingly often. PHP loads its code when the processes start. As long as old PHP-FPM workers or Apache processes with mod_php are running, they continue to work with the old, vulnerable version. Why this is so and how to restart correctly is explained under After the update: restarting PHP-FPM and all workers.
Evidence that counts later
A patch without proof has, in case of doubt, not been installed, at least as far as customers, insurers or auditors are concerned. For each system, record which package level is installed, whether the CVE numbers appear in the changelog and when the running processes were started. On Debian and Ubuntu systems, read-only commands like these help (adjust the package name to your system):
# Does the installed package contain the fixes?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# When were the running PHP-FPM processes started?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
If the start time of the processes is before the installation of the package, the restart is missing. This is described in detail in Proving CVE numbers in the package changelog.
A patch closes a vulnerability for the future. It does not remove malware that was planted beforehand, and it does not prove that nothing happened before. For emergency patches, a search for traces is therefore a fixed part of the procedure.
Automating where it is safe
Automatic security updates for operating system packages take over a lot of routine work. They only help, however, if backups exist, someone reads the results and the affected services are restarted too. How to set this up on Linux and what the limits are is described in Automatic security updates on Linux servers.
Containers need their own path. There, the running system is not updated; instead the image with the corrected PHP version is rebuilt and rolled out. A patch process that only knows servers easily overlooks these systems. Therefore also include build pipelines and image registries in the list of patch paths, with a responsible person and the same evidence as for classic servers: which PHP version is running in the deployed container, and since when?
Applications, CMS and plugins usually need their own tested path, because updates there change functionality more often. The fixed monthly date is the right place for this. In the end, what matters is that all paths converge in the same documentation: one place where you can see which system is at which level.
How does PHP SOS help?
- Together with you, we write down the patch classes, windows and approvals, tailored to your systems and your organisation.
- We set up automatic security updates with restart checks and notification where that makes sense.
- We take on emergency patches including restart, evidence and search for traces through our PHP patch service.
- We keep the evidence for each system in a form you can present to customers, insurers or auditors.
Conclusion: Patch management seems unspectacular as long as it works. That is exactly the goal: when the next critical alert arrives, a rehearsed procedure runs and nobody has to improvise.
Frequently asked questions
What is the difference between patch management and vulnerability management?
Vulnerability management records and assesses vulnerabilities and decides what to do. Patch management carries out the decision: testing updates, installing them, restarting services and proving success. The two interlock.
Should security updates be installed automatically?
For operating system packages this often makes sense, provided backups exist and the result is checked after each run. It is important that the affected services restart too. With PHP, old processes otherwise stay in memory with the vulnerable code.
How do I prove that a patch really works?
With the installed package level and the CVE numbers in the package changelog, the time of installation and the start time of the running processes, which must be later than the installation.
What if an update breaks something?
That is what the rollback path is for: a backup or snapshot before the update and a described procedure for rolling back. For security updates, rolling back should be the exception and should be paired with an interim measure.