# IT Service Provider Contracts: Defining Security Obligations Clearly

> What a contract with an agency, host or IT service provider should regulate on security: updates, restarts, reporting channels, logs, access and exit.

Source: https://phpsos.de/en/blog/dienstleistervertrag-sicherheit/  
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:** A contract with an IT service provider should not mention security merely in passing but regulate it concretely: who updates which components, within what period and with what evidence, how critical vulnerabilities are communicated, who takes part in an incident, how logs are kept and access is managed, and what happens on exit. This page gives general guidance and is not legal advice; contracts are reviewed by a lawyer.

## The Question PHP2Shell Asked: Who Is Responsible?

On 21 October 2026 at 4 p.m. German time, the PHP project published the patches. The BSI (German Federal Office for Information Security) recommended updating immediately or, where that was not possible, taking the web servers off the network temporarily. In many companies, what began afterwards was not the work but the search for who was responsible. The agency pointed to the host, the host to the contract, and the contract said "maintenance on a time-and-materials basis".

Such gaps in the contract are not an isolated case. Many contracts with agencies and service providers were concluded when the matter was building a website, not operating it securely over years. A critical vulnerability in the PHP runtime, which affects neither the CMS nor application code, then easily falls between all stools.

## What an IT Service Provider Contract Should Regulate on Security

The following overview lists the points that have proven important in practice. It does not replace a legal review but helps to recognize gaps in an existing contract.

| Item to regulate | What should be recorded | Relevance to PHP2Shell |
|---|---|---|
| Scope of services | Which layers are looked after: operating system, PHP runtime, web server, CMS, plugins, own code | The PHP runtime was often missing from the list |
| Update deadlines | graduated by severity, with an exception rule for emergencies | critical vulnerability with CVSS v4.0 9.2 |
| Restart and evidence | Updates count as done only after a restart of all processes, with written proof | new files alone do not close the vulnerability |
| Information | active notification of critical vulnerabilities, with assessment and plan | many customers had to ask themselves |
| Cooperation in incidents | support with analysis, preservation, restoration, contact persons | tracing after the patch |
| Logs | type, retention, handover on request | the trade press advised preserving logs from 20 October |
| Access | personal accounts, two-factor authentication, list of all access | who actually had access? |
| Subcontractors | who else is involved, notification of changes | the host of the host |
| End of life of software | notice in good time before end of support, migration plan | PHP 8.2 ends on 31 December 2026 |
| Exit | handover of data, documentation and access, withdrawal of rights | switching after an incident |

## Deadlines and Evidence: The Points That Count Most

Deadlines are the core. A wording such as "promptly" is no help in an emergency. Agree deadlines separately by severity and define what the severity is measured by, for example by the classification of the vendor or the BSI. For exceptional situations, an emergency rule should apply: who can be reached, who decides whether a system is temporarily taken off the network, and how additional effort is billed.

Evidence is equally important. With PHP2Shell, the displayed version number often showed little, because distributions and hosts apply fixes as backports. Reliable proof names the package state, the time of installation and the restart of all PHP processes. Exactly which details count is described in [How to Ask Your Host About the Patch Status](https://phpsos.de/en/ratgeber/hoster-patch-status-erfragen/). Include these details as mandatory content in the contract.

> **Tip:**
> Ask the provider for a task matrix for the contract: one row per component, one column per task, a name in every cell. Gaps are then noticed immediately, long before the next notice arrives.

## Access, Subcontractors and Exit

Service providers need access, and that is exactly a frequent attack path. Provide that each person receives their own account, that two-factor authentication is mandatory where the technology allows it, and that you can request a current list of all access at any time. Departed employees of the provider must be removed from all systems promptly.

If the provider itself works with partners, such as a data center or a specialized forensics team, you should know about it. If one of these partners processes personal data, data protection obligations come into play. More on this in the article [Data Processing When Service Providers Access Servers](https://phpsos.de/en/blog/auftragsverarbeitung-serverzugriff/).

The exit is what is most often forgotten when concluding a contract. Provide that at the end of the contract, data, configuration, documentation and credentials are handed over completely, all of the provider's access is withdrawn and this is confirmed in writing. Especially after an incident, an orderly switch is otherwise difficult.

## Reviewing Existing Contracts: How to Proceed

You do not have to renegotiate all contracts. A pragmatic procedure is enough to begin with:

1. Gather all contracts with agencies, hosts and IT service providers that concern websites or servers.
2. Compare each contract with the table above and mark open points.
3. Raise the most important gaps with the provider in writing, starting with scope of services, deadlines and evidence.
4. Record the results as a supplementary agreement and have it reviewed legally.
5. Carry the task matrix over into the emergency plan.

For management, this step is also a question of due care. Anyone who regulates responsibilities clearly and documents decisions is in a better position if questions are asked later. Background is offered by [Management Liability for IT Security Gaps](https://phpsos.de/en/compliance/geschaeftsfuehrer-haftung/). The typical division of tasks for managed servers is described in [Managed Server: Clarifying Responsibility](https://phpsos.de/en/server/managed-server/).

## How does PHP SOS help?

- We read your existing contracts and service descriptions from a technical point of view and mark which components and tasks are missing.
- We create a task matrix for all websites and servers that you can coordinate with your service providers.
- We formulate the technical requirements for deadlines, evidence and reporting channels that your lawyer can adopt into the contract.
- Where nobody is responsible, we take over the tasks ourselves through a [security maintenance contract](https://phpsos.de/en/leistungen/security-wartungsvertrag/) with a clearly described scope.

**Conclusion:** A good contract does not prevent a security vulnerability, but it prevents time being lost on the question of responsibility in an emergency. This page is general information and not legal advice.


## Frequently asked questions

**Does an IT service provider have to apply security updates without an order?**  
That depends on the contract. Without a clear provision, it is often disputed whether updates are part of the service owed. The contract should therefore state expressly who updates which components and within what period. For the legal assessment in the individual case, a lawyer is responsible.

**Do I additionally need a DPA?**  
If the provider processes personal data on your behalf or can access it, a data processing agreement under Art. 28 GDPR is generally required. It does not replace the service contract but supplements it. Clarify this with your data protection officer.

**Which deadlines for security updates are common?**  
There are no fixed values. A graduated scheme by severity makes sense, such as separate deadlines for critical, high and other vulnerabilities. What matters is that the deadlines are in writing and include an exception rule for emergencies like PHP2Shell.

**What happens to access when the contract ends?**  
The contract should regulate this: return or deletion of data, handover of credentials and documentation, withdrawal of all of the provider's access and a confirmation of it.

## Sources

- [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)
- [BSI (German Federal Office for Information Security)](https://www.bsi.bund.de/)
- [php.net: supported versions](https://www.php.net/supported-versions.php)