# IT-leverandørkontrakter: Fastlæg sikkerhedspligter klart

> Hvad en kontrakt med bureau, hostingudbyder eller IT-leverandør bør regulere om sikkerhed: opdateringer, genstart, meldevej, logge, adgange og udtrædelse.

Kilde: https://phpsos.de/da/blog/dienstleistervertrag-sicherheit/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** En kontrakt med en IT-leverandør bør ikke blot nævne sikkerheden i forbifarten, men regulere den konkret: hvem der opdaterer hvilke komponenter, inden for hvilken frist og med hvilken dokumentation, hvordan der informeres om kritiske sårbarheder, hvem der medvirker ved en hændelse, hvordan logge opbevares og adgange administreres, og hvad der sker ved udtrædelse. Denne side giver generelle henvisninger og er ingen retsrådgivning; kontrakter gennemgås af en advokat.

## Spørgsmålet, PHP2Shell har stillet: Hvem er ansvarlig?

Den 21.10.2026 kl. 16 tysk tid offentliggjorde PHP-projektet rettelserne. BSI (det tyske forbundsagentur for informationssikkerhed) anbefalede øjeblikkelig opdatering eller, hvor det ikke var muligt, midlertidigt at tage webserverne af nettet. I mange virksomheder begyndte der bagefter ikke arbejde, men søgningen efter ansvaret. Bureauet pegede på hostingudbyderen, hostingudbyderen på kontrakten, og i kontrakten stod "vedligeholdelse efter forbrug".

Sådanne huller i kontrakten er intet enkelttilfælde. Mange kontrakter med bureauer og leverandører blev indgået, da det handlede om at bygge et website, ikke om dets sikre drift gennem år. En kritisk sårbarhed i PHP-kørselsmiljøet, som hverken berører CMS eller applikationskode, falder så let mellem alle stole.

## Hvad en IT-leverandørkontrakt bør regulere om sikkerhed

Følgende oversigt nævner de punkter, der har vist sig vigtige i praksis. Den erstatter ikke en juridisk gennemgang, men hjælper med at opdage huller i den eksisterende kontrakt.

| Reguleringspunkt | Hvad der bør fastholdes | Relation til PHP2Shell |
|---|---|---|
| Ydelsesomfang | Hvilke lag der betjenes: operativsystem, PHP-kørselsmiljø, webserver, CMS, plugins, egen kode | PHP-kørselsmiljøet manglede ofte i opregningen |
| Opdateringsfrister | graduerede efter alvorlighed, med undtagelsesregel til nødsituationer | kritisk sårbarhed med CVSS v4.0 9,2 |
| Genstart og dokumentation | Opdateringer gælder først som udført efter genstart af alle processer, med skriftlig dokumentation | nye filer alene lukker ikke sårbarheden |
| Information | aktiv underretning ved kritiske sårbarheder, med vurdering og plan | mange kunder måtte selv spørge |
| Medvirken ved hændelser | støtte ved analyse, sikring, gendannelse, kontaktperson | sporsøgning efter rettelsen |
| Logge | art, opbevaring, udlevering på forlangende | fagpressen rådede til at sikre logge fra 20.10. |
| Adgange | personlige konti, totrinslogin, liste over alle adgange | hvem havde egentlig adgang? |
| Underleverandører | hvem der ellers er involveret, information ved skift | hostingudbyderens hostingudbyder |
| Softwarens levetid | varsel i god tid før supportudløb, migreringsplan | PHP 8.2 udløber den 31.12.2026 |
| Udtrædelse | udlevering af data, dokumentation og adgange, inddragelse af rettigheder | skift efter en hændelse |

## Frister og dokumentation: de punkter, der tæller mest

Frister er kernen. En formulering som "hurtigst muligt" hjælper ikke i alvorlige tilfælde. Aftal frister adskilt efter alvorlighed, og fastlæg, hvad alvorligheden måles på, f.eks. producentens eller BSI's klassificering. Til usædvanlige situationer bør der gælde en nødregel: hvem der kan kontaktes, hvem der beslutter, om et system midlertidigt tages af nettet, og hvordan merarbejde afregnes.

Lige så vigtig er dokumentationen. Ved PHP2Shell sagde det viste versionsnummer ofte lidt, fordi distributioner og hostingudbydere indspiller rettelser som backport. En holdbar dokumentation nævner pakkestatus, tidspunktet for installationen og genstarten af alle PHP-processer. Hvilke oplysninger der præcist tæller, beskriver [Sådan spørger I jeres hostingudbyder om patchstatus](https://phpsos.de/da/ratgeber/hoster-patch-status-erfragen/). Optag disse oplysninger som obligatorisk indhold i kontrakten.

> **Tip:**
> Lad leverandøren give jer en opgavematrix til kontrakten: en række pr. komponent, en kolonne pr. opgave, i hver celle et navn. Huller falder så straks i øjnene, længe før den næste meddelelse kommer.

## Adgange, underleverandører og udtrædelse

Leverandører har brug for adgange, og netop dem er en hyppig angrebsvej. Regulér, at hver person får en egen konto, at totrinslogin er et krav, hvor teknikken tillader det, og at I til enhver tid kan forlange en aktuel liste over alle adgange. Fratrådte medarbejdere hos leverandøren skal hurtigt fjernes fra alle systemer.

Arbejder leverandøren selv med partnere, f.eks. et datacenter eller et specialiseret forensik-team, bør I vide det. Behandler en af disse partnere personoplysninger, kommer databeskyttelsesretlige pligter til. Mere herom i indlægget [Databehandling, når leverandører får adgang til servere](https://phpsos.de/da/blog/auftragsverarbeitung-serverzugriff/).

Udtrædelsen glemmes oftest ved kontraktindgåelsen. Fastholdt, at data, konfiguration, dokumentation og adgangsdata ved kontraktens udløb udleveres fuldstændigt, alle leverandørens adgange inddrages, og at dette bekræftes skriftligt. Netop efter en hændelse er et ordnet skift ellers vanskeligt.

## Gennemgå eksisterende kontrakter: sådan går I frem

I behøver ikke genforhandle alle kontrakter. Et pragmatisk forløb er nok til at begynde med:

1. Saml alle kontrakter med bureauer, hostingudbydere og IT-leverandører, der berører websites eller servere.
2. Afstem hver kontrakt med tabellen ovenfor, og markér åbne punkter.
3. Tag de vigtigste huller op skriftligt hos leverandøren, begyndende med ydelsesomfang, frister og dokumentation.
4. Fastholdt resultaterne som tillægsaftale, og lad dem gennemgå juridisk.
5. Overfør opgavematrixen til nødplanen.

For ledelsen er dette trin også et spørgsmål om omhu. Den, der regulerer ansvar klart og dokumenterer beslutninger, står bedre, hvis der senere stilles spørgsmål. Baggrunden giver [Ledelsens ansvar ved it-sikkerhedshuller](https://phpsos.de/da/compliance/geschaeftsfuehrer-haftung/). Den typiske opgavefordeling ved betjente servere beskriver [Managed server: Afklar ansvaret](https://phpsos.de/da/server/managed-server/).

## Hvordan hjælper PHP SOS konkret?

- Vi læser jeres eksisterende kontrakter og ydelsesbeskrivelser ud fra et teknisk synspunkt og markerer, hvilke komponenter og opgaver der mangler.
- Vi udarbejder en opgavematrix for alle websites og servere, som I kan afstemme med jeres leverandører.
- Vi formulerer de tekniske krav til frister, dokumentation og meldeveje, som jeres advokat kan overtage i kontrakten.
- Hvor ingen er ansvarlig, overtager vi selv opgaverne via en [security-vedligeholdelsesaftale](https://phpsos.de/da/leistungen/security-wartungsvertrag/) med klart beskrevet omfang.

**Konklusion:** En god kontrakt forhindrer ingen sikkerhedssårbarhed, men den forhindrer, at der i alvorlige tilfælde går tid tabt med spørgsmålet om ansvar. Denne side er generel information og ingen retsrådgivning.


## Ofte stillede spørgsmål

**Skal en IT-leverandør indspille sikkerhedsopdateringer uden ordre?**  
Det afhænger af kontrakten. Uden klar regulering er det ofte omstridt, om opdateringer hører til den skyldige ydelse. Derfor bør kontrakten udtrykkeligt fastholde, hvem der opdaterer hvilke komponenter og inden for hvilken frist. Til den retlige vurdering i det enkelte tilfælde er en advokat ansvarlig.

**Har jeg desuden brug for en databehandleraftale?**  
Behandler leverandøren personoplysninger på jeres vegne eller kan få adgang til dem, er der som regel brug for en aftale om databehandling efter art. 28 GDPR. Den erstatter ikke ydelseskontrakten, men supplerer den. Afklar det med jeres databeskyttelsesrådgiver.

**Hvilke frister for sikkerhedsopdateringer er almindelige?**  
Faste værdier findes ikke. Fornuftigt er en gradering efter alvorlighed, f.eks. adskilte frister for kritiske, høje og øvrige sårbarheder. Vigtigt er, at fristerne står skriftligt og indeholder en undtagelsesregel til nødsituationer som PHP2Shell.

**Hvad sker der med adgangene, når kontrakten udløber?**  
Det bør kontrakten regulere: tilbagelevering eller sletning af data, udlevering af adgangsdata og dokumentation, inddragelse af alle leverandørens adgange og en bekræftelse herpå.

## Kilder

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [php.net: Understøttede versioner](https://www.php.net/supported-versions.php)