Kort gezegd: Een contract met een IT-dienstverlener moet de beveiliging niet terloops noemen, maar concreet regelen: wie welke componenten bijwerkt, binnen welke termijn en met welk bewijs, hoe over kritieke kwetsbaarheden wordt geïnformeerd, wie bij een incident meewerkt, hoe logboeken worden bewaard en toegangen beheerd en wat er bij de exit gebeurt. Deze pagina geeft algemene aanwijzingen en is geen juridisch advies; contracten laat u door een advocaat beoordelen.
De vraag die PHP2Shell stelde: wie is verantwoordelijk?
Op 21-10-2026 om 16.00 uur Duitse tijd publiceerde het PHP-project de patches. De BSI (de Duitse federale dienst voor informatiebeveiliging) adviseerde een onmiddellijke update of, waar dat niet kon, de webservers tijdelijk van het net te halen. In veel bedrijven begon daarna niet het werk, maar de zoektocht naar de verantwoordelijkheid. Het bureau verwees naar de hostingprovider, de hostingprovider naar het contract en in het contract stond "onderhoud naar rato van inspanning".
Zulke gaten in het contract zijn geen uitzondering. Veel contracten met bureaus en dienstverleners zijn gesloten toen het ging om het bouwen van een website, niet om het veilige beheer ervan over jaren. Een kritieke kwetsbaarheid in de PHP-runtime, die noch het CMS noch de applicatiecode betreft, valt dan gemakkelijk tussen wal en schip.
Wat een contract met een IT-dienstverlener over beveiliging moet regelen
Het volgende overzicht noemt de punten die in de praktijk belangrijk zijn gebleken. Het vervangt geen juridische toetsing, maar helpt gaten in het bestaande contract te herkennen.
| Regelpunt | Wat moet worden vastgelegd | Verband met PHP2Shell |
|---|---|---|
| Omvang van de dienstverlening | Welke lagen worden verzorgd: besturingssysteem, PHP-runtime, webserver, CMS, plug-ins, eigen code | De PHP-runtime ontbrak vaak in de opsomming |
| Updatetermijnen | gestaffeld naar ernst, met uitzonderingsregel voor noodgevallen | kritieke kwetsbaarheid met CVSS v4.0 9,2 |
| Herstart en bewijs | Updates gelden pas na herstart van alle processen als afgerond, met schriftelijk bewijs | nieuwe bestanden alleen dichten de kwetsbaarheid niet |
| Informatie | actieve melding bij kritieke kwetsbaarheden, met inschatting en plan | veel klanten moesten zelf navragen |
| Medewerking bij incidenten | ondersteuning bij analyse, veiligstelling, herstel, aanspreekpunt | sporenonderzoek na de patch |
| Logboeken | soort, bewaring, overdracht op verzoek | vakpers adviseerde logboeken vanaf 20-10 te bewaren |
| Toegangen | persoonlijke accounts, tweestapsverificatie, lijst van alle toegangen | wie had eigenlijk toegang? |
| Onderaannemers | wie er nog meer betrokken is, informatie bij wijziging | hostingprovider van de hostingprovider |
| Einde van de levensduur van software | tijdige melding vóór einde van de ondersteuning, migratieplan | PHP 8.2 eindigt op 31-12-2026 |
| Exit | overdracht van gegevens, documentatie en toegangen, intrekking van de rechten | overstap na een incident |
Termijnen en bewijs: de punten die het meest tellen
Termijnen zijn de kern. Een formulering als "tijdig" helpt in het ergste geval niet verder. Spreek termijnen af gescheiden naar ernst en leg vast waaraan de ernst wordt gemeten, bijvoorbeeld aan de indeling door de fabrikant of de BSI. Voor buitengewone situaties moet een noodregeling gelden: wie bereikbaar is, wie beslist of een systeem tijdelijk van het net gaat en hoe de extra inspanning wordt afgerekend.
Even belangrijk is het bewijs. Bij PHP2Shell zei het getoonde versienummer vaak weinig, omdat distributies en hostingproviders correcties als backport doorvoeren. Een betrouwbaar bewijs noemt de pakketstatus, het tijdstip van installatie en de herstart van alle PHP-processen. Welke gegevens precies tellen, beschrijft Zo vraagt u uw hostingprovider naar de patchstatus. Neem deze gegevens als verplichte inhoud in het contract op.
Laat u door de dienstverlener bij het contract een taakmatrix geven: een regel per component, een kolom per taak, in elke cel een naam. Gaten vallen dan meteen op, lang voordat de volgende melding komt.
Toegangen, onderaannemers en exit
Dienstverleners hebben toegangen nodig en juist die zijn een veelgebruikte aanvalsroute. Regel dat elke persoon een eigen account krijgt, dat tweestapsverificatie verplicht is waar de techniek dat toelaat en dat u op elk moment een actuele lijst van alle toegangen kunt opvragen. Vertrokken medewerkers van de dienstverlener moeten tijdig uit alle systemen worden verwijderd.
Werkt de dienstverlener zelf met partners, bijvoorbeeld een datacenter of een gespecialiseerd forensisch team, dan moet u dat weten. Verwerkt een van die partners persoonsgegevens, dan komen er verplichtingen op het gebied van gegevensbescherming bij. Meer daarover in het artikel Verwerking in opdracht wanneer dienstverleners bij servers kunnen.
De exit wordt bij het sluiten van het contract het vaakst vergeten. Leg vast dat bij het einde van het contract gegevens, configuratie, documentatie en toegangsgegevens volledig worden overgedragen, alle toegangen van de dienstverlener worden ingetrokken en dit schriftelijk wordt bevestigd. Juist na een incident is een ordelijke overstap anders moeilijk.
Bestaande contracten controleren: zo gaat u te werk
U hoeft niet alle contracten opnieuw te onderhandelen. Een pragmatische werkwijze volstaat voor het begin:
- Alle contracten met bureaus, hostingproviders en IT-dienstverleners verzamelen die websites of servers betreffen.
- Elk contract vergelijken met de tabel hierboven en open punten markeren.
- De belangrijkste gaten schriftelijk bij de dienstverlener aankaarten, te beginnen met omvang van de dienstverlening, termijnen en bewijs.
- Resultaten vastleggen als aanvullende overeenkomst en juridisch laten toetsen.
- De taakmatrix overnemen in het noodplan.
Voor de directie is deze stap ook een kwestie van zorgvuldigheid. Wie verantwoordelijkheden helder regelt en beslissingen documenteert, staat er beter voor als later vragen worden gesteld. Achtergronden daarover biedt Aansprakelijkheid van de directie bij IT-beveiligingslekken. De typische taakverdeling bij beheerde servers beschrijft Managed server: verantwoordelijkheid verduidelijken.
Hoe helpt PHP SOS concreet?
- Wij lezen uw bestaande contracten en dienstbeschrijvingen vanuit technisch oogpunt en markeren welke componenten en taken ontbreken.
- Wij stellen een taakmatrix op voor alle websites en servers, die u met uw dienstverleners kunt afstemmen.
- Wij formuleren de technische eisen aan termijnen, bewijs en meldwegen, die uw advocaat in het contract kan overnemen.
- Waar niemand verantwoordelijk is, nemen wij de taken zelf over via een beveiligingsonderhoudscontract met duidelijk omschreven omvang.
Conclusie: Een goed contract voorkomt geen beveiligingslek, maar voorkomt wel dat in het ergste geval tijd verloren gaat met de vraag naar de verantwoordelijkheid. Deze pagina is algemene informatie en geen juridisch advies.
Veelgestelde vragen
Moet een IT-dienstverlener beveiligingsupdates zonder opdracht doorvoeren?
Dat hangt af van het contract. Zonder duidelijke regeling is vaak omstreden of updates tot de verschuldigde prestatie behoren. Daarom moet het contract uitdrukkelijk vastleggen wie welke componenten bijwerkt en binnen welke termijn. Voor de juridische beoordeling in het concrete geval is een advocaat bevoegd.
Heb ik daarnaast een verwerkersovereenkomst nodig?
Als de dienstverlener in opdracht persoonsgegevens verwerkt of er toegang toe kan krijgen, is in de regel een verwerkersovereenkomst op grond van art. 28 AVG nodig. Ze vervangt het dienstencontract niet, maar vult het aan. Stem dat af met uw functionaris voor gegevensbescherming.
Welke termijnen voor beveiligingsupdates zijn gebruikelijk?
Vaste waarden bestaan niet. Zinvol is een gradatie naar ernst, bijvoorbeeld gescheiden termijnen voor kritieke, hoge en overige kwetsbaarheden. Belangrijk is dat de termijnen schriftelijk vastliggen en een uitzonderingsregel voor noodgevallen zoals PHP2Shell bevatten.
Wat gebeurt er met toegangen als het contract eindigt?
Dat moet het contract regelen: teruggave of verwijdering van gegevens, overdracht van toegangsgegevens en documentatie, intrekking van alle toegangen van de dienstverlener en een bevestiging daarvan.