GDPR compliance: Jak zapewnić zgodność z RODO w firmie IT

Nowa wersja aplikacji jest prawie gotowa. Zespół domyka backlog, QA zgłasza ostatnie poprawki, a klient pyta o termin wdrożenia. I właśnie wtedy pada pytanie, które potrafi zatrzymać cały projekt: czy to jest zgodne z RODO?

W wielu firmach IT ten moment wygląda podobnie. Do tej pory rozmowa dotyczyła funkcji, integracji, wydajności i kosztów utrzymania. Nagle pojawiają się hasła typu zgody, logi, retencja danych, backupy, role administratora i procesora. Jeśli produkt przetwarza dane użytkowników, temat nie jest dodatkiem. To część architektury systemu.

Dobra wiadomość jest taka, że GDPR compliance nie trzeba traktować jak hamulca dla rozwoju produktu. W praktyce to zestaw zasad, które pomagają projektować oprogramowanie bardziej przewidywalne, bezpieczne i godne zaufania.

Wprowadzenie Czym jest GDPR compliance i dlaczego to kluczowe

RODO, czyli europejskie przepisy o ochronie danych osobowych, określa jak organizacje mają zbierać, przechowywać, udostępniać i usuwać dane osób fizycznych. Dla firmy technologicznej to nie jest tylko temat dla działu prawnego. To sprawa architektury, procesów operacyjnych, supportu, DevOps i produktu.

Najprościej mówiąc, GDPR compliance oznacza, że firma potrafi wykazać, po co przetwarza dane, jakie dane przetwarza, kto ma do nich dostęp, jak je zabezpiecza i co zrobi, gdy użytkownik poprosi o wgląd albo usunięcie informacji. To brzmi formalnie, ale w praktyce sprowadza się do bardzo konkretnych pytań projektowych.

Gdzie firmy IT najczęściej się zatrzymują

Problem zwykle nie polega na złej woli. Problem polega na tym, że wiele produktów rośnie szybciej niż dokumentacja i procedury. MVP działa. Pierwsi klienci są zadowoleni. Potem dochodzi analityka, helpdesk, integracja z CRM, narzędzie do mailingów, monitoring błędów i kolejne środowiska chmurowe. W pewnym momencie nikt już nie ma pełnego obrazu przepływu danych.

Właśnie dlatego zgodność z RODO warto traktować jak część jakości produktu, podobnie jak testy automatyczne czy kontrolę dostępu. Jeżeli interesuje Cię, jak organizacje opisują takie zasady od strony użytkownika, zobacz przykładową politykę prywatności.

Praktyczna zasada: jeśli zespół nie potrafi w prosty sposób odpowiedzieć, jakie dane trafiają do systemu i dlaczego, to problem nie jest prawny. To problem projektowy.

Dlaczego to ma znaczenie biznesowe

RODO nie działa na zasadzie luźnej rekomendacji. Naruszenia mogą mieć realne skutki finansowe, bo kary mogą sięgać 4% rocznego obrotu firmy zgodnie z opisem na Nflo o GDPR i ochronie danych UE.

To jednak tylko część ryzyka. Druga część jest bardziej przyziemna. Klient enterprise zapyta o DPA, miejsce hostingu, role dostępu i sposób obsługi incydentów. Startup, który nie ma uporządkowanego podejścia do danych, często przegrywa już na etapie security review albo vendor assessment.

RODO jako element zaufania do produktu

Użytkownik nie widzi Twojej architektury. Widzi efekt. Czy formularz zbiera tylko to, co potrzebne. Czy konto można łatwo usunąć. Czy panel klienta jasno pokazuje, jakie dane są zapisane. Czy system nie żąda uprawnień bez sensu.

To właśnie tutaj GDPR compliance przestaje być teorią. Staje się częścią doświadczenia użytkownika. Dobrze wdrożone RODO porządkuje produkt i zmniejsza liczbę ryzyk, które później kosztują najwięcej.

Podstawowe pojęcia i kluczowi gracze Administrator Procesor i Dane Osobowe

Na początku warto uporządkować trzy pojęcia, które pojawiają się w niemal każdym projekcie IT. Bez nich trudno dobrze zaprojektować odpowiedzialność w systemie i w umowach.

Administrator i procesor w prostym ujęciu

Najłatwiej myśleć o tym jak o relacji architekt i wykonawca.

Administrator danych decyduje, po co i jak dane są przetwarzane. To on określa cel. Na przykład firma SaaS zbiera dane użytkowników, aby prowadzić konta klientów, wystawiać faktury i obsługiwać zgłoszenia.

Procesor danych działa w imieniu administratora. Nie ustala celu biznesowego, tylko wykonuje usługę. Typowy przykład to software house utrzymujący system, dostawca hostingu, platforma mailingowa albo operator helpdesku.

W praktyce jedna firma może być administratorem w jednym procesie i procesorem w innym. Własne dane pracowników obsługuje jako administrator, ale dane klientów swojego klienta może przetwarzać jako procesor.

Krótki przykład:

Sytuacja	Kto jest administratorem	Kto jest procesorem
Firma prowadzi własny sklep internetowy	właściciel sklepu	dostawca hostingu, system mailingowy
Software house utrzymuje aplikację klienta	klient	software house
SaaS zbiera dane użytkowników końcowych do własnej usługi	operator SaaS	wybrani podwykonawcy techniczni

Jeżeli współpraca dotyczy przetwarzania danych na zlecenie, umowa musi to porządkować. W praktyce pomaga dobrze przygotowana umowa outsourcingu i elementy, które powinna zawierać, bo odpowiedzialność za dane nie może opierać się na domysłach.

Co naprawdę jest daną osobową

Tu wiele zespołów nadal myśli zbyt wąsko. Dane osobowe to nie tylko imię, nazwisko czy PESEL. Zgodnie z technicznym ujęciem RODO opisanym przez Seku­raka w omówieniu nowej regulacji, obejmują one także identyfikator sieciowy, adres IP oraz zmienne przechowywane w formie ciasteczek, uznane za dane osobowe od 25 maja 2018 roku.

To ma bardzo konkretne skutki dla produktów cyfrowych. Jeżeli aplikacja zapisuje adresy IP w logach, korzysta z identyfikatorów sesji, analizuje zachowanie użytkownika albo integruje narzędzia śledzące, to dotyka obszaru danych osobowych, nawet jeśli nigdzie nie ma formularza z polem „imię i nazwisko”.

Jeśli zespół uznaje, że „to tylko dane techniczne”, bardzo łatwo przeoczyć realne obowiązki wynikające z RODO.

Częsty błąd w aplikacjach B2B

Wiele firm zakłada też, że dane przedsiębiorcy wpisanego do publicznego rejestru można traktować swobodniej. To mylne podejście. Dane osób prowadzących działalność gospodarczą są objęte ochroną RODO również wtedy, gdy widnieją publicznie w rejestrach takich jak CEIDG. Dla zespołu produktowego oznacza to tyle, że publiczna dostępność danych nie usuwa obowiązku ich właściwego przetwarzania.

Dlatego już na etapie analizy systemu warto rozpisać:

• Jakie dane wpływają do produktu i z jakich źródeł.
• Które moduły je wykorzystują, na przykład billing, CRM, support, analityka.
• Kto decyduje o celu przetwarzania, a kto tylko wykonuje usługę.
• Jakie dane są tylko pozornie techniczne, ale nadal mogą identyfikować użytkownika.

Taki porządek oszczędza dużo pracy później, gdy pojawia się audyt, nowy klient korporacyjny albo incydent bezpieczeństwa.

Prawa osób których dane dotyczą Twoje obowiązki jako dostawcy oprogramowania

Użytkownik aplikacji nie myśli kategoriami artykułów rozporządzenia. On chce po prostu wiedzieć, co firma o nim przechowuje, poprawić błąd w profilu albo zamknąć konto. Dla zespołu IT to oznacza, że prawa osoby, której dane dotyczą, muszą mieć odbicie w funkcjach systemu.

Jak te prawa wyglądają w realnej aplikacji

Załóżmy, że użytkownik korzysta z platformy SaaS. Zakłada konto, wpisuje dane firmy, dodaje członków zespołu i korzysta z integracji z zewnętrznymi usługami. Po kilku miesiącach chce sprawdzić, co system o nim wie.

Jeśli produkt jest dobrze zaprojektowany, użytkownik powinien móc:

• zobaczyć swoje dane w panelu lub otrzymać je w czytelnej formie,
• poprawić nieaktualne informacje bez pisania maila do supportu,
• ograniczyć niektóre działania, gdy trwa wyjaśnienie sporu,
• pobrać dane w sensownym formacie,
• zgłosić sprzeciw wobec części przetwarzania, na przykład marketingowego,
• usunąć konto lub zainicjować usunięcie danych, jeśli nie ma podstaw do dalszego przetwarzania.

Brzmi prosto, ale po stronie technicznej to rzadko jest jeden przycisk.

Najwięcej problemów powoduje usuwanie danych

Prawo do usunięcia danych nie oznacza automatycznie prostego kasowania jednego rekordu z tabeli users. Dane mogą występować w wielu miejscach. W relacjach do zgłoszeń supportowych, w logach aplikacyjnych, systemie billingowym, narzędziu do analityki, eksportach dla księgowości albo backupach.

Dlatego zespoły produktowe powinny ustalić wcześniej:

1. Gdzie dane są przechowywane. Nie tylko w głównej bazie.
2. Które elementy podlegają usunięciu, a które muszą być zachowane z innych powodów.
3. Jak wygląda proces techniczny. Manualnie, półautomatycznie czy w pełni automatycznie.
4. Kto zatwierdza wykonanie operacji i jak jest to odnotowane.

Dobre wdrożenie praw użytkownika zaczyna się nie w regulaminie, tylko w modelu danych i architekturze integracji.

Funkcje, które warto zaplanować od razu

Poniższa lista zwykle sprawdza się lepiej niż późniejsze „dopisywanie RODO” po wdrożeniu:

• Panel edycji profilu z historią zmian tam, gdzie to uzasadnione.
• Eksport danych w uporządkowanym formacie.
• Mechanizm dezaktywacji i usunięcia konta zamiast wyłącznie kontaktu mailowego.
• Odrębne zgody i preferencje komunikacyjne zamiast jednej zbiorczej zgody.
• Proces weryfikacji tożsamości przy wnioskach wrażliwych, żeby nie wydać danych niewłaściwej osobie.

Jeżeli chcesz porównać, jak w praktyce opisuje się zasady ochrony danych osobowych, warto zobaczyć przykładowe polityki prywatności i sprawdzić, czy funkcje produktu rzeczywiście wspierają to, co dokument obiecuje użytkownikowi.

Największa wartość dla software house'u jest prosta. Gdy prawa użytkownika przekładają się na konkretne funkcje, produkt jest jednocześnie bardziej zgodny, bardziej czytelny i mniej zależny od ręcznej obsługi przez support.

Zarządzanie ryzykiem w praktyce DPIA i rola Inspektora Ochrony Danych

W dobrze prowadzonym projekcie RODO nie zaczyna się od reakcji na problem. Zaczyna się wcześniej, kiedy zespół dopiero planuje nową funkcję, integrację albo model monitorowania użytkownika.

DPIA jako kontrola bezpieczeństwa przed wdrożeniem

DPIA, czyli ocena skutków dla ochrony danych, działa jak przegląd ryzyk przed rozpoczęciem robót. Zamiast budować funkcję i dopiero potem pytać, czy wszystko jest zgodne, zespół analizuje wcześniej, jakie zagrożenia może stworzyć przetwarzanie danych.

To ma szczególne znaczenie w projektach, gdzie pojawia się systematyczne monitorowanie, przetwarzanie danych wrażliwych, profile użytkowników, analiza zachowań albo szerokie użycie danych pracowniczych. W polskiej praktyce temat ten staje się szczególnie ważny przy monitorowaniu pracowników, danych biometrycznych i politykach BYOD. Przed wdrożeniem systematycznego monitorowania pracodawca powinien przeprowadzić i udokumentować DPIA, która ocenia ryzyka, konieczność, proporcjonalność i zabezpieczenia.

Dla zespołu technologicznego dobra DPIA odpowiada między innymi na pytania:

• Czy zakres danych jest konieczny dla celu biznesowego.
• Czy da się ograniczyć widoczność danych dla części ról i modułów.
• Jakie szkody mogą spotkać użytkownika, jeśli dojdzie do błędu lub nadużycia.
• Jakie zabezpieczenia trzeba wdrożyć jeszcze przed uruchomieniem funkcji.

IOD nie jest dekoracją organizacyjną

Drugim ważnym elementem jest Inspektor Ochrony Danych, często oznaczany jako IOD. Ta rola porządkuje nadzór nad zgodnością, doradza przy ocenie ryzyk i pomaga połączyć perspektywę prawną z operacyjną.

Według danych opisanych przez Wolters Kluwer w raporcie Legal Compliance, w 2025 roku 91% firm w Polsce posiada wyznaczonego Inspektora Ochrony Danych. To pokazuje, że rynek traktuje ten obszar coraz bardziej systemowo.

W praktyce IOD jest najbardziej użyteczny wtedy, gdy nie dostaje dokumentów do podpisu na końcu projektu, tylko uczestniczy wcześniej. Na etapie decyzji o retencji danych, modelu logowania, konfiguracji monitoringu czy wdrożeniu narzędzi zewnętrznych.

Zespół nie potrzebuje kolejnej osoby od blokowania wdrożeń. Potrzebuje partnera, który potrafi wcześnie wskazać ryzyka i uprościć decyzje.

Kiedy to działa najlepiej

Najbardziej dojrzałe organizacje łączą DPIA, bezpieczeństwo i zarządzanie ryzykiem w jeden obieg decyzyjny. Jeżeli temat ten jest Ci bliski, dobrym rozwinięciem będzie spojrzenie na zarządzanie ryzykiem IT jako stały element rozwoju systemów, a nie jednorazową kontrolę.

W praktyce oznacza to prostą zmianę nawyku. Zamiast pytać „czy możemy to wdrożyć”, lepiej pytać „jak wdrożyć to tak, by ograniczyć ryzyko i nadal dowieźć wartość biznesową”.

Zabezpieczenia techniczne i organizacyjne Jak chronić dane w systemach IT

RODO bez środków bezpieczeństwa pozostaje tylko dokumentacją. To właśnie warstwa techniczna i organizacyjna decyduje, czy deklaracje firmy mają pokrycie w rzeczywistości.

Ochrona danych od projektu, nie po fakcie

Jedna z najważniejszych zasad mówi o ochronie danych w fazie projektowania. Chodzi o to, by prywatność nie była dokładana na końcu w formie poprawki. Jeśli system od początku zakłada minimalizację danych, separację uprawnień i sensowną retencję, późniejsza zgodność jest dużo prostsza.

Dobry przykład to formularz rejestracyjny. Jeżeli produkt potrzebuje tylko e-maila i hasła, zbieranie numeru telefonu „na zapas” zwiększa zakres ryzyka. To samo dotyczy logów. Jeżeli zespół loguje pełne payloady żądań w środowisku produkcyjnym, bardzo łatwo przechwycić dane, które wcale nie powinny tam trafiać.

Co warto wdrożyć w warstwie technicznej

Nie ma jednej uniwersalnej listy dla każdego systemu, ale kilka mechanizmów powtarza się niemal zawsze:

• Szyfrowanie danych zarówno w transmisji, jak i w spoczynku. Dotyczy baz danych, kopii zapasowych i wybranych plików.
• Kontrola dostępu oparta na rolach. Programista, support, klient i administrator nie powinni widzieć tego samego zakresu informacji.
• Pseudonimizacja tam, gdzie to możliwe. Szczególnie w raportowaniu, testach i analityce.
• Separacja środowisk. Dane produkcyjne nie powinny bez potrzeby trafiać do środowisk deweloperskich.
• Rejestrowanie dostępu do danych. Nie po to, by śledzić wszystko, ale by móc wykryć nadużycia i wyjaśnić incydent.

Warto też pamiętać o backupach. Sama kopia zapasowa nie rozwiązuje problemu bezpieczeństwa. Trzeba jeszcze wiedzieć, kto ma do niej dostęp, jak długo jest przechowywana i czy proces odtworzenia został sprawdzony.

Organizacja ma znaczenie tak samo jak technologia

Nawet najlepsza architektura nie pomoże, jeśli pracownicy nie rozumieją podstawowych zasad. W praktyce dużo incydentów wynika nie z braku narzędzi, tylko z chaosu operacyjnego.

Najczęściej sprawdzają się:

• jasne polityki dostępu do systemów i danych,
• procedury reagowania na incydenty,
• szkolenia dla zespołu technicznego i nietechnicznego,
• regularne audyty bezpieczeństwa,
• kontrola zmian przy wdrażaniu nowych integracji i usług.

Według danych z PwC o compliance w Polsce, w 2025 roku 94% polskich firm posiada dokumentację zgodności z RODO, a 58% zainwestowało w systemy szyfrowania danych osobowych. Sama dokumentacja nie wystarczy, ale ten kierunek pokazuje, że szyfrowanie i formalizacja zabezpieczeń stają się standardem.

Wniosek operacyjny: jeśli bezpieczeństwo zależy wyłącznie od ostrożności pojedynczych osób, to system jest zbyt kruchy.

Gdzie to połączyć z codzienną pracą zespołu

Dla wielu organizacji dobrym punktem odniesienia jest ISO 27001 certification, bo pomaga spiąć zabezpieczenia techniczne z procesami organizacyjnymi. Nie chodzi o papier dla samego papieru. Chodzi o powtarzalność działań.

W codziennym rozwoju produktu oznacza to, że wymagania dotyczące prywatności powinny trafiać do backlogu tak samo jak wymagania funkcjonalne. Jeśli planujesz nową integrację, migrację do chmury albo rozbudowę analityki, pytanie o dane musi pojawić się od razu.

RODO w cyklu życia aplikacji Praktyczny przewodnik dla Software Houseów

Dla software house'u RODO nie kończy się na polityce prywatności i wzorze umowy. Najwięcej pracy dzieje się tam, gdzie produkt realnie żyje. W backlogu, architekturze, pipeline wdrożeniowym, utrzymaniu, monitoringu i supportcie.

Faza analizy i projektowania

Najlepszy moment na decyzje dotyczące danych to początek projektu. Wtedy najłatwiej jeszcze ograniczyć zakres zbieranych informacji, zaplanować retencję, podzielić role i ustalić, które integracje będą rzeczywiście potrzebne.

Na tym etapie warto zadać kilka pytań:

• Jakie dane są absolutnie konieczne do działania produktu?
• Czy wszystkie pola formularzy są uzasadnione, czy część wynika tylko z przyzwyczajenia?
• Które procesy będą wymagały śladu audytowego, a które nie?
• Czy da się odseparować dane klienta od danych diagnostycznych?

W SaaS to szczególnie ważne przy modelu multitenant. Dane klientów muszą być logicznie i operacyjnie odseparowane tak, by dostęp jednego tenant'a nie prowadził do wglądu w zasoby drugiego. To jest temat nie tylko bezpieczeństwa, ale też jakości projektu.

Chmura i model współdzielonej odpowiedzialności

Przeniesienie systemu do AWS czy Azure nie rozwiązuje automatycznie kwestii zgodności. Dostawca chmury odpowiada za część warstwy infrastrukturalnej, ale konfiguracja usług, zakres logowania, dostęp administracyjny, retencja i integracje nadal pozostają po stronie zespołu wdrożeniowego lub klienta.

Z perspektywy RODO oznacza to, że trzeba pilnować między innymi:

• lokalizacji przetwarzania danych,
• dostępu podwykonawców do środowisk,
• konfiguracji usług monitorujących,
• treści umów z dostawcami i subprocesorami,
• zasad usuwania danych po zakończeniu współpracy.

Jeżeli klient pyta „czy jesteśmy zgodni, bo używamy uznanego dostawcy cloud?”, odpowiedź brzmi: nie zawsze. Narzędzie może być dobre, ale sposób jego użycia może tworzyć ryzyko.

Monitoring, logi i observability

To obszar, w którym zespoły techniczne często wchodzą na grząski grunt bez złych intencji. Chcą diagnozować błędy, analizować wydajność i skracać czas reakcji na incydenty. To słuszne cele. Problem zaczyna się wtedy, gdy do logów trafia zbyt dużo danych.

W praktyce warto ustalić:

• które logi są niezbędne operacyjnie,
• jakie pola muszą być maskowane,
• kto ma wgląd do dashboardów i alertów,
• jak długo logi są przechowywane,
• czy narzędzia klasy APM, error tracking i SIEM nie wynoszą więcej informacji, niż zakładano.

Dobre observability nie polega na zbieraniu wszystkiego. Polega na zbieraniu dokładnie tego, co potrzebne do utrzymania systemu.

SLA, support i dostęp serwisowy

Przy utrzymaniu aplikacji łatwo zapomnieć, że zgodność z RODO dotyczy też działań po wdrożeniu. Support, administratorzy, analitycy i zewnętrzni partnerzy mogą mieć styczność z prawdziwymi danymi użytkowników podczas diagnozy błędów lub odtwarzania incydentów.

Dlatego warto ustalić:

Obszar	Dobra praktyka
dostęp serwisowy	nadawany czasowo i zgodnie z rolą
zgłoszenia supportowe	ograniczanie kopiowania pełnych danych do ticketów
środowiska testowe	unikanie użycia pełnych danych produkcyjnych
eskalacje incydentów	jasna ścieżka odpowiedzialności i dokumentowania działań

Takie decyzje nie są dodatkiem do SLA. To część odpowiedzialnego utrzymania produktu.

DPA i relacje z klientem oraz podwykonawcami

W relacji software house, klient i poddostawcy bardzo ważne są umowy powierzenia przetwarzania danych. To one porządkują role, zakres operacji, obowiązki bezpieczeństwa i zasady współpracy w razie incydentu. Jeśli dokumentacja jest ogólna, zespół techniczny często później improwizuje w praktyce.

Najbardziej problematyczne są sytuacje, w których projekt korzysta z wielu usług zewnętrznych, a nikt nie ma pełnej mapy subprocesorów. Wtedy trudno odpowiedzieć klientowi, gdzie dokładnie płyną dane i na jakich zasadach.

Pułapka globalnych polityk bez lokalnego dopasowania

To szczególnie częsty problem w grupach międzynarodowych. Jak wskazuje Argon Legal w analizie wdrażania globalnych polityk GDPR w Polsce, polskie firmy z międzynarodowych grup kapitałowych często stosują dokumentację wprowadzoną w grupie, ale nie dostosowują jej do indywidualnego kontekstu działania na miejscu, co zwiększa ryzyko niezgodności z GDPR. Dla ograniczenia tego ryzyka firma w Polsce powinna zweryfikować i uzupełnić dokumentację ochrony danych pod lokalny kontekst.

To ważna lekcja także dla software house'ów. Nawet jeśli klient ma gotowe globalne wzory, lokalna praktyka przetwarzania danych może wyglądać inaczej. Inne narzędzia, inny model supportu, inna struktura dostępu, inne obowiązki pracodawcy. Dokument ma sens tylko wtedy, gdy odpowiada temu, jak system i procesy działają naprawdę.

Podsumowanie Zgodność z RODO jako przewaga konkurencyjna

Najgorszy sposób myślenia o RODO to traktowanie go wyłącznie jak listy formalności. Wtedy zespół robi minimum potrzebne do „odhaczenia” tematu, a problemy wracają przy pierwszym audycie, większym kliencie albo incydencie.

Lepsze podejście jest prostsze. Traktuj GDPR compliance jako część dojrzałości produktu. Tak samo jak testowalność, bezpieczeństwo, skalowalność i utrzymywalność. System zaprojektowany z myślą o danych osobowych zwykle ma czytelniejsze procesy, lepszą kontrolę dostępu, mniej zbędnych informacji w bazach i niższe ryzyko kosztownych błędów.

Dla software house'ów i firm technologicznych ma to jeszcze jeden wymiar. Klienci coraz częściej nie pytają już tylko, czy aplikacja działa. Pytają, czy można jej zaufać. Czy dane są odseparowane. Czy usunięcie konta jest realne. Czy monitoring nie wykracza poza potrzebę operacyjną. Czy umowy i praktyka są spójne.

Zaufanie do produktu nie powstaje po publikacji polityki prywatności. Powstaje w decyzjach projektowych podejmowanych każdego dnia.

Jeśli spojrzysz na RODO w ten sposób, przestaje być obciążeniem. Staje się ramą, która pomaga budować lepsze oprogramowanie. Bardziej przewidywalne dla zespołu, bardziej bezpieczne dla użytkownika i bardziej wiarygodne dla klienta biznesowego.

---

Jeśli chcesz uporządkować zgodność RODO w swoim produkcie, aplikacji SaaS lub procesach utrzymaniowych, warto skonsultować to z zespołem, który rozumie zarówno technologię, jak i realia wdrożeń. Develos Ratajczak Gajos S.K.A. wspiera firmy w projektowaniu, rozwoju i utrzymaniu rozwiązań IT z naciskiem na bezpieczeństwo, architekturę i praktyczne podejście do zgodności.