A beépített adatvédelem (Privacy by design – PbD) nagyjából a kilencvenes években alakult ki (Ontario-ban!) és 2009-ben publikálták először mint keretrendszert.

A NAIH szótár szerint: „lényege, hogy az adatvédelmi szempontoknak megfelelő gyakorlat nem merülhet ki a hatályos szabályozásnak való formális megfelelésben. Az adott szervezet alapvető működési elve az adatvédelmi szempontoknak való megfelelés, ezért működését, struktúráját ezek maximális figyelembevételével alakítja ki, az adatvédelmi szempontokat már az egyes működési fázisok megtervezésekor beépíti és így biztosítja az adatvédelem teljes körű érvényesülését. Rokon területe a „privacy by default” megközelítésnek.”

Mit is mond erről pontosan a GDPR rendelet?

  1. cikk: Beépített és alapértelmezett adatvédelem (Data protection by design and by default)

„(1) Az adatkezelő a tudomány és technológia állása és a megvalósítás költségei, továbbá az adatkezelés jellege, hatóköre, körülményei és céljai, valamint a természetes személyek jogaira és szabadságaira jelentett, változó valószínűségű és súlyosságú kockázat figyelembevételével mind az adatkezelés módjának meghatározásakor, mind pedig az adatkezelés során olyan megfelelő technikai és szervezési intézkedéseket – például álnevesítést – hajt végre, amelyek célja egyrészt az adatvédelmi elvek, például az adattakarékosság hatékony megvalósítása, másrészt az e rendeletben foglalt követelmények teljesítéséhez és az érintettek jogainak védelméhez szükséges garanciák beépítése az adatkezelés folyamatába.”

Azaz, a GDPR rendelet arra próbálja rávenni a termékek, szolgáltatások és alkalmazások gyártóit/fejlesztőit, hogy a fejlesztés minden szakaszában (igen, már a tervezés fázisában is!) foglalkozzanak az adatvédelemmel, legyen eleve beépített, ne pedig utólagos toldozás-félmegoldás.

Az adatvédelmi tisztviselőnek (DPO!), akinek ezzel kapcsolatban tanácsot kell adnia az adatkezelőnek, először is meg kell értenie a beépített adatvédelem (PbD) számos aspektusát, például azt, hogy hogyan vonatkozik az érintettek magánéletére, hogyan alkalmazzák ezt a szervezetek, hogyan alkalmazzák ezt a meghatározott technológiákra, és hogyan lehet az adatvédelmet és a biztonságot egyidejűleg megvalósítani előzetes tervezéssel.

A kockázatértékelés elvégzése után ki kell választani az adatvédelmi kontrollokat. Erre nagyjából két megközelítés létezik: adatvédelmi politika alapú („bízz bennünk”) és az adatvédelmi architektúra alapú („bízz a rendszerben”). Az előbbi a ma alkalmazott tipikus megközelítés, bár a magánélet védelmével kapcsolatos kockázatok kezelése nem mindig épül be teljesen a rendszerfejlesztés életciklusába.

Nyilván mindenki számára jobb lenne, ha már a rendszerek tervezésénél figyelemmel lennék ezekre a kérdésekre és a rendszerbe, folyamatokba épített, automatizált biztosítékokat, kontrollokat használnánk.

Ilyenek, például a lehető legkevesebb jogosultság kiosztása, csak a munkavégzéshez valóban szükséges hozzáférések, a bizalom felváltása a kontrollokkal, a kötelező hozzáférés-ellenőrzések, a feladatok és felelősségek szétválasztása, stb.

A lényeg, hogy már a tervezés fázisában foglalkozzanak az adatkezelők az adatvédelemmel, legyen az eleve tervezett és beépített.