In short: A website maintenance contract with a security focus makes sure that updates, backups and monitoring do not depend on chance. We look after your websites and PHP servers on an ongoing basis, keep them up to date, test restoration and respond according to an agreed procedure when a new vulnerability becomes known. You receive an understandable report regularly.
Why security belongs in the website maintenance contract
Many maintenance contracts cover CMS updates and stop there. PHP2Shell has shown that this is not enough: the vulnerabilities CVE-2026-109618 and CVE-2026-109619 are in PHP itself, not in the CMS. A WordPress or Shopware update does not close them. Anyone who maintains only the CMS does not have the real danger in view.
Then there is the factor of time. Between the advance notice from php.net on 20 October 2026 and the release of the patches on 21 October, one day passed, and according to media reports a first observed attack attempt had already occurred on 17 October. In such situations, only a procedure that is in place beforehand helps, together with someone who has access and knows which systems are affected. Anyone who starts looking for credentials, calling service providers and clarifying responsibilities only in an emergency loses exactly the time that attackers use.
Another point is often underestimated: backups that have never been restored are a promise without proof. Only a restore test shows whether a backup is complete and how long it actually takes to get back to operation.
Who benefits from a security maintenance contract
A maintenance contract with a security focus suits above all companies whose website or shop is business-critical but that have no in-house administration for servers and PHP. Typical examples are online retailers, medical practices, law firms and mid-sized companies with customer portals, but also public bodies with several web presences.
It is equally sensible if responsibility is currently spread across many shoulders: an agency built the website, a hosting provider supplies the server, a former employee knew the access credentials. In such constellations, a situation like PHP2Shell quickly shows that nobody is clearly responsible. The contract creates a fixed point of contact that knows the situation and is allowed to act.
For a single, small website without forms or customer data, a leaner scope may be enough. We clarify that in the inventory.
What the security maintenance contract includes
- Updates: operating system, web server, PHP, CMS, extensions and dependencies, on a fixed schedule and additionally for critical vulnerabilities
- Restart and proof: after PHP updates, restart of all workers with a check that no old processes are running
- Backups: following the 3-2-1 rule, with regular restore tests. The basics are covered at Backups following the 3-2-1 rule.
- Monitoring: file integrity, logins, processes and logs, as described in Security monitoring for web servers
- Lifecycle: early planning before a PHP version reaches the end of its support, for example PHP 8.2 on 31 December 2026
- Emergency procedure: agreed steps for the worst case, with access credentials and contact persons that are immediately known during an incident
- Report: regular summary with updates installed, events and recommendations
Who is responsible for what?
Many security gaps arise not technically but organisationally: everyone thinks someone else is taking care of it. That is why we record responsibilities in writing. A typical example:
| Task | Hosting provider | Agency | PHP SOS | You |
|---|---|---|---|---|
| Hardware, network, data center | yes | |||
| Operating system and PHP updates | depending on contract | yes | ||
| CMS and extensions | yes | by arrangement | ||
| Content and user accounts | yes | |||
| Monitoring and emergency procedure | yes | approvals |
The actual distribution depends on your contracts. With managed servers in particular, it is worth taking a close look at what the provider really covers, see Managed server: clarifying responsibility. Agencies with many client sites will find a suitable model at Security partner for agencies.
How does PHP SOS help?
- Inventory: We record all websites, servers, versions, access credentials, backups and existing contracts.
- Initial hardening: Open updates and known weaknesses are closed first, before ongoing support begins.
- Agreement: We record scope, schedule, responsibilities and the emergency procedure in writing, including the question of when you are asked before changes are made.
- Ongoing support: Updates, backups, monitoring and reports according to plan, and for critical vulnerabilities additionally according to the agreed emergency procedure.
- Annual review: Together we check whether the contract still fits your system landscape.
What we need and what we do not promise
We need permanent administrative access, a contact person with decision-making authority, contact with the hosting provider and agency, and information about planned changes to your applications. We manage access credentials separately for each client and document who has access. If you are planning changes to your systems, such as a new shop, another website or a change of hosting provider, tell us early so that updates, backups and monitoring can grow with them.
We do not promise that your systems will never be attacked. A maintenance contract lowers the risk and ensures that in an emergency action is taken quickly and in an orderly way. We do not state prices and response times across the board, but set them in the quote after the inventory. How to prepare for an emergency organisationally as well is described in Creating an IT emergency plan for web servers.
Frequently asked questions
What belongs in a website maintenance contract with a security focus?
At a minimum, updates for server, PHP, CMS and extensions, regular backups with a restore test, security monitoring and a clear arrangement for emergencies. It is also important to record in writing who is responsible for what.
Does the maintenance contract replace my agency or my hosting provider?
Not necessarily. We often work together with the agency and hosting provider and take over the security part. What matters is that responsibilities are distributed without gaps and nothing falls between the parties involved.
What happens when a critical vulnerability like PHP2Shell becomes known?
Then we check which of your systems are affected, install updates according to the agreed procedure or apply interim measures, and inform you of the status. How quickly this happens is something we define together in the contract.
Is there a fixed price?
The scope depends on the number and type of your systems. After an inventory, we prepare a quote that describes exactly what is included.