Et sikkerhetsvedlegg skal beskrive hvilke tekniske og organisatoriske tiltak som beskytter den aktuelle behandlingen av personopplysninger. Det bør gjøre det mulig å forstå hva som er gjennomført, hvem som har ansvar og hvordan virkningen kontrolleres. En liste med ord som kryptering, tilgangsstyring og sikkerhetskopi er et svakt grunnlag hvis omfang og utførelse er uklare.
Artikkel 32 i GDPR krever egnede tiltak vurdert mot risikoen og angir relevante hensyn og beskyttelsesmål. Artikkel 28 knytter databehandleravtalen til gjennomføring av nødvendige sikkerhetstiltak. Et eget vedlegg kan være en praktisk måte å dokumentere dette på, men regelverket fastsetter ikke ett universelt vedleggsformat som passer alle avtaler. NSMs grunnprinsipper kan støtte valg av tiltak i norske virksomheter.
Avgrens tjenesten og opplysningene først
Angi hvilken behandling, tjeneste og hvilket miljø vedlegget gjelder. Beskriv relevante datakategorier, grupper av registrerte og tilgangsbehov. En leverandør kan ha flere tjenester med forskjellige sikkerhetsegenskaper. Et generelt konserndokument sier ikke nødvendigvis hva som er aktivert i kundens konkrete løsning.
Knytt avgrensningen til databehandleravtalen og relevante beskrivelser av behandlingen. Skill produksjon, test, support og sikkerhetskopier der beskyttelsen eller opplysningene er forskjellige. Vedlegget bør også forklare hvilke tiltak kunden må utføre selv, slik at ansvar ikke faller mellom partene.
Beskriv risikoen som tiltakene skal håndtere
Vurder uautorisert tilgang, utilsiktet endring, tap og utilgjengelighet ut fra den konkrete behandlingen. Beskriv konsekvensene for de registrerte, ikke bare økonomisk tap for virksomheten. Et system med begrensede kontaktopplysninger kan ha et annet beskyttelsesbehov enn en tjeneste med omfattende helserelatert informasjon.
Tiltakene må svare på risikoen. En sikkerhetskopi reduserer ikke automatisk risiko for urettmessig lesing, og kryptering løser ikke alene feil i tilgangsmodellen. Koble derfor hvert viktig tiltak til et beskyttelsesbehov. Dette gjør det lettere å vurdere om en leverandørs standardpakke faktisk dekker det relevante problemet.
Bruk fire opplysninger for hvert tiltak
Beskriv tiltaket, omfanget, ansvarlig rolle og kontrollen som viser at det virker. Angi også kjente begrensninger. «Tilgang kontrolleres» kan bety alt fra en etablert gjennomgang til at noen av og til ser på en liste. Formuleringen bør gjøre det mulig for en annen person å forstå hva som faktisk skjer.
| Del av beskrivelsen | Eksempel på nødvendig presisering |
|---|---|
| Tiltak | Tilgang gis etter godkjent rolle og dokumentert behov |
| Omfang | Produksjonsmiljøet for den definerte kundetjenesten |
| Ansvar | Systemeier godkjenner, drift oppretter og avslutter |
| Kontroll | Rolleutvalg sammenholdes med godkjenninger og avsluttede oppdrag |
| Begrensning | En bestemt eldre integrasjon håndteres gjennom et eget dokumentert unntak |
Dette er en struktur som kan brukes i flere deler av vedlegget. Den bør fylles med dokumenterte forhold. Hvis tiltaket er planlagt, merkes det som planlagt med ansvar og forutsetninger, ikke beskrives som gjennomført sikkerhet.
Konfidensialitet: hvem kan lese opplysningene?
Beskriv identitetskontroll, rollefordeling og godkjenning av tilgang. Ta med administratorer, tjenestekontoer og leverandørtilgang. Angi hvordan tilganger avsluttes når ansatte eller konsulenter ikke lenger trenger dem. Skill vanlig bruk fra privilegert administrasjon der dette inngår i løsningen.
Henvis til passordpolicy og autentisering for det detaljerte oppsettet, men behold en forståelig beskrivelse i vedlegget. Dokumenter også fysisk adgang der den er relevant. En skyleverandørs kontroll av datasenteret fritar ikke kunden fra å beskytte arbeidsflater, utskrifter og egne enheter.
Integritet: hvem kan endre og videreformidle?
Beskriv hvordan endringer i opplysninger og konfigurasjon begrenses og kan undersøkes. Vurder nødvendige godkjenninger, validering og sporbarhet. En rettighetsmodell som skiller lesing fra endring kan være sentral, men virkningen må kontrolleres i den faktiske applikasjonen.
Ta med overføringer og eksport. En fil kan være korrekt i hovedsystemet, men endres eller knyttes til feil person ved en integrasjon. Bruk riktighetsarbeidet til å beskrive relevante kontroller. Skill sikkerhet mot uautorisert endring fra den bredere plikten til å holde opplysningene tilstrekkelig riktige for formålet.
Tilgjengelighet og gjenoppretting
Beskriv hvilke kopier som lages, hva de omfatter og hvordan de beskyttes. Angi hvem som kan gjennomføre gjenoppretting, hvilke avhengigheter som finnes og hvordan resultatet prøves. Unngå å likestille en vellykket sikkerhetskopijobb med demonstrert evne til å gjenopprette en brukbar tjeneste.
Knytt vedlegget til gjenopprettingsplanen. Hvis bestemte mål avtales, må de være forståelige og knyttet til omfang og forutsetninger. Skill kundens forventning fra det som faktisk er dokumentert eller avtalt med leverandøren. Et teknisk mål uten kapasitet og kontroll kan gi et misvisende bilde av beredskapen.
Kryptering og pseudonymisering må beskrives presist
Oppgi hvor beskyttelsen gjelder og hvem som kan dekryptere eller koble opplysningene tilbake. Kryptering under transport og ved lagring har forskjellige funksjoner. Et vedlegg bør ikke gi inntrykk av at leverandøren mangler tilgang til klartekst hvis leverandøren faktisk behandler innholdet som del av tjenesten.
Bruk krypteringsvurderingen og relevante nøkkelrutiner som underlag. Dersom pseudonymisering brukes, forklar skillet mellom analysedata og koblingsnøkkel. Tiltaket kan redusere eksponering uten å gjøre dataene anonyme. Beskriv den faktiske virkningen og hvilke scenarioer som fortsatt krever andre tiltak.
Utfylt eksempel for en avgrenset kundeportal
Følgende eksempel viser hvordan et vedlegg kan bli konkret. Det beskriver en tenkt løsning og er ikke en påstand om en bestemt leverandør:
| Område | Eksempel på utfylt beskrivelse |
|---|---|
| Omfang | Kundeportalens produksjonsmiljø med kontaktopplysninger og henvendelser |
| Tilgang | Saksbehandlere får rolle etter systemeiers godkjenning; administratorarbeid utføres med særskilt konto |
| Deling | Eksterne mottakere får avgrenset tilgang til den aktuelle saken; åpne lenker brukes ikke i denne løsningen |
| Logging | Administrative rolleendringer og relevante eksporter registreres; hendelser undersøkes av navngitt driftsrolle |
| Gjenoppretting | Drift gjennomfører en planlagt kontroll av database og vedlegg, med faglig bekreftelse fra systemeier |
| Avslutning | Oppdragsavslutning utløser stenging av tilgang og kontroll av relevante arbeidskopier |
| Åpent punkt | En eldre eksportjobb skal erstattes; midlertidig tilgang og videre oppfølging er dokumentert separat |
Eksemplet viser en konkret beskrivelse, men etablerer ikke at akkurat disse tiltakene er tilstrekkelige for alle kundeportaler. Den faktiske risikovurderingen, teknologien og avtalen må avgjøre innholdet. Fjern formuleringer dere ikke kan dokumentere i egen leveranse.
Beskriv organisatoriske tiltak som utførte oppgaver
Ta med opplæring, hendelseshåndtering, leverandøroppfølging og endringsstyring der de er relevante. Skriv hva ansatte skal gjøre og hvem som følger opp. «Alle ansatte er bevisste på personvern» er vanskelig å etterprøve. En konkret rutine for feil mottaker, mistet utstyr og varsling kan derimot demonstreres gjennom en egnet arbeidsøvelse.
Knytt ansvaret til informasjonssikkerhetspolicyen. Vedlegget bør ikke inneholde et parallelt sett roller som strider mot virksomhetens faktiske organisering. Kontroller også at eksterne driftsleverandører kjenner hvilke oppgaver de har og hvordan de dokumenterer sin del.
Kontroller underleverandører og kundens plikter
Beskriv hvordan relevante sikkerhetskrav videreføres og følges opp hos underdatabehandlere. Kunden trenger et tilstrekkelig grunnlag for å forstå beskyttelsen, men ikke nødvendigvis alle interne tekniske detaljer. En samlet beskrivelse må likevel ha et klart omfang og ikke skjule sentrale avvik i tjenestekjeden.
Vær tydelig på kundestyrte innstillinger. Hvis kunden må aktivere en funksjon eller vedlikeholde roller, bør dette fremgå som en konkret oppgave. Leverandørens tilgjengelige funksjon er ikke bevis på at kunden har tatt den i bruk. Kontroller sammenhengen mellom avtale, administrasjonsgrensesnitt og faktisk arbeidsmåte.
Behandle unntak og endringer uten å svekke oversikten
Et unntak bør beskrive risiko, begrunnelse, kompenserende tiltak og videre oppfølging. Det er ingen dispensasjon fra regelverket. Vurder om endringen påvirker det sikkerhetsnivået kunden har lagt til grunn, og håndter kommunikasjon og avtalevilkår etter den konkrete situasjonen.
Versjoner vedlegget og knytt det til riktig avtale. En ny leverandørpresentasjon bør ikke automatisk erstatte det dokumenterte grunnlaget uten gjennomgang. Bevar nødvendig historikk slik at virksomheten kan forstå hva som gjaldt da en hendelse eller behandling fant sted.
Avslutt med kontrollbevis og et tydelig ansvar
Velg relevante bevis som viser gjennomføring: godkjente tilganger, kontroll av gjenoppretting, oppfølging av avvik eller verifisert konfigurasjon. Angi dato, system og omfang. Beviset bør være tilstrekkelig uten å inneholde unødvendige personopplysninger eller hemmelige sikkerhetsverdier.
Den ferdige leveransen er et vedlegg som beskriver den aktuelle behandlingen og kan brukes ved avtaleoppfølging og endringer. Det skal gjøre det klart hvilke tiltak som finnes, hvilke forutsetninger kunden må oppfylle og hvilke spørsmål som fortsatt er åpne. Slik blir dokumentasjonen et brukbart grunnlag for å vurdere sikkerhet over tid.