IT bør derfor vurdere blant annet tilgangsstyring, beskyttelse av data, logging, integrasjonssikkerhet, sårbarhetshåndtering, hendelseshåndtering, driftskontinuitet, underleverandører og hva som skjer med data når avtalen avsluttes.
Sikkerhetskravene bør være konkrete og tilpasses virksomhetens risiko. Personvernregelverket bygger også på at tekniske og organisatoriske sikkerhetstiltak skal stå i forhold til risikoen ved behandlingen av personopplysninger.
Målet er ikke å finne en leverandør som svarer «ja» på flest mulig sikkerhetsspørsmål. Målet er å forstå hvordan sikkerheten faktisk er organisert, dokumentert og fulgt opp gjennom hele systemets levetid.
Før IT vurderer leverandørens sikkerhet, bør virksomheten forstå hva HR-systemet faktisk skal brukes til.
Et system som inneholder grunnleggende organisasjonsdata, har ikke nødvendigvis samme risikoprofil som et system som også behandler omfattende medarbeiderhistorikk, dokumenter og andre personopplysninger med høyere beskyttelsesbehov.
Start derfor med spørsmål som:
Dette gir IT et bedre grunnlag for å stille krav som faktisk passer virksomheten.
Prinsippene om dataminimering og innebygd personvern tilsier også at virksomheter bør begrense behandlingen til det som er nødvendig for formålet og bygge personvern inn i løsningene fra starten.
HR-data skal være tilgjengelige for dem som trenger informasjonen for å gjøre jobben sin – men ikke for alle.
IT bør derfor forstå hvordan systemet håndterer:
Autentisering: Hvordan bekrefter systemet hvem brukeren er?
Tilgangsstyring: Hvordan bestemmes det hva brukeren får se eller gjøre?
Roller: Kan forskjellige roller få ulike tilganger?
Administrative rettigheter: Hvordan kontrolleres brukere med særlig omfattende tilgang?
Endringer: Hva skjer når en medarbeider bytter rolle, avdeling eller slutter?
Det er også relevant å undersøke hvordan systemet kan inngå i virksomhetens eksisterende løsning for identitets- og tilgangsstyring.
Spør for eksempel om støtte for virksomhetens krav til enkel pålogging, flerfaktorautentisering og automatisert brukeradministrasjon.
Det viktigste er ikke bare hvilke teknologier systemet støtter, men om tilgangsmodellen passer virksomhetens egne sikkerhetsprinsipper.
En HR-medarbeider med tilgang til sin del av organisasjonen og en systemadministrator med omfattende rettigheter representerer ulike risikonivåer.
IT bør derfor undersøke hvordan leverandøren håndterer privilegerte tilganger.
Aktuelle spørsmål er:
Hvem kan få administratortilgang?
Kan administrative roller begrenses?
Hvordan godkjennes og fjernes slike tilganger?
Blir administrative handlinger logget?
Hvordan får leverandørens egne medarbeidere eventuell tilgang til kundedata?
Det siste punktet er særlig viktig.
Det bør være tydelig hvilke situasjoner som kan kreve leverandørtilgang, hvordan den autoriseres og hvordan aktiviteten kan spores.
Et system kan ha gode funksjoner for vanlige brukere og samtidig ha for svake kontroller rundt administrative rettigheter. Derfor bør disse vurderes separat.
IT bør forstå hvordan informasjonen beskyttes både når den lagres og når den flyttes mellom systemer.
Spør blant annet:
Hvordan krypteres data under overføring?
Hvordan beskyttes data som er lagret?
Hvordan håndteres sikkerhetskopier?
Hvordan er kundedata skilt fra andre kunders data?
Hvordan håndteres krypteringsnøkler og andre sikkerhetsmekanismer?
Kryptering er ett av flere tiltak som EDPB trekker frem når virksomheter vurderer hvordan personopplysninger skal sikres. Samtidig må sikkerhetsnivået vurderes ut fra risiko og sammenhengen dataene behandles i.
IT bør derfor unngå å bruke ett teknisk krav som et enkelt mål på om en løsning er «sikker».
Sikkerhet består av flere lag.
Et HR-system står sjelden alene.
Medarbeiderdata kan for eksempel deles med lønn, identitets- og tilgangsstyring og andre forretningssystemer.
Det betyr at sikkerhetsvurderingen også må omfatte hvordan data kommer inn og ut av systemet.
IT bør spørre:
Hvordan autentiseres systemer som kobler seg til?
Hvordan autoriseres tilgangen til bestemte data?
Kan integrasjoner begrenses til informasjonen de faktisk trenger?
Hvordan håndteres nøkler, tokens og andre autentiseringsmekanismer?
Logges datautvekslingen?
Hvordan varsles feil eller uvanlig aktivitet?
Et godt API er ikke bare et spørsmål om hvor enkelt det er å integrere. IT trenger også kontroll på hvem som kan hente eller endre data, og hvilke mekanismer som beskytter dataflyten.
Hvis dere vil gå mer i dybden på systemroller og dataansvar, kan dere lese «Hvilket system skal vedlikeholde hvilke medarbeiderdata?»
Når noe skjer i et HR-system, må virksomheten kunne forstå hva som har skjedd.
Logging kan være relevant for å undersøke spørsmål som:
Men det holder ikke at leverandøren svarer «vi har logging».
IT bør også forstå hva som logges, hvor lenge logger oppbevares, hvem som kan se dem og hvordan de kan brukes ved en hendelse.
Sporbarhet og logghåndtering er sentrale elementer i sikkerhetsarbeid og inngår også i europeisk veiledning for sikker behandling og sikker skytjenesteforvaltning.
Ingen programvare er ferdig med sikkerhetsarbeidet den dagen den settes i produksjon.
IT bør derfor undersøke hvordan leverandøren arbeider kontinuerlig med å finne og redusere risiko.
Spør blant annet:
Hvordan testes løsningen for sikkerhetssvakheter?
Hvordan håndteres oppdagede sårbarheter?
Hvordan prioriteres kritiske funn?
Hvordan håndteres sikkerhet i utviklingsprosessen?
Brukes eksterne sikkerhetsrevisjoner eller tester?
Hvordan dokumenteres oppfølgingen?
Sertifiseringer, revisjonsrapporter og sikkerhetstesting kan gi nyttig dokumentasjon. De bør likevel ses som deler av et større bilde.
En sertifisering viser ikke nødvendigvis at alle risikoer er eliminert. Den kan derimot gi IT mer informasjon om hvordan leverandøren arbeider systematisk med sikkerhet.
Spørsmålet bør ikke være om leverandøren kan garantere at en hendelse aldri vil skje.
Et mer nyttig spørsmål er:
Hva skjer dersom noe faktisk skjer?
IT bør undersøke:
Hvordan oppdages sikkerhetshendelser?
Hvem har ansvar for å håndtere dem?
Hvordan klassifiseres alvorlighetsgrad?
Når og hvordan blir kunden informert?
Hvordan samarbeider leverandøren med kunden under hendelsen?
Hvordan dokumenteres årsak, konsekvens og tiltak i etterkant?
Det er også relevant å forstå hvilke forpliktelser som er regulert i avtalen.
En moden hendelsesprosess handler både om teknologi, roller, kommunikasjon og læring.
Sikkerhet handler ikke bare om å hindre uautorisert tilgang.
Virksomheten må også kunne få tilgang til informasjonen når den trenger den.
IT bør derfor vurdere:
Hvordan tas sikkerhetskopier?
Hvordan beskyttes sikkerhetskopiene?
Hvordan gjenopprettes systemet etter en alvorlig hendelse?
Hvor ofte testes gjenoppretting?
Hvilke mål gjelder for tilgjengelighet og gjenoppretting?
Hvordan håndteres større driftsavbrudd?
Svarene bør vurderes opp mot hvor kritisk HR-systemet er for virksomheten.
Et system som inngår i onboarding, offboarding, tilgangsstyring eller lønnsrelaterte prosesser kan ha avhengigheter som gjør langvarig utilgjengelighet mer krevende enn det først kan se ut til.
ENISA fremhever blant annet tilgjengelighet, hendelseshåndtering, sårbarhetsstyring, datalivssyklus og logghåndtering som relevante områder ved styring av skytjenester.
Sikkerhetsvurderingen bør omfatte hele datalivssyklusen, ikke bare perioden systemet er i normal drift.
IT og personvernansvarlige bør forstå:
Hvor behandles og lagres data?
Hvilke underleverandører brukes?
Hvordan varsles kunden om endringer i underleverandører?
Hvordan eksporteres data dersom virksomheten bytter system?
Hvilke formater kan data eksporteres i?
Når slettes data etter at avtalen er avsluttet?
Hvordan håndteres sikkerhetskopier etter sletting?
GDPR stiller også krav knyttet til forholdet mellom behandlingsansvarlig og databehandler, og bruk av underleverandører må håndteres innenfor disse rammene.
De konkrete juridiske kravene bør kvalitetssikres av virksomhetens personvern- eller juridiske kompetanse.
Et av de viktigste grepene IT kan gjøre i en anskaffelse, er å gjøre sikkerhetskravene etterprøvbare.
I stedet for:
«Har dere gode rutiner for sikkerhet?»
spør:
«Hvordan dokumenterer dere sikkerhetsstyringen, og hvilken dokumentasjon kan vi få tilgang til?»
En enkel oversikt kan se slik ut:
| Område | Dokumentasjon IT kan be om |
|---|---|
| Sikkerhetsstyring | Sikkerhetspolicyer og relevante sertifiseringer |
| Ekstern kontroll | Revisjonsrapport eller uavhengig bekreftelse |
| Sikkerhetstesting | Beskrivelse av testprosess og oppfølging |
| Tilgangsstyring | Dokumentasjon av roller og administrative tilganger |
| Hendelser | Hendelseshåndteringsprosess |
| Kontinuitet | Dokumentasjon på backup og gjenoppretting |
| Personvern | Databehandleravtale og informasjon om underleverandører |
| Avslutning | Rutiner for eksport, oppbevaring og sletting |
ENISA har også anbefalt at sikkerhetskrav i anskaffelser gjøres konkrete nok til at virksomheten kan vurdere og følge dem opp gjennom tjenestens levetid.
Sikkerhetsvurderingen bør ikke komme som siste punkt før kontrakten signeres.
IT bør involveres tidlig nok til å påvirke:
Det gjør det enklere å oppdage krav som ikke kan løses uten store tilpasninger senere.
HR kan vurdere om løsningen støtter arbeidsprosessene. IT kan vurdere hvordan den passer inn i virksomhetens sikkerhetsmodell og tekniske miljø. Personvern, innkjøp og juridisk kompetanse kan samtidig ha ansvar for andre deler av vurderingen.
Sikkerhet ved valg av HR-system er derfor et tverrfaglig arbeid, ikke bare et spørsmål til IT.
CatalystOne publiserer informasjon om sikkerhet og personvern i sitt Trust Centre. Der finnes blant annet informasjon om sikkerhetsprosesser, revisjoner, sertifiseringer, hosting og databeskyttelse.
CatalystOne er sertifisert etter ISO 27001:2022 og gjennomgår en årlig ISAE 3000 type 2-attestasjon. CatalystOnes kundedata hostes i Microsoft Azure-datasentre i Sverige.
Slik dokumentasjon kan inngå i ITs leverandørvurdering sammen med virksomhetens egne krav, risikovurderinger og avtaleverk.
Sertifiseringer og tekniske tiltak erstatter ikke den vurderingen. Det avgjørende er om løsningen og leverandørens sikkerhetsmodell passer virksomhetens behov og risikobilde.
IT bør normalt ha en sentral rolle, men vurderingen bør også involvere relevante personer innen HR, personvern, informasjonssikkerhet, innkjøp og juridisk kompetanse. Hvem som bør delta, avhenger av virksomhetens organisering og risiko.
Nei. En sertifisering kan være nyttig dokumentasjon på systematisk sikkerhetsarbeid, men IT bør også vurdere blant annet tilgangsstyring, arkitektur, testing, hendelseshåndtering, kontinuitet og leverandørens konkrete løsning.
Det finnes ikke én kravliste som passer alle virksomheter. Prioriter krav ut fra hvilke data systemet skal behandle, hvilke prosesser det inngår i og konsekvensen dersom data blir utilgjengelige, endret eller tilgjengelige for uvedkommende. Dette samsvarer med den risikobaserte tilnærmingen i personvernregelverket.
Nei. Sikkerhet må følges opp gjennom hele levetiden til løsningen. Endringer i systemet, integrasjonene, leverandørkjeden eller virksomhetens eget risikobilde kan gjøre det nødvendig å gjennomgå krav og kontroller på nytt.
Det finnes ingen enkeltfunksjon eller sertifisering som alene avgjør om et HR-system passer virksomhetens sikkerhetsbehov.
IT trenger et helhetsbilde.
Hvilke data skal behandles? Hvem får tilgang? Hvordan beskyttes informasjonen? Hvordan oppdages avvik? Hva skjer ved en hendelse? Og kan leverandøren dokumentere svarene?
Når disse spørsmålene stilles tidlig i prosessen, blir det enklere å sammenligne leverandører på tydelige kriterier og velge en løsning som passer både HR-behovene og virksomhetens krav til sikkerhet og forvaltning.
(Artikkelen gir generell veiledning og erstatter ikke en konkret risikovurdering eller juridisk vurdering av virksomhetens forpliktelser.)