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.
Zapraszamy do obejrzenia transmisji z wydarzenia:
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
Często zadawane pytania
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.
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.
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ń.
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.
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.
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).
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.
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.
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.
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
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.
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.
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)
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.
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.
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.
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 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.
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.
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.
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
You must be logged in to post a comment.