Wersja 1.1.0 (rew. 1) · Obowiązuje od 21 września 2026.
SHA-256: 2b13f39ac63c…
2b13f39ac63c3333bfd77f2dee21677b1e23c3dd1ffa7f282af544aa43f45ca5Załącznik nr 2 do DPA - Środki techniczne i organizacyjne Akta CRM
Wersja: 1.1.0 (rewizja 1)
Data aktualizacji: 4 września 2026 r.
Numeracja: podany wyżej numer wersji pochodzi z rejestru rewizji dokumentów prawnych i jest tym samym numerem, który wraz z sumą kontrolną SHA-256 zapisywany jest w potwierdzeniu prawnym Kancelarii. Wcześniejsze wydania tego dokumentu były dodatkowo oznaczane odrębną numeracją redakcyjną (ostatnio „1.4”); numeracja ta jest historyczna, nie jest numerem wersji dokumentu i nie jest dalej prowadzona.
Podmiot przetwarzający: Yaraslau Lahinouski, osoba fizyczna świadcząca usługę Akta CRM
Kontakt: [email protected]
Niniejszy dokument stanowi Załącznik nr 2 do Umowy powierzenia przetwarzania danych osobowych zawartej pomiędzy Yaraslau Lahinouski a Kancelarią. Jest doręczany elektronicznie przy zawarciu umowy i publikowany pod adresem aktacrm.com/dpa/annex-2.
Zgodnie z art. 30 ust. 2 lit. d RODO jest to ogólny opis środków technicznych i organizacyjnych. Szczegóły konfiguracji zabezpieczeń nie są ujawniane, ponieważ ich publikacja sama w sobie obniżałaby poziom ochrony. Na uzasadnione żądanie Administrator może otrzymać dodatkowe informacje w trybie art. 28 ust. 3 lit. h RODO.
1. Izolacja danych Kancelarii
Dane każdej Kancelarii są odseparowane na poziomie bazy danych, a nie tylko interfejsu. Każdy rekord należy do jednej Przestrzeni Roboczej, a reguły bezpieczeństwa bazy danych uniemożliwiają odczyt i zapis poza własną Przestrzenią. Separacja jest weryfikowana automatycznymi testami przed każdym wdrożeniem.
2. Uwierzytelnianie i uprawnienia
Każdy użytkownik ma indywidualne konto. Dostęp do danych wynika z roli nadanej przez Kancelarię (właściciel, administrator, prawnik, asystent, dostęp tylko do odczytu), a uprawnienia są sprawdzane po stronie serwera i bazy danych, niezależnie od interfejsu. Operacje o podwyższonym ryzyku wymagają ponownego uwierzytelnienia.
Konto może zostać dodatkowo zabezpieczone drugim składnikiem uwierzytelnienia — jednorazowym kodem z aplikacji (TOTP). Składnik ten jest dostępny dla każdego konta użytkownika Kancelarii i włącza go samodzielnie posiadacz konta w ustawieniach. Kancelaria może ponadto wymagać drugiego składnika od wszystkich swoich użytkowników. Wymóg ten ustawia wyłącznie właściciel Przestrzeni Roboczej; jego zmiana należy do operacji o podwyższonym ryzyku, wymaga ponownego uwierzytelnienia i pozostawia wpis w rejestrze działań Kancelarii. Podniesienie wymogu jest odrzucane po stronie bazy danych, dopóki sam właściciel nie ma potwierdzonego składnika — w przeciwnym razie wymóg odciąłby od Przestrzeni Roboczej także jego, a nikt inny nie może go zdjąć; zdjęcie wymogu nie jest uzależnione od żadnego warunku tego rodzaju. Wymóg zaczyna obowiązywać przy kolejnym wejściu do Przestrzeni Roboczej: osoby pracujące w chwili jego włączenia nie są wylogowywane, a otwarte sesje nie są przerywane. Osobie bez potwierdzonego składnika Przestrzeń Robocza nie jest pokazywana — zamiast niej otwiera się ekran włączenia składnika. Wymóg rozstrzyga o wejściu do Przestrzeni Roboczej i nie jest warunkiem, od którego reguły bezpieczeństwa bazy danych uzależniają dostęp do poszczególnych rekordów. Dla konsoli operatorskiej Usługodawcy drugi składnik jest natomiast wymagany bezwarunkowo — dostęp bez potwierdzonego drugiego składnika jest odrzucany po stronie bazy danych i nie ma ścieżki zastępczej. Zresetowanie drugiego składnika użytkownika przez Usługodawcę pozostawia wpis w rejestrze działań Kancelarii i powoduje zawiadomienie właściciela Przestrzeni Roboczej.
3. Szyfrowanie i przechowywanie
Transmisja odbywa się wyłącznie kanałem szyfrowanym. Dane w bazie i pliki w magazynie obiektowym są szyfrowane w spoczynku po stronie dostawców infrastruktury. Dokumenty nie są dostępne publicznie — udostępniane są wyłącznie przez krótko ważne, podpisane odnośniki wydawane po sprawdzeniu uprawnień.
4. Rozliczalność i rejestr działań
System prowadzi rejestr zdarzeń w trybie wyłącznie dopisywania: zapisów nie można zmienić ani usunąć. Dowody zawarcia umowy — treść zaakceptowanych dokumentów, ich sumy kontrolne, znacznik czasu i metoda uwierzytelnienia — są niezmienne i przechowywane jako realizacja obowiązku z art. 5 ust. 2 RODO.
5. Usuwanie i potwierdzenie usunięcia
Usunięcie Przestrzeni Roboczej obejmuje bazę danych, magazyn plików, kopie w zasobniku zapasowym oraz odwołanie powiązanych integracji. Każdy etap jest weryfikowany, a zakończenie procesu potwierdzane trwałym znacznikiem, który blokuje przypadkowe odtworzenie danych. Administrator otrzymuje potwierdzenie usunięcia zgodnie z DPA.
Prawidłowość tego procesu jest monitorowana automatycznie w obu kierunkach: zarówno zatrzymanie usuwania, jak i jego uruchomienie przed właściwym terminem powodują alert wymagający interwencji człowieka.
6. Kopie zapasowe i ciągłość działania
Kopie zapasowe bazy danych są tworzone i przechowywane przez dostawcę bazy. Kopie dokumentów są przechowywane w odrębnym zasobniku w tej samej jurysdykcji i usuwane po 90 dniach.
Poza kopiami tworzonymi przez dostawcę bazy Usługodawca nie utrzymuje własnej, niezależnej od tego dostawcy kopii bazy danych. Zadanie, które wykonywało dobowy zrzut logiczny bazy do odrębnego zasobnika, zostało wycofane 5 sierpnia 2026 r.; od tego dnia jedyną ścieżką odtworzenia bazy są kopie zarządzane przez dostawcę bazy, obejmujące — na planie, z którego Usługodawca u niego korzysta — siedem ostatnich dób. Wynikają z tego dwa następstwa i Kancelaria powinna je znać przed oceną z art. 32 ust. 1 lit. b i c RODO: zdarzenie dotyczące samego dostawcy, czyli utrata projektu albo konta u niego, nie ma dziś ścieżki odtworzenia, a stanu bazy sprzed okresu przechowywania kopii u dostawcy nie da się odtworzyć. Kopie dokumentów są od tego niezależne — leżą w zasobniku innego dostawcy i awarii bazy nie podlegają. Usługodawca ujawnia ten stan, zamiast opisywać plan ciągłości działania, którego w części dotyczącej bazy danych nie ma; przywrócenie niezależnej kopii bazy jest przedmiotem odrębnej decyzji i nie jest w niniejszym załączniku przyrzekane.
Odtworzenie danych z kopii cofa bazę do stanu wcześniejszego, może więc przywrócić do niej Przestrzeń Roboczą już usuniętą — razem z zapisem o jej usunięciu. Dlatego po każdym odtworzeniu danych, zanim odtworzone środowisko zostanie dopuszczone do użytku, Usługodawca sprawdza według udokumentowanej procedury, czy w odtworzonych danych nie znalazła się Przestrzeń Robocza wcześniej usunięta, a każdą znalezioną usuwa ponownie. Sprawdzenie opiera się na zapisach o usunięciu istniejących niezależnie od odtwarzanej bazy, w tym na potwierdzeniach usunięcia doręczonych Administratorom; jego wykonanie jest odnotowywane.
7. Bezpieczny rozwój i zmiany
Zmiany w systemie przechodzą automatyczne testy obejmujące izolację danych i uprawnienia, a wdrożenie produkcyjne jest możliwe wyłącznie po ich pomyślnym zakończeniu. Zmiany w strukturze bazy danych są wersjonowane i porównywane ze stanem produkcyjnym przed wdrożeniem.
8. Organizacja dostępu i poufność
Dostęp administracyjny do środowiska produkcyjnego ma wyłącznie Usługodawca i jest ograniczony do czynności niezbędnych do świadczenia usługi. Każda operacja administracyjna wymaga podwyższonego uwierzytelnienia, potwierdzenia i pozostawia niezmienny wpis w rejestrze. Usługodawca zapewnia, aby każda osoba przez niego upoważniona do przetwarzania danych Kancelarii była zobowiązana do zachowania tajemnicy, zgodnie z art. 28 ust. 3 lit. b RODO; jego własny obowiązek zachowania poufności wynika z DPA. Osoby zapraszane przez Kancelarię do jej Przestrzeni Roboczej składają odrębne zobowiązanie do zachowania poufności przy przyjęciu zaproszenia — jest to zobowiązanie umowne wobec Kancelarii, a nie wykonanie art. 28 ust. 3 lit. b RODO.
9. Obsługa incydentów
Zgłoszenia i podejrzenia naruszenia ochrony danych są przyjmowane pod adresem [email protected] oraz przez dedykowany formularz w systemie. Usługodawca zawiadamia Administratora bez zbędnej zwłoki po stwierdzeniu naruszenia i udziela pomocy w wykonaniu obowiązków z art. 33 i 34 RODO. W razie potrzeby dostęp do Przestrzeni Roboczej może zostać czasowo ograniczony na czas wyjaśnienia.
10. Podprocesorzy
Lista podprocesorów, zakres powierzonych im danych, lokalizacje przetwarzania i podstawy transferu znajdują się w Załączniku nr 1. Zmiana składu podprocesorów wymaga uprzedniego powiadomienia Administratora z prawem sprzeciwu.
11. Kontrola wgrywanych plików
Dokumenty wgrywane do sprawy lub do kartoteki klienta przyjmowane są wyłącznie w formatach PDF, JPEG i PNG. Typ pliku rozpoznaje się po jego zawartości — po sygnaturze rozpoczynającej plik — a nie po rozszerzeniu nazwy; plik, którego zawartość nie odpowiada typowi zadeklarowanemu przy wgrywaniu, jest odrzucany, tak samo jak plik, którego rozmiar w magazynie różni się od zadeklarowanego. Treść przyjętego pliku jest następnie badana regułami wykrywającymi zawartość aktywną: w dokumencie PDF — elementy uruchamiające skrypt, otwierające zewnętrzny program, osadzające inny plik lub formularz wykonywalny; w obrazie — kod dopisany do metadanych albo poza właściwy obraz. Reguły te czytają strukturę pliku i jego opisy tekstowe, a w plikach dużych — ich początek i koniec; nie czytają danych skompresowanych, więc treść ukryta wewnątrz skompresowanego strumienia nie jest przez nie widziana.
Pliki importu — arkusze CSV i XLSX służące do wczytania kartotek — przechodzą kontrolę odrębną i węższą. Skoroszyt XLSX jest pakietem plików: sprawdza się jego sygnaturę oraz spis zawartości pakietu, odczytywany bez rozpakowywania go, i wymaga się obecności części właściwych dla arkusza kalkulacyjnego; pakiet zawierający projekt makr (VBA) jest odrzucany. Plik CSV jest zwykłym tekstem i nie ma sygnatury, którą można by sprawdzić — odrzucane są wyłącznie te pliki, o których da się dowieść, że tekstem nie są: rozpoznane jako archiwum, dokument PDF, program wykonywalny lub obraz, zawierające bajt zerowy albo nadmiar znaków sterujących. Kontrola pliku CSV jest z tego powodu słabsza od pozostałych i nie jest tu przedstawiana jako im równa.
Treść plików importu nie jest natomiast badana regułami wykrywającymi zawartość aktywną i badana być nie może. Komórka arkusza zawiera tekst wpisany przez Kancelarię albo pochodzący od jej klienta, a ciąg taki jak „<script” jest w takim tekście treścią legalną; nie da się go odróżnić od próby ataku inaczej niż odrzucając zwykłe akta sprawy. Kontrola importu ogranicza się zatem do formatu i budowy pliku, a nie obejmuje tego, co zapisano w komórkach.
Plik, który nie przeszedł którejkolwiek z opisanych kontroli, jest usuwany z magazynu, a nie zachowywany.
Do opisanych kontroli nie jest używany zewnętrzny skaner antywirusowy: wykonuje je w całości Usługodawca we własnej infrastrukturze, żaden plik nie jest w tym celu przekazywany na zewnątrz i żaden dostawca usługi skanowania plików nie jest wymieniony w Załączniku nr 1. Usługa ma techniczną możliwość kierowania wgrywanych plików do skanera zewnętrznego i możliwość ta jest wyłączona. Jej włączenie oznaczałoby przekazywanie plików w całości nowemu odbiorcy danych, dlatego wymaga uprzedniego wpisania tego odbiorcy do Załącznika nr 1 w trybie zmiany podprocesorów opisanym w sekcji 10, z prawem sprzeciwu Administratora. Rozstrzyga wykaz z Załącznika nr 1: dopóki nie jest w nim wymieniony dostawca usługi skanowania plików, skanera zewnętrznego w przetwarzaniu nie ma.
12. Tajemnica zawodowa Kancelarii i obsługa żądań organów
Usługodawca przyjmuje, że materiał powierzony mu przez Kancelarię jest objęty tajemnicą zawodową, której Kancelaria podlega — adwokacką, radcowską albo inną tajemnicą prawnie chronioną. Nie rozstrzyga, czy w konkretnym przypadku tajemnica obejmuje określone dane; ocena ta należy do Kancelarii. Na co dzień chronią tę tajemnicę środki opisane w sekcjach 1-4 i 8: izolacja danych każdej Kancelarii na poziomie bazy danych, sprawdzanie uprawnień po stronie serwera i bazy danych niezależnie od interfejsu, udostępnianie dokumentów wyłącznie krótko ważnymi, podpisanymi odnośnikami wydawanymi po sprawdzeniu uprawnień oraz ograniczenie dostępu administracyjnego do czynności niezbędnych, z podwyższonym uwierzytelnieniem i niezmiennym wpisem w rejestrze.
Zasady postępowania wobec żądań organów określa DPA: § 11a — wobec żądań kierowanych do Usługodawcy przez organy władzy publicznej Rzeczypospolitej Polskiej, a § 10a — wobec żądań organów państw trzecich kierowanych bezpośrednio do podprocesorów. Niniejsza sekcja opisuje wyłącznie środki, którymi Usługodawca te zasady wykonuje, i nie zmienia zakresu żadnego z tych paragrafów.
Zawiadomienie o żądaniu organu otrzymane od podprocesora jest zapisywane w systemie w rejestrze prowadzonym wyłącznie w trybie dopisywania: wraz ze wskazaniem podprocesora, rodzaju zdarzenia, państwa organu oraz — dla żądania ujawnienia danych — opisu danych objętych żądaniem, organu występującego, podstawy prawnej żądania i udzielonej odpowiedzi. Rodzaj zdarzenia jest ograniczony do dwóch zdarzeń wskazanych w klauzuli 15.1 lit. a) standardowych klauzul umownych, żeby żądaniem organu polskiego skierowanym do Usługodawcy nie dało się posłużyć jak zawiadomieniem otrzymanym od podprocesora. Zapisu nie można później zmienić ani usunąć. Odrębnie zapisywane jest, którą Przestrzeń Roboczą zawiadomiono i pod jakim adresem, a jeżeli adresu właściciela Przestrzeni Roboczej nie da się ustalić — przyczyna. Samo zawiadomienie jest przekazywane odrębnym rodzajem wiadomości na adres e-mail właściciela Przestrzeni Roboczej podany przy rejestracji.
Usługodawca nie utrzymuje dyżuru całodobowego i nie zobowiązuje się, że podprocesor zawiadomi go o żądaniu, zakwestionuje je albo odmówi jego wykonania; zakres zobowiązań poszczególnych podprocesorów w tej sprawie nie jest jednakowy i wynika z zawartych z nimi umów, a podstawę umowną każdego z nich wskazuje Załącznik nr 1.