# IT-leverantörsavtal: reglera säkerhetsskyldigheter tydligt

> Vad ett avtal med byrå, webbhotell eller IT-leverantör bör reglera om säkerhet: uppdateringar, omstart, rapporteringsvägar, loggar, åtkomster och utträde.

Källa: https://phpsos.de/sv/blog/dienstleistervertrag-sicherheit/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** Ett avtal med en IT-leverantör bör inte bara nämna säkerheten i förbigående utan reglera den konkret: vem som uppdaterar vilka komponenter, inom vilken frist och med vilket belägg, hur man informeras om kritiska sårbarheter, vem som medverkar vid en incident, hur loggar sparas och åtkomster hanteras och vad som händer vid utträde. Den här sidan ger allmänna anvisningar och är ingen juridisk rådgivning; avtal granskas av en advokat.

## Frågan som PHP2Shell ställde: vem ansvarar?

Den 21 oktober 2026 klockan 16 tysk tid publicerade PHP-projektet patcharna. BSI (den tyska federala myndigheten för informationssäkerhet) rekommenderade omedelbar uppdatering eller, där det inte gick, att tillfälligt ta webbservrarna från nätet. I många företag började därefter inte arbetet utan sökandet efter ansvaret. Byrån hänvisade till webbhotellet, webbhotellet till avtalet, och i avtalet stod ”underhåll efter åtgången tid”.

Sådana luckor i avtalen är inget enskilt fall. Många avtal med byråer och leverantörer slöts när det gällde att bygga en webbplats, inte dess säkra drift över år. En kritisk sårbarhet i PHP-körmiljön, som varken berör CMS eller applikationskod, faller då lätt mellan stolarna.

## Vad ett IT-leverantörsavtal bör reglera om säkerhet

Följande översikt nämner de punkter som i praktiken har visat sig viktiga. Den ersätter ingen juridisk granskning men hjälper till att upptäcka luckor i det befintliga avtalet.

| Regleringspunkt | Vad som bör fastslås | Koppling till PHP2Shell |
|---|---|---|
| Tjänstens omfattning | Vilka lager som sköts: operativsystem, PHP-körmiljö, webbserver, CMS, tillägg, egen kod | PHP-körmiljön saknades ofta i uppräkningen |
| Uppdateringsfrister | graderade efter allvarlighetsgrad, med undantagsregel för nödsituationer | kritisk sårbarhet med CVSS v4.0 9,2 |
| Omstart och belägg | Uppdateringar räknas först efter omstart av alla processer som genomförda, med skriftligt belägg | nya filer ensamma stänger inte sårbarheten |
| Information | aktiv avisering vid kritiska sårbarheter, med bedömning och plan | många kunder fick själva fråga efter |
| Medverkan vid incidenter | Stöd vid analys, säkring, återställning, kontaktperson | spårsökning efter patchen |
| Loggar | Typ, lagring, utlämning på begäran | fackpressen rådde att säkra loggar från den 20 oktober |
| Åtkomster | personliga konton, tvåfaktorsinloggning, lista över alla åtkomster | vem hade egentligen åtkomst? |
| Underleverantörer | vilka som i övrigt är inblandade, information vid byte | webbhotellets webbhotell |
| Programvarans livslängd | Besked i god tid före supportslut, migreringsplan | PHP 8.2 upphör den 31 december 2026 |
| Utträde | Utlämning av data, dokumentation och åtkomster, indragning av rättigheter | byte efter en incident |

## Frister och belägg: de punkter som räknas mest

Frister är kärnan. En formulering som ”snarast” hjälper inte i skarpt läge. Avtala frister separat efter allvarlighetsgrad och fastslå vad allvarlighetsgraden mäts mot, till exempel tillverkarens eller BSI:s klassificering. För extraordinära lägen bör en nödregel gälla: vem som är nåbar, vem som avgör om ett system tillfälligt tas från nätet och hur merarbete debiteras.

Lika viktigt är beläggen. Vid PHP2Shell visade det angivna versionsnumret ofta lite, eftersom distributioner och webbhotell lägger in rättelser som backport. Ett hållbart belägg anger paketläget, tidpunkten för installationen och omstarten av alla PHP-processer. Vilka uppgifter som exakt räknas beskriver [Så frågar ni ert webbhotell efter patchstatus](https://phpsos.de/sv/ratgeber/hoster-patch-status-erfragen/). Ta in dessa uppgifter som obligatoriskt innehåll i avtalet.

> **Tips:**
> Låt leverantören ge er en uppgiftsmatris till avtalet: en rad per komponent, en kolumn per uppgift, ett namn i varje cell. Luckor upptäcks då omedelbart, långt innan nästa meddelande kommer.

## Åtkomster, underleverantörer och utträde

Leverantörer behöver åtkomster, och just de är en vanlig angreppsväg. Reglera att varje person får ett eget konto, att tvåfaktorsinloggning är obligatorisk där tekniken tillåter det och att ni när som helst kan begära en aktuell lista över alla åtkomster. Avgångna medarbetare hos leverantören måste tas bort ur alla system i god tid.

Arbetar leverantören själv med partner, till exempel ett datacenter eller ett specialiserat forensikteam, bör ni känna till det. Behandlar någon av dessa partner personuppgifter tillkommer dataskyddsrättsliga skyldigheter. Mer om det i inlägget [Personuppgiftsbehandling när leverantörer får åtkomst till servrar](https://phpsos.de/sv/blog/auftragsverarbeitung-serverzugriff/).

Utträdet glöms oftast bort vid avtalsslutet. Fastslå att data, konfiguration, dokumentation och inloggningsuppgifter vid avtalets slut lämnas över fullständigt, att alla leverantörens åtkomster dras in och att detta bekräftas skriftligt. Särskilt efter en incident är ett ordnat byte annars svårt.

## Granska befintliga avtal: så går ni tillväga

Ni behöver inte omförhandla alla avtal. Ett pragmatiskt förlopp räcker till att börja med:

1. Samla alla avtal med byråer, webbhotell och IT-leverantörer som berör webbplatser eller servrar.
2. Jämför varje avtal med tabellen ovan och markera öppna punkter.
3. Ta upp de viktigaste luckorna skriftligt med leverantören, med början i tjänstens omfattning, frister och belägg.
4. Dokumentera resultaten som tilläggsöverenskommelse och låt granska den juridiskt.
5. För över uppgiftsmatrisen till nödplanen.

För ledningen är detta steg också en fråga om omsorg. Den som reglerar ansvar tydligt och dokumenterar beslut står bättre rustad om frågor ställs senare. Bakgrund ger [Ledningens ansvar vid IT-säkerhetsluckor](https://phpsos.de/sv/compliance/geschaeftsfuehrer-haftung/). Den typiska arbetsfördelningen för skötta servrar beskriver [Managed server: klargör ansvaret](https://phpsos.de/sv/server/managed-server/).

## Hur hjälper PHP SOS konkret?

- Vi läser era befintliga avtal och tjänstebeskrivningar ur teknisk synvinkel och markerar vilka komponenter och uppgifter som saknas.
- Vi tar fram en uppgiftsmatris för alla webbplatser och servrar som ni kan stämma av med era leverantörer.
- Vi formulerar de tekniska kraven på frister, belägg och rapporteringsvägar som er advokat kan ta in i avtalet.
- Där ingen ansvarar tar vi själva över uppgifterna via ett [säkerhetsunderhållsavtal](https://phpsos.de/sv/leistungen/security-wartungsvertrag/) med tydligt beskrivet omfång.

**Slutsats:** Ett bra avtal förhindrar ingen säkerhetslucka, men det förhindrar att tid går förlorad på frågan om ansvar i skarpt läge. Den här sidan är allmän information och ingen juridisk rådgivning.


## Vanliga frågor

**Måste en IT-leverantör installera säkerhetsuppdateringar utan uppdrag?**  
Det beror på avtalet. Utan tydlig reglering är det ofta omtvistat om uppdateringar ingår i den avtalade tjänsten. Därför bör avtalet uttryckligen fastslå vem som uppdaterar vilka komponenter och inom vilken frist. För den rättsliga bedömningen i det enskilda fallet ansvarar en advokat.

**Behöver jag dessutom ett personuppgiftsbiträdesavtal?**  
Om leverantören på uppdrag behandlar personuppgifter eller kan komma åt dem krävs i regel ett avtal om personuppgiftsbehandling enligt art. 28 GDPR. Det ersätter inte tjänsteavtalet utan kompletterar det. Klargör det med ert dataskyddsombud.

**Vilka frister för säkerhetsuppdateringar är vanliga?**  
Fasta värden finns inte. Rimligt är en gradering efter allvarlighetsgrad, till exempel separata frister för kritiska, höga och övriga sårbarheter. Viktigt är att fristerna står skriftligt och innehåller en undantagsregel för nödsituationer som PHP2Shell.

**Vad händer med åtkomster när avtalet upphör?**  
Det bör avtalet reglera: återlämnande eller radering av data, utlämning av inloggningsuppgifter och dokumentation, indragning av alla leverantörens åtkomster och en bekräftelse på det.

## Källor

- [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: versioner som stöds](https://www.php.net/supported-versions.php)