Wśród danych

Blog dla przedsiębiorców działających w cyfrowym świecie

  • Michał Nosowski

Privacy by design w praktyce tworzenia oprogramowania

Aktualizacja: cze 20


Privacy by design to tajemniczo brzmiący zwrot, który był często powtarzany w związku z nowościami, jakie miały być wprowadzone do świata ochrony danych osobowych przez RODO.


O samej zasadzie napisano już sporo, więc nie będę specjalnie się powtarzał. Chciałbym natomiast zwrócić uwagę na praktyczne kwestie związane ze istnieniem tej zasady. Dlatego ten artykuł ma na celu przedstawienie, jak stosowanie zasady privacy by design powinno wyglądać w praktyce, na przykładzie tworzenia oprogramowania komputerowego z użyciem metodyk zwinnych. Wykorzystuję w nim nieco doświadczeń z projektów, w których ostatnio uczestniczyłem lub uczestniczę i widzę, że to dobra droga jeśli chodzi o tworzenie oprogramowania zgodnego z przepisami prawa.


Czym jest privacy by design?


Na początku przypomnę co o privacy by design możemy przeczytać w samym RODO, a dokładnie w artykule 25 ust. 1 tego pięknego Rozporządzenia:


Uwzględniając stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie wystąpienia i wadze zagrożenia wynikające z przetwarzania, administrator – zarówno przy określaniu sposobów przetwarzania, jak i w czasie samego przetwarzania –wdraża odpowiednie środki techniczne i organizacyjne, takie jak pseudonimizacja, zaprojektowane w celu skutecznej realizacji zasad ochrony danych, takich jak minimalizacja danych, oraz w celu nadania przetwarzaniu niezbędnych zabezpieczeń, tak by spełnić wymogi niniejszego rozporządzenia oraz chronić prawa osób, których dane dotyczą.

O co więc chodzi? O to aby projektując jakieś rozwiązanie, a następnie tworząc je, wdrażając je, stosując albo nawet przestając stosować, brać pod uwagę kwestie dotyczące ochrony danych osobowych. Innymi słowy, realizując projekt musimy mieć z tyłu głowy kwestie dotyczące ochrony danych osobowych przez cały czas jego trwania – tak aby przypadkiem (albo nawet i celowo) nie wyszło nam coś, co będzie niezgodne z RODO.


Metodyki agile a privacy by design


W skrócie, dla osób które nie siedzą w świecie tworzenia oprogramowania komputerowego: Czym są metodyki zwinne (ang. agile)?


To sposób zarządzania projektem, który zakłada odformalizowanie procesu tworzenia oprogramowania, a dzięki temu umożliwia sprawne adaptowanie prac do zmieniającej się rzeczywistości oraz wymagań klienta. Na czym dokładnie polega? Na początku klient przedstawia ogólne założenia projektu, np. poprzez przedstawienie tzw. user stories, czyli opisu tego, co użytkownicy będą mogli zrobić za pomocą oprogramowania. Nie tworzymy więc gigantycznej dokumentacji, która określa każdy szczegół projektu, bo zakładamy, że w trakcie prac i tak coś się zmieni. Zamiast tego określamy ogólne cele jakie chcemy osiągnąć i siadamy do pracy.


Cały cykl tworzenia końcowego dzieła dzielony jest na trwające kilka lub kilkanaście dni etapy (sprinty), w ramach których zespół projektowy realizuje kolejne zadania, mające przybliżyć go do wykonania finalnego produktu na rzecz klienta. Poszczególne efekty prac po każdym ze sprintów prezentowane są klientowi, tak aby możliwe było wprowadzenie ewentualnych poprawek. Dzięki temu zmiany mogą być dokonywane na bieżąco i nie wymagają dokonywania modyfikacji w końcowym dziele.





Jaka jest w tym wszystkim rola prawnika

Z uwagi na to iż szczegółowe założenia dotyczące tworzenia takiego projektu (oprogramowania) ulegają ciągłym zmianom, prawnik powinien badać kwestie zgodności tworzonego w ramach projektu oprogramowania z regulacjami prawnymi przez cały okres jego tworzenia. Nie tylko na początku (w fazie wstępnego projektowania) ani na samym końcu (w momencie prezentacji gotowego produktu). Stąd też tak istotne jest prawidłowe stosowanie zasady privacy by design w toku całego procesu realizacji projektu – zgodność z RODO będzie możliwa do osiągnięcia jeżeli kompetentna osoba będzie czuwała nad tym w całym toku życia projektu – od wstępnych założeń aż po jego oddanie do użytku, a także samo wykorzystywanie w bieżącej działalności czy też zakończenie korzystania z danego narzędzia.

Nie mówię, że prawnik od RODO ma być częścią zespołu programistów i siedzieć z nimi 8 godzin dziennie, sprawdzając każdą linijkę kodu pod kątem ewentualnego naruszenia zasad ochrony danych osobowych. Nie musi być nawet na codziennych standupach związanych z omówieniem bieżących postępów w realizacji projektu.

Ale taki prawnik powinien wiedzieć, jakie są ogólne kierunki związane z rozwojem aplikacji. Dotyczy to także ewentualnych zmian założeń dotyczących tworzonego oprogramowania. Innymi słowy, jeżeli w pierwotnym projekcie dokonywane są jakieś zmiany, powinien on o tym wiedzieć (chyba, że mają czysto techniczny charakter, nie łączą się w żaden sposób z danymi albo ich zabezpieczaniem itp.).

Dlatego dobrze by było gdyby (zwłaszcza przy większych projektach) prawnik brał udział w spotkaniach zespołu projektowego z właścicielem biznesowym programu. Dlaczego? Na tym spotkaniu omawiane są postępy prac i często omawia się na nich ewentualne zmiany i kierunki dalszego rozwoju aplikacji.


To jest moment gdzie prawnik, mający wiedzę na temat ochrony danych osobowych, może wyłapać te kwestie, które będą wiązały się z przetwarzaniem danych w ramach aplikacji i ocenić je pod kątem zgodności z prawem. Nie ma również przeszkód aby zasugerował on zespołowi projektowemu takie rozwiązania, które tę zgodność zapewnią. Czy taki prawnik powinien zostać zatrudniony przez sam zespół projektowy (tzn. realnych twórców oprogramowania) czy przez klientów - osoby, które decydują o stworzeniu danego programu? To nie ma większego znaczenia – ważne aby miał bieżący kontakt z zespołem projektowym i dostęp do informacji dotyczących prac przez cały czas ich trwania.


Na jakie kwestie należy zwrócić szczególną uwagę?


Co szczególnie powinno takiego prawnika interesować:

  1. Kwestie związane z tym jak dane będą trafiały do aplikacji – np. może to obejmować sposób rejestracji użytkowników, zakres wprowadzanych przez nich informacji, proces zakładania konta itp. W każdym z tych wypadków kłania się nam przetwarzanie danych osobowych i konieczność oceny, czy to co robimy jest zgodne z prawem.

  2. Informacje związane z tym po co dane będą w ramach aplikacji przetwarzane i czy rzeczywiście są niezbędne do tego aby osiągnąć założone cele biznesowe – możemy wdrożyć milion zabezpieczeń danych osobowych, ale jeśli będziemy zbierać ich więcej niż rzeczywiście potrzebujemy i tak zostanie to uznane za błąd. Dlatego niezwykle istotną kwestią jest rzetelne odpowiedzenie sobie na pytanie – po co mi dane i jakich danych potrzebuję aby osiągnąć założony cel (innymi słowy: po co zbieramy dane i dlaczego tak dużo?)

  3. Długość przechowywania danych – dane powinny być przechowywane tylko tak długo jak długo są niezbędne do realizacji celu przetwarzania jest mocno zaakcentowana w RODO. Stąd też musimy wiedzieć, kiedy powinniśmy usunąć dane i w jaki sposób to zrobić – aby było to możliwie wygodne dla nas, a przy tym skuteczne i bezpieczne,

  4. Dostęp do danych i określenie zasad takiego dostępu – chodzi tutaj o różnego rodzaju uprawnienia dostępu do bazy użytkowników, możliwości osób obsługujących aplikację itp. Ważna sprawa ze względu na bezpieczeństwo,

  5. Kwestie związane z bezpieczeństwem – przy czym normalne jest to, że taki prawnik poprosi o wsparcie specjalisty w tym zakresie. Niekiedy takim specjalistą może być po prostu członek zespołu programistów, którzy pracują nad stworzeniem aplikacji, o ile ma wiedzę na temat bezpieczeństwa. W innym przypadku konieczne może być wsparcie kogoś z zewnątrz.

  6. Miejsce przechowywania danych, lokalizacja serwerów bazodanowych itp. – element ten musi być przeanalizowany z uwagi na konieczność zawarcia ewentualnych umów powierzenia i ogólnej weryfikacji tego czy ewentualni usługodawcy w ogóle są na tyle rzetelni aby powierzyć im dostęp do danych osobowych,

  7. Proces zapisywania logów w ramach aplikacji, informacji dotyczących tego kto wykonywał operacje na danych osobowych – kolejna ważna sprawa z uwagi na konieczność zapewnienia poufności danych,

  8. Inne kwestie, np. związane z tym czy dokumentacja dotycząca aplikacji zawiera jakieś informacje o przetwarzaniu danych osobowych w jej ramach i jakie. Nie ukrywam, że w sytuacji gdy jej nie ma prawnik powinien wesprzeć zespół tak aby ją stworzyć.

Po co to wszystko? Z wielu powodów. Wystarczy wziąć pod uwagę kilka zasad przetwarzania danych znanych z RODO.


  • Mamy zasadę ograniczenia celu, która mówi o tym, że aby przetwarzać dane osobowe musimy sprecyzować w jakim celu będą one przetwarzane.

  • Mamy zasadę minimalizacji, która mówi o tym aby przetwarzać dane tylko w sytuacji gdy jest to niezbędne do realizacji danego celu.

  • Mamy zasadę ograniczenia przetwarzania, która mówi o tym, że dane muszą być przechowywane tylko tak długo jak są niezbędne do realizacji celu przetwarzania.

  • Mamy w końcu zasadę poufności i integralności, która mówi o tym, że dane muszą być przetwarzane w taki sposób aby zapewnić ich odpowiednie bezpieczeństwo.


Wzięcie tych zasad pod uwagę już na etapie tworzenia aplikacji:
a) sprawia, że aplikacja będzie zgodna z prawem,
b) ułatwia późniejsze korzystanie z niej tak aby nie naruszyć niczyich praw,
c) pozwala uniknąć tworzenia kosztownych i czasochłonnych funkcjonalności, których i tak nie będzie można używać, bo powodowałoby to niezgodność działalności klienta z przepisami prawa.

Z drugiej strony, wybór metodyk zwinnych w toku tworzenia produktu ułatwia ewentualne dostosowanie go do przepisów nawet gdyby na wstępnym etapie prac pojawiło się coś co może budzić wątpliwości pod kątem zgodności z prawem.





Przyznam, że biorę obecnie udział w kilku projektach, w ramach których właśnie tak tworzy się oprogramowanie – na bieżąco badając zgodność z regulacjami prawnymi. I stwierdzam, że to świadczy o naprawdę profesjonalnym podejściu zespołu projektowego i osób decyzyjnych odpowiedzialnych za projekt. Nie ukrywam, że tego rodzaju współdziałanie osób zajmujących się kwestiami prawnymi i technicznymi może skutkować nową, lepszą jakością tworzonego oprogramowania.


Słyszałem kiedyś, że prawnicy i księgowi mają obecnie gigantyczny wpływ na proces projektowania i tworzenia samochodów. Być może podobnie będzie z programami komputerowymi - zasada privacy by design na pewno nas do tego przybliża.



Szukasz prawnika, który doradza firmom IT w procesie tworzenia oprogramowania? Możesz śmiało się ze mną skontaktować, pisząc na kontakt@bytelaw.pl, albo korzystając z formularza kontaktowego tutaj.


#agile #privacybydesign #programowanie #rodo #prawo #ochronadanychosobowych #tworzenieoprogramowania #zasadaminimalizacji #celprzetwarzania

Michał Nosowski

Jestem radcą prawnym specjalizującym się w prawie nowych technologii. Stworzyłem tego bloga po to aby dzielić się swoją pasją - czyli badaniem styku świata IT i prawa.

 

W ramach kancelarii ByteLaw, której jestem współzałożycielem, pomagam głównie startupom, software house'om, freelancerom i ludziom zajmującym się marketingiem internetowym. Jeśli chcesz dowiedzieć się więcej, zapraszam do odwiedzenia strony Kancelarii.

  • Twitter Social Icon
  • LinkedIn Social Icon
  • Facebook Social Icon
  • Instagram Social Icon

Projekt: 2020 Michał Nosowski, Toruń.