Security by design: modewoord of toverwoord?

Het begrip ‘privacy by design’ is in de jaren 90 geintroduceerd door Canadese privacytoezichthouder Ann Cavoukian. Het begrip ‘privacy-enhancing technologies’ (PET’s) bestond al. Ann Cavoukian was van mening dat ‘a more substantial approach’ vereistwas. Met andere woorden: niet alleen technische, maar ook organisatorische en fysieke maatregelen. Ann Couvakian introduceerde de ‘seven foundational principles’:

• Proactief in plaats van reactief, preventief in plaats van herstellend
• Privacy als standaard
• Privacy geïntegreerd in het ontwerp
• Volledige functionaliteit, ‘positive sum’ in plaats van ‘zero-sum’
• Veiligheid van begin tot eind, bescherming tijdens de volledige levenscyclus
• Zichtbaarheid en transparantie, houd het open
• Respect voor de privacy, laat de gebruiker centraal staan

Met de zeven beginselen van privacy by design werd in feite ook privacy by default geïntroduceerd (in de vorm van het beginsel ‘Privacy als standaard’) en security by design (in de vorm van het beginsel ‘Veiligheid van begin tot eind, bescherming tijdens de volledige levenscyclus’). Krachtige veiligheidsmaatregelen van begin tot eind zijn volgens Ann Cavoukian essentieel voor het behoud van privacy.

De opvatting van Ann Cavoukian heeft navolging gekregen. Inmiddels zijn de beginselen van privacy by design gecodificeerd. Zo leggen onze Algemene Verordening Gegevensbescherming (AVG) privacy by design (artikel 25 lid 1 AVG) en privacy by default (artikel 25 lid 2 AVG) als verplichting op, ook al worden deze termen niet expliciet genoemd. In de literatuur zijn opmerkingen gemaakt over het abstracte karakter van artikel 25 AVG. Zo zijn er geluiden dat de eisen die in dit artikel zijn opgenomen, het midden houden tussen een abstract geformuleerd beginsel en een min of meer concrete opdracht.[1] Deze kritiek is mijns inziens terecht. Goed beschouwd noemt artikel 25 lid m1 AVG slechts twee concrete verplichtingen:

• Dataminimalisatie (zie ook artikel 5 lid 1 sub c AVG): alleen strikt noodzakelijke gegevens verzamelen
• Pseudonimiseren (zie ook artikel 4 lid 5 AVG)

Verder bevat de AVG een aantal afzonderlijke bepalingen met verplichtingen die nauw samenhangen met privacy by design & default. Je kunt het ook anders
stellen: om te kunnen voldoen aan deze verplichtingen is het noodzakelijk privacy by design toe te passen:

• Encryptie (artikel 6 lid 4 sub e, artikel
  32 lid 1 sub a AVG)
• Bewaren (artikel 5 lid 1 sub e AVG).

De vraag is: Hoe moeten deze (deels abstracte) verplichtingen in de praktijk worden uitgevoerd? Welk houvast hebben bedrijven en organisaties daarbij? In 2015, al voor invoering van de AVG, heeft ENISA [2] in haar rapport ‘Privacy and Data Protection by Design – from policy to engineering’[3] getracht een brug te bouwen tussen ‘the legal framework’ en ‘the available technologies implementation measures’. Vier jaar mlater heeft de EDPD[4] richtlijnen[5] gepubliceerd over de toepassing van data protection by design en default. Ondanks de goedbedoelde pogingen bieden de richtlijnen niet het houvast die zij beoogden te bieden. Bestudering van de richtlijnen leidt mijns inziens tot de conclusie dat slechts een aantal voorbeelden en handvatten wordt gegeven, maar dat de richtlijnen toch vrij abstract blijven. Hetzelfde geldt voor het eerder verschenen ENISA-rapport. ENISA is deze mening overigens ook zelf aangedaan. In haar rapport ‘Guidance and gaps analysis for European Standardisation’[6] komt zij onder meer tot de volgende bevindingen:

• Het concept van privacy by design en de implementatie ervan worden nog steeds niet duidelijk gepresenteerd, ondanks een algemene consensus over waargenomen voordelen;
• Het aantonen van naleving van privacynormen op het gebied van informatiebeveiliging is niet zo eenvoudig als toen een datalek in de systemen van de GGD werd geconstateerd. In de Kamerbrief van staatssecretaris Knops van BZK naar aanleiding van de motie Kröger c.s., wordt privacy by design expliciet genoemd, evenals de zeven principes van Ann Cavoukian. In de brief wordt gerefereerd aan de overheidsbrede maatregelen die reeds zijn getroffen, waaronder het instrument Inkoopeisen Cybersecurity Overheid (ICO). Tegelijkertijd geeft de staatssecretaris aan dat deze maatregelen verder aangevuld dienen te worden vanuit de zeven principes.[7] Ook in het Cybersecuritybeeld Nederland 2021[8] van het NCTV[9] en het NCSC[10] wordt expliciet benoemd dat een baseline[11] niet voldoende is en wordt de noodzaak van nadere regulering erkend.

Ervan uitgaande dat het Europees en Nederlands voornemen om privacy (en daarmee security) by design nadere invulling te geven daadwerkelijk wordt gerealiseerd, is het de vraag wie verantwoordelijk is voor de juiste toepassing daarvan. Op grond van de AVG is privacy & security by design een verplichting van de verwerkingsverantwoordelijke (in veel gevallen de opdrachtgever). De praktijk is echter, dat verwerkingsverantwoordelijken software niet zelf ontwikkelen en dat door de opdrachtgever vaak te weinig eisen worden gesteld ten aanzien van beveiliging. Dit heeft tot gevolg dat kwetsbaarheden in de software vaak pas aan het licht komen in de gebruiksfase, soms pas op het moment dat er een cyberincident plaatsvindt. Dit is uiteraard een onwenselijke zaak. Het zou daarom goed zijn als de verplichting van security by design zich ook rechtstreeks zou richten tot developers en aanbieders. Met name bij standaardsoftware zou het mijns inziens zo moeten zijn dat een afnemer erop zou moeten kunnen vertrouwen dat bij de ontwikkeling van de software security by design is toegepast: Veiligheid van begin tot eind, bescherming tijdens de volledige levenscyclus (waarbij geldt dat de toepassing en het gebruik van standaardsoftware eveneens bepalend zijn voor de veiligheid en deze factoren uiteraard buiten de invloedsfeer en verantwoordelijkheid van de developers en aanbieders liggen). Daarbij komen we wel weer terug op een eerder punt, te weten dat eerst op Europees niveau nadere invulling zal moeten worden gegeven aan de verplichtingen die security by design met zich meebrengt. Om het niet nog complexer en enigszins behapbaar te houden laten we het mondiale karakter van digitalisering vooralsnog buiten beschouwing.

Security by design is geen nieuw modewoord. Het bestaat al sinds de jaren 90 en in inmiddels gecodificeerd. Het belang van security by design als onderdeel van privacy by design in de strijd tegen cybercrime staat buiten kijf. Het ontbreken van een definitie en concrete invulling van security by design op Nederlands en Europees niveau heeft echter tot gevolg dat het voor bestuurders en developers op dit moment onvoldoende duidelijk is wat nu precies van hen wordt verwacht. Om cyberrisico’s het hoofd te kunnen bieden is het van belang dat deze nadere invulling op korte termijn komt.

• Security by design is een belangrijk instrument bij het weerbaar maken van een organisatie tegen cybercriminaliteit; hoe eerder securityvraagstukken worden meegenomen in het ontwikkeltraject, des te meer impact de maatregelen zullen hebben;
• De AVG gaat uit van accountability. Het is dan ook van belang te documenteren op welke wijze aan de verplichting van privacy & security by design is voldaan.
• Bij een gebrek aan concrete handvatten voor de concrete invulling van privacy & security by design doen organisaties en bedrijven er vooralsnog goed
  aan de bestaande richtlijnen/baselines te volgen, aangevuld met een risicoanalyse op organisatieniveau.
• Bestuurders van verwerkingsverantwoordelijken zijn verantwoordelijk voor een adequate omgang met digitale risico’s. Zolang de verplichting van privacy & security by design zich niet (ook) rechtstreeks tot developers en aanbieders van software richt, is het zaak concrete eisen te stellen aan developers en aanbieders (en deze eisen weer te documenteren in het kader van accountability).

[1] Zie bijvoorbeeld H.J. Bolte in ‘EDPB richtlijnen over Data Protection by Design en Default’ in Privacy & Informatie (P&I)
[2] European Union Agency for Cybersecurity
[3] https://www.enisa.europa.eu/publications/privacy-and-data-protection-by…
[4] European Data Protection Board
[5] Guidelines 4/2019 on Article 25 Data Protection by Design and Default
[6] https://www.enisa.europa.eu/publications/guidance-and-gaps-analysis-for…
[7] De verwachting was dat deze invulling in de loop van 2021 gereed zou zijn.
[8] https://www.nctv.nl/documenten/publicaties/2021/06/28/cybersecuritybeeld-nederland-2021
[9] Nationaal Coördinator Terrorismebestrijding en Veiligheid
[10] Nationaal Cyber Security Centrum
[11] https://www.ncsc.nl/documenten/
publicaties/2021/juni/28/handreikingcybersecuritymaatregelen