Czy ADO zamawiający aplikacje powinien wraz z aplikacją dostać od firmy tworzącej aplikacje dokumentacje związaną z realizacją art. 25 RODO przez firmę tworzącą aplikację?

ODPOWIEDŹ

Obowiązek posiadania dokumentacji związanej z ochroną danych osobowych w fazie projektowania spoczywa na administratorze. Rzecz jasna, firma programistyczna może –
a wręcz powinna – być zaangażowana w data protection by design (szczególnie w aspektach związanych z bezpieczeństwem), natomiast może nie mieć pełnej wiedzy co do planowanych przez ADO celów i sposobów przetwarzania danych osobowych.

Punktem wyjścia do wdrożenia domyślnej ochrony danych powinno być dokładne rozpisanie sekwencji kolejnych działań składających się na proces, który ma być realizowany w ramach projektowanej aplikacji, przykładowo (w dużym uproszczeniu, w odniesieniu do procesu przetwarzania danych osobowych w związku z przypadkami mobbingu):

1. zgłoszenie przypadku mobbingu,
2. weryfikacja zgłoszenia przez komisję antymobbingową,
3. podjęcie decyzji co do dalszego postępowania ze zgłoszeniem:
   • umorzenie
   • postępowanie dyscyplinarne
   • zgłoszenie podejrzenia popełnienia przestępstwa,
4. archiwizacja dokumentów,
5. brakowanie dokumentów.

Następnie, każdą z powyższych operacji przetwarzania należy poddać ocenie pod kątem zdolności do zapewnienia zasad ochrony danych (art. 5 RODO) oraz praw (12-22 RODO)
i wolności (Karta Praw Podstawowych UE) osób, których dane dotyczą. W szczególności, ocena zasad ochrony danych oraz realizacji praw osób, których dane dotyczą, powinna być realizowana przez ADO i w oparciu o jego wytyczne, ponieważ deweloperzy mogą nie znać m.in. podstaw prawnych, na których administrator chce oprzeć przetwarzanie, planowanych przez niego okresów retencji czy ewentualnego przekazywania danych do państw trzecich.

Firma programistyczna powinna natomiast odgrywać aktywną rolę w kontekście wdrażanych mechanizmów bezpieczeństwa. Wytyczna EROD 4/2019 wskazuje w tym aspekcie, że dostarczając rozwiązania informatyczne, producenci oprogramowania powinni wykorzystywać swoją wiedzę fachową do budowania zaufania i „kierowania” swoimi klientami na etapie projektowania rozwiązań, które gwarantują poszanowanie dla praw i wolności osób, których dane dotyczą.

To z kolei oznacza, że projektowanie produktów i usług powinno ułatwiać zaspokojenie potrzeb administratorów danych. I dalej: podmioty przetwarzające oraz producenci aplikacji powinni odgrywać aktywną rolę w spełnianiu przez administratora wymogu uwzględniania „stanu wiedzy technicznej” 
i powiadamiać go o wszelkich zmianach, które mogą wpłynąć na skuteczność stosowanych przez niego/nich środków. EROD zaleca również, aby administratorzy zagwarantowali sobie pomoc procesora/producenta oprogramowania w realizacji tego obowiązku w zawieranych umowach.

Jeżeli chodzi zaś stricte o wymagania dot. funkcjonalności systemu IT, to pozwolę sobie wskazać na pewien „standard”, który aplikacje powinny realizować, natomiast absolutnie nie twierdzę, że jest to katalog zamknięty.

Funkcjonalności dotyczące realizacji praw osób, których dane dotyczą

1. Odnotowywanie informacji odnośnie udzielonej zgody (jeżeli będzie ona podstawą przetwarzania) w ramach logów systemowych:
   1. Kto udzielił zgody i jaką miała ona treść?
   2. Kiedy została ona udzielona?
   3. Jakie informacje otrzymał podmiot danych przy składaniu oświadczenia o wyrażeniu zgody?
   4. Jakie informacje zostały udzielone o sposobie wyrażenia zgody?
   5. Czy zgoda została wycofana, a jeśli tak, to kiedy?
2. Możliwość umieszczenia tzw. obowiązku informacyjnego (art. 13 RODO) w sytuacji pozyskiwania danych osobowych bezpośrednio od osoby, której dane dotyczą.
3. Zdolność do tzw. aktywnej retencji, tj. zdefiniowania czasów, po przekroczeniu których określone rekordy będą usuwane z systemu (oraz kopii zapasowych).
4. Zdolność do usuwania rekordów odnoszących się do poszczególnych osób fizycznych
   (art. 17 RODO).
5. Zdolność do zablokowania poszczególnych rekordów danych, tak aby ich przetwarzanie ograniczało się wyłącznie do fizycznego przechowywania (art. 18 RODO).
6. Zdolność do wyeksportowania bazy danych zawierającej dane osobowe do formatu CVS.
7. Zdolność do zablokowania pewnych rekordów w kontekście prowadzonych działań marketingowych (prawo do sprzeciwu, prawo do wycofania zgody).
8. Odnotowywanie daty pierwszego wprowadzenia danych do systemu.
9. Odnotowywanie identyfikatora użytkownika wprowadzającego dane osobowe do systemu.
10. Odnotowywanie identyfikatora użytkownika dokonującego poszczególnych operacji na danych osobowych.
11. Odnotowywanie źródła danych, w przypadku zbierania danych nie od osoby, której one dotyczą.
12. Odnotowywanie informacji o odbiorach danych.

Funkcjonalności dotyczące bezpieczeństwa

1. Niewyświetlanie identyfikatorów systemu lub aplikacji, aż do chwili pomyślnego zakończenia procedury logowania się do systemu.
2. Wyświetlanie podczas logowania ogólnego ostrzeżenia, że dostęp do systemu jest dozwolony jedynie dla uprawnionych użytkowników.
3. Niewyświetlanie w trakcie logowania komunikatów pomocniczych, które mogłyby pomóc nieuprawnionemu użytkownikowi.
4. Zatwierdzanie jedynie kompletnych informacji wejściowych, niezbędnych do zalogowania. Jeżeli wystąpi błąd, to zaleca się, aby system nie wskazywał, która część danych jest poprawna lub niepoprawna.
5. Ochrona przed próbami zalogowania się poprzez podanie wszystkich możliwych kombinacji.
6. Wykonywanie zapisu nieudanych i udanych prób logowania.
7. Generowanie zdarzenia związanego z bezpieczeństwem, jeśli została wykryta potencjalna próba lub wykryto udane przełamanie zabezpieczeń logowania.
8. Wyświetlanie następujących informacji po pomyślnym zakończeniu procedury logowania:
   • data i godzina ostatniego pomyślnego logowania się do systemu,
   • szczegółowe dane dotyczące nieudanych prób logowania się, jakie zdarzyły się od chwili ostatniej udanej próby.
9. Blokowanie wyświetlania wprowadzanego hasła.
10. Niemożność przesyłania haseł przez sieć otwartym tekstem.
11. Zamykanie nieaktywnych sesji po określonym czasie nieaktywności użytkownika.
12. Wymuszanie użycia indywidualnych identyfikatorów użytkownika i haseł, aby zapewnić zachowanie rozliczalności.
13. Wymuszanie wyboru haseł odpowiedniej jakości.
14. Wymuszanie na użytkownikach zmiany haseł przy pierwszym logowaniu.
15. Wymuszanie okresowe zmiany haseł oraz zmiany w razie potrzeby.
16. Prowadzenie spisu poprzednio używanych haseł użytkowników oraz zapobieganie ponownemu ich użyciu.
17. Uniemożliwianie wyświetlania haseł na ekranie podczas ich wprowadzania.
18. Przechowywanie plików z hasłami w innym miejscu niż dane systemu aplikacji.
19. Przechowywanie i przesyłanie hasła w formie zabezpieczonej.