En säkerhetsbilaga ska beskriva vilka tekniska och organisatoriska åtgärder som gäller för en bestämd behandling. Den behöver gå att jämföra med hur tjänsten faktiskt fungerar. ”Vi använder kryptering och har säkerhetsrutiner” säger för lite om vilka uppgifter som skyddas, vem som ansvarar och hur skyddet följs upp.
Här får du en struktur och ett ifyllt exempel för en sådan bilaga. Den kan användas av en personuppgiftsansvarig som dokumenterar sin egen behandling eller granskar ett personuppgiftsbiträdes underlag. Syftet är att beskriva tillämpade åtgärder och synliga luckor, så att ett beslut kan fattas på ett korrekt underlag.
Vad artiklarna 28 och 32 kräver
Artikel 32 GDPR gäller både personuppgiftsansvariga och personuppgiftsbiträden. Säkerhetsnivån ska vara lämplig med hänsyn till riskerna, behandlingens förutsättningar, den tekniska utvecklingen och genomförandekostnader. Bestämmelsen tar bland annat upp konfidentialitet, integritet, tillgänglighet, motståndskraft, återställning och regelbunden kontroll av åtgärdernas effektivitet. Den innehåller ingen identisk checklista för varje organisation. GDPR: artikel 32.
Ett biträdesavtal ska enligt artikel 28 bland annat binda biträdet att vidta de åtgärder som krävs enligt artikel 32. En särskild namngiven bilaga är ett praktiskt sätt att göra beskrivningen tydlig, men förordningen föreskriver inte att dokumentet måste heta ”TOM” eller följa ett visst mallformat. Avtalsregleringen behöver vara konkret och anpassad till behandlingen. EDPB: riktlinjer 07/2020 om ansvariga och biträden.
Använd guiden om personuppgiftsbiträdesavtal för övriga avtalsfrågor. Säkerhetsbeskrivningen ersätter inte instruktioner om ändamål, underbiträden, incidenter, återlämning eller radering.
1. Avgränsa vad bilagan faktiskt täcker
Börja med tjänst, miljö, version och de behandlingar som omfattas. Ange vilka kategorier av uppgifter och registrerade som berörs samt vilka parter som ansvarar för driften. En koncernövergripande säkerhetspolicy säger inte automatiskt vilka funktioner som är aktiverade i just den köpta tjänsten.
Beskriv särskilt vad kunden måste konfigurera. En molntjänst kan erbjuda flerfaktorsautentisering utan att kunden har slagit på den. Ett avtal som bara räknar upp tillgängliga funktioner kan därför ge en felaktig bild av det verkliga skyddet. Skriv vilka åtgärder som ingår i tjänsten och vilka som kräver ett separat kundbeslut.
Utgå från systemkartan och dataflödena. Ta med relevanta administrativa gränssnitt, exporter, supportåtkomst och reservmiljöer. Om en funktion ligger utanför bilagan ska avgränsningen beskrivas tydligt och kopplas till det dokument som reglerar den.
2. Beskriv risk och skydd tillsammans
IMY beskriver informationssäkerhet som ett löpande arbete där verksamheten analyserar behov och risker, väljer åtgärder och följer upp skyddet. En bra bilaga visar resultatet av arbetet i en form som går att förstå och kontrollera. IMY: informationssäkerhet.
Koppla varje viktig åtgärd till det problem den ska hantera. Om risken är att en supporttekniker ser fler kunders uppgifter än uppdraget kräver behöver beskrivningen behandla åtkomstbegränsning, godkännande, spårbarhet och avslut av åtkomst. Ett allmänt påstående om att personalen har sekretessförbindelser täcker inte den tekniska behörighetsfrågan.
Bedöm också om åtgärden skapar ny behandling. Om alla användares aktiviteter loggas för ett säkerhetsändamål behövs fortfarande uppgiftsminimering, åtkomst och gallring för loggarna. Ett säkerhetsintresse gör inte obegränsad övervakning proportionerlig.
3. Ifyllt exempel på en säkerhetsbilaga
Följande ifyllda bilaga avser en helt fiktiv supporttjänst med kunders kontaktuppgifter och ärendehistorik. Åtgärderna illustrerar dokumentationsnivån i ett tänkt uppdrag; ingen verklig leverantör eller kundmiljö har granskats i exemplet.
Omfattning: Produktion, administrativ åtkomst och säkerhetskopior för supporttjänsten. Kundens identitetsleverantör och personalens lokala enheter beskrivs i kundens egna säkerhetsrutiner. Dokumentägare: tjänsteansvarig. Version: 1, daterad den 8 september 2026.
| Skyddsområde | Tillämpad åtgärd i exemplet | Ansvar och verifiering |
|---|---|---|
| Användaråtkomst | Individuella konton och roller som skiljer läsning av tilldelade ärenden från administration | Kunden godkänner roller; leverantören tillämpar dem och visar kontroll av åtkomstgränser |
| Privilegierad åtkomst | Administrativa uppgifter kräver särskild behörighet och flerfaktorsautentisering | Driftansvarig kontrollerar tilldelning, ändring och avslut i behörighetsärenden |
| Supportåtkomst | Åtkomst för felsökning är knuten till ett dokumenterat supportärende och begränsas till behovet | Supportansvarig godkänner; utförd åtkomst kan följas i skyddad logg |
| Transportskydd | Klientanslutningar och överföringen till bakomliggande applikation använder verifierad TLS | Plattformsteamet kontrollerar både yttre anslutning och intern delsträcka |
| Återställning | Säkerhetskopior hanteras skilt från vanliga användarkonton och återställning övas i avskild miljö | Drift dokumenterar uppnådd återställningstid och kvarstående beroenden |
| Radering | Ärenden och exporter omfattas av beslutade regler med angivna utlösande händelser | Tjänsteägaren granskar genomförandet och hanteringen av kopior |
| Förändringar | Säkerhetsrelevanta ändringar granskas före införande och följs upp efteråt | Utvecklings- och driftansvariga registrerar kontrollresultat och avvikelser |
Till tabellen hör faktiska parametrar och hänvisningar: vilken autentisering som används, den beslutade återställningsnivån, hur ofta respektive kontroll utförs och vilka dokument som visar resultatet. Om detaljerna ännu inte är fastställda ska de markeras som öppna punkter. Låt inte exemplet skapa ett avtalslöfte om en åtgärd som bara planeras.
4. Gör tekniska formuleringar möjliga att kontrollera
Skriv ”administrativa konton använder den beslutade autentiseringsmetoden och granskas vid rollbyte” i stället för enbart ”starka lösenord”. Den konkreta lösenords- och autentiseringspolicyn kan precisera återställning, tjänstekonton och hantering av förlorade faktorer. Kontrollera att bilagans omfattning även täcker reservkonton och alternativa inloggningsvägar.
För kryptering behöver omfattning och nyckelhantering framgå. Det räcker inte att namnge en algoritm om okontrollerade administratörskonton kan läsa både data och nycklar. Hänvisa till krypteringsrutinen och ange vem som ansvarar för varje del. Lägg aldrig privata nycklar, lösenord eller återställningskoder i den bilaga som skickas till kunder.
För tillgänglighet ska ni skilja säkerhetskopiering från verifierad återställning. Ange vilka data och beroenden som omfattas, vilken återställningsnivå som beslutats och vad senaste kontrollen faktiskt visade. Återställningsplanen med RTO och RPO ger underlaget för att beskriva detta utan att förväxla en målsättning med uppmätt förmåga.
5. Ta med organisatoriska åtgärder och ansvar
Tekniken behöver en fungerande beslutsordning. Beskriv vem som godkänner behörigheter, hur personal får relevanta instruktioner och vem som tar emot säkerhetsavvikelser. Ange hur behörigheter ändras när uppgifter byts och hur tillgång till tjänsten avslutas när en person lämnar organisationen.
Dokumentera kontaktvägar vid incidenter och hur biträdet bistår den ansvarige enligt avtalet. Blanda inte ihop biträdets underrättelse till kunden med kundens eventuella anmälan till IMY. Koppla arbetet till incidentrutinen, så att namn på funktioner, kontaktvägar och eskalering fungerar även utanför ordinarie arbetstid där riskerna kräver det.
En informationssäkerhetspolicy kan ge den övergripande ansvarsfördelningen. Bilagan bör sedan beskriva vad som gäller för den aktuella tjänsten. Undvik att hänvisa till ett internt dokument som motparten aldrig kan få tillräcklig information om för att bedöma skyddet.
6. Granska leverantörens bevis med rätt omfattning
Ett certifikat eller en granskningsrapport kan ge värdefullt underlag. Kontrollera vilken organisation, tjänst, plats och period som omfattas. Läs avgränsningar, undantag och kundens egna förutsatta åtgärder. En rapport om datacentrets fysiska säkerhet visar inte i sig att applikationens behörighetskontroller fungerar.
Bestäm granskningsdjup efter risk och osäkerhet. Ett frågeformulär kan ge en första överblick, men ett svar ”ja” behöver ibland följas av dokumentation, demonstration eller annan granskning. Det finns ingen allmän regel att ett visst certifikat alltid räcker för nyhetsbrev eller att en viss rapporttyp alltid krävs för alla HR-tjänster.
Spara varje öppen fråga med konsekvens och beslut. Ett exempel är: ”Leverantören beskriver dagliga säkerhetskopior men har inte visat återställning av kundbilagor. Tjänsteägaren begär komplettering före användning för ärenden där bilagorna är nödvändiga.” Det är mer användbart än ett generellt grönt statusfält för hela leverantören.
7. Håll gällande version och åtgärdsplan åtskilda
En bilaga ska visa vad som gäller nu. Planerade förbättringar får beskrivas, men med tydlig status och utan att räknas som införda. Ändringar som påverkar den avtalade säkerheten behöver hanteras enligt avtalet och bedömas utifrån behandlingens risker.
Artikel 32 kräver ett förfarande för regelbunden prövning av åtgärdernas effektivitet, men anger ingen gemensam årsfrist för alla kontroller. Välj frekvens och utlösande händelser efter behov. Nya system, förändrad supportmodell, säkerhetsincidenter eller en kontroll som misslyckats kan kräva tidigare omprövning.
Ett bra uppföljningsprotokoll visar vilken åtgärd som kontrollerades, med vilket underlag, vilket resultat som sågs och vem som tar nästa steg. Förvara det tillsammans med övriga bevis för ansvarsskyldighet. Gör det möjligt att återfinna den version som gällde när ett beslut eller avtal ingicks.
Vanliga frågor
Måste alla säkerhetsdetaljer publiceras?
Nej. Beskriv skyddet tillräckligt konkret för den relevanta mottagaren och ge fördjupande underlag genom en lämplig kontrollerad kanal. Skydda hemligheter och känslig teknisk information utan att använda sekretess som standardsvar på varje nödvändig granskningsfråga.
Kan samma bilaga användas för alla kunder?
En gemensam grund kan fungera om tjänsten och åtgärderna verkligen är desamma. Markera kundspecifika inställningar, avvikelser och ansvar. Säkerställ att bilagan omfattar den köpta versionen och de tillägg som faktiskt används.
Är en incident bevis på att bilagan var fel?
En incident behöver utredas. Bedöm vad som inträffat, vilka åtgärder som fanns och om de var lämpliga och fungerade. Dokumentet får inte ersätta faktiska bevis, men en incident betyder inte automatiskt att varje säkerhetsåtgärd varit otillräcklig.