Privacy by Design – cóż mogłoby pójść źle…

Data: 2018-06-08
Autor: Sebastian Konkol
Privacy by Design – cóż mogłoby pójść źle…

Miałem przyjemność uczestniczyć niedawno w Warsaw Alfresco Day, w czasie którego George Parapadakis snuł opowieści o przygotowaniach do RODO – na przykładach. Zaczął od „ankiety” wśród uczestników, na ile – w ich opinii – reprezentowane przez nich firmy są przygotowane i będą do 25 maja 2018 r. Moim zdaniem w tej ankiecie zabrakło jednego pytania: „Ile osób spośród państwa uważa, że absolutnie nikt nie będzie gotowy do RODO?” Mimo badań twierdzących inaczej, w odpowiedzi na takie pytanie ja podniósłbym rękę. Dlaczego tak uważam na przykładzie jednego z wymagań stawianych przez RODO / GDPR, Privacy by Design.

Choć koncepcja privacy by design osadza się w pracach Ann Cavoukian w lat dziewięćdziesiątych ubiegłego wieku, nie dysponujemy praktycznymi metodami uczynienia tej koncepcji operacyjną, pragmatycznie stosowaną. Zapisanie w RODO wprost odniesienia do tej koncepcji uruchomiło lawinę traktatów filozoficznych, jednak – na tyle, na ile udało mi się przez nie przegryźć – żadne z tych przedsięwzięć nie zostało skonkludowane czymś mającym praktyczne zastosowanie. Odpowiedzi na pytanie jak poprawnie metodycznie stosować privacy by design nadal brak. Dzisiaj nie pozostało już za wiele czasu na filozofowanie, a coraz więcej firm przygotowując się do RODO podejmuje drogi na skróty. W przypadku privacy by design skrót oznacza: weź specjalistę od bezpieczeństwa informacji i niech on zrobi tę robotę. Mało czasu oznacza wdrażanie pierwszego pomysłu, jaki przychodzi do głowy, a pierwszym pomysłem specjalisty od bezpieczeństwa informacji będzie zastosowanie polityki need to know – zmieńmy tak systemy (sic!), aby użytkownicy mieli dostęp jedynie do tego, do czego powinni mieć do wykonania swoich zadań. Wygląda dobrze, prawda? W tydzień po wdrożeniu biznes zaczyna się dławić, po kilku tygodniach zatrzymuje się. Co poszło nie tak?

Sekret leży w określeniu „wykonania swoich zadań”. Aplikując politykę need to know analitycy skupiają się na zadaniach, jakie wynikają z udokumentowanych reguł – procesów lub inaczej opublikowanych zadań. Niestety, co najmniej znacząca część zadań wykonywanych przez ludzi nie jest osadzona w udokumentowanych procesach. Praktyka jest raczej bezpośrednia: mam narzędzie (system), które pozwala mi na wykonanie pewnego zadania, więc je wykonuję, choć nigdzie nie jest to udokumentowane. Moi koledzy polegają na tym, co robię, choć nie uczyniliśmy tego udokumentowanym procesem. Firma polega na tej sekwencji działań generującej wartość. Zaaplikowanie polityki need to know oznacza najprawdopodobniej zablokowanie dostępu do narzędzia, w konsekwencji wyłączenie sekwencji działań generującej wartość dla firmy. Skala jednak zaskakuje, gdyż współczesny świat coraz częściej opiera się na takich ujawnianych możliwościach – są one podstawą w praktykach codziennych działań operacyjnych. Co więcej, firmy odnoszące największe sukcesy wręcz opierają się na tworzeniu takich nieformalnych relacji współpracy. Sukces operacyjny polega na wykorzystaniu narzędzi – need to know jest sprzeczne z tym. No i cała tajemnica się wyjaśnia.

Część ‘by Design’ wskazuje jasno, że skróty w realizacji privacy by design są fundamentalnie złe. Łatanie, szczególnie w pośpiechu i w oparciu o pobieżne zrozumienie, w niczym nie pomoże, a najprawdopodobniej doprowadzi do większych tarapatów. Wymaga ono podejścia o znacznie, znacznie szerszym polu widzenia, niż jedynie bezpieczeństwo informacji.

Pozostaw komentarz