Skal du bruke reelle eller syntetiske data i utviklingsprosesser? Oftere enn ikke er det et kostnadsspørsmål, der reelle data ofte blir ansett som billigere. Preben Gustavsen argumenterer i dette innlegget for at du likevel bør vurdere å lage syntetiske datasett.
Sparer du penger ved å benytte reelle data i test- og utviklingsprosesser? Et stadig tilbakevendende tema i krysningspunktet mellom test- og utviklingsprosesser og informasjonssikkerhet er spørsmålet om kostnader.
En vanlig påstand å møte i prosjekter er at det å etablere syntetiske data for test krever for mye ressurser i form av tid og kapasitet, til at det kan prioriteres. Derfor er det nødvendig å kopiere data fra produksjonsmiljøet
for å komme videre. Samtidig krydres påstanden om at det er nødvendig å teste mot reelle data for å sikre god kvalitet i testgjennomføringen.
Ta vare på informasjonssikkerheten
At det koster å etablere syntetiske data for test er åpenbart, men er det nødvendigvis billigere å kopiere data fra produksjonsmiljøet? Informasjon som behandles i et produksjonsmiljø har normalt behov for å
sikres mot tap, utilsiktet endring og ikke minst mot innsyn fra uautoriserte personer. Å kopiere denne informasjonen til testformål skjer gjerne under radaren til de som skal verne om den, men behovene for informasjonssikkerhet faller
ikke bort for det.
Når informasjon kopieres ut fra produksjonsmiljøet så følger altså kravene til informasjonssikkerhet med, selv om ikke en sikkerhetsleder eller andre minner deg på det. Så, når vurderinger skal gjøres
om hva som koster minst må kostnader til sikkerhetstiltak og kontrollhandlinger inkluderes i regnestykket.
Dersom informasjonen som hentes fra produksjonsmiljøet inkluderer personopplysninger, kommer personopplysningsloven til anvendelse for test- og utviklingsprosessene. Det betyr alle tekniske miljøer hvor opplysningene behandles. Slik bruk
av personopplysninger krever selvsagt også at test og utvikling av programvare er innenfor det som utgjør lovhjemmel for behandlingen.
Så, sparer du fortsatt penger når du inkluderer mekanismer som sterk autentisering, logging, nettverkssegmentering, sikker lagring eller DLP? Hva om vi også ser på deler av internkontrollen som risikovurdering, oppfølging
av bruk av informasjonen, opplæring og bevisstgjøring, etablering og oppfølging av databehandleravtaler og ikke minst avvikshåndtering? Har du oversikt over hvem som tar kopier av datasettet, hvor det lagres og hvorvidt det
slettes når behovet er borte? Er programvareleverandøren din en databehandler? Dette er alle spørsmål du må ha et bevisst og avklart forhold til før datasett kopieres.
Sikre terskelverdiene med syntetiske data
Utover kostnadsspørsmålet skal det vurderes om testing holder like høy kvalitet når det ikke testes på reelle data – informasjon som gjenspeiler en virkelighet. I en del tilfeller er det et godt argument at programvare
må verifiseres mot et gyldig datasett, men det bør være mot slutten av utviklingsprosessen når det nærmer seg tid for å ta programvaren i bruk i produksjonsmiljøet. Generelt i testaktiviteter bør
det også testes mot syntetiske data for å sikre god kvalitet, blant annet med å sikre at terskelverdier på de ulike datatypene er samstemte over grensesnitt, at datatyping er konsistent og at ikke uventede verdier fører
til kjørefeil i koden.
I noen tilfeller vil det være i personvernets interesse at programvare testes mot reelle data, men det forutsetter som nevnt at krav til informasjonssikkerhet og internkontroll er ivaretatt. Derimot er det en forutsetning at denne vurderingen er
gjort, at beslutningen er forankret med den behandlingsansvarlige og at informasjon om behandlingen dekker dette temaet slik at den registrerte vet at opplysninger om en selv benyttes også til støttefunksjoner som kvalitetssikring. At
det kan være i personvernets interesse å bruke personopplysninger i test innebærer at personvernulempen åpenbart oppveies av fordelen det gir.
Ser vi til nytt regelverk for personvern (GDPR) får den behandlingsansvarlige større handlingsrom til selv å vurdere hva som er i tråd med opprinnelig formål med behandlingen, men samtidig settes det større krav til
kvalitet i vurderinger som skal gjøres. Den behandlingsansvarlige må i større grad enn før måtte stå til ansvar for vurderinger og beslutninger knyttet til personvern.
Gode beslutningsanalyser for å ta det beste valget
For å være sikker på å velge den mest kostnadseffektive tilnærmingen til test- og utvikling, og samtidig ivareta kvalitet og behov for informasjonssikkerhet, bør den som eier informasjonen sørge for at det gjøres
gode beslutningsanalyser.
Kostnader til etablering av et syntetisk datasett som kan gjenbrukes på tvers av prosjekter over tid må settes opp mot kostnader for å etablere tilfredsstillende informasjonssikkerhet. I datasett med personopplysninger skal også
personvernkonsekvensen vurderes. I tilfeller hvor data som skal behandles ikke finnes allerede, må dette skapes uansett. Har man etablert et syntetisk sett, så har man ressursene, kunnskapen og metodene for å gjøre dette når
man skal skape tilstander som ikke allerede finnes. Dette bidrar til å holde kostnadene nede over tid. Min påstand er at mange vil bli overrasket over hvor billig det er å etablere syntetiske datasett samtidig som kvaliteten i testprosessen
heves.
Jeg benytter samtidig anledningen til å oppfordre eiere av nasjonale registre i forvaltningen til å etablere syntetiske datasett for test- og utviklingsformål slik at andre virksomheter enkelt kan teste mot dine tjenester og for å
bidra til bedre forutsigbarhet og lavere kostnader i alle fremtidige utviklingsprosjekter. Ved å legge til rette for at andre kan utvikle tjenester basert på dine data bidrar du til å digitalisere Norge!