Bagatelizują obowiązki z tym związane nałożone przez unijne rozporządzenie albo robią to w sposób niedostateczny lub błędny. Tymczasem prezes Urzędu Ochrony Danych Osobowych bacznie się im przygląda, o czym świadczy coraz większa liczba decyzji. Autorka jest prawnikiem, certyfikowanym testerem oprogramowania ISTQB
Unijne rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych; Dz.Urz. UE z 2016 r. L 119, s. 1; dalej: RODO) wymaga od administratorów i podmiotów przetwarzających wdrożenia odpowiednich środków technicznych i organizacyjnych, które zapewnią danym osobowym właściwą ochronę. I choć od daty rozpoczęcia stosowania rozporządzenia (25 maja 2018 r.) minęło już kilka lat, to wielu przedsiębiorców nie realizuje obowiązków poprawnie. Zazwyczaj skupiają się na „papierowym bezpieczeństwie” związanym z dokumentacją, aby spełnić podstawowe wymogi na wypadek kontroli. Zapominają, że znaczenie mają realne działania techniczne i organizacyjne, a ich dobrym przykładem jest m.in. testowanie oprogramowania. [ramka] Ostatnie decyzje prezesa Urzędu Ochrony Danych Osobowych nakładające surowe sankcje za brak testów lub niewłaściwe ich przeprowadzenie powinny być sygnałem dla przedsiębiorców, że czas na zmianę podejścia do tej kwestii. Uzasadnienia decyzji organu zawierają cenne wskazówki, na co należy zwrócić szczególną uwagę w zakresie testów. Analiza tych decyzji, a także orzeczeń sądów administracyjnych, pozwala poznać nie tylko stawiane wymagania, lecz także sposób interpretacji przepisów RODO przez organ nadzorczy i sądy.
O jakie działania chodzi
Testowaniem oprogramowania nazywamy czynności polegające na weryfikacji jego jakości. Innymi słowy, jest to sprawdzanie, czy wytworzone oprogramowanie działa zgodnie z założeniem biznesowym i jakościowym. Na przykład podmiot zakładający sklep internetowy powinien dokładnie przetestować jego działanie przed uruchomieniem i udostępnieniem dla klientów, m.in. w zakresie bezpieczeństwa danych, transakcji, spełnienia wymagań funkcjonalnych i niefunkcjonalnych oraz w celu weryfikacji, czy spełnia założenia biznesowe i prawne. Na testy oprogramowania składa się cały cykl czynności, które z kolei są istotnym elementem procesu wytwarzania oprogramowania. Można je podzielić na fazy, m.in planowanie testów, analiza testów, pisanie scenariuszy testowych, przygotowanie środowisk testowych, egzekucja testów, automatyzacja, zgłaszanie błędów, retesty, testy regresji, testy penetracyjne itd. Na każdym z tych szczebli istnieje ryzyko pojawienia się błędów, które w ostateczności mogą rzutować na zgodność z prawem, ochronę danych i bezpieczeństwo przetwarzania. Dzięki testom otrzymujemy informację, czy oprogramowanie zawiera takie błędy i dzięki temu je naprawić, aby finalny produkt był jak najlepszej jakości. Im wcześniej osoba testująca znajdzie błędy, tym koszt ich naprawy jest tańszy, a samo oprogramowanie bezpieczniejsze. ©℗
Poznaj podstawy prawne
Konieczność testowania oprogramowania w kontekście ochrony danych wynika m.in. z art. 32 RODO, który brzmi: „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, administrator i podmiot przetwarzający wdrażają odpowiednie środki techniczne i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający temu ryzyku”. Wśród przykładów wspomnianych w tym przepisie „odpowiednich środków” wskazano m.in właśnie regularne testowanie, mierzenie i ocenianie skuteczności środaków technicznych i organizacyjnych mających zapewnić bezpieczeństwo przetwarzania.
Zatem biorąc pod uwagę treść art. 32, aby w ogóle ocenić, jakie środki techniczne i w jaki sposób powinny być stosowane, konieczne jest najpierw określenie ryzyka, jakie wiąże się z przetwarzaniem danych, a dopiero w drugiej kolejności ‒ odpowiedni wybór środków technicznych i organizacyjnych, które będą adekwatne w danym przypadku. Chodzi np. o przeprowadzenie odpowiednich analiz ryzyka czy DPIA (ang. Data Protection Impact Assessment, procesu oceny skutków dla ochrony danych). Taką kolejność potwierdza również art. 24 ust. 1 RODO, z którego treści dowiadujemy się, że „uwzględniając charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie i wadze zagrożenia, administrator wdraża odpowiednie środki techniczne i organizacyjne, aby przetwarzanie odbywało się zgodnie z rozporządzeniem RODO i aby móc to wykazać. Środki te powinny być poddawane przeglądom i uaktualniane”.
Kolejną podstawą jest art. 25 RODO, który wskazuje: „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 rozporządzenia oraz chronić prawa osób, których dane dotyczą”. A zatem przepisy o ochronie danych osobowych należy analizować już na etapie projektowania rozwiązań, jakie zamierza się wprowadzić. Uruchamiając np. sklep internetowy, już na etapie analizy i planowania jego funkcjonalności należy uwzględnić zakres ochrony danych osobowych – nie tylko związany z samym rozwiązaniem e-commerce, lecz także na wszelkich płaszczyznach biznesowych jak: reklamacje, sprzedaż, obsługa klienta, wykorzystywane narzędzia technologiczne itp. Co ważne, administrator powinien wdrożyć odpowiednie środki techniczne i organizacyjne, aby domyślnie przetwarzane były wyłącznie te dane osobowe, które są niezbędne do osiągnięcia każdego konkretnego celu przetwarzania. Obowiązek ten odnosi się do ilości zbieranych danych osobowych, zakresu ich przetwarzania, okresu przechowywania oraz dostępności. Zatem wybrane środki techniczne i organizacyjne dotyczą nie tylko papierowego zabezpieczenia za pomocą dokumentacji, lecz także innych rozwiązań stricte fizycznych, technicznych mających na celu ochronę danych ‒ w tym teleinformatycznych. Nie ma przy tym znaczenia, czy skala działalności jest mała, średnia czy duża, albowiem to administrator, znając specyfikę swojej działalności i kontekst zakresu danych, powinien wdrożyć środki adekwatne do ich ochrony. Powinien je cyklicznie testować, mierzyć przyjęte rozwiązania, czy nie wymagają poprawy, udoskonalenia, rozszerzenia – innymi słowy, czy są adekwatne oraz czy inne czynniki nie wpłynęły na ich skuteczność. Testowanie oprogramowania stosowanego w przedsiębiorstwie jest właśnie jednym z takich środków.
Zadbaj o adekwatność i ciągłość
Orzecznictwo i decyzje prezesa UODO również wskazują na konieczność wprowadzania środków technicznych i organizacyjnych, które będą adekwatne do rodzaju danych, jakie się przetwarza. Jak np. wskazał Wojewódzki Sąd Administracyjny w Warszawie w wyroku z 26 sierpnia 2020 r., sygn. akt II SA/Wa 2826/19, art. 32 RODO „nie wymaga od administratora danych wdrożenia jakichkolwiek środków technicznych i organizacyjnych, które mają stanowić środki ochrony danych osobowych, ale wymaga wdrożenia środków adekwatnych”. Sąd dodał również: „Taką adekwatność oceniać należy pod kątem sposobu i celu, w jakim dane osobowe są przetwarzane, ale też należy brać pod uwagę ryzyko związane z przetwarzaniem tych danych osobowych, które to ryzyko charakteryzować się może różną wysokością. (…) Przyjęte środki mają mieć charakter skuteczny, w konkretnych przypadkach niektóre środki będą musiały być środkami o charakterze niwelującym niskie ryzyko, inne muszą niwelować ryzyko wysokie, ważne jednak jest, aby wszystkie środki (a także każdy z osobna) były adekwatne i proporcjonalne do stopnia ryzyka”. Takie stanowisko sądu podzielił również prezes UODO w decyzji nr DKN.5112.1.2020 z 3 grudnia 2020 r. Trudno się z takim stanowiskiem nie zgodzić, każdy przedsiębiorca prowadzi bowiem inny rodzaj działalności, może przetwarzać inne dane, korzystać z innych rozwiązań technologicznych. A zatem ten podmiot, który przetwarza dane, najlepiej wie, co przetwarza, z jakich narzędzi i programów korzysta oraz w jakim zakresie oraz jakie „adekwatne” środki bezpieczeństwa powinny być zastosowane.
Z kolei w wyroku WSA w Warszawie z 3 września 2020 r., sygn. akt II SA/Wa 2559/19, podkreślono dodatkowo potrzebę ciągłości monitorowania zastosowanych środków. Sąd mianowicie orzekł, że „Podmioty przetwarzające dane osobowe zobligowane są nie tylko do zapewnienia zgodności z wytycznymi ww. rozporządzenia poprzez jednorazowe wdrożenie organizacyjnych i technicznych środków bezpieczeństwa, ale również do zapewnienia ciągłości monitorowania poziomu zagrożeń oraz zapewnienia rozliczalności w zakresie poziomu oraz adekwatności wprowadzonych zabezpieczeń”.
Przygotuj regulacje i procedury
Biorąc pod uwagę wskazany wyżej wyrok sądu, ogromne znaczenie ma również opracowanie odpowiedniej i adekwatnej dokumentacji potwierdzającej wdrożenie RODO w danej działalności. Przy czym sama dokumentacja nie jest wystarczająca, bo liczą się realne czynności mające na celu ochronę danych. Chodzi o czynności, które są odpowiednio zaplanowane i wdrożone. Podobnie jest z testowaniem oprogramowania. Stworzenie i przyjęcie samej „ogólnej” polityki ochrony danych będzie niekompletne, jeżeli w jej zakresie nie znajdą się procedury związane z zakresem regularnego testowania, mierzenia i oceniania skuteczności przyjętych środków technicznych i organizacyjnych. Taki tok myślenia potwierdza prezes UODO w wymienionej decyzji nr DKN.5112.1.2020, w której wskazano, że „przyjęte przez Spółkę środki mogłyby być skuteczne, gdyby w ramach wdrożonych procedur zawierały również uregulowania dotyczące regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych mających zapewnić bezpieczeństwo przetwarzania i które byłyby przez Spółkę przestrzegane. Tymczasem w prowadzonej przez Spółkę ww. dokumentacji opisującej proces przetwarzania danych oraz zastosowane środki organizacyjne i techniczne, pozyskanej w toku dokonywania czynności kontrolnych, kwestie te nie zostały uregulowane”. Zatem nie wystarczy tylko testować, należy przyjąć procedurę, plan działania, harmonogram, który będzie realizowany i poddany kontroli. Co ważne, w przedmiotowej decyzji prezes UODO wskazał również, że dokonywanie testów wyłącznie w sytuacji pojawiającego się zagrożenia, bez wprowadzenia procedury, która określałaby harmonogram działań zapewniających regularne testowanie, mierzenie i ocenianie skuteczności wdrożonych środków, jest niewystarczające. Istotne znaczenie będzie miała cykliczność testów, mierzenia skuteczności nawet wtedy, kiedy nie są wprowadzane żadne zmiany. Wszelkie realne czynności, które podmiot wykonuje, powinny wynikać z procedur, a te jasno powinny wskazywać na poszczególne działania, ich cykliczność, przyjęte zasady. Można zakładać, że dobrym podejściem byłoby również wskazanie osób odpowiedzialnych za wykonywanie poszczególnych etapów testów oraz wprowadzenie kontroli przestrzegania harmonogramu, np. przez komórkę compliance.
Weryfikuj regularnie i w sytuacji zmian
Testowanie oprogramowania często co do zasady jest realizowane przy wprowadzaniu zmian do systemu. Można wyróżnić testy penetracyjne i regresji. Testy penetracyjne można wykonywać w każdym czasie i bardzo często wykonuje się je cyklicznie – w celu bezpieczeństwa. Testy regresji natomiast robi się po wprowadzeniu zmian w systemie informatycznym, przeważnie obejmują one zakres zmiany oraz obszary mogące wpływać poprzez tę zmianę na inne komponenty oprogramowania. Można jednak zaplanować osobny zakres testów regresji, by cyklicznie weryfikować określony zakres oprogramowania, nawet jeżeli nie będzie zmian. Niekiedy testy te są zautomatyzowane, czasami są to dodatkowe testy bezpieczeństwa, a czasami jest to połączenie kilku rodzajów testów, aby weryfikowały oprogramowanie na różnych płaszczyznach. Warto jednak zauważyć, że w decyzji DKN.5112.1.2020 prezes UODO wskazał, że przeprowadzanie testów tylko wtedy, gdy są zmiany albo program zawiódł, jest niewystarczające, a przeprowadzania „incydentalnych działań” nie można nazwać „regularnym testowaniem”. Jak ujął organ „(…) działania takie nie wyczerpują bowiem wymogu regularności. Testy powinny być wykonywane niezależnie, czy takie zmiany w działalności zachodzą, czy też nie”. Dodatkowo organ w tejże decyzji wskazał, że jeżeli zachodzą jakieś zmiany w oprogramowaniu, np. techniczne lub prawne, to powinny być one czynnikiem powodującym konieczność przeprowadzenia ponownej analizy ryzyka i ich wpływu na bezpieczeństwo przetwarzanych danych. Wynik analizy należy zaś uwzględnić przy stosowaniu środka bezpieczeństwa, jakim jest regularne testowanie. Takie stanowisko jest zrozumiałe głównie dlatego, że każda zmiana powoduje ryzyko, że dane oprogramowanie może w innych komponentach swojego działania doprowadzić do potencjalnych błędów, a te do naruszenia ochrony, integralności, bezpieczeństwa. Zatem należy szczególną uwagę zwrócić na analizę wpływu zmiany (ang. Impakt Analysis) na inne części oprogramowania. Innymi słowy, trzeba dobrze zidentyfikować obszary, które wymagają modyfikacji, aby zmiana mogła zostać wprowadzona, oraz zidentyfikować obszary, na które zmiana może mieć wpływ. Taka identyfikacja ma na celu dokładne poznanie systemu i wybranie odpowiedniego rodzaju testów w celu weryfikacji.
Kontroluj podmiot zewnętrzny
Najczęściej przedsiębiorcy zlecają wykonanie oprogramowania specjalistycznemu podmiotowi zewnętrznemu. Nie jest nowością, że podmiot, który to oprogramowanie tworzy, zobowiązany jest dostarczyć jak najlepsze jakościowo rozwiązanie (poprzedzone z jego strony testami), natomiast nie oznacza to, że zlecający wykonanie oprogramowania przyjmuje dane oprogramowanie bez weryfikacji. Powinien on również po swojej stronie zweryfikować, czy dane oprogramowanie jest bez wad oraz czy jest odpowiednio zabezpieczone. Z taką problematyką zmierzył się prezes UODO w decyzji nr DKN.5130.2215.2020 z 19 stycznia 2022 r. W analizowanej sprawie podmiot, zlecając innemu wykonanie oprogramowania, nie weryfikował, czy firma realizująca dane oprogramowanie stosuje się do zakresu umowy i dba o bezpieczeństwo danych. W decyzji podniesiono, że „(…) administrator pomimo wdrożonych procedur oraz posiadanej wiedzy, jak zgodnie z powszechnie stosowanymi praktykami powinno przebiegać wprowadzanie zmian w systemach informatycznych, na żadnym etapie wdrożenia nie prowadził nadzoru nad tym, czy wdrożenie faktycznie przebiega zgodnie z powszechnie obowiązującymi standardami. Spółka (…) nie egzekwowała od podmiotu przetwarzającego (dostawcy oprogramowania) realizacji umów, nie stosowała się do własnej praktyki wdrażania zmian w środowisku IT opartej o wewnętrzne regulacje oraz nie weryfikowała podmiotu przetwarzającego w zakresie prowadzonych działań mających na celu usprawnienie funkcjonowania usługi. Wdrożenie środków technicznych i organizacyjnych powinno polegać nie tylko na jednorazowym zastosowaniu przez administratora odpowiednich przepisów, zasad przetwarzania danych osobowych w danej organizacji, ale także na dokonywaniu regularnych przeglądów tych środków, a w razie potrzeby na uaktualnianiu wcześniej przyjętych rozwiązań”. Płynie z tego wniosek, że za każdym razem, kiedy administrator odbiera zmiany w oprogramowaniu czy też nowe rozwiązania, ze szczególną uwagą powinien przeprowadzić testy weryfikujące, czy dane oprogramowanie jest bezpieczne i bez wad. Nacisk trzeba też położyć na kontrolę podmiotu przetwarzającego, który tworzy oprogramowanie na podstawie umowy i ma z administratorem umowę powierzenia danych, m.in. czy stosuje się do zapisów umowy, chroni dane oraz przestrzega wszelkich procedur i przepisów RODO.
Uważaj, wykorzystując realne zasoby
Przy realizacji oprogramowania przez podmiot zewnętrzny warto zwrócić uwagę również na wykorzystywanie danych prawdziwych na potrzeby testów oprogramowania. Jakiś czas temu duński organ ochrony danych osobowych Datatilsynet (odpowiednik polskiego UODO) opublikował na stronie www.datatilsynet.dk wytyczne dotyczące testów oprogramowania, które mogą być cenną wskazówką również dla polskich firm. Wskazał w nich m.in., że niekiedy wykorzystywanie danych „produkcyjnych” (realnych) na potrzeby testów jest niezbędne, a czasami nawet konieczne, chociażby do przeprowadzenia odpowiednich i rzetelnych testów. Powinno się jednak przy tym mieć na uwadze, że w takiej sytuacji środowiska testowe powinny być zabezpieczone, aby adekwatnie je chronić. Co ważne, jak jednocześnie wskazano, wszędzie tam, gdzie jest możliwe wykorzystywanie danych fikcyjnych na potrzeby testów, nie należy wykorzystywać danych produkcyjnych.
Duński organ nadzorczy zwrócił też uwagę, że jeśli w środowisku testowym dochodzi do zamiany prawdziwych danych produkcyjnych na dane testowe, to czynność tę powinna poprzedzić faza prawidłowej oceny ryzyka. Innymi słowy, w takich sytuacjach powinny zostać przeprowadzone te same czynności wymagane przez przepisy rozporządzenia RODO jak dla systemów produkcyjnych. Równie istotnym problemem, o którym wspomniał duński organ, jest to, czy administrator lub podmiot przetwarzający posiada podstawę prawną do przetwarzania danych osobowych w celach testów oprogramowania oraz czy jest realizowana anonimizacja (lub usuwanie danych) po realizacji testów.
Przeprowadzaj analizy ryzyka
W decyzji nr DKN.5130.2559.2020 z 9 grudnia 2021 r. prezes UODO nakładając karę, zwrócił uwagę na kilka aspektów, jak m.in. niezastosowanie odpowiednich środków technicznych i organizacyjnych, brak regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych oraz brak analizy zasadności braku szczegółowego dziennika zdarzeń w aplikacji. Co ważne, organ w przywołanej decyzji wskazał istotny element, jakim są testy penetracyjne. W jego ocenie „trudno mówić o przyjmowaniu pewnych założeń dotyczących zagrożeń, nie przeprowadzając pełnego formalnego audytu systemu, w tym testów penetracyjnych, nie mając tym samym świadomości, jakie możliwości ma osoba uzyskująca nieuprawniony dostęp do systemu informatycznego. Należy wyraźnie podkreślić, że analizując ryzyko w przyjmowanych scenariuszach (wektorach potencjalnego ataku), należy mieć świadomość, jakie realne możliwości ma atakujący, uwzględniając m.in. metody socjotechniczne, stan wiedzy technicznej, fizyczne aspekty bezpieczeństwa, w tym bezpieczeństwa teleinformatycznego, przy czym wspomnianego atakującego należy rozpatrywać zarówno z punktu widzenia osoby nieznającej organizacji administratora oraz jej infrastruktury informatycznej, jak również osoby, która wiedzę tę posiada”. Oznacza to, że podmiot, realizując analizę ryzyka, musi zakładać scenariusze potencjalnego ataku. Tym samym powinien przeprowadzić odpowiednie testy, w tym penetracyjne, oraz audyty, które pozwolą mu dowiedzieć się, z jakim ryzykiem wiąże się dany system.
Nie zapominaj o rejestrowaniu logów
Inną kwestią, na którą zwrócił uwagę organ nadzorczy we wspomnianej decyzji nr DKN.5130.2559.2020, są logi systemu (chodzi o zapisy informatyczne, które zawierają zestaw informacji umożliwiający stwierdzenie, kto, kiedy, jakie operacje, w odniesieniu do jakich danych wykonał w systemie). Nie każdy administrator zdaje sobie z tego sprawę, że logi pełnią istotną funkcję w utrzymywaniu kontroli nad systemem. W ocenie organu każdy administrator powinien przeanalizować, na jakim poziomie szczegółowości i przez jaki okres powinny być rejestrowane logowania do systemu. „Szczegółowość zapisów logów jest kwestią indywidualną, uzależnioną od zaimplementowanych funkcjonalności oraz zadań użytkownika. W kontekście przetwarzania danych osobowych administrator powinien móc również wykazać, że osoby, które upoważnił do przetwarzania danych osobowych, przetwarzają je zgodnie z zasadami określonymi w rozporządzeniu 2016/679, tj. tylko wtedy, kiedy jest to niezbędne dla uzyskania określonego celu przetwarzania oraz w zakresie jakim jest to niezbędne”.
Biorąc pod uwagę wskazane decyzje prezesa UODO, niewątpliwie testy oprogramowania są bardzo istotnym elementem ochrony danych osobowych. Nie ulega wątpliwości, że od ich poprawnego przygotowania, analizy ryzyka, cykliczności, poprawności, znajomości systemu będzie w znacznej mierze zależało, czy podmiot będzie w stanie wykazać odpowiednią staranność przy stosowaniu środków organizacyjnych i technicznych.
Zapraszamy do zadawania pytań
