„Ochrona danych w fazie projektowania – wymogi RODO w tworzeniu oprogramowania” – seminarium naukowe

Written by Tomasz Soczyński

Seminarium zaplanowane zostało z myślą o osobach uczestniczących w procesach wytwarzania oprogramowania tj. programistach i architektach oprogramowania, czy osobach biorących udział w specyfikowaniu wymagań i odbieraniu systemów informatycznych. Jest ono adresowane także do wszystkich tych, którzy są zainteresowani tworzeniem systemów i programów zgodnych ze standardami wprowadzonymi przez RODO. Uczestnicy seminarium będą mogli zdobyć wiedzę oraz wziąć udział w dyskusji na temat aktualnej sytuacji prawnej dotyczącej ochrony danych osobowych, ze szczególnym uwzględnieniem jej wpływu na systemy informatyczne.

Prelegenci

Dr Edyta Bielak-Jomaa

Prezes Urzędu Ochrony Danych Osobowych. Doktor nauk prawnych, autorka ponad 30 opracowań z zakresu prawa pracy, problematyki rynku pracy oraz ochrony danych osobowych. Naukowo zajmuje się problematyką ochrony dóbr osobistych pracowników i ochroną danych osobowych w zatrudnieniu. Jako pierwsza rozpoczęła badania nad ochroną danych osobowych bezrobotnych i poszukujących pracy.

Maciej Gawroński

Maciej Gawroński jest radcą prawnym od ponad dwudziestu lat zajmującym się prawnymi aspektami nowoczesnych technologii. Maciej był konsultantem Grupy Roboczej Art. 29 ds. międzynarodowych transferów danych osobowych, ekspertem Komisji Europejskiej ds. kontraktów cloud computingowych, współpomysłodawcą niektórych przepisów RODO (przenoszalność danych, odpowiedzialność podprzetwarzających, forma elektroniczna (dokumentowa)). Maciej jest redaktorem i współautorem bestsellerowej książki „RODO Przewodnik ze wzorami”, książki „RODO i UODO Przewodnik ze wzorami” (publikacja 23.10.2018), książki „Przewodnik po ustawie o przeciwdziałaniu praniu pieniędzy i finansowaniu terroryzmu” (w publikacji). Maciej doradzał w setkach projektów informatycznych, w tym odpowiadał za pełen cykl życia wdrożenia IT o wartości przekraczającej miliard złotych w samych usługach. Maciej reprezentował też Polskę i przedsiębiorców w sporach o miliardowej wartości, w sporach patentowych, w kwestiach stricte korporacyjnych. Maciej wykładał prawo cloud computingu na studiach podyplomowych w Szkole Głównej Handlowej. Aktualnie Maciej Gawroński jest partnerem zarządzającym kancelarii Gawroński & Partners, współautorem systemu Good Data Protection System (gdpsystem.pl) firmy Good Data Protection Standard Sp. z o.o.

Dr Arwid Mednis

Dr Arwid Mednis jest specjalistą w zakresie prawa ochrony danych osobowych, bezpieczeństwa informacji i prawa telekomunikacyjnego. Jest radcą prawnym, wykładowcą na Wydziale Prawa i Administracji Uniwersytetu Warszawskiego. Dr Mednis jest autorem lub współautorem licznych publikacji naukowych z zakresu ochrony danych, prawa telekomunikacyjnego, a także prawa administracyjnego. Prowadzi praktykę TMT/IP & Data protection w PwC Legal.

Dr inż. Wacław Iszkowski

Senior Konsultant rynku teleinformatycznego, Ekspert PIIT, Członek Komitetu Informatyki PAN. [1971-1990] Adiunkt w Instytucie Informatyki Wydz. Elektroniki Politechniki Warszawskiej, prowadzący zajęcia z programowania, programowania współbieżnego i systemów operacyjnych. [1990-2004] Pracował w Oracle, Digital Equipment Corporation, EDS, 2SI oraz w TP Internet. [1993-2016] Co dwa lata wybierany na Prezesa Polskiej Informatyki i Telekomunikacji (PIIT). Aktywny udział w formułowaniu aktów prawnych w informatyce [w tym pierwsza ustawa o ochronie danych osobowych] oraz telekomunikacji. Członek Rad Informatyzacji. Członek Grupy Roboczej ISTAG przy DG INFSO KE. Członek EXB DigitalEurope i innych. [Współ]Autor podręczników informatycznych [BASIC, FORTRAN, Typy i Struktury Danych, Implementacja Systemów Operacyjnych, Programowanie Współbieżne} oraz o rynku teleinformatycznym [Przeszczep Managementu, Edytor Raportów Kongresów Informatyki] i wielu artykułów. Członek Honorowy Polskiego Towarzystwa Informatycznego.

Adrian Kapczyński

Uczeń Profesora Andrzeja Grzywaka, pasjonat informatyki, od 20 lat zgłębiający zagadnienia związane z bezpieczeństwem teleinformatycznym. Autor ponad 100 opracowań naukowych oraz uczestnik ponad 100 projektów w świecie praktyki gospodarczej.
W ramach Politechniki Śląskiej: wykładowca, lider zespołu badawczego, pełnomocnik dziekana ds. współpracy z przemysłem, pełnomocnik dziekana ds. zdalnej edukacji, konsultant w zakresie bezpieczeństwa informacji, członek wydziałowych komisji, uczelnianych rad ekspertów oraz uczelnianych zespołów projektowych. W ramach firmy Netology: specjalista w zakresie R&D, pełnomocnik zarządu ds. innowacji, członek rady nadzorczej. W ramach Polskiego Towarzystwa Informatycznego: dyrektor regionalny Izby Rzeczoznawców, wiceprezes zarządu Oddziału Górnośląskiego, prezes zarządu Sekcji Przyszłości IT, członek zarządu Sekcji Bezpieczeństwa Informacji oraz członek Rady Naukowej PTI. W ramach Polskiego Komitetu Normalizacyjnego, przewodniczący Komitetu Technicznego nr 309.
Edukator z powołania, fan zespołu Chicago Bulls, miłośnik serialu LOST, kolekcjoner dawnego sprzętu komputerowego oraz szczęśliwy tata niesamowitych córek.

Janusz Żmudziński

Wiceprezes Polskiego Towarzystwa Informatycznego. Architekt rozwiązań bezpieczeństwa IT w wiodących polskich firmach informatycznych. Od wielu lat zajmuje się rozwiązaniami związanymi z bezpieczeństwem informacji. Posiadane certyfikaty: CISA, CISM, CRISC, CISSP, CEH, Prince2 Practitioner, TOGAF. Członek Polskiego Towarzystwa Informatycznego, ISACA, Association of Enterprise Architects.

Błażej Pabiszczak

Założyciel i Prezes Zarządu firmy YetiForce Sp. z o.o. Od dziesięciu lat zajmuje się doradztwem i projektowaniem systemów open source a od czterech lat tworzy jeden z najlepszych systemów, dostępny dla każdego bez żadnych opłat i ograniczeń. Prelegent na wielu konferencjach związanych z bezpieczeństwem, otwartym oprogramowaniem i systemami CRM/ERP.

Dariusz Stefański

Kierownik Zespołu Audytów Technicznych i Proceduralnych w NASK PIB (Naukowa i Akademicka Sieć Komputerowa – Państwowy Instytut Badawczy. Auditor wiodący SZBI PN-ISO/IEC 27001:2013, Auditor wiodący Systemu Zarządzania Usługami PN-ISO/IEC 20000-1:2013, Auditor Wiodący Systemu Zarządzania Ciągłością Działania ISO 22301:2012, ISO 31000 Risk Manager. Obszary zainteresowań:  związane z analizą ryzyka w bezpieczeństwie informacji; audyt, projektowanie i wdrażanie Systemów Zarządzania Bezpieczeństwem Informacji; audyt, przetwarzania danych osobowych, projektowanie i wdrażanie rozwiązań w tym obszarze; audyt, projektowanie i wdrażanie Planów Ciągłości Działania.

Adam Masiak

Specjalista w obszarze ochrony danych oraz bezpieczeństwa informacji. Doświadczenie zdobywał jako administrator bezpieczeństwa informacji w sektorze ubezpieczeń. Aktualnie członek zespołu realizującego zadania w obszarze ochrony danych osobowych w T-Mobile Polska SA odpowiedzialny za aspekty ochrony prywatności w projektach technologicznych.

Pytania jakie państwo zadaliście w ramach seminarium „OCHRONA DANYCH W FAZIE PROJEKTOWANIA – WYMOGI RODO W TWORZENIU OPROGRAMOWANIA” były dla nas niezmiernie cenne i posłużyły nam do budowy zestawu praktycznych odpowiedzi.

Często zadawane pytania

Czy gdy hashowany zasób umożliwia realizację funkcji „podaj mi PESEL, ja obliczę hash i sprawdzę czy ten hash występuje w zbiorze, tobie odpowiem wyłącznie [TAK] albo [NIE]” to czy taki zasób jest zbiorem danych osobowych? Oczywiście możemy wzmocnić procedurę przez dodanie soli.

Jeżeli hashowany zasób zawiera numery PESEL lub inne dane osobowe, to nadal jest zestawem danych osobowych. Opinia 05/2014 w sprawie technik anonimizacji

Arwid Mednis: Z danymi osobowymi mamy do czynienia wszędzie tam gdzie można wskazać osobę, której dotyczą posiadane przez firmę/instytucję dane. PESEL może być daną osobową jeśli możemy (np. po połączeniu z innymi danymi) wskazać osobę której dotyczy. Jeśli zewnętrzny podmiot odpytuje bazę i ma dane wskazujące na konkretną osobę to odpowiedź TAK/NIE może dostarczyć mu dodatkowych informacji na temat zidentyfikowanej osoby. Dla podmiotu dysponującego bazą/zasobem dane są danymi osobowymi, jeśli – pomimo szyfrowania – może on wskazać kogo dotyczą. Szyfrowanie jest metodą zabezpieczenia danych, nie jest natomiast sposobem na niestosowanie RODO. Dopiero anonimizacja pozwala na niestosowanie Rozporządzenia.

Czy jeśli podmiot ma jedynie interes biznesowy w przetwarzaniu danych osobowych (tzn. nie interesują go konkretne rekordy danych a jedynie efekt w postaci zwiększenia sprzedaży) to czy można go uznać za ADO? przykład :realizacja akcji marketingowych przez dom mediowy dla konkretnych klientów

Tak zgodnie z RODO „administrator” oznacza osobę fizyczną lub prawną, organ publiczny, jednostkę lub inny podmiot, który samodzielnie lub wspólnie z innymi ustala cele i sposoby przetwarzania danych osobowych; jeżeli cele i sposoby takiego przetwarzania są określone w prawie Unii lub w prawie państwa członkowskiego, to również w prawie Unii lub w prawie państwa członkowskiego może zostać wyznaczony administrator lub mogą zostać określone konkretne kryteria jego wyznaczania;

„przetwarzanie” oznacza operację lub zestaw operacji wykonywanych na danych osobowych lub zestawach danych osobowych w sposób zautomatyzowany lub niezautomatyzowany, taką jak zbieranie, utrwalanie, organizowanie, porządkowanie, przechowywanie, adaptowanie lub modyfikowanie, pobieranie, przeglądanie, wykorzystywanie, ujawnianie poprzez przesłanie, rozpowszechnianie lub innego rodzaju udostępnianie, dopasowywanie lub łączenie, ograniczanie, usuwanie lub niszczenie;

Arwid Mednis: „Interes biznesowy” może wystarczyć do uznania za ADO, jeśli podmiot przetwarzając dane realizuje własne potrzeby (np. reklamuje własne produkty). Jeśli wykonuje czynności wyłącznie na rzecz innego podmiotu (np. realizuje kampanię marketingową w imieniu innej firmy) i nie korzysta z danych dla własnych celów, wówczas jest w świetle RODO podmiotem przetwarzającym.

Czy możliwe jest przyjęcie, że zasada ograniczenia czasu przechowywania danych nie ma zastosowania do zarchiwizowanych kopii zapasowych służbowych kont poczty elektronicznej ?

Zasada ograniczenia czasowego ma zastosowanie do zarchiwizowanych kopii zapasowych. Administrator powinien przewidzieć okres przechowywania zgodny z przyjętymi celami przetwarzania, np. archiwizacja w celu dokumentowania złożonych zamówień.

Czy można archiwizować wnioski z żądaniem usunięcia danych w celu ewentulanego „ustalenia, dochodzenia lub obrony roszczeń”?

Usunięcie danych wprawdzie nie powinno oznaczać ich wtórnego przechowywania, jednak zasada rozliczalności (art. 5 ust. 2 RODO) może wymagać zachowania informacji czy dokumentów potwierdzających komunikację z osobą składającą żądanie usunięcia danych i fakt usunięcia takich informacji.

Czy obowiazki wynikające z Privacy by Design są po stronie „Zamawiającego” czy dostawcy systemu, który dostarcza rozwiązanie na podstawie np. SIWZ?

Obowiązki wynikające z art. 25 RODO ostatecznie leżą po stronie administratora danych, który będzie korzystał z rozwiązań dostarczanych w ramach przetargów publicznych. Może to być zamawiający albo podmiot, na którego rzecz on działa. Z taką sytuacją mieliśmy dotychczas do czynienia w przypadku instytucji Administratora Systemu Informatycznego, który odpowiadał za dostarczanie oprogramowania wielu administratorom danych (np. minister spraw wewnętrznych i administracji zapewniający rozwiązania techniczne dla centrów powiadamiania ratunkowego zgodnie z art. 10 ustawy o systemie powiadamiania ratunkowego).

Maciej Gawroński: W praktyce jednak zamawiający może oczekiwać, aby dostawca zapewnił obsługę wymogów składających się w jego ocenie na „Privacy by design”. Powinien jednak sformułować konkretne oczekiwania, jeżeli miałyby one stanowić warunki udziału lub kryteria oceny.

Czy ochrona danych osobowych kończy się na etapie projektowania systemu IT? A co z testami, wdrożeniem, zarządzaniem zmianami i konfiguracją?

Ochrona danych osobowych jest wymagana nie tylko w cyklu życia danych ale także w całym cyklu życia systemu, w którym są one przetwarzane (zaczynając od jego projektowania, poprzez regularne testowanie i aktualizowanie w celu wyeliminowania zidentyfikowanych luk i podatności, aż po jego wycofywanie z eksploatacji). Wynika to z art. 25 RODO dot. wymogu ochrony danych w fazie projektowania (Privacy by Design).

Czy praktyka tworzenia takich samych identyfikatorów (nie identyfikujących wprost osoby fizyczne np. skrót MD5 z adresu e-mail bez soli) przez wielu ADO w tej samej branży jest podstawą do uznania, że ryzyko dla prywatności jest podwyższone i czy należałoby ten fakt uwzględnić w analizie ryzyka?

Praktyka wykorzystywania takich samych identyfikatorów dla jednej osoby w różnych systemach, bez względu na to, czy są one tworzone z lub bez soli, powinno być uznana jako jeden z czynników zwiększających ryzyko dla prywatności i uwzględnione w analizie ryzyka.

Czy przekazanie zewnętrznemu podmiotowi danych poddanych pseudonimizacji (klucz posiada ADO, a nie odbiorca) wiąże się z obowiązkiem zawarcia umowy powierzenia ?

Umowa powierzenia jest wymagana w przypadku powierzenia przetwarzania danych osobowych niepoddanych pseudonimizacji czy anonimizacji.

Arwid Mednis: Przekazanie danych spseudonimizowanych przez ADO innemu podmiotowi, dla którego są one de facto anonimowe, nie jest powierzeniem przetwarzania danych osobowych. ADO powinien jednak zwrócić uwagę czy odbiorca danych nie ma możliwości identyfikacji konkretnych osób.

Czy przewoźników (kurierów) uznajemy za administratorów czy procesorów?

Kurierzy mogą działać jako operatorzy pocztowi na podstawie umowy o świadczenie usług pocztowych, tzn. podmioty, którym powierzono przetwarzanie danych w zakresie dostarczania przesyłek. Warto porównać z analogiczną sytuacją pod rządami ustawy o ochronie danych osobowych z 1997 r.: https://www.giodo.gov.pl/file/12539[PDF]

Maciej Gawroński: W mojej ocenie operator pocztowy jest administratorem danych przetwarzanych w ramach wykonywania działalności regulowanej. Stąd z operatorem usługi kurierskiej nie ma potrzeby zawierać umowy powierzenia przetwarzania danych, skoro nie zawiera się takiej umowy z Pocztą Polską. Jeżeli jednak operator usługi kurierskiej lub innej pocztowej miałby świadczyć dodatkowe usługi (np. kopertowanie), wtedy umowa powierzenia byłaby potrzebna. Zakres dostępu do danych byłby bowiem większy niż potrzebny do wykonywania działalności regulowanej.

Czy w przypadku projektowania systemów w modelu SaaS, które przetwarzają dane osobowe, umowa powierzenia przetwarzania danych osobowych może być jako załącznik akceptowanego przez użytkownika regulaminu użytkowania? Czy niezbędne jest uwierzytelnienie takiego regulaminu podpisem kwalifikowanym?

Administrator danych  może powierzyć dane osobowe innemu podmiotowi, w drodze umowy zawartej na piśmie lub w formie elektronicznej. Co do zasady praktyczniejszym podejściem może okazać się  zastosowanie aneksu do umowy z uwagi na to, że regulamin może wprowadzić w błąd a pamiętajmy że obie strony muszą zapewnić zgodność z art. 28 RODO. Jednakże zasady zawierania umów lub innych aktów prawnych, w tym w formie elektronicznej, nie są określone w RODO, ale w innych przepisach unijnych i / lub krajowych.Podpis elektroniczny jest jednym z kilku sposobów udowodnienia zawarcia umowy

Maciej Gawroński:Tak. umowa powierzenia przetwarzania danych osobowych może być załącznikiem do regulaminu i może podlegać zawarciu przez elektroniczną akceptację. Nie ma konieczności stosowania podpisu elektronicznego. Wyjaśniła to Komisja Europejska http://www.europarl.europa.eu/doceo/document/E-8-2018-003163-ASW_EN.html?redirect

 

Jak należy rozumieć motyw 29-w tym:”należy umożliwić stosowanie u tego samego administratora środków pseudonimizacyjnych niewykluczających ogólnej analizy o ile admin. ten zastosował środki tech. i organiz. niezbędne do tego, by niniejsze rozporz. zostało wdrożone w zakresie danego przetwarzania”

Motyw ten należy czytać razem z motywem nr 28, zgodnie z którym pseudonimizacja nie powinna wykluczać stosowania innych środków ochrony danych osobowych. Ogólna analiza danych osobowych oznacza jedną z form przetwarzania danych osobowych.

Jaka jest koncepcja „zabezpieczenia funkcjonalności realizacji prawa do ograniczenia przetwarzania danych” w systemach informatycznych? („Oflagowanie”, „otagowanie” rekordów w celu wykluczenia z wykonywania pewnych (jakiego katalogu) operacji?)

Ponieważ przepisy o ograniczaniu przetwarzania danych są neutralne technologicznie, zastosowane metody są zależne od przyjętych procedur działania i stosowanego oprogramowania. Przykładowo, jeżeli flagowanie lub tagowanie rekordów, których dotyczy ograniczenie przetwarzania spełniają żądanie osoby, której dane dotyczą, to będą wystarczające. Takie oznaczanie powinno być jasnym sygnałem dla pracowników, że dane można przechowywać, ale nie należy ich tymczasowo używać w zwyczajnych procesach.

Jaki jest przyjęty sposób (albo koncepcja) realizacji praw osób, których dane przetwarza administrator w systemach nieustrukturalizowanych (poczta, EZD) ? W szczególności mając na uwadze, że dane osobowe nie mogą zazwyczaj być użyte jako kryteria wyszukiwania.

Sposób realizacji praw osób w tego typu systemach, zależy od jego implementacji, dlatego tego typu pytanie należy zadać jego producentowi. Trzeba jednak pamiętać, że nawet w systemach niestrukturalizowanych możliwe jest wyszukiwanie informacji wg pewnych kryteriów.

Maciej Gawroński:  Odpowiedź zależy od możliwości zautomatyzowanego przetwarzania takich nieustrukturyzowanych danych w konkretnym systemie, ponieważ RODO stosuje się zasadniczo do zautomatyzowanego przetwarzania danych (art. 2 RODO). Jednak możliwość zautomatyzowanego wyszukiwania danych, nie obliguje nas, zgodnie z art. 11 ust. 1 RODO, do korzystania z niej tylko po to, aby zastosować RODO w całości. Jeżeli natomiast osoba zgłosi się w celu wykonania swoich praw, należy wykorzystać istniejące możliwości technologiczne pod warunkiem, że poda ona potrzebne szczegóły (zgodnie z art. 11 ust. 2 RODO)

Jakie są różnice w podejściu do zasad ( wymogów) projektowania systemów informatycznych przed i w trakcie obowiązywania RODO? Jakie najważniejsze różnice w posiadanych funkcjonalnościach powinien mieć system IT przed i w trakcie obowiązywania RODO?

Podejście do projektowania systemów przed i po RODO nie powinny się w dużym stopniu różnić, bo wymagania bezpieczeństwa i prywatności danych istniały w polskim prawodawstwie przed rozpoczęciem stosowania RODO. Wymagania funkcjonalne systemów powinny oczywiście zapewnić przetwarzanie danych zgodnie z obowiązującymi przepisami, realizację praw osób fizycznych i rozliczalność administratora.

Maciej Gawroński: Ja się z tym mocno nie zgadzam 😊 Projektowanie systemów informatycznych przed RODO w praktyce pomijało zarówno aspekty prywatności jak i kwestie bezpieczeństwa, spychając te zagadnienia na nabywców systemów. RODO zmienia tę sytuację zdecydowanie. Dostawca systemu nie może już zasłaniać się wykrętem „zrobicie sobie bezpieczeństwo jakie chcecie” lub przemilczeć kwestii obsługi praw jednostki przez funkcjonalności natywne systemu i musi być gotowy na zmierzenie się z tymi wyzwaniami.

Arwid Mednis: Wymagania odnośnie do systemów były przed RODO w znacznym stopniu regulowane przepisami prawa. Pod rządami RODO, nie ma konkretnych wymagań w przepisach, natomiast istnieje ogólny obowiązek uwzględniania przy projektowaniu rozwiązań technicznych stanu wiedzy technicznej, kosztów wdrażania oraz charakteru, zakresu, kontekstu i celów przetwarzania oraz ryzyka naruszenia praw lub wolności osób fizycznych. Jest to tzw. risk-based approach.

Jakie środki techniczne systemów informatycznych powinny zostać wdrożone by spełniać wymogi RODO pod kątem bezpieczeństwa danych? Szyfrowanie dysków, szyfrowanie wiadomości e-mail, szyfrowanie wybranych zasobów, systemy kontroli dostępu, DLP?

Obowiązuje co do zasady risk-based approach. Zgodnie z Art. 32 ust. 1 lit. c) RODO administrator i podmiot przetwarzający wdraża odpowiednie środki techniczne takie jak regularne testowanie, mierzenie i ocenianie skuteczności środków technicznych i organizacyjnych mających zapewnić bezpieczeństwo przetwarzania danych osobowych.  Przykładowe zabezpieczenia można znaleźć np. w normach ISO z serii 27000 i można je użyć jako punkt wyjściowy.

Kiedy warto wykonać testy penetracyjne dla uruchamianego systemu IT? Kto powiniem przeprowadzić takie testy?

Testy penetracyjne pozwalają zweryfikować, czy zdefiniowane w fazie projektowania wymagania bezpieczeństwa i prywatności są właściwie zaimplementowane (tzw. Privacy by Design). Testy penetracyjne powinny być wykonane przed wdrożeniem oraz powtarzane cyklicznie. Jeżeli testy takie miałby przeprowadzić podmiot zewnętrzny i doszłoby do dostępu do danych osobowych, konieczne jest zawarcie umowy powierzenia danych. W przypadku pracownika itp. podobnych osób wystarczające może być upoważnienie do dostępu.

Proszę o przykład realizacji pseudonimizacji, np. w postaci modelu architektury i omówienia sposobu implementacji mechanizmów dostępu do pseudonimizowanych danych.

Model pseudonimizacji oraz jego implementacja musi być stosowny do systemu i zakresu danych oraz celów i sposobów ich przetwarzania. Przykład zostanie opracowany i przedstawiony w terminie późniejszym.

W jaki faktyczny sposób realizowany jest w aktualnych systemach IT służących do przetwarzania danych osobowych (w których dochodzi do przetwarzania danych osobowych) proces archwizowania (przekazywania do zasobu archiwalnego) danych mając na uwadze kontekst m.in. JRWA/kategorii archiwalnej/etc ?

W  JRWA odnajdujemy klasyfikację wskazującą okres przechowywania dokumentacji wynikającą np. z przepisów prawa pracy, rozliczeń finansowych, kodeksu postępowania administracyjnego itp. Wymogi te muszą być realizowane w systemach przetwarzających dane. Administrator danych wymaga od dostawców oprogramowania zapewniania zgodności z przepisami  w szczególności o ochronie danych i archiwizacji.

Maciej Gawroński: Zasadniczo aktualnie systemy IT obsługują proces archiwizacji i usuwania danych w szczątkowym stopniu.

W jaki sposób stosować zapis z motywu 78-„Zasadę uwzględniania …należy też brać pod uwagę w przetargach publicznych.” Czy w zapisach SIWZ należy precyzyjnie opisać jak zamawiający rozumie tę zasadę, a jeśli tak, to jak taki zapis może/powinien wyglądać? Jak oceniać spełnialność takiego zapisu?

Istotne warunki zamówienia powinny uwzględniać zasady Privacy by Design i Privacy by Default.

Arwid Mednis: Odpowiedź na to pytanie zależy od charakteru zamówienia. Jeśli istotą usługi jest przetwarzanie danych osobowych (np. zamówienie dotyczy budowy rejestru z danymi), wówczas zamawiający jako ADO powinien wykonać ocenę skutków przetwarzania (tzw. DPIA) i na tej podstawie określić w SIWZ środki, które jego zdaniem mitygują stwierdzone ryzyko.

Maciej Gawroński: Postulat uwzględniania obu zasad PbD w zamówieniach publicznych wymaga przemyślenia przez zamawiających, aby prawidłowo przekuć go w stosowne warunki udziału lub kryteria oceny. RODO nie daje w tym zakresie żadnych podpowiedzi. Idealnie należałoby zapewnić zamawiającemu wybór najlepszej jego zdaniem metody urzeczywistniającej te zasady spośród zaproponowanych przez oferentów. W świetle dotychczasowego orzecznictwa Krajowej Izby Odwoławczej będzie to zapewne niemożliwe.

W jaki sposób zrealizować prawo do ograniczenia przetwarzania w sytuacji w której dane osobowe przetwarzane są w Excel’u lub w aplikacji typu Płatnik?

Realizacja tego prawa powinna oprzeć się na możliwości wyłączenia pewnych rekordów z tymczasowego przetwarzania (z wyjątkiem przechowywania danych), ale nie jest możliwe podanie jednego zestawu wskazówek. Będzie to zależało od funkcjonalności każdego systemu / aplikacji. Dlatego administrator danych dokonując wyboru danego rozwiązania technicznego poddaje analizie wymagane funkcjonalności w procesie przetwarzania danych.

Maciej Gawroński: Co do przetwarzania w Excelu można rozważyć dodanie dwóch kolumn: Ograniczenie przetwarzania Toggle Y/N, Ograniczenie przetwarzania Explanation.

Z której metodyki OWASP korzystać przy budowaniu aplikacji? W jaki sposób dostosować metodyki OWASP do własnej organizacji?

Wybór szczegółowych praktyk OWASP zależy od rodzaju aplikacji, jej funkcjonalności oraz specyfiki organizacji. Dlatego najlepiej jest na początku zapoznać się z nią w całości, a potem wspólnie ze specjalistami od cyberbezpieczeństwa ustalić, które jej elementy należy zastosować we wszystkich systemach, a które w konkretnych aplikacjach. Pełna informacja (w języku angielskim) jest dostępna tutaj: https://www.owasp.org

link do gry:
https://techinfo.uodo.gov.pl/webgl/index.html