Säkerhetskrav i IT-avtal: så får du dem rätt 2026

Säkerhetskraven i ett IT-avtal har en uppgift: att din information skyddas lika bra hos leverantören som hos dig, och att du kan visa det. 2026 räcker det inte längre med en allmän skrivning om att leverantören ska tillämpa “branschmässig säkerhet”. GDPR kräver ett biträdesavtal med bestämt innehåll. Cybersäkerhetslagen kräver att du styr riskerna i hela leverantörskedjan. Säkerhetsskyddslagen kräver ett eget säkerhetsskyddsavtal när verksamheten är säkerhetskänslig. Här går vi igenom vilka krav som ska in i avtalet, i vilken ordning arbetet bör göras och var de flesta organisationer brister.

Kort sagt

• Klassa informationen och gör en riskbedömning innan du skriver en enda klausul. Utan dem vet du inte vilken säkerhetsnivå du ska kräva.
• Behandlar leverantören personuppgifter åt er krävs ett personuppgiftsbiträdesavtal enligt artikel 28.3 i GDPR, med bland annat säkerhetsåtgärder, underbiträden och rätt till granskning.
• Omfattas ni av cybersäkerhetslagen gäller sedan 1 oktober 2026 detaljerade föreskrifter om säkerhet vid utkontraktering, och även äldre avtal kan behöva kompletteras.
• Får leverantören tillgång till säkerhetsskyddsklassificerade uppgifter krävs ett säkerhetsskyddsavtal, och det ska vara på plats innan leverantören får tillgång.
• Säkerhetskrav som ingen följer upp är bara text. Skriv in revision, rapportering och konsekvenser som tydliga skyldigheter.

Innehållsförteckning

• Tre regelverk som ställer olika krav på avtalet
• Börja före avtalet: klassning och riskbedömning
• Klausulerna som bär säkerheten
• Biträdesavtalet när personuppgifter ingår
• Cybersäkerhetslagen gör leverantörskedjan till ert ansvar
• När standardavtalet inte räcker: säkerhetsskyddsavtal
• Misstagen vi ser oftast
• Så ser vi på det
• Hjälp med säkerhetskraven i era IT-avtal
• Vanliga frågor
• Källor

Tre regelverk som ställer olika krav på avtalet

Det vanligaste felet vi ser är att alla säkerhetskrav hamnar i samma bilaga, oavsett vilket regelverk de kommer från. Då blir avtalet svårt att följa upp och luckor är lätta att missa. Börja i stället med att reda ut vilka regelverk som faktiskt träffar just den här leveransen.

Ett och samma avtal kan träffas av alla tre. Säg att en kommun upphandlar drift och moln för sitt verksamhetssystem. Den kan då behöva ett PuB-avtal för medborgarnas personuppgifter, krav enligt cybersäkerhetslagen om kommunen omfattas och ett säkerhetsskyddsavtal om delar av systemet rör säkerhetskänslig verksamhet. Det är tre separata frågor med tre olika bedömningar.

Börja före avtalet: klassning och riskbedömning

Säkerhetskrav går inte att formulera i ett vakuum. Upphandlingsmyndighetens vägledning om informationssäkerhet vid upphandling beskriver informationsklassning och riskanalys som grunden för kraven, inte som ett förberedande steg som kan hoppas över. Vet du inte vilket värde informationen har, och vad som händer om den läcker, ändras eller blir otillgänglig, kan du inte heller avgöra vilka avtalskrav som är rimliga.

MSB:s vägledning Upphandla informationssäkert pekar på samma sak: informationssäkerhet vid upphandling handlar om att identifiera de krav som behövs för att informationen ska hanteras säkert hos den externa leverantören. En felaktig klassning slår åt båda hållen. Överskattar du skyddsbehovet betalar du för säkerhet du inte behöver och skrämmer bort bra leverantörer. Underskattar du det skriver du under ett avtal med hål som är dyra att täppa till i efterhand.

Så här brukar ett fungerande förarbete se ut:

1. Kartlägg informationen. Vilken information ska leverantören hantera, lagra eller kunna komma åt? Ingår personuppgifter, och i så fall vilka kategorier?
2. Klassa konfidentialitet, riktighet och tillgänglighet. Ett lönesystem och en publik webbplats har helt olika profiler.
3. Gör en riskbedömning av leveransen. Var finns datan, vem har åtkomst, vilka underleverantörer ingår och vad händer vid ett avbrott?
4. Gör en DPIA om behandlingen kräver det. Vid behandling av personuppgifter med hög risk bör konsekvensbedömningen vara klar innan avtalet låses. Vår guide om hur du genomför en DPIA steg för steg visar hur.
5. Översätt resultatet till krav. Varje identifierad risk bör kunna kopplas till en klausul, en kontroll eller ett medvetet beslut att acceptera risken.

Klausulerna som bär säkerheten

När förarbetet är gjort är det dags att skriva. Här är de områden som nästan alltid behöver regleras uttryckligen. IMY understryker att säkerhetsåtgärder enligt GDPR består av både tekniska och organisatoriska åtgärder, och det är kopplingen mellan dem som avtalet måste fånga. Kryptering hjälper föga om ingen har ansvar för nycklarna.

Säkerhetsnivå och referensramverk

Ange vilken nivå som gäller och hur den mäts. Hänvisa gärna till ett etablerat ramverk, till exempel ISO/IEC 27001 och 27002, men skriv också ut de kontroller som är kritiska för just er leverans. En certifiering visar att leverantören har ett ledningssystem, inte att er tjänst ingår i certifikatets omfattning. Be att få se omfattningen.

Incidenter och rapportering

Avtalet bör ange vad som räknas som en incident, hur snabbt leverantören ska underrätta er, till vem och vilken information rapporten ska innehålla. Era egna tidsfrister gentemot IMY, eller gentemot tillsynsmyndigheten enligt cybersäkerhetslagen, börjar ofta löpa när ni får kännedom om incidenten. Leverantörens frist måste därför vara kortare än er egen. Skriv också in en skyldighet att medverka i utredningen och att bevara loggar.

Underleverantörer

Kräv förhandsgodkännande, eller åtminstone förhandsinformation om nya underleverantörer med rätt att invända. Säkerhetskraven ska föras vidare nedåt i kedjan på motsvarande nivå. Här brister många avtal, och det var en del av problemet i det IMY-ärende vi beskriver längre ned.

Rätt till revision och insyn

En granskningsrätt som bara omfattar en årlig rapport från leverantören räcker sällan. Skriv in rätt att genomföra egna granskningar, eller låta en oberoende part göra det, även på plats hos leverantören när risken motiverar det. Reglera vem som betalar och hur ofta granskningar får göras.

Kryptering, åtkomst och nyckelhantering

Specificera kryptering vid överföring och lagring, vem som förvaltar nycklarna, hur behörigheter tilldelas och återkallas och hur åtkomst loggas. Våra principer för behörighetsstyrning fungerar som checklista för den delen.

Kontinuitet, exit och radering

Ange återställningstider, krav på säkerhetskopiering och vad som händer när avtalet upphör: i vilket format datan lämnas tillbaka, inom vilken tid och hur radering ska bekräftas. En exitklausul som skrivs först när relationen redan har spruckit blir sällan bra.

Ändringar och uppföljning

Hot och regler ändras under avtalstiden. Bygg in en skyldighet att anpassa säkerhetsåtgärderna när lagkraven ändras, återkommande säkerhetsmöten och konkreta påföljder, som vite eller hävningsrätt, vid väsentliga brister.

Biträdesavtalet när personuppgifter ingår

Så fort leverantören behandlar personuppgifter för er räkning krävs ett personuppgiftsbiträdesavtal. IMY:s sida om personuppgiftsbiträdesavtal går igenom minimikraven i artikel 28.3. Avtalet ska bland annat reglera att:

• behandling bara sker enligt era dokumenterade instruktioner,
• personer med åtkomst omfattas av tystnadsplikt,
• biträdet vidtar säkerhetsåtgärder enligt artikel 32,
• underbiträden bara anlitas på de villkor som avtalet anger,
• biträdet hjälper er att uppfylla de registrerades rättigheter och era skyldigheter kring säkerhet, incidenter och konsekvensbedömningar,
• uppgifterna raderas eller återlämnas när tjänsten upphör,
• ni får den information som behövs för att visa efterlevnad och kan genomföra granskningar.

Vi går igenom varje punkt mer i detalj i artikeln om vad artikel 28.3 kräver av biträdesavtalets klausuler. Frågan ser likadan ut i alla branscher och alla EU-länder. Vill du se hur samma logik tillämpas i en helt annan verksamhet finns ett exempel på när ett hotell behöver ett biträdesavtal. Den som köper HR- och rekryteringssystem som tjänst kan också läsa en spanskspråkig guide till GDPR-efterlevnad vid rekrytering.

Hur dyrt det kan bli när kedjan inte fungerar visar IMY:s beslut mot Statens servicecenter från 2020. Myndigheten var personuppgiftsbiträde åt andra myndigheter. Den fick en sanktionsavgift på 150 000 kronor för att inte i tid ha underrättat de personuppgiftsansvariga om en personuppgiftsincident, och 50 000 kronor för sen anmälan till tillsynsmyndigheten. Beslutet tar också upp kravet på tillräckliga garantier från underbiträdet om lämpliga tekniska och organisatoriska åtgärder. Lärdomen för den som skriver avtalet: incidentflödet mellan biträde, underbiträde och personuppgiftsansvarig ska beskrivas i detalj, med tidsfrister och kontaktvägar, inte i allmänna ordalag.

Gäller avtalet molntjänster tillkommer frågor om tredjelandsöverföring och delat ansvar, som vi reder ut i Molntjänster och GDPR: vem ansvarar och vad kräver lagen?.

Cybersäkerhetslagen gör leverantörskedjan till ert ansvar

Cybersäkerhetslagen (2025:1506) genomför NIS2 i svensk rätt och trädde i kraft i januari 2026. Den 1 oktober 2026 kompletterades lagen med Myndigheten för civilt försvars föreskrifter om säkerhetsåtgärder. Säkerhet vid utveckling och utkontraktering är ett av de uttryckliga områdena där, tillsammans med bland annat incident- och kontinuitetshantering och ledningens utbildning.

För IT-avtal är två saker särskilt viktiga:

• Leverantören bedöms före avtalet. Ni förväntas bedöma en tänkt leverantörs förmåga på cybersäkerhetsområdet innan avtalet ingås, och sedan hantera riskerna i leverantörskedjan under hela avtalstiden. Det kräver att avtalet ger er rätt till information och insyn.
• Gamla avtal går inte fria. Föreskrifterna i MCFFS 2026:11 tar upp att avtal och överenskommelser som ingåtts före den 1 oktober 2026 så långt som möjligt bör kompletteras med krav på cybersäkerhet, och att riskerna med avtal som innehåller otillräckliga krav ska hanteras. En genomgång av befintliga drift-, moln- och supportavtal hör därför till höstens viktigaste uppgifter.

Lagen träffar även leverantörer som inte själva omfattas. Upphandlingsmyndigheten konstaterar att leverantörer i en upphandling, som normalt inte omfattas av regelverket, ändå kan behöva förhålla sig till kraven. Levererar ni till en kommun, en region eller ett energibolag kommer kraven alltså till er via avtalet.

MCF lyfter dessutom ledningens ansvar. Säkerhetsnivån ska inte delegeras bort till IT eller juristerna utan att ledningen tar ställning. I praktiken betyder det att säkerhetskraven i större IT-avtal bör förankras i ledningen, och att det ska gå att visa att så har skett. Hur ledningen kan bygga upp den dokumentationen beskriver vi i 90 dagar för ledningen att skapa bevis enligt NIS2.

När standardavtalet inte räcker: säkerhetsskyddsavtal

Säkerhetsskydd är något annat än vanlig informationssäkerhet. Det handlar om att skydda verksamhet som har betydelse för Sveriges säkerhet. När en leverantör får tillgång till säkerhetsskyddsklassificerade uppgifter eller deltar i säkerhetskänslig verksamhet ska parterna ingå ett säkerhetsskyddsavtal.

Upphandlingsmyndigheten förklarar att avtalet ska säkerställa att leverantören uppnår samma skydd som den upphandlande organisationen. Tidpunkten är avgörande. Avtalet ska finnas innan leverantören får tillgång, och i en säkerhetsskyddad upphandling kan det behövas redan under anbudstiden om klassificerade uppgifter lämnas ut till anbudsgivarna. Kravet gäller inte bara upphandlingar. PTS påpekar att det också blir aktuellt när ni ingår ett avtal eller inleder ett samarbete med en annan aktör.

Säkerhetsskyddsavtalet ersätter inte PuB-avtalet eller säkerhetsbilagan, det kompletterar dem. Läs mer om hur vi arbetar med säkerhetsskyddslagen i praktiken.

Misstagen vi ser oftast

• Kraven skrivs för sent. Leverantörens standardavtal är redan färdigförhandlat när säkerhetsfrågan dyker upp. Då är förhandlingsläget som sämst.
• Certifikatet får ersätta kraven. I avtalet står att leverantören är ISO 27001-certifierad, men ingenting om vad som gäller för just er tjänst.
• Incidentfristerna går inte ihop. Leverantören har 72 timmar på sig att underrätta er, samtidigt som er egen rapportering ska ske inom samma tid.
• Underleverantörerna saknas. Avtalet reglerar huvudleverantören men säger inget om de molnplattformar och supportpartner som faktiskt hanterar datan.
• Ingen följer upp. Granskningsrätten finns, men ingen har ansvar för att använda den.
• Exit saknas. Ingen har tänkt på hur datan ska återlämnas och raderas när avtalet löper ut.

Så ser vi på det

Vi möter säkerhetskrav i IT-avtal från flera håll: som externa dataskyddsombud som granskar biträdesavtal, som informationssäkerhetsexperter som gör säkerhetsgranskningar av leverantörer och som interimsjurister som förhandlar avtalen. Vår erfarenhet är att problemet sällan är att organisationer inte vet att de ska ställa krav. Problemet är att kraven inte hänger ihop med verksamhetens faktiska risker, och att ingen äger uppföljningen efter undertecknandet.

Därför börjar vi alltid i klassningen och riskbedömningen. Vi skriver hellre färre krav som går att kontrollera än en lång bilaga som ingen läser. Ett bra säkerhetsavtal ska gå att använda den dag en incident inträffar: vem ringer vem, inom vilken tid och med vilken information. Kan avtalet inte svara på det har det inte gjort sitt jobb.

Vi ser också att 2026 är året då juridik och informationssäkerhet inte längre går att hålla isär. Cybersäkerhetslagen, GDPR och säkerhetsskyddslagen ställer olika krav, men leverantören möter dem i samma avtal. Den som samordnar kraven från början sparar både förhandlingstid och justeringar i efterhand.

— Jesper

Hjälp med säkerhetskraven i era IT-avtal

Behöver ni gå igenom befintliga leverantörsavtal mot de nya föreskrifterna, eller få stöd inför en större upphandling? Vi hjälper till med säkerhetsgranskningar, GDPR-granskningar och DPIA och med avtalsrådgivning via våra rådgivnings- och konsulttjänster, också i form av ett rådgivningspaket på 100 timmar. Vill ni hålla ordning på leverantörer, avtal och kontroller över tid kan det göras i vår GRC-plattform Trustview, som stödjer arbete enligt GDPR, ISO 27000, NIS2 och DORA.

Vanliga frågor

Måste alla IT-avtal innehålla ett biträdesavtal?

Nej, bara när leverantören behandlar personuppgifter för er räkning. Det gäller dock de flesta drift-, moln-, support- och SaaS-avtal, eftersom leverantören nästan alltid kommer åt någon form av personuppgifter. Är leverantören i stället självständigt personuppgiftsansvarig behövs inget biträdesavtal, men ansvarsfördelningen bör ändå regleras.

Räcker det att leverantören är ISO 27001-certifierad?

Certifieringen är en bra grund men ersätter inte avtalskraven. Kontrollera att certifikatets omfattning täcker den tjänst ni köper. Skriv sedan in de kontroller, rapporteringsfrister och granskningsrättigheter som er riskbedömning kräver.

Påverkar cybersäkerhetslagen avtal vi redan har?

Ja. Enligt MCF:s föreskrifter, som gäller från 1 oktober 2026, bör avtal som ingåtts före det datumet så långt som möjligt kompletteras med cybersäkerhetskrav, och riskerna med otillräckliga avtal ska hanteras. Börja med de leverantörer som har störst betydelse för era samhällsviktiga tjänster.

När behövs ett säkerhetsskyddsavtal i stället för en vanlig säkerhetsbilaga?

När leverantören får tillgång till säkerhetsskyddsklassificerade uppgifter eller deltar i säkerhetskänslig verksamhet. Säkerhetsskyddsavtalet kommer då utöver övriga säkerhetskrav, inte i stället för dem, och det ska vara undertecknat innan leverantören får tillgång.

Vem i organisationen ska äga säkerhetskraven i IT-avtalen?

Ledningen ansvarar för säkerhetsnivån, men det praktiska ägarskapet bör ligga hos en utpekad funktion, ofta CISO eller informationssäkerhetsansvarig i samarbete med jurist och dataskyddsombud. Det viktiga är att någon har ett uttryckligt ansvar för uppföljningen under hela avtalstiden.

Källor

• Upphandlingsmyndigheten: Informationssäkerhet vid offentlig upphandling
• MSB: Upphandla informationssäkert, en vägledning
• IMY: Säkerhetsåtgärder
• IMY: Personuppgiftsbiträdesavtal
• IMY: Beslut mot Statens servicecenter
• MCF: Krav på säkerhetsåtgärder som stärker cybersäkerheten
• MCFFS 2026:11 om säkerhetsåtgärder och ledningens utbildning
• Upphandlingsmyndigheten: Cybersäkerhetslagens (NIS2) påverkan på offentlig upphandling
• Upphandlingsmyndigheten: Säkerhetsskyddsavtal
• Upphandlingsmyndigheten: Säkerhetsskyddad upphandling
• PTS: Säkerhetsskyddsavtal

Rekommendationer

• Informationssäkerhet i offentlig sektor: nya krav 2026
• Standardavtalsklausuler GDPR: vad SCC kräver av dig 2026
• Säkerhetsskyddslagen
• Svenska företag måste följa NIS2 – trots försenad lag