Baggrund for de interne kontroller i GDPR- og compliance-arbejdet

Praksis viser, at det kan være forbundet med store bøder, hvis der er de mindste udfordringer med data-sikkerheden. Noget så simpelt som manglende opdatering af software, kombineret med et vellykket hack, der udnytter, at softwaren ikke er opdateret, kan udløse en betydelig bøde. Når DPO’en kommer på besøg i it-afdelingen, er det derfor helt centralt, at de rigtige spørgsmål stilles og belyses på den rette måde, som man dels sikrer, at alting er, som det bør være, og dels at der kan dokumenteres compliance i forhold til reglerne.

GDPR & it-compliance: Devil is in the detail

DPO’en kan f.eks. spørge til, om software bliver (sikkerheds)opdateret, og om der findes en procedure for dette. Hvis svaret er ja, kan DPO’en tro, at alting er i skønneste orden. Men djævelen ligger i detaljen: Måske svares der kun ja til, at noget software opdateres, og måske dækker opdateringsproceduren kun nogle dele af softwaren – f.eks. windowsklienter.

Ved siden af windowsklienterne findes ofte klienter med andre styresystemer som Apple og Linux, tablets og mobiltelefoner med Android. Der findes også typisk en række servere i organisationen med f.eks. et virtuelt miljø og mange virtuelle servere, Microsoft-servere, Linux-servere, databaser og meget andet, som hoster organisationens forretningssystemer, ERP-platforme, CRM-systemer, HR-databaser, data warehouse platforme, storage, backup, telefoni, videoovervågning m.v.
Videre findes der som regel en masse netværksudstyr, routere, switche og access points. Dette udstyr er måske ikke blevet opdateret, siden det blev sat op, har hard-codede administrator-logins og understøttes måske ikke teknisk set af fabrikanten længere.

Foruden ovenstående kan der være forskellige former for udstyr, som måske falder uden for it-afdelingens ansvarsområde, men som alligevel er på netværket – f.eks. alarmudstyr, videovervågning, styring af luft og varme og lagersystemer. Denne type udstyr kan siges at være en del af Internet of Things, og der ses en stigende tendens til, at denne type udstyr anvendes til at hacke sig ind i organisationerne uden at blive opdaget før skaden allerede ER sket.

Eksterne brugere, rettighedsstyring og cloud-tjenester - husk de øvrige aktiører it-økosystemet

Eksterne konsulenter får adgang til virksomhedens netværk med deres udstyr, og medarbejderne som medbringer deres eget udstyr og måske / måske ikke kan få adgang til nogle af virksomhedens ressourcer. Der er et stort rum for, at dagligdags handlinger ikke kortlægges, og at DPO’en ikke får spurgt ind til de rette tekniske forhold. Altsammen blot i forhold til til opdateringer af software og systemer. Hertil kommer alle de andre områder, der også skal spørges ind til:

• Oprettelse og nedlæggelse af brugere
• Rettigheder hos brugerne
• Leverandørstyring
• Brug af cloud-tjenester
• Hændelses-rapportering
• Beredskab
• Backup
• Kryptering af udstyr og kommunikation og meget mere. 

Interne kontroller med udgangspunkt i standarder

Sikkerhedsstandarden ISO27002 og fra 2024 også NIS2, indeholder en række kontroller, som organisationen kan bruge som inspiration til, hvilke sikkerhedstiltag, der skal etableres og kontrolleres. Standarden kræver, at organisationen tager action, og kontrollerne er lavet med formen: ”Du skal…”.
DPO’en kan på den måde vende kravet om til et spørgsmål: ”Har vi gjort….”, og så bede om dokumentation herfor, fra den som ejer kontrollen. At bruge en sikkerhedsstandard betyder, at man kommer hele vejen rundt om sikkerheden, og er altså en garanti for, at man ikke glemmer noget. ISO27001 er ikke den eneste mulighed. Man kan også bruge NIST 800-53, ISF eller en mere simpel kontrolliste som CIS18.

Forordningen indeholder mange andre ting end det sikkerhedsmæssige – f.eks. principperne i artikel 5: formålsbegrænsning, dataminimering, sletning, m.v. Efterlevelse af disse øvrige krav skal også kontrolleres og dokumenteres. Standarden kan derfor ikke stå alene. Alle de krav, som forordningen indeholder, kan mappes sammen med sikkerhedskravene, så man får et samlet kontrolframework. Hvis organisationen skal efterleve andre forhold – anden lovgivning, branchestandarder m.v. – kan disse også med fordel mappes ind i dette kontrolframework.

Udformningen af interne kontroller

Organisationen bør lave en proces for etablering, vedligeholdelse og godkendelse af interne kontroller.

Der bør først og fremmest være en beskrivelse af kontrollen, og den bør referere til de krav, som den har til formål at kontrollere. Videre bør der tages stilling til, hvem der ejer kontrollen (den der skal kontrolleres) og hvem der kontrollerer (auditor). Der bør være funktionel uafhængighed mellem kontrolejer og auditor, således at der mindst mulig sandsynlighed for, at parterne inddrager usaglige betragtninger i forhold til vurderingen af, om kontrollen er efterlevet. Herefter bør der tages stilling til, om hele eller dele af kontrollen kan gennemføres automatiseret. Kan man f.eks. automatisk udtrække en log (eller flere), som giver en opdateringsstatus på software og hardware i organisationen og sammenligner med nyeste version? Yderligere bør der tages stilling til, hvornår kontrollen gennemføres og hvor hyppigt. Disse kontroller lægges ind i et årshjul.

Når selve kontrollen gennemføres, interviewer auditor kontrolejer og får evt. gennemgået det tekniske materiale (f.eks. logs), som det på forhånd er fastlagt er tilknyttet auditen. Auditor registrerer, om den forgange periode giver anledning til bemærkninger, og om der skal foretages justeringer i den kommende periode, som kontrolejeren skal etablere. Desuden noterer auditor om de to forhold er tilfredsstillende eller ej – f.eks. ved at markerer dem med rød, gul, grøn. Auditor samler op på sine audits hen over året og rapporterer mindst årligt til ledelsen, hvad status er og hvad auditor anbefaler, der skal iværksættes af nye tiltag.

Links

For relateret materiale, læs vores artiklen om Governance.