Umowa na obsługę IT w warszawskiej firmie: SLA, RODO i NIS2 - czego nie może w niej zabraknąć

Cztery filary umowy - checklista na jedną stronę

Umowa obsługi IT dla firmy 10-70 osób w Warszawie powinna przedstawiać najważniejsze ustalenia na jednej, czytelnej checkliście. Taka strona od razu pokazuje, co faktycznie zostało zagwarantowane, a co pozostaje obietnicą sprzedażową lub luźną deklaracją handlową. Sprawdź to już przy pierwszym czytaniu projektu, bo zarząd może wtedy szybko wychwycić luki w zapisach. Ma też jasny punkt odniesienia przy porównywaniu ofert kilku dostawców; tu wychodzi różnica.

1. Przedmiot i zakres usług - opis prac w ryczałcie, rozdzielenie pomocy zdalnej i wizyt stacjonarnych oraz wskazanie usług dodatkowo płatnych poza abonamentem.
2. Parametry SLA - czas reakcji według pilności zgłoszenia oraz gwarantowany czas usunięcia usterki krytycznej obejmującej działanie całej firmy.
3. Kary umowne - z góry określone kwoty lub procenty za niedotrzymanie czasów naprawy albo przestój systemów szczególnie ważnych dla działalności.
4. Model rozliczeniowy - jasne rozdzielenie, które usługi obejmuje abonament miesięczny, a które są rozliczane godzinowo w modelu Time & Material.
5. Sprzęt i licencje - zapis, że zakup komputerów, licencji Microsoft 365 czy serwerów finansuje klient, a wykonawca odpowiada za doradztwo i konfigurację.
6. Poufność / NDA - zobowiązanie firmy IT do zachowania tajemnicy przedsiębiorstwa, danych handlowych i know-how warszawskiej organizacji.
7. Umowa powierzenia danych osobowych - załącznik do umowy głównej oparty na art. 28 rozporządzenia 2016/679.
8. Polisa OC wykonawcy - numer polisy, suma gwarancyjna oraz zakres, który obejmuje błędy w obsłudze informatycznej firmy.
9. Własność kont i licencji - potwierdzenie, że konta administracyjne, domeny i licencje należą do klienta oraz opis przekazania haseł i dokumentacji przy zmianie dostawcy.

SLA, czyli jedyna część umowy, którą naprawdę kupujesz

SLA w praktyce określa, ile minut lub godzin firma z Mokotowa czy Woli może pozostać bez systemu sprzedaży lub poczty. Pozostałe fragmenty umowy porządkują formalności i relację biznesową, ale to parametry SLA przekładają się na realne bezpieczeństwo operacyjne. W chwili awarii liczy się tylko to, co zapisano tam wprost, z konkretnymi liczbami; reszta to tło. Zapamiętaj to.

SLA (Service Level Agreement) opisuje poziom świadczenia usług, który obejmuje czas reakcji, czas naprawy, dostępność systemów oraz konsekwencje za niedotrzymanie ustaleń. Czas reakcji oznacza moment rozpoczęcia pracy nad zgłoszeniem przez helpdesk lub specjalistę, a czas naprawy opisuje chwilę przywrócenia działania usługi albo wdrożenia skutecznego obejścia. Takie obejście ma pozwolić użytkownikom wrócić do pracy; sprawdź, czy jest zdefiniowane.

Tabela priorytetów i czasów reakcji

Tabela elementów SLA, które muszą znaleźć się w umowie

8:00-16:00 czy 24/7 - pułapka, która unieważnia dobre czasy reakcji

Ten sam zapis „czas reakcji kilkanaście-kilkadziesiąt minut” znaczy coś innego w trybie 24/7, a co innego przy godzinach pracy 8:00-16:00 w dni robocze. Biuro logistyczne na Białołęce, które zaczyna pracę o 6:00, musi sprawdzić, czy zgłoszenie awarii o 6:30 uruchamia bieg SLA od razu. Jeżeli nie, ustal, czy czas liczy się dopiero po rozpoczęciu godzin serwisowych; tu wiele firm się myli. To realna pułapka.

Umowa powinna wyraźnie wskazywać, czy czas reakcji jest liczony w godzinach serwisowych 8:00-16:00, czy kalendarzowo przez 24 h na dobę. Gwarancja reakcji w 1-2 h poza standardowym oknem pracy podnosi koszt abonamentu i stawek godzinowych, więc zarząd musi podjąć konkretną decyzję. Nie powinien zostawiać tego działowi zakupów, a Ty doprecyzuj te widełki przed podpisaniem. Sprawdź to w umowie.

Kary umowne - bez nich SLA jest deklaracją, nie zobowiązaniem

SLA bez kar finansowych nie daje realnego bodźca, by w sytuacji przeciążenia działu wsparcia nadać priorytet zgłoszeniom spółki z Warszawy. Jasno określone sankcje, wyrażone kwotowo lub procentowo, motywują wykonawcę do pilnowania czasów reakcji i naprawy także wtedy, gdy jednocześnie pojawia się wiele incydentów; sprawdź, jak to policzyć. W praktyce to właśnie stosowanie kar przesądza, czy SLA działa jak wiążący standard, czy jak marketingowa deklaracja. Tu nie ma przypadku.

Kary mogą być powiązane z konkretnymi progami, na przykład przekroczeniem maksymalnego czasu niedostępności systemu ponad ustalone 99,9% w skali roku. Dobrze opisane przedziały czasowe i wartości procentowe zmniejszają ryzyko sporu interpretacyjnego między firmą a dostawcą z Warszawy lub Piaseczna. Rozliczaj je wspólnie na podstawie raportów z systemu ticketowego, bo to ułatwia późniejsze rozmowy o jakości obsługi. Reszta to już technika.

Jak wygląda dobrze zorganizowane wsparcie: L1, L2, L3 i system ticketowy

Sprawnie ułożone wsparcie IT dla kancelarii w Śródmieściu lub kliniki na Mokotowie dzieli zadania między poziomy L1, L2 i L3, a całość opiera na systemie ticketowym. Taka konstrukcja przyspiesza obsługę, ponieważ każde zgłoszenie trafia od razu we właściwe miejsce; dlatego liczba „zgubionych” maili spada. Jednocześnie pozwala mierzyć jakość usług w czasie i porównywać ją z zapisanym SLA. Zarząd widzi wtedy nie tylko koszt abonamentu, ale także realny poziom obsługi użytkowników.

Tabela poziomów wsparcia z przykładami zgłoszeń

Helpdesk IT jest pierwszym punktem styku użytkownika z działem wsparcia oraz linią odpowiedzialną za zgłoszenia telefoniczne, mailowe lub z systemu ticketowego. Do jego zadań należy przyjmowanie i rejestrowanie zgłoszeń, resetowanie haseł, pomoc przy instalacji programów oraz wstępna diagnoza usterek sprzętu, więc sprawdź, czy Twoja firma ma jasne procedury. Prowadzi też pomoc zdalną, korzystając z narzędzi do zdalnego pulpitu, a trudniejsze sprawy przekazuje do L2 lub L3, dbając o aktualizację informacji w systemie. Tu liczy się konsekwencja i porządek.

System ticketowy zamienia każde zgłoszenie pracownika z Warszawy w cyfrowy bilet z unikalnym numerem oraz historią działań. Zlecenia trafiają do systemu z e-maila, czatu lub telefonu, a następnie są przypisywane do konkretnego specjalisty lub działu. Otrzymują status „nowe”, „w toku” lub „zamknięte”, a cała wymiana wiadomości pozostaje w jednym wątku; dzięki temu nie musisz szukać rozmów po skrzynkach. Dzięki temu znacznie łatwiej później przeprowadzić audyt i rozliczyć SLA. Sprawdź, czy dostawca to ma.

Dzięki numerom ticketów żadne zgłoszenie nie ginie, a helpdesk może mierzyć rzeczywisty czas reakcji i naprawy. Statystyki z systemu pokazują, ile incydentów krytycznych pojawiło się w miesiącu oraz jak długo użytkownicy z Białołęki czy Piaseczna czekali na rozwiązanie problemów. Na tej podstawie oceniasz też, czy wysokość abonamentu jest adekwatna do obciążenia działu wsparcia, dlatego przeanalizuj te raporty co kwartał. Sprawdź to wprost.

Jak zgłosić awarię, żeby skrócić czas naprawy

Dobrze przygotowane zgłoszenie przyspiesza diagnozę i ogranicza liczbę dodatkowych pytań do użytkownika. Pracownik powinien przekazać podstawowe informacje w powtarzalny sposób, niezależnie od tego, czy korzysta z telefonu, e-maila, czy portalu zgłoszeniowego. Ułatwia to pracę helpdesku i skraca czas potrzebny na rozpoczęcie faktycznej naprawy, więc przeszkol swój zespół z takiego schematu. Tu zyskujesz godziny.

• Opis błędu: co dokładnie się stało oraz jaka czynność była wykonywana tuż przed wystąpieniem problemu.
• Komunikat błędu: zrzut ekranu lub zdjęcie ekranu telefonu, dołączone do ticketu lub wiadomości e-mail.
• Dane sprzętu: nazwa komputera lub numer inwentarzowy laptopa albo stacji roboczej z biura na Mokotowie.
• Skala problemu: informacja, czy błąd dotyczy jednej osoby, całego działu, czy całej firmy z kilku biur w Warszawie.
• Kanały kontaktu: numer telefonu do oddzwonienia, służbowy adres e-mail oraz preferowana forma kontaktu zwrotnego.

Helpdesk a service desk - czym się różnią

Rozróżnienie helpdesk i service desk ma znaczenie przy ustalaniu zakresu obsługi informatycznej firm w Warszawie. Metodyka ITIL traktuje service desk jako szerszą funkcję zarządzania usługami IT, a helpdesk koncentruje się na szybkim reagowaniu na pojedyncze incydenty użytkowników. W umowie doprecyzuj więc, czy kupujesz wyłącznie reakcję na awarie, czy także wsparcie procesów biznesowych; to są dwa różne światy. Co to zmienia w praktyce?

RODO: umowa powierzenia to nie formalność

Przy outsourcingu IT w warszawskiej firmie, która przetwarza dane klientów, umowa powierzenia przetwarzania danych osobowych jest wymagana przez art. 28 RODO. Dokument ten zabezpiecza zarówno administratora danych, jak i wykonawcę, dlatego nie powinieneś go traktować jako mało ważny załącznik do kontraktu. W razie incydentu to właśnie do niego wracają inspektorzy i prawnicy, szukając podstaw odpowiedzialności; zapytaj więc dostawcę, jak stosuje takie zapisy w praktyce. To jest realne ryzyko.

Art. 28 rozporządzenia 2016/679 nakłada obowiązek zawarcia umowy powierzenia w formie pisemnej lub elektronicznej, jeśli zlecane jest przetwarzanie danych osobowych. Obowiązek powstaje, gdy firma informatyczna ma lub może mieć dostęp do takich danych, na przykład przy zdalnym helpdesku, hostingu systemów CRM lub testowaniu aplikacji na realnych bazach; nawet krótkotrwały podgląd ekranu z danymi pacjentów czy klientów oznacza przetwarzanie, które wymaga umowy. Sprawdź to przed startem współpracy. Bez tego będzie problem.

W praktyce umowa powierzenia jest konieczna, jeśli informatyk może połączyć się z komputerem użytkownika za pomocą zdalnego pulpitu albo zalogować się do bazy danych pacjentów kliniki na Mokotowie. Brak takiego dokumentu przy stałej obsłudze IT to sytuacja wyjątkowa, możliwa tylko przy bardzo wąskim, ściśle technicznym zakresie usług, więc jeśli prowadzisz firmę z danymi osobowymi, zakładaj raczej konieczność podpisania. Dlatego przed podpisaniem kontraktu jasno ustal, czy dostawca kiedykolwiek będzie miał wgląd w dane osobowe. Bez tego ryzykujesz spór.

Umowa powierzenia powinna jednoznacznie opisywać przedmiot i czas trwania przetwarzania, charakter i cel operacji, kategorie danych oraz grupy osób, których dane dotyczą. Zgodnie z art. 32 RODO trzeba również wskazać środki zapewniające bezpieczeństwo i poufność oraz sposób wspierania administratora w realizacji praw osób, których dane są przetwarzane; sprawdź, czy dokument tego nie pomija. Jasno opisane procedury później ułatwiają rozliczenie obowiązków między stronami.

Dokument powinien określać tryb zgłaszania naruszeń ochrony danych bez zbędnej zwłoki, wraz z podaniem kanałów kontaktu i osób odpowiedzialnych po stronie dostawcy. Zapis o podpowierzeniu musi wprost wskazywać, że firma IT nie może przekazywać danych podwykonawcom bez pisemnej zgody administratora, którym w tym przypadku jest warszawska spółka lub kancelaria. To ogranicza ryzyko, że dane trafią poza ustalony krąg podmiotów. Zapisz to jasno.

Administrator ma prawo audytować dostawcę, na przykład poprzez przegląd procedur bezpieczeństwa, wizytę w serwerowni lub weryfikację logów dostępu. Takie działania pozwalają sprawdzić, czy praktyka operacyjna wykonawcy jest spójna z zapisami umowy oraz z wymaganiami art. 32 RODO; zaplanuj te audyty w harmonogramie rocznym. Zaplanuj te audyty z wyprzedzeniem, aby nie były traktowane jak nadzwyczajne kontrole. I trzymaj się planu.

NIS2 i nowelizacja KSC - dlaczego dostawca IT stał się elementem compliance

Dyrektywa NIS2 oraz zmiany w ustawie o krajowym systemie cyberbezpieczeństwa przenoszą wybór firmy IT na poziom odpowiedzialności zarządu. Dostawca obsługi informatycznej staje się elementem bezpieczeństwa łańcucha dostaw, który wpływa na zgodność regulacyjną przedsiębiorstwa oraz ocenę nadzoru nad ryzykiem. W praktyce oznacza to konieczność dokumentowania kryteriów wyboru partnera IT i sposobu kontroli jego pracy; sprawdź, czy Twoja firma robi to już teraz. Nie da się już tego pominąć.

Dyrektywa 2022/2555 NIS2 nakłada obowiązek przekazania wczesnego ostrzeżenia o poważnym incydencie bezpieczeństwa w ciągu 24 godzin. Pełne zgłoszenie incydentu musi zostać złożone w ciągu 72 godzin, a po zakończeniu działań naprawczych wymagany jest raport końcowy, który opisuje przyczyny i wnioski. Terminy te trzeba uwzględnić w procedurach współpracy z firmą IT, tak aby nie zabrakło czasu na zebranie danych technicznych i informacji biznesowych; inaczej zgłoszenie będzie niekompletne. Ustal to z dostawcą już na starcie.

Dla podmiotów o znaczeniu kluczowym przewidziano kary do 10 mln EUR lub 2% obrotu, w zależności od tego, która wartość jest wyższa. Tak wysokie sankcje pokazują, jak poważnie traktowane jest zarządzanie cyberbezpieczeństwem na poziomie zarządczym; dlatego szkolenia zarządu nie mogą być formalnością. NIS2, w połączeniu z nowelizacją krajowego systemu cyberbezpieczeństwa, wiąże bezpieczeństwo informacyjne z osobistą odpowiedzialnością zarządu. Obejmuje to również obowiązkowe szkolenia kadry kierowniczej.

Jednym z wymagań jest bezpieczeństwo łańcucha dostaw, obejmujące także weryfikację firm świadczących obsługę informatyczną firm Warszawa. Oznacza to, że ocena kompetencji i procedur dostawcy IT staje się częścią systemu compliance, a nie wyłącznie decyzją zakupową. Wymagania wobec partnera IT powinny być więc spójne z polityką bezpieczeństwa całej organizacji; sprawdź, czy Twoja polityka to opisuje. Tu nie ma dowolności.

Wdrożenie NIS2 wymaga przeprowadzenia analizy ryzyka, przygotowania planów ciągłości działania BCP i DRP oraz utrzymania codziennej higieny cyfrowej. Praktyczne działania obejmują stosowanie kryptografii, kontrolę dostępu opartą na zasadzie minimalnych uprawnień oraz uwierzytelnianie wieloskładnikowe MFA dla kont administracyjnych w systemach używanych przez warszawskie biura; bez tego procedury pozostaną na papierze. Bez takiej podstawy nawet najlepiej napisana umowa z dostawcą IT nie zapewni zgodności z nowymi regulacjami. To twardy fakt.

Niniejszy artykuł ma charakter informacyjny i nie jest poradą prawną w rozumieniu przepisów o działalności doradczej lub adwokackiej. Przy wdrażaniu wymagań NIS2 i KSC konieczne jest skonsultowanie się z prawnikiem lub doradcą specjalizującym się w cyberbezpieczeństwie regulowanym, który oceni sytuację konkretnej firmy. Bez tego ryzykujesz błędną interpretację. Sprawdź to z prawnikiem.

Ryzyka outsourcingu IT i jak je zamknąć zapisami w umowie

Outsourcing IT dla firmy z Warszawy łączy oszczędności kosztowe z konkretnymi ryzykami organizacyjnymi. Starannie skonstruowane zapisy umowy pozwalają te ryzyka wyraźnie ograniczyć, ale nie usuwają ich całkowicie, dlatego decyzja o zleceniu obsługi na zewnątrz powinna być świadoma i dobrze udokumentowana. Zarząd musi wiedzieć, na co się godzi, przenosząc część procesów poza firmę. To odpowiedzialność.

AIO wskazują na typowe wady outsourcingu IT: mniejszą kontrolę nad infrastrukturą, ryzyko naruszenia poufności danych, zależność od zewnętrznego dostawcy, wolniejszą reakcję przy obsłudze wielu klientów, brak rozwoju kompetencji wewnętrznych, ukryte koszty oraz trudności komunikacyjne przy offshoringu. Jednocześnie outsourcing IT bywa ogólnie bezpieczniejszym rozwiązaniem niż budowa własnego działu, jeśli dobrze dobrany partner działa według przejrzystej umowy i jasnych standardów; sprawdź to w referencjach. W praktyce liczy się więc nie tyle „czy outsourcować”, ile „na jakich zasadach to zrobić”. Tu zapada decyzja.

Tabela 3. Ryzyka outsourcingu IT i zapisy umowne je ograniczające

Kontrakt powinien dodatkowo przewidywać możliwość sprawdzenia opinii i referencji dostawcy przed podpisaniem, zawarcie NDA oraz przygotowanie exit planu już w pierwszym kwartale współpracy. Ograniczenie uprawnień administratorów do niezbędnego minimum zmniejsza obszar potencjalnego nadużycia i ułatwia późniejsze przekazanie środowiska nowemu partnerowi; sprawdź, czy Twoja firma ma taki scenariusz. Zaplanuj to od razu. To jest praktyczne.

Audyt IT - od czego zaczyna się dobra umowa

Rzetelna umowa obsługi informatycznej zwykle zaczyna się od audytu IT, który pokazuje faktyczny stan infrastruktury, poziom bezpieczeństwa i zgodność licencji. Bez takiego etapu zakres usług i SLA łatwo oderwiesz od realnych możliwości sieci oraz serwerów w warszawskich biurach, dlatego przed podpisaniem kontraktu zapytaj o koszt i zakres audytu. Audyt porządkuje też listę priorytetów, co pomaga zdecydować, co trzeba zrobić od razu, a co można odłożyć. Tu zaczyna się porządek.

Audyt IT jest niezależną oceną systemów informatycznych, infrastruktury sieciowej i procedur bezpieczeństwa stosowanych w firmie 10-70 osób. Zakres obejmuje serwery, komputery, urządzenia sieciowe, oprogramowanie oraz konfiguracje zabezpieczeń, w tym politykę haseł i proces aktualizacji; na tej podstawie dostawca może realnie oszacować SLA. Analiza tych elementów pozwala ocenić, czy obecna infrastruktura udźwignie planowany rozwój organizacji. Sprawdź to przed inwestycjami.

Jednym z ważnych elementów audytu jest weryfikacja bezpieczeństwa danych, w szczególności kopii zapasowych i mechanizmów ochrony antywirusowej. Kolejnym obszarem jest zgodność z przepisami RODO oraz wymaganiami NIS2, które mogą dotyczyć kancelarii prawnych lub podmiotów medycznych działających w Warszawie; tu często wychodzą luki w procedurach. W raporcie często wskazywane są też „szybkie wygrane”, czyli działania o niskim koszcie i dużym wpływie na bezpieczeństwo.

Audyt sprawdza również efektywność kosztową licencji, czyli czy opłacone subskrypcje Microsoft 365 lub innych systemów są realnie wykorzystywane przez pracowników na Śródmieściu, Mokotowie i w Piasecznie. Wyniki przedstawiane są w raporcie z listą priorytetów oraz planem działań naprawczych, co ułatwia zarządowi zdefiniowanie zakresu nowej umowy; na tym etapie możesz też skorygować budżet. Taki dokument później staje się punktem odniesienia przy ocenie, czy współpraca z dostawcą przebiega zgodnie z założeniami. I czy trzeba coś zmienić.

Przeprowadzenie audytu przed podpisaniem długoletniej umowy abonamentowej pomaga urealnić SLA i listę usług. Ogranicza to liczbę aneksów w pierwszych 6-12 miesiącach współpracy oraz pozwala lepiej zaplanować budżet na projekty modernizacyjne, dlatego jeśli prowadzisz rosnącą firmę, potraktuj audyt jako inwestycję. Audyt staje się więc kosztem, który buduje dobrze skonstruowany kontrakt. To rozsądny start.

Jak wybrać dostawcę-10 pytań, które trzeba zadać na pierwszym spotkaniu

Spotkanie z potencjalną firmą informatyczną w Warszawie potraktuj jako uporządkowany wywiad, a nie tylko prezentację ofertową. Poniższa lista pytań ułatwia zestawienie propozycji trzech różnych dostawców w oparciu o konkretne i porównywalne kryteria. Dzięki temu wybór partnera opiera się na faktach, a nie wyłącznie na wrażeniu po spotkaniu; przygotuj te pytania wcześniej. Skąd inaczej weźmiesz punkt odniesienia?

1. Jaki jest gwarantowany czas reakcji SLA na awarię krytyczną obejmującą całą firmę i czy liczony jest w trybie 24/7, czy 8:00-16:00?
2. W jakich dokładnie godzinach działa helpdesk i czy zgłoszenia po godzinach szczytu w Warszawie trafiają do dyżurującego inżyniera?
3. Czy backupy danych są nie tylko wykonywane, ale również regularnie testowane odtworzeniowo, na przykład raz w miesiącu lub raz na kwartał?
4. Jaki jest zakres wsparcia zdalnego, a jaki on-site oraz czy dojazd do Śródmieścia, Mokotowa, Woli i Piaseczna jest dodatkowo płatny?
5. Jak wygląda polityka bezpieczeństwa: stosowane szyfrowanie, kontrola dostępu, uwierzytelnianie MFA dla administratorów oraz zarządzanie uprawnieniami?
6. Jakie są zasady by odpowiedzialności za błędy oraz jakie umowy poufności NDA podpisują pracownicy firmy informatycznej Warszawa?
7. Czy podpisywana jest umowa powierzenia przetwarzania danych osobowych zgodnie z art. 28 RODO oraz jakie są procedury zgłaszania naruszeń?
8. Jaki model rozliczeń jest stosowany: abonament Managed Services, stawki godzinowe Time & Material czy model hybrydowy z limitem godzin?
9. Czy usługa jest skalowalna wraz ze wzrostem organizacji z 10 do 70 stanowisk i jak zmienia się wtedy abonament miesięczny?
10. Jakie są referencje i doświadczenie w branży kancelarii prawnych, klinik medycznych, agencji marketingowych lub firm logistycznych z aglomeracji warszawskiej?

Kiedy rozważyć Black Rack? Helpdesk IT Warszawa realizowany przez Black Rack to usługa skierowana do firm z Warszawy i aglomeracji, działających w przedziale 5-60 osób, bez własnego działu IT, ale przetwarzających dane wrażliwe lub objęte tajemnicą zawodową. Zgłoszenia trafiają do centralnego systemu ticketowego i są obsługiwane w modelu L1-L3, obejmując stanowiska Windows i macOS, Microsoft 365, VPN oraz administrację serwerami, wirtualizacją Proxmox VE, chmurą prywatną i konfiguracjami wysokiej dostępności; jeśli Twoja firma ma oddziały, zapytaj o zasięg. Współpraca opiera się na zapisanych w umowie zasadach i SLA, a zasięg obsługi koncentruje się na Warszawie i okolicznych miastach.
Organizacje z oddziałami poza aglomeracją powinny więc osobno ustalić warunki wizyt on-site, bo inaczej powstanie luka w oczekiwaniach.

FAQ

Czy przy obsłudze informatycznej trzeba podpisać umowę powierzenia RODO?

Jeżeli dostawca obsługi IT ma lub może mieć dostęp do danych osobowych pracowników lub klientów, art. 28 rozporządzenia 2016/679 wymaga zawarcia umowy powierzenia. Forma umowy może być pisemna lub elektroniczna, dlatego sprawdź, czy propozycja dostawcy to przewiduje. Brak takiego dokumentu przy stałej obsłudze IT jest rzadkim wyjątkiem, możliwym tylko przy bardzo ograniczonym zakresie usług, w którym nie dochodzi do przetwarzania danych osobowych. Sprawdź ten warunek przed startem współpracy.

Jaki czas reakcji na awarię krytyczną jest standardem rynkowym?

AI Overviews wskazują, że typowy czas reakcji SLA na awarię krytyczną mieści się w zakresie kilkunastu-kilkudziesięciu minut. Musisz jednak sprawdzić, czy ten parametr dotyczy trybu 24/7, czy jedynie godzin serwisowych 8:00-16:00 w dni robocze; bez tego zapis może być mylący. Zgłoszenie o 18:00 w drugim wariancie formalnie zaczyna być obsługiwane dopiero następnego dnia roboczego. To duża różnica.

Czym różni się czas reakcji od czas naprawy?

Czas reakcji (response time) to maksymalny okres od zgłoszenia do podjęcia pracy przez helpdesk lub specjalistę, zwykle kilkanaście-kilkadziesiąt minut dla priorytetu krytycznego. Czas naprawy (resolution time) obejmuje pełne usunięcie skutków incydentu lub zastosowanie obejścia, co może wynosić kilka godzin, a przy złożonych awariach nawet 24-48 godzin; zapytaj dostawcę o typowe wartości dla Twojej branży. Zapytaj dostawcę o oba parametry osobno.

Czy firma IT może przekazać nasze dane podwykonawcy?

Zgodnie z wytycznymi RODO podpowierzenie przetwarzania danych osobowych wymaga pisemnej zgody administratora, czyli warszawskiej firmy zlecającej usługę. Umowa powierzenia powinna wprost określać zasady korzystania z podwykonawców; sprawdź, czy te punkty są wystarczająco precyzyjne. Brak zgody oznacza zakaz przekazywania danych do kolejnych podmiotów, także spoza Polski. To prosty filtr.

Co powinien zawierać exit plan przy zmianie firmy informatycznej?

Exit plan powinien opisywać przekazanie haseł do kont administracyjnych, dostępów do chmury, dokumentacji konfiguracji sieci i serwerów oraz historii ticketów. Niezbędny jest też zapis potwierdzający, że licencje, domeny i konta główne należą do klienta; bez tego Twoja firma traci kontrolę. Poprzedni dostawca powinien usuwać swoje dostępy w określonym terminie po zakończeniu współpracy.
I to zapisz wprost.

Czy NIS2 dotyczy małej firmy w Warszawie?

NIS2 bezpośrednio obejmuje podmioty kluczowe i ważne, ale małe firmy z Warszawy często działają w ich łańcuchu dostaw jako usługodawcy lub podwykonawcy. W takiej sytuacji weryfikacja bezpieczeństwa staje się elementem audytu dostawcy; zapytaj klientów, jak oceniają Twoje procedury. Zarząd powinien znać zasady zgłaszania incydentów w 24 i 72 godziny oraz wymagania dotyczące bezpieczeństwa łańcucha dostaw. Inaczej trudno obronić się przed zarzutami.

Kto jest właścicielem kont administracyjnych i licencji?

Bezpieczna konstrukcja umowy przewiduje, że właścicielem kont administracyjnych, licencji Microsoft 365, domen oraz innych zasobów pozostaje klient. Firma informatyczna korzysta z nich na zasadzie powierzonego dostępu; sprawdź, czy w Twojej umowie jest to opisane jednoznacznie.
Exit plan powinien wymuszać przekazanie wszystkich haseł i odzyskanie samodzielnej administracji przez firmę z Warszawy w razie rozwiązania kontraktu outsourcingowego. Tu nie ma miejsca na domysły.