Wyjście z wewnątrzgrupowego IT. Jak rozpleść środowisko, które nigdy nie zostało splecione świadomie.

„Mamy sprzedać spółkę zależną. Ile czasu potrzebujemy na rozdzielenie IT?" — „Dwa tygodnie." — „A ile naprawdę?" — „Trzy miesiące, jeśli zaczniecie od inwentaryzacji, której nigdy nie robiliście, i od umów powierzenia danych, których nigdy nie podpisaliście."

W grupach kapitałowych IT nie jest usługą. To przyzwyczajenie. Przez lata nikt nie podpisuje żadnej umowy, bo między spółkami z jednej grupy „się ufa". Stan faktyczny wyprzedza stan prawny i nikt nie ma z tym problemu — dopóki grupa trzyma się razem. Problem pojawia się w dniu, gdy trzeba rozpleść coś, co nigdy nie zostało splecione świadomie: sprzedaż spółki zależnej, wydzielenie, zmiana właścicielska, usamodzielnienie podmiotu.

Jeśli prowadzisz grupę kapitałową z centralizowanym IT, planujesz spin-off albo przygotowujesz spółkę do sprzedaży — ten artykuł wyjaśni, z jakimi ryzykami prawnymi, podatkowymi i operacyjnymi musisz się zmierzyć przy wyjściu z wewnątrzgrupowego IT. Dowiesz się, jakie kroki podjąć przed podpisaniem jakiegokolwiek porozumienia, jak zabezpieczyć warstwę RODO i co zrobić z licencjami, które nie przechodzą automatycznie między spółkami.

Pojęcia, które musisz znać przed rozpoczęciem rozdzielenia

Zanim przejdziemy do konkretnych kroków, warto uporządkować terminologię. Rozdzielenie IT w grupie kapitałowej dotyka kilku reżimów prawnych naraz — a każdy z nich posługuje się własnymi pojęciami.

Pojęcie	Co oznacza	Dlaczego ma znaczenie przy rozdzieleniu IT
Umowa powierzenia przetwarzania (art. 28 RODO)	Umowa między administratorem danych a podmiotem, który przetwarza dane w jego imieniu	Jeśli spółka A administrowała systemami spółki B bez takiej umowy — przez cały okres przetwarzanie odbywało się z naruszeniem RODO
Cesja umowy	Przeniesienie praw i obowiązków z umowy na inny podmiot	Regulaminy dostawców chmurowych (Google, Microsoft) mogą wymagać pisemnej zgody na cesję — bez niej harmonogram przekazania staje się fikcją
Transakcja kontrolowana (art. 11c ustawy o CIT)	Transakcja między podmiotami powiązanymi, dla której ceny muszą odpowiadać warunkom rynkowym	Nieodpłatne przekazanie IT między spółkami z grupy generuje przychód z nieodpłatnych świadczeń u strony przejmującej
TSA (umowa o świadczenie usług przejściowych)	Umowa regulująca tymczasowe świadczenie usług (np. IT) po transakcji	Typowy okres TSA w polskiej praktyce wynosi od kilku tygodni do trzech miesięcy
Strategia wyjścia (exit strategy)	Udokumentowany plan zakończenia współpracy z dostawcą ICT	Wymagana formalnie dla podmiotów objętych DORA i NIS2

Dlaczego rozdzielenie IT w grupie kapitałowej to problem prawny, a nie techniczny

Większość zarządów traktuje rozdzielenie IT jako zadanie dla działu technicznego: „przekażcie hasła, przepiszcie domeny, zróbcie migrację". Tymczasem przekazanie nie polega na wydaniu hasła. Polega na zmianie strony umowy albo założeniu nowego stosunku prawnego od zera.

Cztery płaszczyzny, które musisz obsłużyć równolegle

Płaszczyzna kontraktowa. Umowy z dostawcami chmury zawierają klauzule ograniczające cesję. Regulamin Google Workspace zabrania przeniesienia lub cesji jakiejkolwiek części umowy bez pisemnej zgody drugiej strony — z wyjątkiem cesji na podmiot stowarzyszony, który na piśmie zobowiąże się do przestrzegania warunków umowy. Cedent zachowuje odpowiedzialność za zobowiązania sprzed cesji. Każda inna próba przeniesienia jest nieważna. To dostawca — nie porozumienie między spółkami — wyznacza realny harmonogram.
Płaszczyzna regulacyjna. DORA (rozporządzenie 2022/2554) nakłada na podmioty finansowe obowiązek posiadania udokumentowanego, przetestowanego planu wyjścia dla każdej umowy ICT wspierającej funkcje krytyczne. NIS2 (dyrektywa 2022/2555) wprowadza analogiczne wymogi zarządzania ryzykiem dostawców ICT. Sprawdź, czy któraś ze stron podlega tym regulacjom — jeśli tak, rozstanie z dostawcą ICT (nawet wewnątrzgrupowym) wymaga formalnej strategii wyjścia.
Płaszczyzna podatkowa. Nieodpłatne świadczenia IT między podmiotami powiązanymi generują przychód z art. 12 ust. 1 pkt 2 ustawy o CIT po stronie beneficjenta. Wartość przychodu ustala się według cen stosowanych wobec innych odbiorców lub cen rynkowych za porównywalne usługi (art. 12 ust. 6 CIT). Pytanie o koszty zadaje się PRZED podpisaniem, nie po.
Płaszczyzna ochrony danych. Wieloletnie przetwarzanie danych osobowych przez spółkę-administratora IT bez umowy powierzenia (art. 28 RODO) to naruszenie, które nie znika w dniu rozstania — właśnie wtedy staje się widoczne. Transfer danych wewnątrz grupy nie ma osobnej podstawy prawnej tylko dlatego, że spółki są powiązane. Motyw 48 RODO (prawnie uzasadniony interes) to argument, nie zwolnienie z obowiązków.

Inwentaryzacja zasobów IT — co zrobić przed podpisaniem jakiegokolwiek porozumienia

Zanim podpiszesz porozumienie o przekazaniu IT, musisz wiedzieć, co przekazujesz. Brzmi banalnie. Nie jest.

Trzy pytania do każdej pozycji

Dla każdego zasobu IT (systemy chmurowe, poczta, bezpieczeństwo, hosting, domeny z danymi rejestratorskimi, urządzenia sieciowe i serwerowe, licencje, sprzęt) odpowiedz na trzy pytania:

Pytanie	Dlaczego ma znaczenie	Konsekwencja braku odpowiedzi
Kto jest właścicielem?	Domeny spółki B mogą być zarejestrowane na spółkę A. Licencje kupione na konto spółki A.	Po transakcji nabywca spółki B odkrywa, że nie ma praw do domen ani oprogramowania
Kto jest stroną umowy z dostawcą?	Cesja umowy wymaga zgody dostawcy. Procedura po stronie dostawcy może trwać tygodnie.	Harmonogram porozumienia staje się fikcją — spółki planowały przekazanie w 2 tygodnie, dostawca potrzebuje 8 tygodni
Kto administruje?	Część dostępów jest „w głowie" jednej osoby z działu IT albo w prywatnym menedżerze haseł	Po rozstaniu nikt nie zna hasła do krytycznego systemu

Lista zasobów, o których łatwo zapomnieć

Konta serwisowe i współdzielone (nieprzypisane do żadnej osoby)
Dostępy zapisane w prywatnych menedżerach haseł poszczególnych osób z działu IT
Tokeny API, klucze SSH, certyfikaty SSL
Konfiguracja MFA przypisana do prywatnych telefonów
Archiwa poczty elektronicznej
Systemy zgłoszeniowe (ticketowe) z danymi klientów obu spółek
Systemy monitorujące i logi bezpieczeństwa
Kopie zapasowe (w tym kopie przechowywane u zewnętrznych dostawców)

Zbuduj listę WSZYSTKICH kont uprzywilejowanych — także nieoficjalnych. Jeśli odpowiedź na pytanie „kto ma dostęp" brzmi „nie wiem" — to sam w sobie jest sygnał, że inwentaryzacja jest konieczna przed jakimkolwiek dalszym krokiem.

Napisz do nas

Warstwa RODO — naruszenie, które ujawnia się dopiero przy rozstaniu

Dlaczego brak umowy powierzenia to problem teraz, a nie „kiedyś"

Jeżeli odpowiedź na pytanie „czy mamy umowę powierzenia przetwarzania z każdym administratorem danych w grupie" brzmi „nigdy o tym nie myśleliśmy" — to znaczy, że przez cały okres współpracy przetwarzanie odbywało się z naruszeniem art. 28 RODO.

Naruszenie art. 28 RODO (brak umowy powierzenia) zagrożone jest karą administracyjną do 10 mln EUR lub 2% rocznego obrotu (art. 83 ust. 4 RODO). Naruszenie obowiązku zgłoszenia naruszenia ochrony danych (art. 33–34 RODO) — do 10 mln EUR lub 2% obrotu.

Co więcej, art. 82 ust. 5 RODO przewiduje regres między współodpowiedzialnymi podmiotami. Żadna klauzula ograniczająca odpowiedzialność tego nie wyłączy. A art. 47 ust. 2 lit. f RODO ustanawia zasadę, że podmiot z grupy posiadający jednostkę w UE odpowiada za naruszenia reguł korporacyjnych przez innego członka grupy.

Co musisz zrobić z RODO przed rozstaniem

Rozstrzygnij role. Ustal, kto był administratorem, a kto podmiotem przetwarzającym za cały okres wspólnego IT. To nie jest kwestia deklaracji — liczy się, kto faktycznie decydował o celach i sposobach przetwarzania.
Zawrzyj brakujące umowy powierzenia. Najpóźniej w dacie podpisania porozumienia, osobno z każdym administratorem. Umowa powierzenia zawierana po latach przetwarzania bez niej nie cofnie naruszenia — ale porządkuje stan na przyszłość.
Wynegocjuj pisemne oświadczenie o stanie przetwarzania. Zażądaj od strony przekazującej: wykazu systemów i kategorii danych, wykazu podprzetwarzających z państwem przetwarzania, informacji o transferach poza EOG, historii naruszeń i ich zgłoszeń, potwierdzenia upoważnień i zobowiązań do poufności.
Ustal termin i zakres trwałego usunięcia danych po zakończeniu przekazania. Art. 28 ust. 3 lit. g RODO wymaga zwrotu albo usunięcia danych po zakończeniu przetwarzania. Wymień wprost miejsca łatwe do pominięcia: kopie zapasowe, archiwa poczty, systemy zgłoszeniowe, menedżery haseł, systemy monitorujące, logi. Zażądaj pisemnego potwierdzenia usunięcia.
Utrzymaj obowiązek wzajemnego informowania o naruszeniach. Ustal krótki termin powiadamiania i utrzymaj ten obowiązek przez oznaczony okres po zakończeniu przekazania — dla zdarzeń mających źródło w okresie wspólnego IT.

Licencje, które nie przechodzą automatycznie

Licencje na oprogramowanie nie przechodzą automatycznie między spółkami. Przeniesienie wymaga zgody licencjodawcy lub wyraźnej podstawy w umowie licencyjnej (art. 74 i n. ustawy o prawie autorskim).

Zweryfikuj przenoszalność każdej licencji. Tam gdzie licencja nie przechodzi — zaplanuj i wyceń zakup nowej przez stronę przejmującą przed podpisaniem porozumienia. Korzystanie z oprogramowania bez ważnej licencji po rozstaniu to naruszenie praw autorskich.

Scenariusz	Ryzyko	Co zrobić
Licencja kupiona na konto spółki A, używana przez spółkę B	Spółka B traci prawo do korzystania po rozstaniu	Sprawdź warunki przeniesienia u licencjodawcy; jeśli niemożliwe — kup nową licencję
Licencja grupowa (volume licensing)	Podział licencji wymaga zgody licencjodawcy i może zmienić warunki cenowe	Skontaktuj się z licencjodawcą i ustal warunki podziału przed podpisaniem porozumienia
Oprogramowanie wewnętrznie opracowane w grupie	Prawa autorskie mogą należeć do spółki A (pracodawcy twórców)	Ustal, kto jest uprawniony, i przygotuj umowę licencyjną lub przeniesienia praw
Darmowe oprogramowanie (open source, freeware)	Co do zasady brak przychodu z nieodpłatnego świadczenia — ale wewnętrznie opracowany system udostępniony wyłącznie spółkom z grupy może zostać zakwalifikowany inaczej	Zweryfikuj warunki licencji open source i dokumentację wewnętrzną

Procedury zmiany podmiotu u dostawców chmurowych — co musisz wiedzieć

Polskie prawo nie zawiera aktu prawnego regulującego chmurę obliczeniową. Ocena dopuszczalności cesji umów chmurowych opiera się na ogólnych przepisach Kodeksu cywilnego, RODO i sektorowych wytycznych (KNF, CSIOZ). To oznacza, że realne ograniczenia wynikają z regulaminów dostawców.

Google Workspace

Regulamin zabrania cesji bez pisemnej zgody — wyjątek to cesja na podmiot stowarzyszony, który na piśmie zobowiąże się do przestrzegania warunków umowy
Domain Transfer wymaga co najmniej 7 dni na wdrożenie zasad przechowywania w Google Vault, 48 godzin na zamianę domeny podstawowej na dodatkową i 24 godzin na testowe uruchomienie
Domena podstawowa nie może być przenoszona, dopóki pełni rolę domeny głównej — musi zostać najpierw przekształcona w domenę dodatkową
Administratorzy obu środowisk muszą wyraźnie upoważnić zespół ds. przenoszenia domen

Microsoft 365 / Azure

Przeniesienie własności rozliczeń subskrypcji Azure wymaga akceptacji przez przyszłego właściciela — po transferze konieczny jest przegląd i aktualizacja przypisań ról
Zmiana katalogu subskrypcji Azure wymaga konta z rolą właściciela istniejącego w bieżącym i nowym katalogu Microsoft Entra — po operacji pełne wyświetlenie danych może zająć kilka godzin
Migracja OneDrive i Exchange Online między dzierżawami wymaga ustanowienia relacji między administratorami obu dzierżaw — czas migracji zależy od liczby użytkowników i wolumenu danych
Dokumentacja techniczna Microsoft nie wymaga dokumentów korporacyjnych (np. odpisu KRS) jako warunku operacji — całość opiera się na uprawnieniach administracyjnych

Wniosek: harmonogram porozumienia między spółkami musi uwzględniać procedury dostawców. Spółki planujące przekazanie w 2 tygodnie mogą odkryć, że dostawca potrzebuje 8 tygodni na zmianę podmiotu.

Fazowe przekazanie — jak uniknąć luki i nakładki

Luka to awaria — po rozstaniu nikt nie zarządza krytycznymi systemami, co prowadzi do przestoju operacyjnego. Nakładka to ryzyko bezpieczeństwa — obie strony z pełnymi uprawnieniami administracyjnymi do tych samych systemów, a w razie incydentu żadna nie jest w stanie wykazać, czyje działanie go spowodowało.

Trzy fazy przekazania

Faza	Zakres	Termin	Uzasadnienie
Faza 1	Środowiska chmurowe i konta (przekazanie uprawnień administracyjnych)	Termin twardy — ustalony w porozumieniu	Najszybsze do wykonania technicznie; wymaga jedynie zmiany poświadczeń
Faza 2	Urządzenia (fizyczne przeniesienie)	Termin twardy — ustalony w porozumieniu	Wymaga logistyki, ale nie prac budowlanych
Faza 3	Warstwa sieciowa (projekt, zakupy sprzętu, prace fizyczne, ewentualna przebudowa okablowania)	Termin rozsądny — bez sztywnej daty	Wymaga projektu, zamówień, prac fizycznych; czas zależy od zakresu

Mechanizm przekazania każdego zasobu

Zaprojektuj dwuetapowy mechanizm:

Udostępnienie poświadczeń — strona przekazująca udostępnia hasła, klucze, tokeny przez bezpieczny kanał (menedżer haseł, link jednorazowy, kanał szyfrowany)
Potwierdzenie odbioru — strona przejmująca potwierdza odbiór w oznaczonym terminie; brak odpowiedzi w terminie oznacza milczące potwierdzenie

Moment przejścia odpowiedzialności wiąż z datą potwierdzonego odbioru, nie z datą podpisania porozumienia.

Po potwierdzeniu odbioru każdego zasobu strona przejmująca zmienia hasła, klucze, tokeny, certyfikaty i konfigurację MFA. Strona przekazująca usuwa kopie poświadczeń. Prowadź rejestr przekazanych dostępów na bieżąco — z datą przekazania i datą potwierdzenia odbioru dla każdej pozycji. To narzędzie operacyjne i dowód w jednym.

Oświadczenie o braku zastrzeżeń — dlaczego nie powinieneś go podpisywać w ciemno

Każde generalne oświadczenie o braku zastrzeżeń złożone w dniu podpisania porozumienia jest oświadczeniem składanym w ciemno. Strona przejmująca potwierdza jakość obsługi IT, której nie miała jak zweryfikować — bo nie miała dostępu administracyjnego do systemów.

Jak ograniczyć ryzyko

Ogranicz oświadczenie o braku zastrzeżeń do okoliczności ujawnionych i weryfikowalnych. Wyłącz z zakresu:

Konfigurację zabezpieczeń (np. czy MFA było włączone, czy kopie zapasowe działały)
Historię dostępów (kto i kiedy miał uprawnienia administracyjne)
Zdarzenia naruszenia ochrony danych (incydenty, o których strona przejmująca nie wie)
Zgodność przetwarzania danych z przepisami RODO

Orzecznictwo Sądu Najwyższego potwierdza, że zrzeczenie się roszczeń przyszłych jest dopuszczalne — ale pod warunkiem dostatecznego sprecyzowania stosunku prawnego, z którego mają wynikać przyszłe roszczenia (wyrok SN I CSK 125/08). Zrzeczenie roszczeń „niewykreowanych" może być skuteczne, jeśli klauzula wprost obejmuje roszczenia „mogące powstać w przyszłości" (wyrok SN II CSKP 1361/22 z 24 kwietnia 2024 r.) — ale to nie oznacza, że powinieneś taką klauzulę akceptować bez ograniczeń.

Czego zrzec się nie można

Wytnij z klauzuli zrzeczenia się roszczeń to, czego zrzec się nie da:

Roszczenia podmiotów danych (osób, których dane dotyczą)
Regres z art. 82 ust. 5 RODO
Odpowiedzialność wobec UODO
Naruszenia ochrony danych sprzed przekazania
Naruszenia samego porozumienia
Odpowiedzialność za szkodę wyrządzoną umyślnie (art. 473 §2 KC — nie można wyłączyć odpowiedzialności za szkodę umyślną)

Aspekt podatkowy — nieodpłatne przekazanie IT między podmiotami powiązanymi

Nieodpłatne przekazanie IT między spółkami z grupy to transakcja kontrolowana w rozumieniu przepisów o cenach transferowych. Ignorowanie tego aspektu może prowadzić do doszacowania przychodu.

Co mówią przepisy

Zgodnie z art. 12 ust. 1 pkt 2 ustawy o CIT przychodami są wartość otrzymanych rzeczy lub praw, a także wartość innych nieodpłatnych lub częściowo odpłatnych świadczeń. NSA w uchwałach FPS 9/02 i II FPS 1/06 zdefiniował nieodpłatne świadczenie jako wszelkie zjawiska gospodarcze, których następstwem jest uzyskanie korzyści kosztem innego podmiotu bez ekwiwalentnego wynagrodzenia, mające konkretny wymiar finansowy.

Nieodpłatne udostępnienie infrastruktury IT, systemów ERP, licencji serwerowych czy usług wsparcia informatycznego przez podmiot powiązany generuje co do zasady przychód po stronie beneficjenta.

Obowiązki dokumentacyjne

Obowiązek	Podstawa prawna	Konsekwencja naruszenia
Ustalenie cen transferowych na warunkach rynkowych	Art. 11c ustawy o CIT	Doszacowanie przychodu przez organ podatkowy
Sporządzenie lokalnej dokumentacji cen transferowych (jeśli przekroczono progi)	Art. 11k–11l ustawy o CIT	Brak dokumentacji = domniemanie nierynkowości
Złożenie oświadczenia o rynkowym charakterze cen transferowych	Art. 11m ustawy o CIT	Poświadczenie nieprawdy — grzywna do 720 stawek dziennych (art. 56c KKS)

Paradoks: oświadczenie z art. 11m CIT deklaruje rynkowość warunków transakcji, która z natury jest nieodpłatna. Zweryfikuj podatkowo nieodpłatność przekazania przed podpisaniem porozumienia — nie po.

Okres przejściowy — korzystanie z cudzej sieci bez zobowiązań

W okresie przejściowym spółka przejmująca często korzysta z infrastruktury sieciowej spółki przekazującej. Sieć pada w piątek wieczorem — nie ma nikogo zobowiązanego do naprawy, bo przyzwolenie na korzystanie nie obejmowało żadnych warunków serwisowych.

Co uregulować w porozumieniu

Zakaz wglądu w treść komunikacji. Tajemnica komunikacji elektronicznej uregulowana w PKE (ustawa z 12 lipca 2024 r., Dz.U. 2024 poz. 1221) obejmuje dane transmisyjne i dane o lokalizacji. Zakaz przetwarzania dotyczy wszystkich osób innych niż nadawca i odbiorca — w tym operatorów sieci wewnętrznych.
Ograniczenie przetwarzania danych transmisyjnych do celu bezpieczeństwa z oznaczonym okresem retencji.
Obowiązek informowania o żądaniach organów i o planowanych pracach lub odłączeniu — z rozsądnym wyprzedzeniem.
Warunki serwisowe — nawet minimalne: czas reakcji, osoba kontaktowa, zasady eskalacji w razie awarii.

Mechanizm ujawnień następczych — co z zasobami odkrytymi po podpisaniu

Inwentaryzacja rzadko jest kompletna w dniu podpisania. Dlatego wpisz do porozumienia mechanizm ujawnień następczych: zobowiązanie do nieodpłatnego przekazania dostępów do zasobów odkrytych po rozpoczęciu procesu, w oznaczonym okresie od podpisania.

Dotyczy to szczególnie:

Kont serwisowych, o których wiedział tylko jeden administrator
Kopii zapasowych przechowywanych w lokalizacjach nieuwzględnionych w pierwotnej inwentaryzacji
Integracji API z systemami zewnętrznymi, o których strona przejmująca nie wiedziała
Subskrypcji SaaS opłacanych z konta spółki przekazującej, ale używanych przez spółkę przejmującą

NIS2 i DORA — dodatkowe wymogi dla podmiotów regulowanych

Jeśli którakolwiek ze stron podlega NIS2 (dyrektywa 2022/2555) albo DORA (rozporządzenie 2022/2554), rozstanie z dostawcą ICT — nawet wewnątrzgrupowym — wymaga formalnej strategii wyjścia.

DORA w art. 28 ust. 2 nakłada na podmioty finansowe obowiązek posiadania udokumentowanego, przetestowanego planu wyjścia dla każdej umowy ICT wspierającej funkcje krytyczne. Plan musi uwzględniać scenariusze awaryjne, harmonogram migracji i zapewnienie ciągłości działania.

NIS2 wprowadza analogiczne wymogi zarządzania ryzykiem dostawców ICT. Standard PolishCloud 2.0 i 3.0 precyzuje elementy planu wyjścia dla polskiego rynku.

Dostawca wewnątrzgrupowy podlega tym samym wymogom co zewnętrzny — brak odrębnej regulacji dla usług IT świadczonych w ramach grupy kapitałowej.

Checklist: 12 kroków przed podpisaniem porozumienia o przekazaniu IT

Nr	Krok	Kategoria
1	Przeprowadź pełną inwentaryzację zasobów IT z odpowiedzią na trzy pytania (właściciel, strona umowy, administrator)	Audyt
2	Zbuduj listę wszystkich kont uprzywilejowanych — w tym nieoficjalnych	Audyt
3	Sprawdź regulaminy dostawców chmury pod kątem dopuszczalności cesji	Weryfikacja prawna
4	Zweryfikuj przenoszalność każdej licencji na oprogramowanie	Weryfikacja prawna
5	Rozstrzygnij role RODO i zawrzyj brakujące umowy powierzenia	Dokumentacja
6	Wynegocjuj pisemne oświadczenie o stanie przetwarzania danych	Dokumentacja
7	Zaprojektuj dwuetapowy mechanizm przekazania z rejestrem dostępów	Proces
8	Podziel przekazanie na fazy (chmura → urządzenia → sieć)	Proces
9	Ogranicz oświadczenie o braku zastrzeżeń do okoliczności weryfikowalnych	Weryfikacja prawna
10	Zweryfikuj podatkowo nieodpłatność przekazania	Weryfikacja prawna
11	Ureguluj okres przejściowy (sieć, tajemnica komunikacji, warunki serwisowe)	Dokumentacja
12	Wpisz mechanizm ujawnień następczych	Dokumentacja

Rozdzielenie IT w grupie — kiedy zacząć i z kim rozmawiać

Rozdzielenie IT w grupie kapitałowej to nie projekt dwutygodniowy. To proces, który wymaga równoległej pracy prawników, działu IT, działu finansowego i zarządu. Im wcześniej go rozpoczniesz, tym mniejsze ryzyko, że w dniu transakcji odkryjesz, że domeny Twojej spółki są zarejestrowane na inny podmiot, MFA nigdy nie było włączone, a o dwóch incydentach bezpieczeństwa nikt nie poinformował UODO.

Przygotowujemy porozumienia o przekazaniu funkcji IT między spółkami, przeprowadzamy inwentaryzację prawną zasobów IT w grupach kapitałowych, negocjujemy warunki rozstania i zabezpieczamy warstwę RODO przy rozdzieleniu systemów. Łączymy prawo IT, ochronę danych, prawo umów i prawo korporacyjne w jednym modelu — bo rozdzielenie IT dotyka ich wszystkich naraz.

Planujesz wydzielenie, sprzedaż lub usamodzielnienie spółki z grupy? Zanim zaczniesz negocjować cenę, sprawdź, ile kosztuje rozplecenie IT. Napisz do nas.

Najczęściej zadawane pytania

Mamy scentralizowane IT w grupie, ale nic nie jest spisane — od czego zacząć?
Od inwentaryzacji zasobów IT. Dla każdej pozycji (systemy chmurowe, poczta, domeny, licencje, urządzenia) odpowiedz na trzy pytania: kto jest właścicielem, kto jest stroną umowy z dostawcą, kto administruje. Dopiero po inwentaryzacji będziesz wiedział, co faktycznie trzeba przekazać — i ile to zajmie.

Czy możemy po prostu przekazać hasła do systemów i uznać, że sprawa jest załatwiona?
Nie. Przekazanie hasła nie zmienia strony umowy z dostawcą, nie przenosi licencji, nie rozwiązuje kwestii RODO i nie zabezpiecza przed odpowiedzialnością za incydenty z okresu wspólnego IT. Przekazanie wymaga zmiany strony umowy lub założenia nowego stosunku prawnego — a to wymaga zgody dostawcy i czasu.

Kto odpowiada za naruszenie RODO, które zdarzyło się 2 lata temu, gdy jedna spółka przetwarzała dane drugiej bez umowy powierzenia?
Odpowiedzialność zależy od ról w rozumieniu RODO. Art. 82 ust. 5 RODO przewiduje regres między współodpowiedzialnymi podmiotami. Art. 47 ust. 2 lit. f RODO ustanawia zasadę, że podmiot z grupy posiadający jednostkę w UE może odpowiadać za naruszenia przez innego członka grupy. Zawarcie umowy powierzenia po fakcie nie cofnie naruszenia — ale porządkuje stan na przyszłość.

Ile czasu realnie zajmuje rozdzielenie IT między spółkami?
Typowy okres TSA w polskiej praktyce wynosi od kilku tygodni do trzech miesięcy. Ale to dotyczy samego świadczenia usług przejściowych. Pełne rozdzielenie — od inwentaryzacji, przez cesję umów z dostawcami, po usunięcie danych z kopii zapasowych — może trwać dłużej, zwłaszcza gdy procedury dostawców chmurowych wymagają osobnego procesu po ich stronie.

Czy nieodpłatne przekazanie IT między spółkami z grupy ma konsekwencje podatkowe?
Tak. Nieodpłatne świadczenia IT między podmiotami powiązanymi generują przychód z art. 12 ust. 1 pkt 2 ustawy o CIT po stronie beneficjenta. Transakcja wymaga dokumentacji cen transferowych (jeśli przekracza progi materialności) i złożenia oświadczenia z art. 11m CIT. Za poświadczenie nieprawdy w tym oświadczeniu grozi grzywna do 720 stawek dziennych (art. 56c KKS).

Nasza spółka podlega NIS2 — czy rozstanie z wewnętrznym dostawcą IT wymaga dodatkowej dokumentacji?
Tak. NIS2 i DORA wymagają formalnej strategii wyjścia dla umów ICT wspierających funkcje krytyczne. Dostawca wewnątrzgrupowy podlega tym samym wymogom co zewnętrzny — brak odrębnej regulacji dla usług IT świadczonych w ramach grupy. Plan wyjścia musi uwzględniać scenariusze awaryjne, harmonogram migracji i zapewnienie ciągłości działania.