Gæstebloggen

Øget regulering stiller nye krav til it-udvikling

Første halvdel af 2018 har været præget af, at en række store regulatoriske regelsæt er trådt i kraft.

I Danmark blev PSD2 fx implementeret ved lov om betalinger den 1. januar 2018, NIS-direktivet blev implementeret ved lov om net- og informationssikkerhed (NIS-loven) den 10. maj 2018 med tilhørende sektor specifikke bekendtgørelser og General Data Protection Regulation (GDPR) trådte i kraft den 25. maj 2018.

Lov om betalinger, NIS-loven og GDPR indeholder blandt andet nye og/eller reviderede regulatoriske tekniske og sikkerhedsmæssige krav, som en række virksomheder skal overholde.

Lov om betalinger, NIS-loven og GDPR står naturligvis ikke alene, og man må nok også forvente, at tendensen til øget regulering - særligt også på cybersecurity området – vil fortsætte.

I takt med at mængden af regulatoriske krav øges, stiger nødvendigheden af at virksomheder ved anskaffelse af it-systemer, tænker de regulatoriske krav ind i udviklingsprocessen på et så tidligt stadie som muligt.

Det er præcist denne tankegang, som er afspejlet i GDPR art. 25's princip om data protection by design, og som i lige så høj grad bør anvendes ved it-udvikling i forhold til anden regulering i form af compliance by design.

Annette Printz Nielsen er senioradvokat i Bird & Bird. Illustration: Privatfoto

It-udvikling ud fra princippet om compliance by design er ikke et nyt fænomen, men den øgede mængde af regulering stiller skærpede krav til både kundens, it-leverandørens og eksterne rådgiveres viden om samspillet mellem regulatoriske forhold og teknologi.

Det øgede regulatoriske landskab

GDPR er et af de regulatoriske regelsæt, som langt de fleste virksomheder i en eller anden grad er omfattet af.

For at være compliant med GDPR skal en virksomhed fx kunne begrænse adgangen til data, håndtere kravet om dataportabilitet og retten til at blive glemt.

Særligt retten til at blive glemt giver en del virksomheder udfordringer i forhold til deres backup systemer, idet det ikke nødvendigvis er muligt at slette udvalgt data.

Disse udfordringer kan være svære at løse i forhold til eksisterende systemer, men netop i forbindelse med nye it-anskaffelser er der mulighed for i udviklingsfasen at tage højde herfor, hvis man udvikler efter princippet om data protection by design eller compliance by design.

Et andet eksempel på regulering, der indeholder regulatoriske tekniske krav, er lov om betalinger som fx pålægger udbydere af betalingstjenester en forpligtelse til anvendelse af stærk kundeautentifikation, når en bruger fx tilgår sin betalingskonto online eller iværksætter en elektronisk betalingstransaktion.

For at kundeautentifikation anses for at være stærk, skal den være baseret på brugen af to eller flere elementer (to-faktor autentifikation), der er kategoriseret som viden (fx en kode), besiddelse (fx en token) eller en iboende egenskab (fx et fingeraftryk).

De nærmere tekniske specifikationer herfor følger af de regulatoriske tekniske standarder for stærk kundeautentifikation og fælles og sikre åbne standarder for kommunikation, som dog først træder i kraft i september 2019.

Det betyder i praksis, at når finansvirksomheder omfattet af lov om betalinger anskaffer et nyt it-system - fx et nyt frontend system - skal det pågældende it-system overholde de regulatoriske krav om to-faktor autentifikation, som påhviler den pågældende finansvirksomhed i lov om betalinger, og på sigt de regulatoriske tekniske standarder for stærk kundeautentifikation og fælles og sikre åbne standarder for kommunikation.

Dette er naturligvis krav, som der bør tages højde for tidligt i udviklingsfasen.

Endelig er NIS-loven et godt eksempel. NIS-loven er rettet mod specifikke ansvarlige aktører i form af operatører af væsentlige tjenester (OVT) og udbydere af digitale tjenester (UDT).

NIS-loven indeholder krav om sikring af et sikkerhedsniveau, der står mål med risikoen i overensstemmelse med udbyderens risikovurdering, herunder ved at implementere passende foranstaltninger til sikring af tilgængelighed, autenticitet, integritet og fortrolighed samt sikre, at tredjepart opretholder en tilsvarende sikkerhed.

Der skal udarbejdes en sikkerhedspolitik og en risikovurdering, som skal udgøre fundamentet for de passende sikkerhedsforanstaltninger.

Kravene er som udgangspunkt ikke konkrete eller formbestemte i NIS-loven, men der er forholdsvis konkrete anbefalinger, der skal tænkes ind i it-design og arkitektur, indkøbsproces og leverandørstyring.

Der skal eksempelvis i sikkerhedspolitikken tages stilling til systematisk forvaltning af net- og informationssystemer, fysisk og miljømæssig sikkerhed, forsyningssikkerhed, adgangskontrol og adskillelse af net og systemer samt særlige sikkerhedsforanstaltninger for kritiske funktioner såsom administrative funktioner.

I forhold til adskillelse af net og systemer, kan det i særlige højrisikotilfælde være nødvendigt at skelne mellem elementer såsom datastrømme og it-ressourcer, der tilhører henholdsvis en kunde, en gruppe af kunder, udbyderen af digitale tjenester eller en tredjepart.

Derudover medfører kravene til indberetning af sikkerhedshændelser, at det kan være nødvendigt, at implementere detekteringssprocesser (intrusion detection) og -procedurer, der sikrer rettidig og tilstrækkelig bevidsthed om unormale begivenheder.

Selvom NIS-loven ikke indeholder konkrete it-krav, da indebærer den risikobetonede tilgang, at it-sikkerhed og indberetning af sikkerhedshændelser skal tænkes ind i hele it-arkitekturen og leverandørhåndteringen.

NIS-loven indebærer dermed et krav om security by design.

Brobygning mellem regulatoriske krav og it-udvikling

Det er helt essentielt for at kunne udvikle it-systemer ud fra princippet om compliance by design, at der bygges bro mellem de regulatoriske krav og de konkrete it-løsninger.

De regulatoriske krav er oftest udformet meget generelt, og det er ikke nødvendigvis nemt at overføre de regulatoriske krav til konkrete tekniske løsninger, da det i høj grad er jura, der skal transformeres til teknologi.

Et eksempel herpå er dét krav, der følger af lov om betalinger om stærk kundeautentifikation. Stærk kundeautentifikation skal i henhold til lov om betalinger baseres på anvendelsen af to eller flere elementer kategoriseret som viden, besiddelse og iboende egenskab.

Når dette krav overføres på en konkret teknisk løsning skal der fx tages stilling til, hvad der helt konkret ligger i "besiddelse", og man kan i den forbindelse fx stille spørgsmålstegn ved, om det er muligt at være i besiddelse af en e-mail, som kan tilgås fra flere enheder, eller om indholdet i en e-mail nærmere udgør viden.

For at kunne formulere de krav til et it-system, som er nødvendige for overholdelse af de relevante regulatoriske krav, og dermed udvikle et it-system ud fra princippet om compliance by design, kræver det på kundesiden en indgående forståelse af de regulatoriske krav og en betydelig forståelse af den tekniske løsning, som kunden ønsker at erhverve.

I større regulerede virksomheder vil kunden typisk have denne viden i forening af kundens Chief Information Officer, Data Protection Officer, Legal & Compliance afdeling samt it-afdeling, mens de mindre regulerede virksomheder (fx de mindre fintechs) ofte i mindre grad vil have samme interne forankring af regulatoriske viden.

På it-leverandørsiden kræver det i tillæg til den tekniske forståelse – som it-leverandøren naturligvis er i besiddelse af – som minimum en vis indsigt i de regulatoriske krav for at kunne udvikle en teknisk løsning, som opfylder disse regulatoriske krav.

Den indsigt er naturligvis noget, som it-leverandøren kan tilegne sig gennem samarbejdet med kunden, men det kræver et tæt samarbejde på tværs af førnævnte funktioner.

Som ekstern rådgiver – uanset om det er som advokat eller konsulent og uanset om det er på kunde- eller leverandørsiden – kræver det ligeledes i stigende grad indgående kendskab til både de regulatoriske krav, de it-retlige forhold samt en generelt teknisk forståelse for de løsninger der udvikles.

Ansvaret for overholdelse af de regulatoriske krav

Helt generelt påhviler de regulatoriske krav dén virksomhed, som er genstand for reguleringen - det vil altså sige kunden - og det er derfor i forhold til de pågældende tilsynsmyndigheder også kunden, der er genstand for sanktioner, hvis ikke kunden lever op til de regulatoriske krav.

Kunden bør derfor nøje overveje i hvilket omfang, kunden vælger af "overvælte" de regulatoriske krav på it-leverandøren.

Set i lyset af konsekvenserne af non-compliance, er det næppe en hensigtsmæssig løsning helt generelt at "overvælte" ansvaret fx ved i kravspecifikationen at anføre, at it-løsningen skal være GDPR compliant.

Det vil også typisk være kunden, der har den nødvendige detailviden om, hvilke regulatoriske sektorspecifikke krav, kunden skal leve op til for at være compliant, og kunden vil derfor også oftest være nærmere til at specificere de konkrete krav end it-leverandøren.

I praksis vil kunden og it-leverandøren typisk drøfte og nå til enighed om disse forhold i løbet af udviklingsprocessen, men under alle omstændigheder bør kunden altid verificere, at de anvendte løsninger lever op til de regulatoriske krav, som kunden er underlagt, da det i sidste ende er kunden - uanset at det er it-leverandørens ansvar at levere en løsning der fx er GDPR compliant - der er underlagt de regulatoriske krav og som er genstand for eventuelle sanktioner fra tilsynsmyndighederne.

Værdiskabende udvikling

Tendensen med øget regulering af tekniske og sikkerhedsmæssige krav vil formentlig fortsætte, og behovet for at udvikle it-systemer ud fra princippet om compliance by design bliver derfor også kun mere relevant.

It-udvikling ud fra princippet om compliance by design er ikke kun en nødvendighed men kan også være utrolig værdiskabende for kunden.

Det kræver dog et tæt samarbejde mellem kunden og it-leverandøren, og at parterne eller disses eksterne rådgivere formår at overføre de regulatoriske krav til tekniske løsninger, der dels er compliant og dels er innovative og værdiskabende.

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Henrik R Jørgensen

Der er nogle gode pointer, der centrerer sig om at tænke sikkerhed og privacy ind i systemer/løsninger på så tidligt et tidspunkt som muligt.

Selv hvis man har med danske leverandører at gøre, kan man ikke som dataansvarlig forlige sig på at GDPR-krav i en RfP er tilstrækkelig. Du er nødt til at have din rådgiver med i designfasen og testfasen også.

Sletning af enkeltoplysninger i backup (som følge af en anmodning herom), ville jeg dog ikke overveje at bruge tid på, så længe backup'en har en begrænset levetid. Som datasubjekt har man ingen rimelig forventning på sletning af sådanne data per anmodning, med mindre de er blevet gendannet i systemet.

Det sidste er ansporet af Annettes glimrende indlæg, men ikke møntet på hende:

Uanset om det måtte være ilde hørt i it-kredse - der er tilsyneladende tale om en kollektiv undladelsessynd: Kan vi ikke godt holde op med at tale om sletteret og -pligt som noget nyt og banebrydende? De to ting har været en del af dansk ret siden 1978. Just get it done. Tak :)

Morten Madsen

Der er intet forkert i det du skriver, men for mig var det blot opremsning af en masse kendt stof.

Alle kan skrive man skal huske at lave et system, der er "compliance by design"

Færre kan designe et system, der er "compliance by design".

Ret få kan udvikle et system, der er "compliance by design".

Jeg glæder mig til din næste blog, hvor du bliver konkret og viser os usecases og database modeller for dit system, der er "compliance by design".

Samt din afsluttende blog, hvor du viser os dit færdige template system, der er "compliance by design", og vi kan finde kildekoden på github og få inspiration.

Annette Printz Nielsen

Det er mit bud, at det er de færreste, der alene kan udvikle et system, der er compliant by design. Min pointe er netop, at det kræver et tæt samarbejde mellem kunden, it-leverandøren og evt. eksterne rådgivere i takt med at de regulatoriske tekniske og sikkerhedsmæssige krav øges. Det er muligvis ikke nyt, men det er dog noget, som vi i advokatbranchen oplever en øget efterspørgsel på.

Du skal nok ikke forvente en blog, hvor jeg viser usecases eller database modeller for et system, der er compliance by design eller en template på et færdigt system. For det første vil det jo afhænge konkret af, hvilket regulatoriske krav den pågældende kunde er underlagt, for det andet vil det afhænge af, hvilket system kunden ønsker udviklet, og sidst men ikke mindst så er jeg advokat og ikke it-udvikler, så jeg har hverken en intention om eller evner til at udvikle it-systemer. Jeg kan derimod som ekstern rådgiver bidrage med blandt andet at vejlede parterne om de regulatoriske krav, og hvorvidt konkrete tekniske løsninger opfylder de pågældende krav.

Jesper Frimann

Man skal nok heller ikke undervurdere, hvad JM,Digst og Datatilsynet skriver i diverse vejledninger.

Det virker lidt som om, at piben har fået en anden lyd. Det er ikke længere kun, anbefaler, bør, det ville være hensigtsmæssigt at... etc. etc.
Nu ser man ordlyd som :

Kort sagt skal du på forhånd have designet og indrettet din it-mæssige og organisatoriske forretnings understøttelse af behandlinger sådan, at forordningens krav og beskytteseshensyn varetages som en integreret del i hele behandlingsforløbet.

og

Forordningen indfører også regler om databeskyttelse gennem design. Reglerne herom skal sikre, at de fornødne garantier i behandlingen integreres fra starten med henblik på at opfylde forordningens krav og beskytte de registreredes rettigheder.

Taget fra Databeskyttelse gennem design og standardindstillinger
( https://www.datatilsynet.dk/media/6879/artikel25og32-vejledning.pdf )

Jeg synes det er et rimeligt klart, at 'nu er det altså alvor'. Og det skal vi jo som bekymrede IT-folk jo bare være glade for.

// Jesper

Mads Hjorth

De dygtige it-udviklere har ikke svært ved at designe og programmere løsninger der lever op til bredt formulerede krav i lovgivning — de har i forvejen god træning i at gætte på hvad kundens krav betyder i praksis :-)

Det sværeste er nok få et overblik over hvilke lovgivning der gælder og hvordan de indbyrdes prioriteres. Bare spørg i banken om hvordan der var mere end en konflikt mellem krav fra forskellige EU instanser.

Så kærer jurister og advokater, hjælp jeres kunder med at remse relevant lovgivning op. Men forsøg ikke at beskrive konsekvenserne for den enkelte tekniske løsning...

Hvordan de enkelt paragraffer fortolkes bliver i sidste ende alligevel afgjort i retten...

Dave Pencroof

Jeg ser MASSER af offentlige institutioner, fra kommunale, kommuner og helt op, så tanken hos mig er at:
1: Datastyrelsen ikke er tilnærmelsesvis klar eller udrustet med de ressourcer og personaler/penge, til at tage sig af noget som helst en RUM tid endnu, måske aldrig ?

2: Kan der være en uudtalt aftale om at det offentlige endnu engang slipper for at rette sig efter loven, eller måske er der ligefrem "tilpasninger" i den danske lovtekst ?

3: Jeg deltager i kommunale og regions sammenhænge, og kommenterer de steder på at det offentlige har en "pligt" (måske lige i overkanten) til at gå foran som det gode eksempel, for som det er nu og har været længe, så ser borgerene at det offentlige igen og igen er mere end på kant med lovene, (jeg ser det alt for ofte), og rigtigt mange borgere mener at når det offentlige gør det og slipper godt fra det, så kan jeg også (nogen mener ligefrem at de også er NØDT til at gøre noget tilsvarende, for ikke at blive løbet over ende), jeg må indrømme at jeg er ubegribeligt træt af dette kapløb mod bunden hvor alle er i et kapløb om at platte og svindle mere end alle andre, og der er stadigt en vanvittigt ide om at tilskuddene, betalte hjælpemidler og lignende, skal man da virkeligt ikke tænke på om det kan gøres bedre og måske markant billigere, NEJ DA du får det jo af kommunen så... ! (glem alt om at der er smartere,bedre,billigere løsninger, bare brug løs) hjernedøde tåber, alle til hobe !

Det offentlige eksisterer igennem tvungne skatter (fint nok), som næsten alle borgere betaler, over en vis alder. Men reelt kommer der kun "ægte" skatter ind fra private virksomheders ansatte, så der er grænser for hvor grådige og krævende borgerene kan være, pengene kommer IKKE fra et overflødighedshorn, men en reelt ret lille procentdel af befolkningen !

Før der kan bygges noget ekstra ind noget som helst sted, skal der VIDEN, fokus, vilje og dybere brugerinddragelse samt en kæmpe kultur ændring som skal i retning af at glemme "det har jeg krav på !" til, "dette er hvad jeg har brug for, for at få et bedre liv !", for så kan der blive plads i budgetterne, samtidigt skal der også ændres på kravene med at skulle indkøbe indenfor "SKI"-aftalere (håber jeg husker udtrykket korrekt), jeg har endnu ikke oplevet at det offentlige har formået at foretage indkøb til noget bare i nærheden at de priser, inkl leverings stabilitet, som private virksomheder og alm borgere kan ved at en lettere indsats, en dygtig indkøber kan tjene sin egen løn ind mange gange, hvis indkøberen ikke er BUNDET af disse i dag tåbelige krav, Ja ! der er muligheder for nepotisme, men det er der godt nok også med dette "system" !

Det er vel også borgerenes opgave at holde det offentlige (inkl de borgere der arbejder i, valgt ind i, det offentlige) i ørene, men ekstremt gør det mindste !

Jeg undskylder at jeg træder lidt ved siden af oplægget, men jeg sidder i tids-helikopteren, på vej ud i en meget dyster fremtid, på stort set alle fronter, mest af alt grundet borgerenes "fravær ved tømmerne", der er særdeles mange områder der skal "mødes" for at fremtidige generationer skal have en chance for at få et ok liv, og ikke livslangt lide under fortidens sløvsind !

Hav alle en tænksom weekend !

Annette Printz Nielsen

Der er ingen tvivl om, at nogle it-leverandører har et vist kendskab til regulatoriske krav, men den efterspørgel vi får fra vores klienter, er ikke, at de ønsker at overlade fortolkningen af de regulatoriske krav alene til it-leverandøren. På samme måde ønsker de heller ikke at overlade udviklingen af de tenkniske løsninger til os advokater :) Min pointe er, at compliance by design kræver et tæt samarbejde.

Derudover så er konsekvensen af non-compliance med regulatoriske krav for kunden ikke noget, der afgøres i retten. Det er noget, der afgøres af de relevante tilsynesmyndigheder, og som kan medføre store bøder, pålæg og i yderste konsekvens inddragelse af kundens licens, hvis kunden er en reguleret virksomhed. Derfor er det helt essentielt for kunden at overholde de regulatoriske krav.

Log ind eller Opret konto for at kommentere