I et selskap som Knowit skjer det mye utvikling på oppdrag fra kunder. I denne forbindelse kommer man selvfølgelig ofte opp i situasjoner hvor man lager systemer som behandler personopplysninger av forskjellig grad. Noen systemer behandler kun identifikatorer (kontaktinformasjon), mens andre systemer behandler personsensitiv informasjon. Og når vi i Knowit Secure er ute hos kunder opplever vi ofte problemstillinger som berører det samme. «Hvordan behandler vi dette ut ifra et GDPR ståsted?»
Det som kan være kjekt å vite er at det norske Datatilsynet har gitt ut en veileder for hvordan «Privacy by Design»/ «Privacy by Default» skal håndteres ved utvikling av systemer. Det er også laget en engelsk versjon som kan hentes på samme side.
Det er klart at kravet til «Privacy by Design/Privacy by Default» gjelder for systemer som behandler sensitive personopplysninger (rase, kjønn, seksuell legning, helseopplysninger eller fagforeningsmedlemskap), men for alle systemer som utvikles, bør man ivareta «Security by Design/Security by Default». Og mye av stoffet i veilederen er like aktuell for å ivareta sikkerhet i det nye produktet som for å ivareta Privacy.
Etter min mening bør alle ledere av utviklingsprosjekter ta med seg en kopi av denne guiden når de starter opp sitt prosjekt. Bruk en time eller to på å vurdere hvor mye av dette du bør/må ta med deg inn i det prosjektet du er ansvarlig for, skriv det inn i prosjektplanen og se til at det blir fulgt opp på linje med andre rammekrav som settes til det endelige produktet du skal levere. En annen ting som prosjektlederen kan ta med seg under armen er en liten matrise over hvilke krav som kan beskrive funksjonalitet som det endelige produktet skal ha. Her opplever jeg ofte at mottaker av produktet danner seg en oppfatning basert på de siste skriverier som har vært i media. For eksempel var det for en tid tilbake et IT-innbrudd på Stortinget i Norge, i etterkant må vi regne med at alle bestillere kommer til å legge stor vekt på at deres nye produkt skal ha kraftig tilgang- og autorisasjonskontroll. Eller når man har lest om systemer som inneholder store feil og mangler, så vil man kreve høy grad av integritet og datakvalitet innebygd i sitt nye produkt osv.
Jeg faller ofte tilbake på en oppstilling som har vist seg å tåle tidens tann. Det man ønsker er funksjoner som ivaretar forretningsmessige krav:
| Krav: | Beskrivelse: |
| Målrettethet |
Informasjonen skal være relevant og aktuell for forretningsprosessen og være levert: - i rett tid - korrekt - konsistent - på en anvendelig måte |
| Effektivitet |
Informasjon skal anskaffes og tilgjengeliggjøres gjennom optimal (produktiv og økonomisk) bruk av ressurser. |
| Konfidensialitet |
Sikkerhet for at kun autoriserte personer får tilgang til følsom eller gradert informasjon, og at det på forhånd er foretatt en gyldig identifisering og autentisering av personen. |
| Integritet |
Sikkerhet for at informasjonen og informasjonsbehandlingen er fullstendig, nøyaktig og gyldig, og et resultat av autoriserte og kontrollerte aktiviteter. |
| Tilgjengelighet |
Sikkerhet for at en tjeneste oppfyller bestemte krav til stabilitet, slik at aktuell informasjon er tilgjengelig ved behov. |
| Overensstemmelse |
Informasjon skal innfri lover, reguleringer/forskrifter og kontraktsmessige avtaler som forretningsprosessen er underlagt, for eksempel eksterne pålagte krav til informasjon. |
| Pålitelighet |
Informasjonen skal være formålstjenlig/hensiktsmessig og robust: - for ledelsen i styringen av virksomheten - for ledelsens utførelse av finansielle og lovpålagte rapporteringsoppgaver |
Forretningsmessige krav til bruk av IKT beskrevet på en allmenn-gyldig måte
Disse 7 punktene er ikke «orakelsvar» som gir en klar utforming, men de kan virke som knagger for prosjektlederen til å diskutere med bestiller hva som skal vektlegges i utviklingen av det nye produktet. Klarer man å konkretisere hva som trengs innenfor konfidensialitet, integritet og tilgjengelighet, ja så har man i det minste gjort et bevisst arbeid med å sikre «Security by Design/Security by Default».
Nå har jeg snakket om forberedelsene slik at man har en «verktøykasse» klar når man starter opp et prosjekt som må ivareta både Security by Design/Security by Default (alltid) og Privacy by Design/Privacy by Default (hvis det innbefatter personopplysninger). I neste blogginnlegg vil jeg snakke om risiko under prosjektgjennomføringen.