TTMS Blog
Świat okiem ekspertów IT
Wpisy autorstwa: Robert Moczulski
Cybersecurity po wycieku danych: dlaczego sam backup nie wystarczy?
Głośne incydenty dotyczące danych medycznych pokazują, że nawet informacje przetwarzane przez wyspecjalizowane systemy mogą stać się celem cyberprzestępców. Gdy dojdzie do naruszenia, zarząd musi odpowiedzieć nie tylko na pytanie, jakie dane mogły zostać ujawnione, lecz także czy organizacja potrafi utrzymać najważniejsze procesy i bezpiecznie odtworzyć środowisko IT. W sierpniu 2026 roku Prezes Urzędu Ochrony Danych Osobowych zapowiedział kontrolę zastosowanych środków technicznych i organizacyjnych w spółce MyDr po informacjach o incydencie dotyczącym danych pacjentów. Organ podkreślił, że dokładna skala zdarzenia nie była jeszcze w pełni znana, a kontroli miał podlegać również sposób prowadzenia analizy ryzyka. To istotne zastrzeżenie: dopóki postępowania trwają, nie należy przesądzać przyczyny ani odpowiedzialności poszczególnych podmiotów. Nie jest to pierwszy poważny sygnał dla polskiego rynku. W listopadzie 2023 roku UODO informował o ataku ransomware połączonym z wyciekiem danych z ALAB Laboratoria. Zdarzenia różnią się mechanizmem i okolicznościami, ale prowadzą do wspólnego wniosku: bezpieczeństwa danych nie można sprowadzać do jednego produktu ani jednej procedury. Wiele firm nadal traktuje backup jako podstawową odpowiedź na cyberzagrożenia. Dobrze zaprojektowana kopia zapasowa może uratować organizację po zaszyfrowaniu, usunięciu lub uszkodzeniu danych. Nie cofnie jednak wycieku, nie odbierze napastnikowi skradzionych informacji i nie zastąpi kontroli dostępu, szyfrowania, monitoringu ani przygotowanego wcześniej planu reagowania. 1. Wyciek danych i utrata danych to dwa różne zagrożenia Wyciek oznacza, że osoba nieuprawniona uzyskała lub mogła uzyskać dostęp do informacji. Utrata danych dotyczy ich niedostępności, usunięcia, zaszyfrowania albo uszkodzenia. Jeden atak może wywołać oba skutki: przestępcy najpierw kopiują dane, a następnie szyfrują systemy i żądają zapłaty za ich odblokowanie lub niepublikowanie. Backup odpowiada przede wszystkim na problem dostępności i odtworzenia. Jeśli kopie są aktualne, odseparowane i możliwe do wykorzystania, firma może odbudować system bez polegania na obietnicach napastnika. Kopia zapasowa nie przywraca jednak poufności informacji, które opuściły organizację. Po wycieku pozostają obowiązki prawne, ryzyko oszustw, koszty obsługi incydentu i utrata zaufania klientów. 1.1 Podwójne wymuszenie zmienia rolę backupu W klasycznym scenariuszu ransomware napastnik szyfrował dane i żądał opłaty za klucz deszyfrujący. Coraz częściej wcześniej kopiuje informacje, a następnie grozi ich publikacją lub sprzedażą. Ten model, określany jako podwójne wymuszenie, sprawia, że możliwość odtworzenia systemu nie kończy kryzysu. Firma może wznowić działalność, ale nadal musi ustalić zakres wycieku, ocenić ryzyko dla osób i kontrahentów oraz prowadzić komunikację zgodnie z obowiązkami prawnymi. W praktyce potrzebne są więc dwa równoległe plany. Pierwszy dotyczy odzyskania systemów i ciągłości działania. Drugi obejmuje analizę naruszenia poufności: zabezpieczenie logów, identyfikację pobranych danych, ograniczenie dalszego dostępu oraz decyzje dotyczące powiadomień. Backup jest kluczowy dla pierwszego planu, ale nie zastępuje drugiego. Takie rozróżnienie ma znaczenie również na gruncie RODO. Art. 32 RODO wskazuje m.in. na zdolność do szybkiego przywrócenia dostępności danych oraz regularne testowanie skuteczności środków bezpieczeństwa. Jednocześnie wymaga ochrony poufności i integralności, a więc szerszego zestawu zabezpieczeń niż sam backup. 2. Czego głośne wycieki danych uczą polski biznes? Pierwsza lekcja dotyczy wartości danych. Dokumentacja medyczna, dane klientów, informacje finansowe, dane pracowników i własność intelektualna mogą służyć do szantażu, kradzieży tożsamości, phishingu lub dalszych ataków. Organizacja powinna wiedzieć, gdzie takie informacje się znajdują, kto ma do nich dostęp i jak szybko wykryje ich nietypowe pobieranie. Druga lekcja dotyczy zależności od dostawców. Dane biznesowe często są przetwarzane w systemach SaaS, chmurze, centrach danych i aplikacjach utrzymywanych przez podmioty trzecie. Przekazanie obsługi technicznej nie usuwa ryzyka po stronie klienta. Potrzebne są wymagania umowne, okresowa ocena zabezpieczeń, uzgodnione zasady raportowania incydentów oraz pewność, że dane można odzyskać także w razie awarii lub zakończenia współpracy. Trzecia lekcja jest zarządcza: bezpieczeństwo nie zaczyna się w chwili ataku. Organizacja powinna wcześniej ustalić priorytety odtwarzania, role decyzyjne, kanały komunikacji i akceptowalny czas przestoju. Dla podmiotów objętych NIS2 wymagania dotyczące ciągłości działania wynikające z NIS2 obejmują m.in. zarządzanie kopiami zapasowymi, odtwarzanie po awarii i zarządzanie kryzysowe. 3. Kiedy backup rzeczywiście ratuje firmę? Kopia zapasowa ma największą wartość, gdy podstawowe dane lub systemy przestają być dostępne. Przyczyną może być ransomware, awaria infrastruktury, błąd administratora, wadliwa aktualizacja, usunięcie danych przez pracownika albo uszkodzenie środowiska chmurowego. Backup pozwala wtedy ograniczyć przestój, odbudować usługi i zmniejszyć zakres nieodwracalnej utraty informacji. Warunkiem jest jednak objęcie kopią całego procesu, a nie tylko pojedynczego katalogu. Do wznowienia działalności mogą być potrzebne bazy danych, konfiguracje, klucze, kod aplikacji, dokumentacja, integracje, obrazy systemów i informacje o kolejności uruchamiania usług. Kopia danych bez wiedzy, jak odtworzyć zależności, może okazać się niewystarczająca. 4. Backup, replikacja, archiwizacja i Disaster Recovery to nie to samo Pojęcia te bywają stosowane zamiennie, choć odpowiadają na inne potrzeby. Backup tworzy punkty, z których można odzyskać wcześniejszą wersję danych. Replikacja utrzymuje drugą, możliwie aktualną kopię środowiska, ale może natychmiast powielić także usunięcie pliku, błędną zmianę lub zaszyfrowanie. Archiwizacja służy długoterminowemu przechowywaniu informacji, a nie szybkiemu wznowieniu całego procesu. Disaster Recovery obejmuje natomiast technologię i procedury potrzebne do przywrócenia usług po poważnym zdarzeniu. Określa kolejność uruchamiania systemów, zależności, zasoby zastępcze, role zespołu i sposób potwierdzenia, że proces działa poprawnie. Firma może więc posiadać wiele kopii plików, a mimo to nie mieć realnego planu odtworzenia działalności. Dojrzała strategia łączy te mechanizmy. Replikacja może skrócić przestój po awarii infrastruktury, backup umożliwia powrót do stanu sprzed ataku, archiwum wspiera retencję, a Disaster Recovery porządkuje sposób wykorzystania wszystkich tych zasobów podczas kryzysu. 4.1 RPO i RTO trzeba określić językiem biznesowym RPO określa, jaką maksymalną ilość ostatnio zapisanych danych organizacja może utracić. RTO wskazuje, jak długo proces może pozostawać niedostępny. Parametry te nie powinny wynikać wyłącznie z możliwości technologii. Muszą odpowiadać skutkom biznesowym: zatrzymaniu produkcji, braku obsługi klientów, opóźnieniu rozliczeń, naruszeniu terminów lub zagrożeniu dla bezpieczeństwa ludzi. 4.2 Przykład: system sprzedażowy i miesięczne archiwum Jeżeli system przyjmuje zamówienia przez całą dobę, utrata danych z ostatnich 24 godzin może oznaczać konieczność ręcznego odtworzenia setek transakcji. Taki proces może wymagać RPO liczonego w minutach i RTO w godzinach. Dla zamkniętego archiwum dokumentów z poprzedniego roku dopuszczalne wartości mogą być znacznie wyższe. Jedna polityka backupu dla obu zasobów prowadzi albo do nadmiernych kosztów, albo do niewystarczającej ochrony. 5. Dlaczego sam backup nie zatrzyma wycieku danych? Backup jest mechanizmem odzyskiwania, a nie pełnym systemem ochrony informacji. Nawet idealnie odtworzona baza pozostaje naruszona, jeśli napastnik wcześniej pobrał jej zawartość. Dlatego kopie muszą być częścią architektury obejmującej profilaktykę, wykrywanie, reakcję i przywracanie działalności. Kontrola dostępu i zasada najmniejszych uprawnień ograniczają liczbę osób oraz kont mogących pobierać dane. MFA, segmentacja i oddzielne konta administracyjne utrudniają przejęcie całego środowiska jednym zestawem poświadczeń. Szyfrowanie chroni dane przechowywane i przesyłane, o ile klucze są zarządzane oddzielnie i bezpiecznie. DLP, klasyfikacja informacji i monitoring pomagają rozpoznać nietypowy transfer lub masowe pobieranie plików. EDR, ochrona przed malware i zarządzanie podatnościami zmniejszają prawdopodobieństwo utrzymania dostępu przez napastnika. Plan Incident Response określa, kto izoluje systemy, zabezpiecza dowody, ocenia ryzyko i uruchamia komunikację kryzysową. 6. Jak zbudować odporny backup: zasada 3-2-1-1-0 Punktem wyjścia jest zasada 3-2-1: trzy kopie danych, dwa różne rodzaje nośników lub środowisk i jedna kopia poza główną lokalizacją. W realiach ransomware warto rozszerzyć ją do modelu 3-2-1-1-0. Dodatkowa jedynka oznacza kopię offline albo niezmienialną, a zero – brak błędów potwierdzony w testach odtwarzania. Ustal, które dane, systemy i konfiguracje są krytyczne dla działania organizacji. Oddziel infrastrukturę backupową od środowiska produkcyjnego, domeny i podstawowych kont administratorów. Stosuj kopie offline lub mechanizmy niezmienialności, które blokują usunięcie i nadpisanie danych przez określony czas. Szyfruj kopie oraz kontroluj dostęp do kluczy, konsoli zarządzającej i procedur awaryjnych. Monitoruj nieudane zadania, zmiany retencji, kasowanie punktów przywracania i nietypowe logowania. Regularnie testuj odtworzenie w izolowanym środowisku i dokumentuj osiągnięte RPO oraz RTO. Zgodnie z wytycznymi CISA dotyczącymi ochrony kopii przed ransomware, organizacje powinny utrzymywać zaszyfrowane kopie danych przechowywane offline oraz regularnie sprawdzać ich dostępność i integralność. Ransomware często próbuje odnaleźć i usunąć dostępne backupy, dlatego logiczna separacja i niezmienialność mają równie duże znaczenie jak częstotliwość wykonywania kopii. 7. Backup bez testu odtworzenia jest tylko założeniem Status „backup wykonany pomyślnie” nie dowodzi, że organizacja potrafi wznowić działanie. Kopia może być niekompletna, uszkodzona, zainfekowana, zależna od niedostępnego klucza albo niemożliwa do uruchomienia na dostępnej infrastrukturze. Problem może ujawnić się dopiero podczas kryzysu, gdy czas i kompetencje zespołu są najbardziej ograniczone. Test powinien obejmować nie tylko odzyskanie pliku, ale także odtworzenie reprezentatywnego procesu. Warto sprawdzić kolejność uruchamiania usług, działanie integracji, poprawność uprawnień, integralność danych i możliwość pracy użytkowników. Ćwiczenie powinno zakończyć się raportem: co odtworzono, ile to trwało, jakie dane utracono i jakie działania naprawcze są potrzebne. Dojrzała organizacja zakłada również niedostępność części personelu i podstawowych narzędzi komunikacji. Instrukcje awaryjne, kontakty, klucze i minimalne konfiguracje powinny być dostępne w sposób bezpieczny także poza środowiskiem dotkniętym incydentem. 8. Pierwsze 24 godziny po incydencie Pierwsze działania mają wpływ zarówno na możliwość odtworzenia systemów, jak i na późniejsze ustalenie przebiegu zdarzenia. Pochopne kasowanie plików, restartowanie serwerów lub natychmiastowe przywrócenie całego środowiska może zniszczyć ślady potrzebne do analizy i ponownie uruchomić mechanizm ataku. Ogranicz rozprzestrzenianie się incydentu. Odizoluj zagrożone systemy i konta zgodnie z przygotowaną procedurą, zachowując materiały potrzebne do analizy. Zabezpiecz dowody i ustal zakres. Zachowaj logi, wskaż systemy objęte zdarzeniem i sprawdź, czy doszło wyłącznie do niedostępności, czy również do pobrania danych. Chroń środowisko odtworzeniowe. Przed przywróceniem danych potwierdź, że kopie są integralne, a konta, podatności lub konfiguracje wykorzystane w ataku zostały zabezpieczone. Uruchom ścieżkę decyzyjną i komunikacyjną. Zaangażuj osoby odpowiedzialne za IT, bezpieczeństwo, ochronę danych, kwestie prawne, ciągłość działania i komunikację z klientami. Odtwarzanie powinno następować zgodnie z priorytetami biznesowymi, nie według przypadkowej kolejności serwerów. Najpierw trzeba uruchomić usługi bazowe i mechanizmy bezpieczeństwa, a następnie procesy o najwyższym wpływie na klientów, przychody, zobowiązania prawne lub bezpieczeństwo operacyjne. 9. Bezpieczeństwo dostawców jest częścią Cybersecurity firmy Jeżeli dostawca przechowuje lub przetwarza dane, ocena backupu powinna obejmować model współodpowiedzialności. Trzeba ustalić, kto wykonuje kopie, gdzie są przechowywane, jak długo trwa odtworzenie, czy klient może otrzymać eksport oraz co dzieje się z danymi po zakończeniu umowy. Samo stwierdzenie, że usługa działa w chmurze, nie odpowiada na te pytania. Umowa powinna określać zasady zgłaszania incydentów, współpracy przy analizie naruszenia, zachowania logów, obsługi żądań organów i powiadamiania osób. Warto również weryfikować podwykonawców, lokalizacje danych, uprawnienia uprzywilejowane i wyniki testów ciągłości działania. Certyfikat lub deklaracja dostawcy mogą wspierać ocenę, ale nie zastępują analizy konkretnej usługi i przepływu danych. 9.1 SaaS nie zawsze oznacza pełny backup po stronie dostawcy W usługach SaaS dostawca zwykle odpowiada za dostępność platformy, ale klient może nadal odpowiadać za retencję, konfigurację, konta użytkowników i możliwość odzyskania przypadkowo usuniętych informacji. Wersjonowanie lub kosz w aplikacji nie zawsze zapewniają wymaganą historię zmian, odseparowaną kopię ani eksport pozwalający odtworzyć proces poza usługą. Przed zakupem należy sprawdzić zakres odpowiedzialności, okres przechowywania usuniętych danych, możliwość masowego odtworzenia, ochronę przed przejęciem konta administratora oraz sposób odzyskania danych w razie długotrwałej niedostępności dostawcy. 10. Od backupu do pełnej cyberodporności Cyberodporność oznacza zdolność zapobiegania incydentom, ich wykrywania, ograniczania skutków oraz przywracania działalności. Backup realizuje tylko część tego cyklu. Jego skuteczność zależy od jakości inwentaryzacji, klasyfikacji danych, zarządzania dostępem, monitoringu i przygotowania ludzi. Dla zarządu praktycznym punktem wyjścia jest zestaw pytań: czy wiemy, gdzie znajdują się najważniejsze dane; czy posiadamy kopię odporną na zmianę; kiedy ostatnio odtworzyliśmy krytyczny proces; kto podejmuje decyzję o izolacji systemów; jak komunikujemy się z klientami i organami; oraz czy dostawcy potrafią przedstawić dowody działania swoich procedur. Brak odpowiedzi wskazuje obszary wymagające pilnego uporządkowania. 10.1 Krótka lista kontrolna dla organizacji Najważniejsze dane i procesy mają przypisanych właścicieli, RPO, RTO oraz kolejność odtwarzania. Co najmniej jedna kopia jest odseparowana, offline lub niezmienialna i chroniona innymi poświadczeniami niż produkcja. Testy obejmują cały proces biznesowy, a nie wyłącznie odzyskanie pojedynczego pliku. Monitoring wykrywa nieudane zadania, zmianę retencji, kasowanie kopii i nietypową aktywność administratorów. Umowy z dostawcami regulują odzyskiwanie danych, współpracę podczas incydentu i zakończenie usługi. Plan Incident Response wskazuje osoby decyzyjne, kanały komunikacji i sposób współpracy funkcji technicznych, prawnych oraz biznesowych. 11. Jak TTMS pomaga przygotować organizację na incydent? TTMS wspiera organizacje w ocenie zabezpieczeń, tworzeniu polityk bezpieczeństwa, ochronie danych oraz przygotowaniu procedur reagowania i ciągłości działania. Zakres wsparcia obejmuje m.in. audyty cyberbezpieczeństwa, szyfrowanie, DLP, ochronę przed malware, zarządzanie podatnościami, Incident Response oraz planowanie odzyskiwania danych po awarii. Takie podejście pozwala umieścić backup w szerszej strategii bezpieczeństwa. Celem nie jest wyłącznie wykonanie kolejnej kopii, lecz potwierdzenie, że najważniejsze procesy można odtworzyć w założonym czasie, a ryzyko wycieku jest ograniczane przez spójne środki techniczne i organizacyjne. Czy Twoja organizacja potrafi nie tylko wykonać backup, ale także bezpiecznie odtworzyć dane i najważniejsze procesy? Sprawdź usługi cyberbezpieczeństwa TTMS i przygotuj firmę na incydent, zanim do niego dojdzie. Czy backup chroni firmę przed wyciekiem danych? Nie. Backup pomaga odzyskać dane po ich usunięciu, zaszyfrowaniu lub uszkodzeniu, ale nie blokuje ich skopiowania przez osobę nieuprawnioną. Ochrona przed wyciekiem wymaga m.in. kontroli dostępu, szyfrowania, DLP, monitoringu oraz reagowania na incydenty. Jak często firma powinna testować odtwarzanie danych? Częstotliwość powinna wynikać z ryzyka i znaczenia procesu. Systemy krytyczne wymagają częstszych testów niż archiwa o niewielkim wpływie na działalność. Test należy powtarzać także po istotnej zmianie infrastruktury, aplikacji, dostawcy lub polityki backupu. Czy backup w chmurze jest wystarczający? Może być częścią skutecznej strategii, ale sama lokalizacja w chmurze nie gwarantuje odporności. Trzeba sprawdzić separację kont, wersjonowanie, niezmienialność, szyfrowanie, retencję, możliwość eksportu oraz scenariusz utraty dostępu do głównego konta lub dostawcy. Czy zasada 3-2-1-1-0 jest obowiązkiem prawnym? Nie jest uniwersalnym przepisem obowiązującym każdą firmę. To praktyczny model projektowania kopii odpornych na awarie i ransomware. Konkretne środki powinny wynikać z analizy ryzyka, rodzaju danych, obowiązujących regulacji, umów oraz wymaganej ciągłości działania. Od czego zacząć ocenę odporności organizacji? Od inwentaryzacji danych i usług krytycznych, określenia RPO i RTO, przeglądu uprawnień oraz testu odtworzenia wybranego procesu. Wynik powinien prowadzić do planu działań obejmującego technologię, procedury, dostawców i odpowiedzialność konkretnych osób.
Czytaj
AI dla prawników w Europie i Wielkiej Brytanii: kluczowe ryzyka i ograniczenia w 2026 roku
Narzędzie AI dla prawników może w kilka minut podsumować setki stron, a mimo to przeoczyć jedno zdanie, które przesądza o wyniku sprawy. Może też wygenerować przekonującą odpowiedź opartą na nieaktualnym przepisie, pomylić jurysdykcje albo narazić informacje poufne, jeśli zostanie podłączone do niewłaściwego środowiska danych. W praktyce nie są to argumenty przeciwko wykorzystywaniu AI w pracy prawniczej. Pokazują raczej, że takich narzędzi nie można traktować jak zwykłego oprogramowania biurowego. Liczy się nie tylko to, czy model potrafi wygenerować użyteczną odpowiedź, ale także to, do jakich danych ma dostęp, kto weryfikuje wynik i w których momentach decyzja i odpowiedzialność muszą pozostać po stronie człowieka. W projektach realizowanych w środowiskach regulowanych często okazuje się, że sam model jest tylko jednym z elementów ryzyka. Równie dużo uwagi wymagają przepływy danych, uprawnienia dostępu, architektura systemu, zasady retencji oraz procedury weryfikacji. Dobrze działający model nie wystarczy, jeśli organizacja nie kontroluje tego, z jakich źródeł korzysta system, gdzie przetwarzane są dane i kto ma dostęp do wygenerowanych wyników. W tym artykule omawiamy najważniejsze ograniczenia generatywnej AI w oprogramowaniu prawniczym oraz zabezpieczenia, które warto wdrożyć przed wykorzystaniem takich narzędzi w rzeczywistych sprawach klientów. Koncentrujemy się przede wszystkim na Unii Europejskiej i Wielkiej Brytanii, gdzie wytyczne regulacyjne i zawodowe są obecnie bardziej rozwinięte. Regionu EMEA (Europa, Bliski Wschód i Afryka) nie należy traktować jako jednego środowiska prawnego. Organizacje działające w Szwajcarii, państwach Zatoki Perskiej lub jurysdykcjach afrykańskich muszą osobno ocenić lokalne wymagania dotyczące ochrony danych, tajemnicy zawodowej oraz zasad świadczenia usług prawnych. Niezależnie od jurysdykcji zasada jest podobna: im bardziej wrażliwa sprawa i wykorzystywane dane, tym mniej miejsca powinno być na niekontrolowane działanie systemu AI. 1. Dlaczego ryzyko związane z AI dla prawników ma w 2026 roku jeszcze większe znaczenie Otoczenie regulacyjne przeszło od ogólnych zasad do obowiązków operacyjnych. W Unii Europejskiej przepisy AI Act zaczynają obowiązywać etapami. Zakazane praktyki i obowiązki dotyczące kompetencji w zakresie AI stosuje się od 2025 roku, a w 2026 roku zaczęły obowiązywać niektóre kolejne przepisy dotyczące zarządzania, egzekwowania i przejrzystości. Dokładny zakres obowiązków zależy od zamierzonego zastosowania systemu oraz od tego, czy organizacja występuje jako dostawca, podmiot stosujący (ang. deployer, zgodnie z terminologią AI Act), importer czy dystrybutor. Komisja Europejska publikuje aktualny harmonogram stosowania przepisów AI Act. Wielka Brytania stosuje odmienny model, oparty na obowiązujących przepisach i regulacjach sektorowych. W sierpniu 2026 roku Solicitors Regulation Authority opublikowała ostrzeżenie dotyczące nieprawidłowych treści generowanych przez AI, poufności informacji klientów, tajemnicy komunikacji prawnik–klient (legal professional privilege, dalej „LPP”), ochrony danych oraz niewystarczającego nadzoru. W obu reżimach wniosek jest podobny: użycie AI nie przenosi odpowiedzialności z organizacji ani z prawnika zatwierdzającego rezultat pracy. Zobacz ostrzeżenie SRA. Zarządzanie wykorzystaniem AI w pracy prawniczej jest więc bieżącym zagadnieniem zarządczym, a nie projektem zgodności, który można odłożyć na przyszłość. Organizacje muszą wiedzieć, z jakich narzędzi korzystają pracownicy, jakie informacje są do nich wprowadzane, na jakich źródłach opierają się wyniki, kto je sprawdza oraz w jaki sposób zgłaszane są incydenty. 2. Najważniejsze ograniczenia generatywnej AI w oprogramowaniu prawniczym 2.1 Halucynacje i odpowiedzi bez wiarygodnej podstawy prawnej Duże modele językowe generują tekst statystycznie prawdopodobny. Nie ustalają samodzielnie, czy dane twierdzenie jest prawidłowe z punktu widzenia prawa. Odpowiedź może zawierać nieistniejące orzeczenie, niedokładny cytat, prawdziwe źródło zastosowane do niewłaściwego zagadnienia albo materiał, który nie odzwierciedla już aktualnego stanu prawnego. Płynny styl utrudnia wykrycie takich błędów, ponieważ nieprawidłowa odpowiedź może wyglądać równie profesjonalnie jak poprawna. Generowanie wspomagane wyszukiwaniem (RAG) może ograniczyć to ryzyko przez oparcie odpowiedzi na wybranych materiałach, ale go nie eliminuje. Recenzowane badanie Stanford dotyczące wiodących narzędzi AI do badań prawnych wykazało istotny odsetek odpowiedzi zawierających halucynacje lub niepoparte źródłami nawet w systemach specjalistycznych. Skutecznym zabezpieczeniem nie jest więc obietnica modelu wolnego od halucynacji, lecz proces, który ujawnia źródła i wymaga weryfikacji proporcjonalnej do ryzyka. 2.2 Luki jurysdykcyjne i kontekstowe Europejska praktyka prawna jest szczególnie wrażliwa na kwestie jurysdykcji. Na odpowiedź mogą wpływać prawo Unii Europejskiej, przepisy krajowe, lokalne zasady proceduralne, wytyczne organów nadzorczych oraz umowne klauzule wyboru prawa. Wielka Brytania pozostaje prawnie odrębna od UE, a tajemnica zawodowa i LPP nie są definiowane jednakowo we wszystkich jurysdykcjach europejskich. System, który nie identyfikuje prawidłowo właściwego państwa, sądu, daty i hierarchii źródeł prawa, może połączyć pozornie wiarygodne twierdzenia w prawnie błędny wniosek. AI może wspierać wyszukiwanie informacji i analizę dokumentów, ale nie powinna zastępować profesjonalnego osądu potrzebnego do ustalenia właściwej normy prawnej, interpretacji niejednoznaczności ani oceny, jak prawo ma zastosowanie do spornych okoliczności faktycznych. 2.3 Poufność i ochrona danych Dokumenty prawne często zawierają dane osobowe, dane szczególnych kategorii, informacje wrażliwe handlowo, strategię procesową oraz treści chronione tajemnicą zawodową lub LPP. Wprowadzenie takich materiałów do usługi AI może powodować ryzyko, jeżeli polecenia (prompty) lub pliki są przechowywane, udostępniane osobom nieupoważnionym, przekazywane za granicę albo wykorzystywane do ulepszania modelu. Na gruncie RODO i UK GDPR organizacje muszą określić swoją rolę, ustalić podstawę prawną, ograniczyć przetwarzanie do niezbędnego zakresu, spełnić obowiązki informacyjne, kontrolować podmioty przetwarzające i dalszych podwykonawców, ustalić okresy retencji, zabezpieczyć transfery międzynarodowe oraz wdrożyć środki odpowiednie do ryzyka. Ocena skutków dla ochrony danych może być wymagana, gdy planowane przetwarzanie może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych. Brytyjski Information Commissioner’s Office publikuje również szczegółowe wytyczne dotyczące AI i ochrony danych. Poufność i ochrona wynikająca z tajemnicy zawodowej powinny być oceniane niezależnie od ochrony danych osobowych. Przetwarzanie może mieć podstawę w RODO, a jednocześnie naruszać obowiązek zawodowy, instrukcję klienta, warunki współpracy lub ograniczenie nałożone przez sąd. 2.4 Stronniczość, niepełne dane i nierówna jakość wyników Wyniki AI odzwierciedlają dane, proces wyszukiwania, instrukcje i kryteria oceny zastosowane w systemie. Historyczna nierównowaga, brak materiałów z określonych jurysdykcji, ograniczone pokrycie językowe, niska jakość dokumentów lub niespójne etykietowanie mogą prowadzić do nierównych rezultatów. Stronniczość może ujawnić się przy ocenie ryzyka, priorytetyzacji dokumentów, analizie ugód albo w rekomendacjach, które pozornie są neutralne, lecz systematycznie działają gorzej w określonych sprawach lub wobec określonych grup. Ocena systemu powinna zatem obejmować reprezentatywne zadania i dokumenty prawne, w tym trudne przypadki, języki mniejszościowe, zeskanowane pliki, sprzeczne źródła oraz sytuacje, w których właściwą odpowiedzią jest wskazanie niepewności zamiast wygenerowania stanowczego wniosku. 2.5 Ograniczona wyjaśnialność i identyfikowalność źródeł Prawnik nie zawsze potrzebuje technicznego wyjaśnienia każdego parametru modelu, ale rezultat pracy prawnej musi nadawać się do sprawdzenia. Użytkownicy powinni móc ustalić, jakie dokumenty lub źródła stanowią podstawę odpowiedzi, odróżnić cytaty od analizy wygenerowanej przez system, sprawdzić wersję i datę źródła oraz rozpoznać sytuację, w której system nie dysponuje wystarczającymi materiałami źródłowymi. Sam interfejs cytowań nie wystarczy, jeżeli wskazane źródło nie potwierdza przedstawionego twierdzenia. Wiarygodny system powinien ułatwiać kontrolę źródeł, a nie tylko dołączać linki do wygenerowanego tekstu. 2.6 Nadmierne zaufanie i skrzywienie automatyzacji Szybko wygenerowana i dobrze napisana odpowiedź stwarza ryzyko skrzywienia automatyzacji (automation bias): użytkownicy mogą analizować projekt przygotowany przez maszynę mniej wnikliwie niż pracę wykonaną przez współpracownika. Powtarzające się poleganie na systemie może również osłabiać nawyki badawcze i zmniejszać prawdopodobieństwo wykrycia anomalii prawnych lub faktycznych. Nadzór człowieka jest skuteczny tylko wtedy, gdy osoba weryfikująca ma wystarczająco dużo czasu, odpowiednie uprawnienia, wiedzę merytoryczną i dostęp do materiałów źródłowych, aby zakwestionować wynik systemu. 3. AI Act a usługi prawne AI Act nie klasyfikuje każdego zastosowania AI w prawie jako systemu wysokiego ryzyka. Klasyfikacja zależy od zamierzonego zastosowania i kontekstu. Wewnętrzne podsumowywanie dokumentów, wyodrębnianie klauzul lub przeszukiwanie bazy wiedzy nie stają się automatycznie zastosowaniami wysokiego ryzyka tylko dlatego, że korzysta z nich kancelaria prawna. Inaczej może być w przypadku niektórych systemów wykorzystywanych przez organy wymiaru sprawiedliwości lub w ich imieniu do badania i interpretowania faktów i prawa oraz stosowania prawa do konkretnych okoliczności. Po rozpoczęciu stosowania odpowiednich przepisów mogą one należeć do kategorii wysokiego ryzyka. Przegląd AI Act przygotowany przez Komisję wyjaśnia strukturę opartą na ryzyku i terminy wdrażania. Dla organizacji prawniczych pierwszym pytaniem dotyczącym zgodności jest często rola organizacji i konkretny przypadek użycia, a nie marka modelu. Organizacja, która wdraża narzędzie podmiotu trzeciego, istotnie je modyfikuje, oferuje je pod własną nazwą albo rozwija system przeznaczony dla klientów, może podlegać różnym obowiązkom. Zespoły zakupowe i produktowe powinny dokumentować tę ocenę, zamiast zakładać, że całą odpowiedzialność regulacyjną ponosi dostawca. Artykuł 4 ustanawia obowiązek zapewnienia odpowiedniego poziomu kompetencji w zakresie AI po stronie dostawców i podmiotów stosujących. Szkolenia powinny uwzględniać rolę danej osoby, przeznaczenie systemu oraz osoby lub grupy, na które system może oddziaływać. Ogólne szkolenie świadomościowe prawdopodobnie nie wystarczy prawnikom zatwierdzającym pisma sądowe, administratorom konfigurującym dostęp ani programistom zmieniającym źródła wykorzystywane w procesie wyszukiwania. Artykuł 50 wprowadza obowiązki w zakresie przejrzystości dotyczące określonych systemów AI i treści. Nie oznacza to, że każdy wewnętrzny dokument opracowany z pomocą AI musi być oznaczany w ten sam sposób, ale wymaga analizy konkretnego przypadku użycia. Komisja opublikowała wytyczne dotyczące obowiązków w zakresie przejrzystości stosowanych od 2026 roku, aby wyjaśnić, kiedy dostawcy i podmioty stosujące muszą informować odbiorców lub oznaczać treści wygenerowane przez AI. 4. Obowiązki zawodowe i oczekiwania sądów w Wielkiej Brytanii Brytyjskie kancelarie muszą uwzględniać zasady i kodeksy postępowania SRA, obowiązki wobec sądu, poufność, LPP, brytyjskie prawo ochrony danych oraz przyjęte mechanizmy nadzoru. Wytyczne SRA podkreślają, że osoba posiadająca odpowiednie uprawnienia musi zachować odpowiedzialność za usługi prawne świadczone z wykorzystaniem AI, a rezultaty wygenerowane przez AI wymagają odpowiedniej kontroli człowieka. Ryzyko jest widoczne w postępowaniach sądowych. W sprawach Ayinde v London Borough of Haringey oraz Al-Haroun v Qatar National Bank High Court analizował materiały prawne zawierające fałszywe źródła i podkreślił odpowiedzialność pełnomocników za weryfikację treści przedstawianych sądowi. Wniosek nie jest taki, że AI jest zakazana. Obowiązki dotyczące poprawności, nadzoru i rzetelności wobec sądu mają zastosowanie niezależnie od sposobu przygotowania dokumentu. Organizacje działające jednocześnie w UE i Wielkiej Brytanii nie powinny zakładać, że jedna polityka będzie wystarczająca we wszystkich przypadkach. Ta sama platforma techniczna może wymagać różnych informacji, postanowień umownych, ścieżek akceptacji i mechanizmów kontroli zawodowej w zależności od jurysdykcji oraz sposobu użycia. 5. Własność intelektualna, umowy i ryzyko dostawcy Proces zakupu narzędzi AI dla prawników powinien obejmować więcej niż cyberbezpieczeństwo. Umowy muszą określać dozwolone sposoby wykorzystywania danych, zasady trenowania modeli, dalszych podwykonawców, retencję i usuwanie danych, zgłaszanie incydentów, prawa audytowe, ciągłość usługi, prawa do wyników, poufność, odpowiedzialność oraz wsparcie w realizacji żądań organów regulacyjnych. Organizacje powinny również potwierdzić, że mają prawo wprowadzać do systemu dokumenty osób trzecich, a generowane treści są sprawdzane pod kątem naruszeń praw i niedozwolonego powielania. Certyfikaty bezpieczeństwa lub zarządzania AI mogą wspierać należytą staranność, ale nie stanowią prawnej bezpiecznej przystani ani nie potwierdzają poprawności wyników prawnych. Ocena powinna wiązać każdy mechanizm kontrolny z rzeczywistą architekturą wdrożenia i konkretnym przypadkiem użycia. 6. Czym wyróżnia się wiarygodny system AI dla prawników Określony cel i jurysdykcja: system jest projektowany dla wskazanych zadań, użytkowników, państw, języków i zbiorów źródeł. Odpowiedzi oparte na źródłach i możliwe do zweryfikowania: użytkownicy mogą otworzyć materiały źródłowe, sprawdzić cytaty i rozpoznać, kiedy system nie ma wystarczających podstaw do udzielenia odpowiedzi. Kontrolowane środowisko danych: dane klientów są odseparowane, dostęp jest ograniczony, okres retencji zdefiniowany, a dane nie są wykorzystywane do trenowania modelu bez wyraźnej zgody. Akceptacja człowieka w istotnych punktach decyzyjnych: wykwalifikowani specjaliści sprawdzają porady, pisma procesowe, komunikację z klientami i inne wyniki o dużym znaczeniu. Rejestrowanie i audytowalność: w odpowiednich przypadkach organizacja może odtworzyć dane wejściowe, źródła, model lub konfigurację, wynik, osobę weryfikującą i ostateczną decyzję. Reprezentatywna ocena: poprawność, jakość wyszukiwania, bezpieczeństwo, stronniczość i scenariusze błędów są testowane przed uruchomieniem oraz monitorowane po wprowadzeniu zmian. Jasny podział odpowiedzialności: dostawca, organizacja, właściciel produktu, zespół bezpieczeństwa informacji, funkcja ochrony danych i prawnik weryfikujący mają zdefiniowane obowiązki. 7. AI w kancelariach prawnych w praktyce europejskiej: TTMS i Sawaryn & Partners Praktycznym przykładem jest współpraca TTMS z polską kancelarią Sawaryn & Partners. Kancelaria potrzebowała rozwiązania do przetwarzania dużej liczby dokumentów spraw, akt sądowych, notatek ze spotkań i nagrań. TTMS wdrożył aplikację opartą na Azure OpenAI, która generuje podsumowania i wspiera aktualizowanie dokumentów. Zgodnie z opublikowanym studium przypadku architekturę zaprojektowano tak, aby dane wejściowe i wygenerowane wyniki nie były udostępniane zewnętrznym organizacjom ani wykorzystywane do trenowania sieci neuronowych. AI4Legal nie jest ograniczony do jednej jurysdykcji. Architektura oparta na dokumentach pozwala wspierać analizę materiałów prawnych w państwach członkowskich UE, Wielkiej Brytanii, Stanach Zjednoczonych i na innych rynkach. System pracuje na materiałach dostarczonych przez użytkownika, zamiast automatycznie pobierać krajowe kodeksy lub zbiory orzecznictwa. Dzięki temu platformę można dostosować do różnych jurysdykcji, bez sugerowania, że zawiera kompletną i stale aktualizowaną bazę prawa każdego państwa. Przypadek ten pokazuje właściwe zastosowanie AI do wspierania pracy prawnej wymagającej analizy dużej liczby dokumentów w kontrolowanym środowisku. Elastyczność jurysdykcyjna nie oznacza, że wyniki są wolne od błędów: zależą one od kompletności, poprawności i aktualności wprowadzonych materiałów. Specjaliści nadal muszą weryfikować właściwe prawo, cytowania i wnioski zgodnie z zasadami mającymi zastosowanie do sprawy. Wartość rozwiązania wynika z dopasowania technologii do określonego procesu, ochrony danych i pozostawienia kontroli prawnej po stronie kancelarii. Sawaryn & Partners publikuje również praktyczne komentarze dotyczące ról i obowiązków wynikających z AI Act, co pokazuje potrzebę połączenia wdrożenia technicznego z zarządzaniem prawnym. 8. Jak zabezpieczyć organizację prawniczą przed zagrożeniami AI Utwórz rejestr systemów AI. Zapisuj narzędzia zatwierdzone i niezatwierdzone, ich właścicieli, użytkowników, kategorie danych, integracje, jurysdykcje oraz zamierzone zastosowania. Klasyfikuj każdy przypadek użycia. Oceniaj rolę organizacji i poziom ryzyka w rozumieniu AI Act, wpływ na ochronę danych, tajemnicę zawodową, warunki uzgodnione z klientem, wymagania sądów oraz lokalne zasady zawodowe. Ustal zasady wprowadzania danych. Określ, jakie informacje mogą być używane, które środowiska są zatwierdzone oraz kiedy wymagana jest anonimizacja lub zastosowanie danych syntetycznych. Przeprowadź due diligence dostawcy i architektury. Sprawdź przepływy danych, ustawienia trenowania, lokalizację przechowywania, dalszych podwykonawców, kontrolę dostępu, usuwanie danych, reagowanie na incydenty, zabezpieczenia umowne oraz zasady zakończenia współpracy. Zaprojektuj weryfikację odpowiednią do zadania. Cytowania orzeczeń, porady prawne, terminy, obliczenia, cytaty i treści kierowane do klientów wymagają wyraźnie określonej kontroli z wykorzystaniem właściwych i wiarygodnych źródeł. Dostosuj szkolenia do rzeczywistych ról. Prawnicy, personel wsparcia, programiści, zespoły zakupowe i kadra zarządzająca potrzebują różnych programów szkoleniowych i ścieżek eskalacji. Monitoruj system produkcyjny. Powtarzaj testy po zmianie modelu, polecenia, źródła lub integracji oraz rejestruj błędy, przypadki ręcznego nadpisania wyniku, skargi i zdarzenia potencjalnie niebezpieczne. Przygotuj procedurę obsługi incydentów. Pracownicy powinni wiedzieć, jak wstrzymać korzystanie z systemu, zabezpieczyć dowody, poprawić rezultat pracy, poinformować osoby decyzyjne i ocenić obowiązki notyfikacyjne. 9. Równowaga między ryzykiem a wartością AI może ograniczyć czas poświęcany na wyszukiwanie, porządkowanie, porównywanie i podsumowywanie informacji. Może również ułatwić dostęp do dużych zbiorów dokumentów, których konsekwentna analiza byłaby w innym przypadku trudna. Korzyści są realne, ale zależą od sposobu zaprojektowania konkretnego przypadku użycia. Nie można ich zakładać wyłącznie na podstawie nazwy modelu ani prezentacji dostawcy. Najlepsze podejście traktuje AI jako część kontrolowanego procesu prawnego. System realizuje określone zadania obliczeniowe lub językowe, natomiast specjaliści pozostają odpowiedzialni za ocenę prawną, weryfikację źródeł, poufność i ostateczną decyzję. Taka równowaga pozwala zwiększyć efektywność bez przedstawiania automatyzacji jako zamiennika odpowiedzialności zawodowej. 10. Najważniejsze wnioski na 2026 rok Ryzyko związane z AI dla prawników w Europie ma wymiar zarówno techniczny, jak i regulacyjny. Halucynacje są tylko jednym z jego elementów. Wymagania UE i Wielkiej Brytanii różnią się, a całego regionu EMEA nie można objąć jednym wnioskiem prawnym. Nie każde narzędzie AI dla prawników jest systemem wysokiego ryzyka w rozumieniu AI Act, ale każdy przypadek użycia powinien zostać sklasyfikowany i udokumentowany. Poufność, tajemnica zawodowa i ochrona danych wymagają odrębnej analizy. AI4Legal może wspierać pracę na dokumentach w różnych jurysdykcjach, ale nie dostarcza ani nie aktualizuje automatycznie właściwego prawa krajowego. Weryfikację przez człowieka należy powierzyć osobie posiadającej odpowiednie kompetencje, oprzeć na źródłach i wbudować w proces, zamiast ograniczać ją do zastrzeżenia prawnego. Wiarygodne wdrożenie łączy odpowiedzi oparte na źródłach, kontrolowane dane, audytowalność, testowanie i jasny podział odpowiedzialności. 11. FAQ Czy korzystanie z AI w pracy prawniczej jest zakazane przez AI Act? Nie. AI Act opiera się na podejściu uwzględniającym poziom ryzyka. Obowiązki zależą od zamierzonego zastosowania, kategorii ryzyka oraz roli organizacji. Wiele wewnętrznych narzędzi zwiększających produktywność nie będzie systemami wysokiego ryzyka, chociaż nadal mogą mieć zastosowanie inne przepisy AI Act, RODO, postanowienia umowne i zasady zawodowe. Czy kancelaria może wprowadzać dokumenty klientów do narzędzia generatywnej AI? Tak, ale dopiero po potwierdzeniu, że sposób użycia jest zgodny z prawem, zasadami poufności i tajemnicy zawodowej, instrukcjami klienta, regułami wykonywania zawodu oraz zabezpieczeniami umownymi i technicznymi narzędzia. Publicznie dostępnych narzędzi konsumenckich nie należy traktować jako zatwierdzonego środowiska dla poufnych materiałów prawnych. Czy prawnicy muszą weryfikować każde cytowanie wygenerowane przez AI? Każde źródło, na którym opiera się porada, pismo procesowe lub inny istotny wniosek prawny, powinno zostać sprawdzone w źródle urzędowym lub innym miarodajnym materiale. Zakres kontroli zadań administracyjnych o niższym ryzyku może być proporcjonalny do charakteru zadania i potwierdzonej w testach niezawodności systemu. Czy certyfikat bezpieczeństwa oznacza, że narzędzie AI dla prawników jest zgodne z prawem? Nie. Certyfikaty mogą potwierdzać wybrane mechanizmy kontrolne, ale zgodność zależy od rzeczywistego przypadku użycia, przepływu danych, konfiguracji, umów, zasad zarządzania i obowiązków prawnych. Certyfikat nie potwierdza poprawności prawnej generowanych odpowiedzi. Czy należy informować klientów o wykorzystywaniu AI? Czasami. Odpowiedź zależy od obowiązujących wymagań przejrzystości, obowiązków zawodowych, warunków współpracy, oczekiwań klienta, znaczenia zadania wspieranego przez AI oraz sposobu przetwarzania informacji klienta. Organizacje powinny zdefiniować sytuacje wymagające ujawnienia informacji zamiast stosować jedno uniwersalne oświadczenie. Czy AI może zastąpić prawnika w dokonywaniu oceny prawnej? Nie. AI może wspierać wyszukiwanie informacji, analizę dokumentów, przygotowywanie projektów i korzystanie z baz wiedzy, ale odpowiedzialność za porady prawne, strategię, pisma procesowe i obowiązki zawodowe pozostaje po stronie wykwalifikowanych osób oraz organizacji podlegających właściwym regulacjom.
Czytaj
AQAP 2210 w projektach IT dla sektora obronnego – wymagania jakościowe dla oprogramowania
W projekcie obronnym jakość oprogramowania nie kończy się na poprawnym działaniu aplikacji w dniu odbioru. Zamawiający potrzebuje kontroli nad wymaganiami, konfiguracją, zmianami, testami, poddostawcami i dowodami potwierdzającymi zgodność produktu z umową. Musi również wiedzieć, jaka wersja została dostarczona, na jakiej podstawie ją zaakceptowano i czy można ją bezpiecznie utrzymywać oraz rozwijać. AQAP 2210 porządkuje te zagadnienia na poziomie projektu programistycznego. Publikacja określa wymagania NATO dotyczące zapewnienia jakości oprogramowania i jest stosowana jako uzupełnienie AQAP 2110 albo AQAP 2310. Jej znaczenie nie wynika jednak z samego występowania skrótu AQAP. W praktyce decydujące są wymagania konkretnej umowy, zakres dostawy, krytyczność oprogramowania oraz uzgodniony sposób nadzoru i odbioru. Dla zamawiającego oznacza to, że wybór dostawcy IT powinien obejmować znacznie więcej niż ocenę technologii, dostępności programistów i ceny. Potrzebny jest partner zdolny do kontrolowanego wytwarzania oprogramowania, utrzymywania identyfikowalności oraz przedstawienia wiarygodnych dowodów jakości. Ten artykuł wyjaśnia, jak rozumieć wymagania AQAP 2210 i jak wykorzystać je podczas wyboru dostawcy IT dla sektora obronnego. NAJWAŻNIEJSZY WNIOSEK: Certyfikat AQAP jest istotnym potwierdzeniem dojrzałości systemu jakości dostawcy. Nie zastępuje jednak analizy wymagań konkretnej umowy ani dowodów jakości powstających podczas realizacji projektu. 1. AQAP 2210 – najważniejsze informacje w skrócie AQAP 2210 dotyczy zapewnienia jakości oprogramowania w projektach realizowanych w środowisku obronnym. Aktualne wydanie to AQAP 2210, wydanie B, wersja 1, opublikowane w 2022 roku. Publikacja jest uzupełnieniem AQAP 2110 albo AQAP 2310 i nie jest projektowana jako całkowicie samodzielny system wymagań. Jej zastosowanie w projekcie wynika przede wszystkim z umowy, specyfikacji zamówienia i przywołanych dokumentów jakościowych. Obejmuje procesy zarządcze i techniczne, w tym planowanie jakości, analizę krytyczności, wymagania, konfigurację, weryfikację, walidację, testy i nadzór nad poddostawcami. Nie narzuca jednego modelu wytwarzania oprogramowania. Może współistnieć z Agile i DevSecOps, jeżeli organizacja zachowuje kontrolę, odpowiedzialność i obiektywne dowody. Certyfikat dostawcy nie oznacza automatycznej zgodności każdego produktu lub projektu. Liczą się zakres certyfikacji, wymagania umowy i sposób zastosowania procesów w realizowanym przedsięwzięciu. 2. Czym jest AQAP 2210? AQAP to skrót od Allied Quality Assurance Publications, czyli sojuszniczych publikacji dotyczących zapewnienia jakości. Dokumenty z rodziny AQAP wspierają wspólne podejście państw NATO do jakości dostaw realizowanych na potrzeby obronności. Ich rolą jest zwiększenie zaufania, że dostawca potrafi dostarczyć wyrób zgodny z wymaganiami kontraktowymi i zapewnić zamawiającemu odpowiednią widoczność procesów wpływających na jakość. AQAP 2210, wydanie B, wersja 1, zawiera uzupełniające wymagania NATO dotyczące zapewnienia jakości oprogramowania. Publikacja jest zorientowana na projekt i obejmuje zarówno procesy zarządcze, jak i techniczne. Jej celem nie jest wskazanie konkretnej metodyki programistycznej, języka, narzędzia czy architektury. Chodzi o ustanowienie takiego poziomu planowania, kontroli i dowodów, który daje zamawiającemu uzasadnione zaufanie do procesu i produktu. AQAP 2210 należy stosować razem z AQAP 2110 albo AQAP 2310, zależnie od podstawowego zestawu wymagań przywołanego w kontrakcie. W Polsce aktualne publikacje wykorzystywane w procesach certyfikacji opisują między innymi Polskie Centrum Badań i Certyfikacji oraz Centrum Certyfikacji Jakości Wojskowej Akademii Technicznej. Status AQAP 2210 jako aktywnej publikacji w wydaniu B można również zweryfikować w amerykańskim rejestrze dokumentów standaryzacyjnych ASSIST. 2.1 Wymaganie kontraktowe, a nie powszechnie obowiązująca ustawa AQAP 2210 nie należy przedstawiać jako aktu prawnego, który automatycznie obowiązuje każdą firmę tworzącą oprogramowanie dla obronności. Zakres wiążących zobowiązań wynika przede wszystkim z kontraktu, specyfikacji, klauzuli jakościowej oraz dokumentów przywołanych przez zamawiającego. W jednym projekcie AQAP 2210 może obejmować pełny cykl rozwoju nowego systemu. W innym zastosowanie może dotyczyć modyfikacji istniejącego rozwiązania, integracji komponentu albo utrzymania oprogramowania. Wymagania mogą podlegać uzasadnionemu dostosowaniu, jeśli publikacja i zamawiający na to pozwalają. Takie decyzje powinny być jednak jawne, zatwierdzone i udokumentowane. Dostawca nie powinien samodzielnie uznawać niewygodnego wymagania za niestosowalne. 3. AQAP 2110 a AQAP 2210 – jaka jest różnica? AQAP 2110 i AQAP 2210 są ze sobą powiązane, ale pełnią inne funkcje. Pierwszy dokument ustanawia szerokie wymagania jakościowe dotyczące projektowania, prac rozwojowych i produkcji. Drugi rozwija te wymagania w odniesieniu do oprogramowania i pracy na poziomie konkretnego projektu. Obszar AQAP 2110 AQAP 2210 Główny zakres Zapewnienie jakości w projektowaniu, pracach rozwojowych i produkcji Uzupełniające zapewnienie jakości oprogramowania Rola Podstawowy zestaw wymagań jakościowych Uzupełnienie programistyczne do AQAP 2110 albo AQAP 2310 Perspektywa System jakości dostawcy i realizacja wyrobu Projekt, procesy i dowody dotyczące oprogramowania Przykładowe obszary Planowanie, ryzyko, dostawcy, niezgodności, nadzór nad realizacją Plan jakości oprogramowania, krytyczność, wymagania, SCM, V&V, testowanie Zastosowanie Zależne od wymagań kontraktu i rodzaju dostawy Gdy kontrakt obejmuje oprogramowanie i przywołuje właściwe wymagania Samodzielność Może stanowić podstawowy dokument jakościowy Stosowany razem z AQAP 2110 albo AQAP 2310 ISO 9001 pozostaje ważną podstawą systemowego zarządzania jakością, ale nie opisuje wszystkich mechanizmów potrzebnych w projekcie obronnym ani szczegółowych wymagań jakościowych dla oprogramowania. Dlatego ocena potencjalnego partnera nie powinna kończyć się na pytaniu o ISO 9001. Należy sprawdzić, czy jego system obejmuje właściwy zakres AQAP i czy organizacja potrafi zastosować go w konkretnym projekcie. 4. Kiedy AQAP 2210 ma zastosowanie w projekcie IT? Najbardziej wiarygodną odpowiedź daje dokumentacja kontraktowa. Wymóg może zostać wskazany bezpośrednio w umowie, specyfikacji warunków zamówienia, klauzuli jakościowej, planie jakości albo wymaganiach przekazanych głównemu wykonawcy i przenoszonych na poddostawców. AQAP 2210 może być istotny w projektach obejmujących: tworzenie nowego oprogramowania na zamówienie; rozwój lub istotną modyfikację istniejącego systemu; utrzymanie i pielęgnację oprogramowania; integrację oprogramowania ze sprzętem, sensorami, efektorami lub platformami; systemy dowodzenia, kierowania i świadomości sytuacyjnej; rozwiązania klasy C2, C4ISR i systemy wsparcia bojowego; oprogramowanie wbudowane albo komponent będący częścią większego wyrobu; wykorzystanie lub modyfikację oprogramowania COTS; dostawę komponentu programistycznego przez poddostawcę głównego wykonawcy. Sam fakt, że w produkcie występuje kod, nie przesądza jednak o identycznym zakresie wymagań. Innej kontroli może wymagać aplikacja wspierająca proces administracyjny, a innej komponent mający wpływ na realizację funkcji krytycznej. Dlatego przed rozpoczęciem prac trzeba zidentyfikować co najmniej zakres dostawy, odpowiedzialność stron, krytyczność oprogramowania, zależności, sposób odbioru i dowody wymagane przez zamawiającego. 4.1 Pytania, które warto zadać przed podpisaniem umowy Które publikacje AQAP i ich wydania zostały przywołane? Czy wymagania dotyczą całej dostawy, konkretnego komponentu czy wybranych procesów? Czy dopuszczono dostosowanie wymagań, a jeśli tak, kto je zatwierdza? Jakie prawa nadzoru i dostępu otrzymuje zamawiający lub przedstawiciel rządowego zapewnienia jakości? Jakie plany, rejestry, raporty i dowody są wymagane przy przeglądach i odbiorze? Które obowiązki muszą zostać przeniesione na poddostawców? Jak będzie oceniana krytyczność oprogramowania i jaki wpływ ma ona na rygor prac? Wczesne wyjaśnienie tych kwestii ogranicza ryzyko kosztownej przebudowy dokumentacji, procesu testowego albo łańcucha dostaw już w trakcie realizacji. 5. Dlaczego AQAP 2210 ma znaczenie dla zamawiającego? W zwykłym projekcie komercyjnym część niejednoznaczności można rozwiązać negocjacją zakresu lub przesunięciem terminu. W projekcie obronnym konsekwencje błędnej konfiguracji, niepełnego testu lub utraty identyfikowalności mogą być znacznie poważniejsze. System może współpracować ze sprzętem, przetwarzać dane istotne operacyjnie albo działać w środowisku o ograniczonej łączności i podwyższonym zagrożeniu. AQAP 2210 pomaga zamawiającemu ograniczać między innymi następujące ryzyka: dostarczenie funkcjonalności niezgodnej z wymaganiami umowy; zmiany wprowadzone bez oceny wpływu i zatwierdzenia; brak powiązania pomiędzy wymaganiem, projektem, kodem i wynikiem testu; niemożność jednoznacznego wskazania konfiguracji przekazanej do odbioru; wykrycie kluczowych błędów dopiero podczas testów akceptacyjnych; brak obiektywnych dowodów potwierdzających wykonanie testów; niekontrolowane wykorzystanie komponentów zewnętrznych; niewystarczający nadzór nad poddostawcą; utrata wiedzy potrzebnej do utrzymania i dalszego rozwoju systemu; zamknięcie niezgodności bez potwierdzenia skuteczności korekty. Najważniejszą wartością nie jest więc sama liczba dokumentów. Jest nią przejrzystość: zamawiający może sprawdzić, jak dostawca interpretuje wymagania, jak kontroluje pracę, jakie ryzyko pozostaje otwarte i na jakiej podstawie uznaje produkt za gotowy. 6. Najważniejsze wymagania AQAP 2210 w projekcie programistycznym AQAP 2210 obejmuje wiele powiązanych procesów. Ich szczegółowe zastosowanie zależy od kontraktu, ale poniższe obszary należą do najważniejszych podczas oceny dostawcy i planowania realizacji. 6.1 Plan jakości oprogramowania projektu Plan jakości oprogramowania projektu, często określany jako Project Software Quality Plan, powinien pokazywać, w jaki sposób organizacja spełni wymagania jakościowe w konkretnym przedsięwzięciu. Nie jest to ogólna polityka jakości ani dokument przygotowywany dopiero przed audytem. Dobry plan łączy wymagania kontraktu z realnym sposobem pracy. Określa zakres, role, odpowiedzialności, cykl życia, przeglądy, metody weryfikacji i walidacji, zarządzanie konfiguracją, nadzór nad poddostawcami, metryki oraz wymagane zapisy. Powinien także wskazywać zależności pomiędzy dokumentami i sposób aktualizacji planu po zmianie projektu. Zamawiający powinien móc na jego podstawie zrozumieć nie tylko, co dostawca deklaruje, ale również kiedy otrzyma dowody, kto podejmie decyzję i jak zostanie obsłużone odstępstwo. 6.2 Analiza krytyczności oprogramowania Krytyczność pomaga dostosować rygor działań do skutków potencjalnego błędu. Analiza powinna uwzględniać funkcję oprogramowania, jego relację z całym systemem oraz wpływ nieprawidłowego działania na ludzi, misję, sprzęt, informacje i ciągłość operacji. Wynik analizy może wpływać na niezależność przeglądów, zakres testów, wymagane pokrycie, częstotliwość raportowania, poziom kontroli zmian i sposób postępowania z ryzykiem. Nie chodzi o automatyczne zastosowanie najbardziej kosztownych środków do każdego komponentu. Chodzi o świadomą, udokumentowaną i uzasadnioną decyzję. 6.3 Zarządzanie wymaganiami i identyfikowalność Wymagania powinny być jednoznaczne, możliwe do zweryfikowania i objęte kontrolą zmian. Dostawca musi rozumieć wymagania systemowe, programistyczne i komponentowe, a także ograniczenia wynikające z architektury, interfejsów, bezpieczeństwa i środowiska działania. Identyfikowalność pozwala przejść od wymagania do rozwiązania projektowego, implementacji i testu, a następnie wrócić od wyniku testu do podstawy kontraktowej. Może być utrzymywana w macierzy albo dedykowanym narzędziu. Najważniejsze, by była aktualna i pozwalała wykryć wymaganie bez projektu, kod bez uzasadnienia lub test bez powiązania. W dojrzałym projekcie zmiana wymagania uruchamia ocenę wpływu na architekturę, kod, testy, dokumentację, terminy i poddostawców. Sama aktualizacja pozycji w backlogu nie wystarcza, jeżeli reszta dowodów pozostaje nieaktualna. 6.4 Zarządzanie konfiguracją oprogramowania Zarządzanie konfiguracją oprogramowania, czyli SCM, ma zapewnić jednoznaczną identyfikację elementów produktu oraz kontrolę nad ich zmianami. Dotyczy to nie tylko kodu źródłowego. Zakres może obejmować wymagania, modele, skrypty, konfiguracje środowisk, biblioteki, dokumentację, dane testowe, narzędzia, artefakty budowania i pakiety instalacyjne. Zamawiający powinien oczekiwać odpowiedzi na kilka praktycznych pytań: Jakie elementy tworzą konkretną wersję produktu? Kto zatwierdził zmianę i na jakiej podstawie? Czy można odtworzyć build przekazany do testów lub odbioru? Jak rejestrowany jest status zmian i niezgodności? Czy dostawca kontroluje zależności, biblioteki i wersje narzędzi? W jaki sposób zabezpiecza repozytoria i ogranicza dostęp? Bez tych mechanizmów nawet poprawnie przetestowana funkcja może trafić do niewłaściwego wydania albo zostać nadpisana przez późniejszą zmianę. 6.5 Weryfikacja, walidacja i testowanie Weryfikacja odpowiada na pytanie, czy produkt został zbudowany zgodnie z określonymi wymaganiami i projektem. Walidacja sprawdza, czy rozwiązanie spełnia potrzeby i zamierzone zastosowanie w docelowym kontekście. W praktyce oba rodzaje działań powinny być zaplanowane, mieć kryteria, właścicieli i zachowane wyniki. Program testów może obejmować testy jednostkowe, integracyjne, systemowe, wydajnościowe, bezpieczeństwa, odpornościowe i akceptacyjne. Zakres zależy od produktu i umowy. Kluczowe znaczenie mają: powiązanie testów z wymaganiami; zdefiniowane środowisko i dane testowe; wersja badanego produktu; kryteria rozpoczęcia i zakończenia testów; wynik, odchylenia i dowody wykonania; rozdzielenie ról, jeśli wymagana jest niezależność; sposób obsługi błędów, retestów i regresji. Automatyzacja może zwiększyć powtarzalność, ale raport z pipeline’u nie jest sam w sobie pełnym dowodem, jeśli nie wiadomo, czego dotyczył, na jakiej wersji został wykonany i według jakich kryteriów został oceniony. 6.6 Niezgodności i działania korygujące Dostawca powinien mieć kontrolowany proces rejestrowania, oceny i zamykania niezgodności. Ważne jest odróżnienie doraźnej korekty błędu od działania korygującego eliminującego jego przyczynę. Rejestr powinien pozwalać ustalić między innymi wpływ problemu, dotknięte wersje, decyzję dotyczącą dalszego postępowania, odpowiedzialność, wynik retestu oraz ewentualną potrzebę poinformowania zamawiającego. Powtarzające się problemy powinny prowadzić do analizy trendu i oceny skuteczności procesu, a nie wyłącznie do kolejnych poprawek kodu. 6.7 Poddostawcy, COTS i komponenty zewnętrzne Współczesne oprogramowanie korzysta z bibliotek, narzędzi, usług, urządzeń i gotowych komponentów. AQAP 2210 nie pozwala traktować ich jako obszaru poza odpowiedzialnością dostawcy. Organizacja powinna oceniać przydatność komponentu, jego ograniczenia, prawa do użycia, dokumentację, konfigurację i wpływ na wymagania. W przypadku COTS potrzebne są obiektywne podstawy uznania, że produkt spełni wymaganą funkcję. Jeżeli pełna identyfikowalność nie jest możliwa, ograniczenie powinno zostać rozpoznane, ocenione i odpowiednio zarządzone. Modyfikacja gotowego oprogramowania może dodatkowo zmienić profil ryzyka i odpowiedzialność za utrzymanie. Podobna zasada dotyczy poddostawców. Główny wykonawca powinien określić wymagania, monitorować wykonanie i zachować dowody nadzoru. Certyfikat poddostawcy może wspierać kwalifikację, ale nie zwalnia z odpowiedzialności za zgodność całej dostawy. 7. Czy Agile i DevSecOps można pogodzić z AQAP 2210? Tak. AQAP 2210 nie narzuca jednego modelu cyklu życia ani obowiązkowego podejścia kaskadowego. Agile i DevSecOps mogą być stosowane, jeśli organizacja potrafi wykazać kontrolę nad wymaganiami, konfiguracją, testami, odpowiedzialnością i wydaniami. Praktyka Agile lub DevSecOps Odpowiadający jej mechanizm jakościowy Product backlog Kontrolowany rejestr wymagań, priorytetów i zmian Definition of Ready Kryteria gotowości wymagania do realizacji Definition of Done Kryteria jakości, testów, dokumentacji i akceptacji Pull request i code review Udokumentowany przegląd oraz zatwierdzenie zmiany Repozytorium kodu Identyfikacja elementów i kontrola konfiguracji CI/CD Powtarzalny build, automatyczne kontrole i zachowane wyniki Test management Powiązanie wymagania, przypadku testowego, wersji i wyniku Release pipeline Kontrolowane wydanie oraz jednoznaczna zawartość wersji Retrospektywa Doskonalenie procesu i działania korygujące Najczęstszy błąd polega na utożsamieniu zwinności z brakiem dokumentacji. Dokumentacja w projekcie Agile może być lżejsza, generowana automatycznie i utrzymywana w narzędziach. Nadal musi jednak być wiarygodna, dostępna i zrozumiała dla osób sprawujących nadzór. Drugim ryzykiem jest nadmierne zaufanie do automatyzacji. Pipeline może wykonać tysiące testów, ale zamawiający potrzebuje także kontekstu: wersji produktu, zakresu testów, kryteriów, odchyleń i zatwierdzenia. DevSecOps wspiera AQAP wtedy, gdy automatyzuje kontrolowany proces, a nie gdy ukrywa brak odpowiedzialności za strumieniem logów. 8. Jakich dokumentów i dowodów może oczekiwać zamawiający? Ostateczny zestaw dowodów wynika z kontraktu. Nie istnieje jeden segregator właściwy dla każdego projektu. W praktyce zamawiający może oczekiwać materiałów takich jak: Obszar Przykładowe dokumenty i zapisy Pytanie kontrolne Planowanie Plan jakości oprogramowania, harmonogram przeglądów, macierz odpowiedzialności Czy wiadomo, kto, kiedy i według jakich kryteriów podejmuje decyzję? Wymagania Specyfikacje, historia zmian, macierz identyfikowalności, protokoły przeglądów Czy każde wymaganie ma źródło, właściciela i sposób weryfikacji? Konfiguracja Plan SCM, lista elementów konfiguracji, baseline’y, rejestr wydań Czy można odtworzyć dokładną wersję przekazaną zamawiającemu? Testowanie Plany, przypadki, dane, raporty, wyniki i rejestry defektów Czy wynik dotyczy właściwej wersji i zatwierdzonego wymagania? Niezgodności Raporty problemów, decyzje, analiza przyczyn, retesty Czy problem został skutecznie zamknięty, a nie tylko oznaczony jako zamknięty? Dostawcy Kryteria kwalifikacji, oceny, wymagania zakupowe, przeglądy Czy obowiązki jakościowe zostały przeniesione i są monitorowane? COTS i zależności Ocena przydatności, wersje, licencje, ograniczenia, dowody funkcjonalne Czy organizacja zna ryzyko i może utrzymać wykorzystany komponent? Odbiór i dostawa Dokumentacja wydania, wyniki akceptacji, wykaz odstępstw Czy zawartość dostawy i pozostałe ograniczenia są jednoznaczne? Dowód powinien być wiarygodny, aktualny, powiązany z zakresem i możliwy do odtworzenia. Zrzut ekranu bez daty, wersji i właściciela ma ograniczoną wartość. Podobnie polityka opisująca proces nie dowodzi jeszcze, że proces rzeczywiście zastosowano w projekcie. 9. Co certyfikat AQAP potwierdza, a czego nie gwarantuje? Certyfikacja systemu zarządzania jakością przez kompetentną jednostkę jest ważnym sygnałem dla zamawiającego. Pokazuje, że określony zakres działalności organizacji został oceniony pod kątem wskazanych wymagań, a firma utrzymuje procesy potrzebne do kontrolowanej realizacji. Certyfikat może potwierdzać: wdrożenie i utrzymywanie systemu jakości zgodnego z określoną publikacją AQAP; objęcie oceną wskazanego zakresu działalności i lokalizacji; istnienie kontrolowanych procesów, odpowiedzialności i zapisów; cykliczną ocenę systemu przez stronę trzecią; organizacyjną podstawę do realizacji kontraktów wymagających AQAP. Sam certyfikat nie gwarantuje automatycznie: zgodności każdego projektu z każdą umową; braku błędów w produkcie; spełnienia wymagań znajdujących się poza zakresem certyfikacji; posiadania wszystkich poświadczeń, koncesji lub kompetencji domenowych wymaganych w projekcie; skutecznego zastosowania procesów bez odpowiedniego zespołu i nadzoru; akceptacji dostawcy przez każdego zamawiającego bez dalszej kwalifikacji. Dlatego należy sprawdzić jednostkę wydającą certyfikat, jego ważność, publikację i wydanie AQAP, zakres certyfikacji, lokalizacje oraz zgodność tego zakresu z planowanym zamówieniem. Warto również poprosić dostawcę o pokazanie, w jaki sposób jego system jakości zostanie zastosowany w konkretnym projekcie. 10. Jak wybrać dostawcę IT do projektu obronnego? Dobry dostawca łączy trzy warstwy: zdolność organizacyjną, kompetencje techniczne i znajomość środowiska obronnego. Brak jednej z nich może ujawnić się dopiero na etapie integracji, nadzoru lub odbioru. 10.1 Checklista dla zamawiającego [ ] Zakres certyfikacji obejmuje rozwój, dostawę lub utrzymanie oprogramowania odpowiadające planowanemu projektowi. [ ] Dostawca potrafi przełożyć wymagania umowy na plan jakości i codzienny sposób pracy zespołu. [ ] Wymagania, decyzje projektowe, implementacja i testy pozostają identyfikowalne. [ ] Zarządzanie konfiguracją obejmuje kod, dokumentację, zależności, środowiska i wydania. [ ] Build przekazany do testów lub odbioru można jednoznacznie odtworzyć. [ ] Proces V&V ma określone role, kryteria, środowiska i zachowane wyniki. [ ] Niezgodności są oceniane, śledzone, retestowane i zamykane na podstawie dowodów. [ ] Poddostawcy i komponenty COTS podlegają kwalifikacji oraz monitoringowi. [ ] Zespół rozumie integrację oprogramowania ze sprzętem i ograniczenia środowiska docelowego. [ ] Dostawca zna specyfikę systemów obronnych, standardów NATO i pracy w łańcuchu dostaw. [ ] Potrafi przygotować dowody jakości wymagane podczas przeglądów, nadzoru i odbioru. [ ] Może zapewnić utrzymanie, zarządzanie zmianą i kontrolowany rozwój po wdrożeniu. [ ] Model współpracy jasno określa odpowiedzialność za produkt, jakość, bezpieczeństwo i decyzje. [ ] Deklarowane doświadczenie odpowiada faktycznemu zakresowi oraz krytyczności zamówienia. 10.2 Sygnały ostrzegawcze podczas kwalifikacji Ostrożność powinny wzbudzić odpowiedzi ograniczające się do stwierdzenia, że firma posiada certyfikat albo pracuje w Agile. Istotne są również następujące sygnały: brak możliwości wyjaśnienia zakresu certyfikacji; plan jakości kopiowany bez dostosowania do projektu; brak właściciela procesu zarządzania konfiguracją; testy niepowiązane z wymaganiami i wersją produktu; poddostawcy traktowani jako odpowiedzialni za własną jakość bez nadzoru głównego wykonawcy; brak kontrolowanego sposobu zatwierdzania odstępstw; dokumentacja przygotowywana dopiero bezpośrednio przed odbiorem; niemożność przedstawienia sposobu obsługi zmian po wdrożeniu. Najlepszym sprawdzianem jest rozmowa oparta na przykładowym scenariuszu: zmienia się wymaganie o wysokiej krytyczności, dotyka komponentu poddostawcy i wymaga nowego testu integracyjnego. Dojrzały partner potrafi opisać ocenę wpływu, decyzje, aktualizację konfiguracji, testy i dowody bez zasłaniania się ogólną procedurą. 11. Dlaczego TTMS jako partner dla sektora obronnego? Wybór partnera technologicznego powinien opierać się na dopasowaniu do konkretnego przedsięwzięcia. W przypadku TTMS istotne jest połączenie certyfikowanego systemu jakości z kompetencjami technicznymi i doświadczeniem domenowym. 11.1 Certyfikowane procesy jakościowe TTMS uzyskał certyfikaty AQAP 2110 i AQAP 2210, o czym informuje komunikat w pressroomie TTMS. Dla potencjalnego zamawiającego jest to potwierdzenie, że określony zakres systemu zarządzania jakością firmy został poddany niezależnej ocenie według wymagań stosowanych w sektorze obronnym i w zapewnieniu jakości oprogramowania. Certyfikacja nie jest przedstawiana jako substytut analizy projektu. Stanowi organizacyjną podstawę, na której można zbudować plan jakości, identyfikowalność, zarządzanie konfiguracją i dowody wymagane przez daną umowę. 11.2 Kompetencje techniczne i znajomość domeny Publiczna oferta TTMS dla sektora obronnego i kosmicznego obejmuje między innymi rozwój oprogramowania, usługi inżynierii obronnej IT, integrację sprzętu z oprogramowaniem, doradztwo techniczne, zarządzanie projektami oraz dostarczanie wyspecjalizowanych zespołów. TTMS opisuje również doświadczenie związane z systemami C2, C4ISR i systemami wsparcia bojowego oraz pracą w środowisku organizacji międzynarodowych. Takie połączenie ma znaczenie, ponieważ zgodność procesu nie zastępuje kompetencji inżynierskich. Z drugiej strony nawet bardzo dobry zespół programistyczny może nie sprostać projektowi obronnemu, jeśli nie potrafi pracować z wymaganiami kontraktowymi, nadzorem jakościowym i formalnymi dowodami. 11.3 Możliwość dopasowania modelu współpracy Projekt może wymagać kompletnego rozwiązania, wydzielonego komponentu, integracji, zespołu programistycznego albo pojedynczych kompetencji. Model powinien zostać dobrany po analizie zakresu, odpowiedzialności i wymagań jakościowych. Niezależnie od formy współpracy należy jasno ustalić właścicieli wymagań, konfiguracji, testów, ryzyka i akceptacji. TTMS może wejść do projektu jako partner technologiczny wspierający rozwój, integrację i utrzymanie oprogramowania. Ostateczne zobowiązania, zastosowane publikacje AQAP oraz zakres dowodów powinny zostać określone w dokumentacji konkretnego przedsięwzięcia. 12. Jak może wyglądać współpraca z TTMS? 12.1 Analiza kontekstu i wymagań Pierwszy etap obejmuje zrozumienie celu systemu, zakresu dostawy, interesariuszy, architektury, wymagań jakościowych i ograniczeń bezpieczeństwa. Zespół identyfikuje publikacje i klauzule przywołane w umowie oraz obszary wymagające doprecyzowania. 12.2 Określenie modelu realizacji Ustalane są odpowiedzialności, skład zespołu, interfejsy z zamawiającym i innymi dostawcami, cykl życia, przeglądy, narzędzia, konfiguracja i wymagane dowody. Na tym etapie należy również zaplanować przeniesienie wymagań na poddostawców. 12.3 Kontrolowany rozwój i raportowanie Realizacja łączy pracę inżynierską z zarządzaniem wymaganiami, ryzykiem, konfiguracją, jakością i niezgodnościami. Zamawiający otrzymuje uzgodnioną widoczność postępu, wyników i otwartych decyzji. 12.4 Weryfikacja, walidacja i odbiór Testy i przeglądy są wykonywane na kontrolowanych wersjach według zatwierdzonych kryteriów. Pakiet odbiorowy powinien jednoznacznie pokazywać zawartość dostawy, wyniki, odstępstwa i pozostałe ograniczenia. 12.5 Utrzymanie i kontrolowany rozwój Po wdrożeniu nadal potrzebne są zarządzanie konfiguracją, obsługa problemów, aktualizacje, ocena wpływu zmian i utrzymanie dokumentacji. Model wsparcia powinien odpowiadać znaczeniu systemu i wymaganej dostępności. 13. Szukasz partnera IT do projektu dla sektora obronnego? Projekt obronny wymaga jednoczesnego zrozumienia technologii, jakości, integracji, bezpieczeństwa i odpowiedzialności kontraktowej. Warto zaangażować dostawcę przed zamknięciem architektury i planu realizacji, aby wymagania AQAP nie zostały potraktowane jako dokumentacyjny dodatek przygotowywany dopiero przed odbiorem. Skontaktuj się z TTMS, aby omówić wymagania techniczne i jakościowe projektu, zakres odpowiedzialności oraz możliwy model współpracy z zespołem Defence. 14. Najczęściej zadawane pytania o AQAP 2210
Czytaj
Licencje i ceny Microsoft 365 w 2026 roku: kompletny przewodnik dla kupujących
Co właściwie kupuje firma, gdy zamawia Microsoft 365? Odpowiedź „pocztę i pakiet Office” już dawno przestała wystarczać. Dziś w grę wchodzą również urządzenia, logowanie, ochrona danych, spotkania, praca w chmurze i coraz częściej także Copilot. Problem w tym, że nie każdy pracownik potrzebuje całego tego zestawu. Najłatwiej pomylić się przy planach, które z perspektywy użytkownika wyglądają niemal tak samo. Word działa, Outlook jest dostępny, pliki można zapisywać w chmurze. Różnica wychodzi dopiero później – na przykład wtedy, gdy dział IT chce zdalnie skonfigurować laptop, wymusić odpowiednie zasady dostępu albo szybko zareagować na zagrożenie. Wtedy okazuje się, że tańsza licencja nie zawsze oznacza niższy koszt. Brakujące zabezpieczenia trzeba przecież zapewnić w inny sposób. W 2026 roku wybór dodatkowo komplikują zmiany obowiązujące od 1 lipca. Microsoft podniósł ceny części planów Business, Enterprise i Frontline, a w niektórych pakietach zmienił również zakres dostępnych funkcji. Nadal można spotkać warianty z Teams i bez Teams, więc porównywanie samych nazw produktów niewiele daje. Trzeba jeszcze sprawdzić moment odnowienia umowy, walutę rozliczenia, podatki oraz warunki zaproponowane przez partnera. Kwota widoczna w cenniku jest zatem punktem wyjścia, nie gotową ofertą. Podobnie jest z Copilotem.Copilot Chat może być dostępny bez dodatkowej opłaty dla użytkowników kwalifikujących się subskrypcji, ale Microsoft 365 Copilot to osobna, płatna licencja wymagająca odpowiedniego planu bazowego. Co ważne, dokupienie Copilota nie porządkuje automatycznie firmowych danych ani uprawnień. Narzędzie korzysta z tego, co już znajduje się w środowisku organizacji – razem z istniejącymi ograniczeniami i błędami. W tym przewodniku przyglądamy się planom Business, Enterprise i Frontline, a także Apps for Business, Office 365 E1 oraz obu wariantom Copilota. Zamiast szukać jednego planu dobrego dla wszystkich, sprawdzamy, co ma sens dla poszczególnych ról. Innej licencji potrzebuje przecież osoba pracująca wyłącznie w przeglądarce, innej administrator, a jeszcze innej pracownik korzystający ze współdzielonego urządzenia. Dopiero z takiego podziału można zbudować rozsądny – i możliwy do obrony finansowo – model licencjonowania. W przewodniku podano amerykańskie komercyjne ceny katalogowe bez podatku. Waluta, korekty lokalne, rabaty partnera, rodzaj umowy, harmonogram płatności i promocje wpływają na ostateczną kwotę. Microsoft 365 w skrócie: pięć zasad wyboru Business Basic sprawdzi się, gdy użytkownik potrzebuje firmowej poczty, współpracy w chmurze oraz aplikacji webowych i mobilnych, ale nie wymaga lokalnie zainstalowanego pakietu Office. Business Standard jest przeznaczony dla osób pracujących w desktopowych wersjach Worda, Excela, PowerPointa i Outlooka, jeśli bezpieczeństwo urządzeń jest zapewniane w inny sposób. Business Premium jest zazwyczaj najlepszym punktem wyjścia dla organizacji do 300 użytkowników, które chcą połączyć produktywność z Intune, Microsoft Entra ID P1 i Defender for Business. Plany Enterprise stają się potrzebne po przekroczeniu limitu 300 użytkowników lub wtedy, gdy organizacja wymaga praw do Windows Enterprise, bardziej zaawansowanego bezpieczeństwa, zgodności albo zarządzania na dużą skalę. F1 i F3 są przeznaczone dla rzeczywistych pracowników pierwszej linii. Copilot Chat może być szeroką warstwą podstawową, natomiast płatny Copilot powinien trafiać do osób, które mają konkretne i mierzalne przypadki użycia. Co zmieniło się w cenach Microsoft 365 w 2026 roku? Nowe komercyjne ceny katalogowe w Stanach Zjednoczonych obowiązują od 1 lipca 2026 roku. Poniższe kwoty są miesięcznym przeliczeniem subskrypcji rocznej, nie obejmują podatku i mogą różnić się w zależności od kraju, waluty i kanału zakupu. Plan Z Teams USD/użytk./mies. Bez Teams USD/użytk./mies. Najważniejsza informacja Business Basic $7,00 $5,40 Pakiet chmurowy dla MŚP; cena wzrosła Business Standard $14,00 $10,79 Aplikacje desktopowe dla MŚP; cena wzrosła Business Premium $22,00 $18,79 Pakiet z zabezpieczeniami; cena bez zmian Apps for Business $10,00 Nie dotyczy Aplikacje desktopowe i OneDrive Office 365 E1 $10,00 $6,79 Produktywność w chmurze; cena bez zmian Office 365 E3 $26,00 $17,45 Nie należy mylić z Microsoft 365 E3 Office 365 E5 $41,00 $32,45 Produktywność, zgodność, analityka i telefonia Microsoft 365 E3 $39,00 $30,45 Produktywność, Windows, tożsamość i urządzenia Microsoft 365 E5 $60,00 $51,45 Zaawansowane bezpieczeństwo i zgodność Microsoft 365 F1 $3,00 $2,50 Lekki wariant Frontline Microsoft 365 F3 $10,00 $8,93 Produktywność dla pracowników Frontline Wariant „bez Teams” jest osobnym SKU, a nie rabatem, który można włączyć bez konsekwencji. Jeżeli organizacja potrzebuje spotkań, czatu i współpracy w Teams, może być konieczny zakup osobnej licencji. Wycena powinna więc wskazywać pełną nazwę SKU, okres zobowiązania, harmonogram płatności i cenę odnowienia. Zmianom cen towarzyszy rozszerzenie wybranych pakietów. Business Basic i Standard otrzymują m.in. większą pojemność poczty, ochronę adresów URL w momencie kliknięcia oraz ulepszenia Copilot Chat. Microsoft 365 E3 zyskuje Defender for Office 365 Plan 1 i dodatkowe funkcje Intune. W E5 pojawiają się kolejne zaawansowane narzędzia Intune oraz wartość związana z Security Copilot. Funkcje są wdrażane etapami, dlatego ich dostępność należy sprawdzić w konkretnym środowisku. Jak rozumieć nazwy planów Microsoft 365? Office 365 i Microsoft 365 nie są synonimami. Office 365 E1, E3 i E5 koncentruje się na aplikacjach i usługach produktywności. Microsoft 365 E3 i E5 obejmuje warstwę Office 365, a dodatkowo prawa do Windows Enterprise oraz szersze funkcje zarządzania tożsamością, urządzeniami i bezpieczeństwem. W tym zestawieniu nie ma standardowego komercyjnego planu „Microsoft 365 E1” – chmurowym planem produktywności jest Office 365 E1. Rodzina Dla kogo Limit użytkowników Typowe zastosowanie Microsoft 365 Business Małe i średnie organizacje Do 300 licencji z rodziny Business w dzierżawie Pracownicy biurowi i operacyjni Office 365 Enterprise Firmy potrzebujące usług produktywności w skali enterprise Bez limitu 300 użytkowników Business Poczta, współpraca i aplikacje Office Microsoft 365 Enterprise Organizacje łączące produktywność, Windows, bezpieczeństwo i zgodność Skala enterprise Zarządzani pracownicy wiedzy Microsoft 365 Frontline Pracownicy obsługi, produkcji, logistyki i pracy zmianowej Skala enterprise; obowiązują kryteria kwalifikacji Handel, zakłady, magazyny i praca terenowa Microsoft 365 Copilot Warstwa AI na kwalifikującej się licencji bazowej Zależnie od SKU; Copilot Business do 300 osób Wybrane procesy pracy z wiedzą Porównanie planów Microsoft 365 Business Plany Business można łączyć w ramach jednego środowiska. Przykładowo Business Premium może trafić do osób korzystających z zarządzanych urządzeń, Standard do wybranych stanowisk o niższym ryzyku, a Basic do użytkowników pracujących głównie w przeglądarce.Warunkiem jest świadome przypisanie usług potrzebnych każdej roli. Plan Produktywność Bezpieczeństwo i zarządzanie Najlepsze zastosowanie / ograniczenie Business Basic $7. Aplikacje webowe i mobilne, poczta firmowa, OneDrive, SharePoint oraz Teams w odpowiednim SKU. Podstawowe mechanizmy; bez Intune i Defender for Business. Praca w przeglądarce. Brak desktopowego Office i limit 300 użytkowników. Business Standard $14. Funkcje Basic oraz desktopowe aplikacje Office. Podstawowe mechanizmy; brak zintegrowanego pakietu zarządzania urządzeniami i ochrony punktów końcowych. Typowy pracownik biurowy, jeśli bezpieczeństwo zapewnia inne rozwiązanie. Business Premium $22. Aplikacje desktopowe, webowe i mobilne, poczta i współpraca. Intune, Entra ID P1, Defender for Business i funkcje ochrony informacji. Organizacja stawiająca na bezpieczeństwo; do 300 użytkowników. Apps for Business $10. Desktopowe aplikacje Office oraz 1 TB OneDrive. Nie jest kompletnym pakietem poczty, współpracy i bezpieczeństwa. Użytkownicy mający pocztę i współpracę na innej platformie. Microsoft 365 Business Basic Business Basic jest najtańszym kompletnym planem Business w tym zestawieniu. Obejmuje firmową pocztę Exchange Online, OneDrive, SharePoint oraz webowe i mobilne wersje Worda, Excela, PowerPointa i Outlooka. Wariant z Teams dodaje spotkania, czat i współpracę zespołową. Plan pasuje do start-upów, współpracowników zewnętrznych i osób pracujących głównie w przeglądarce. Ograniczenie nie sprowadza się jednak wyłącznie do braku desktopowego Worda. Basic nie zawiera zintegrowanego zarządzania urządzeniami i ochrony punktów końcowych znanych z Business Premium. Jeżeli firma korzysta z niezarządzanych laptopów lub przetwarza wrażliwe dane klientów, przed zakupem należy doliczyć koszt brakujących zabezpieczeń. Praktyczna rekomendacja: zwykle od 1 do 100 użytkowników o prostych potrzebach, przy formalnym limicie 300 licencji Business. Microsoft 365 Business Standard Business Standard jest naturalnym wyborem dla osób, które codziennie tworzą dokumenty, prezentacje i arkusze. Do usług Basic dodaje desktopowe wersje Worda, Excela, PowerPointa i Outlooka. Dobrze sprawdza się w biurach liczących 20-50 osób, jeżeli ochrona urządzeń i zarządzanie dostępem są już zapewniane przez inne rozwiązania. Problem pojawia się wtedy, gdy firma zakłada, że każdy plan Microsoft 365 automatycznie obejmuje pełny pakiet zabezpieczeń Microsoft. Standard nie zapewnia Intune, Entra ID P1 ani Defender for Business w zakresie Business Premium. Jeżeli wymagane są dostęp warunkowy, centralne zarządzanie urządzeniami i wykrywanie zagrożeń na punktach końcowych, Premium może okazać się prostszy i tańszy niż zestaw osobnych produktów. Microsoft 365 Business Premium Business Premium łączy produktywność Standard z mechanizmami, których coraz częściej wymagają klienci, ubezpieczyciele i audytorzy. Microsoft Intune zarządza urządzeniami firmowymi i mobilnymi, Microsoft Entra ID P1 umożliwia stosowanie dostępu warunkowego, a Defender for Business zapewnia ochronę punktów końcowych, wykrywanie zagrożeń i reakcję na incydenty. To zazwyczaj najlepszy punkt wyjścia dla firmy świadczącej usługi profesjonalne, dostawcy sektora medycznego lub organizacji pracującej z poufnymi danymi. Licencja nie zastępuje konfiguracji, monitoringu i procedur bezpieczeństwa, a jej granicą handlową pozostaje 300 użytkowników. Praktyczna rekomendacja: 20-300 użytkowników albo mniejsze firmy o podwyższonym ryzyku. Microsoft 365 Apps for Business Apps for Business to subskrypcja aplikacji, a nie „Business Standard bez spotkań”. Obejmuje desktopowy pakiet Office i OneDrive, lecz nie zawiera firmowej skrzynki Exchange Online ani kompletnego zestawu współpracy i bezpieczeństwa. Ma sens, gdy poczta i komunikacja są dostarczane przez inną platformę lub gdy wybrany pracownik potrzebuje lokalnego Office, ale nie całego pakietu Microsoft 365. Plan traci atrakcyjność, gdy oddzielnie dokupuje się pocztę, Teams, zabezpieczenia i zarządzanie tożsamością. Należy również pamiętać o limicie 300 użytkowników w rodzinie Business i sprawdzić kwalifikację konkretnego SKU do Copilota. Business Standard czy Business Premium? Kryterium Business Standard Business Premium Desktopowe aplikacje Office Tak Tak Exchange, OneDrive i SharePoint Tak Tak Microsoft Intune Nie Tak Entra ID P1 i dostęp warunkowy Nie jako uprawnienie pakietu Tak Defender for Business Nie Tak Najlepszy wybór, gdy Bezpieczeństwo i urządzenia są obsługiwane poza pakietem Firma chce spójnego pakietu produktywności i zabezpieczeń Cena katalogowa z Teams $14 $22 Różnica 8 dolarów miesięcznie oznacza 96 dolarów rocznie na użytkownika. Właściwe pytanie nie brzmi więc: „czy Premium jest o 57% droższy?”, lecz: „czy równoważne zarządzanie tożsamością, urządzeniami i punktami końcowymi zapewnimy za mniej niż 96 dolarów rocznie, łącznie z obsługą administracyjną?”. Plany Business a plany Enterprise Business Premium nie jest z definicji „gorszą” wersją Enterprise. Dla 200-osobowej firmy może być bardzo mocnym pakietem. Enterprise staje się konieczny, gdy organizacja przekracza limit 300 użytkowników, potrzebuje praw do Windows Enterprise, zaawansowanych funkcji Purview, Defender lub Entra albo działa w skali wymagającej złożonych umów i globalnego zarządzania. Wybierz Business, gdy… Wybierz Enterprise, gdy… Środowisko pozostanie poniżej limitu 300 użytkowników Business. Organizacja przekroczy limit 300 użytkowników. Business Premium obejmuje wymagane mechanizmy bezpieczeństwa. Potrzebne są prawa i funkcje bezpieczeństwa, zgodności lub Windows z E3/E5. Firma oczekuje zwartego i prostego pakietu dla MŚP. Kluczowe są globalne zarządzanie, umowy enterprise i złożone role. Zaawansowane eDiscovery, zarządzanie ryzykiem i analityka nie są podstawowym wymaganiem. Zaawansowane Purview, Entra ID P2, Defender lub Power BI uzasadniają E5. Plany Enterprise: Office 365 E1 oraz Microsoft 365 E3 i E5 W tej części zestawiamy plany, które często trafiają do jednego zapytania ofertowego, mimo że należą do różnych rodzin. Office 365 E1 jest planem produktywności w chmurze. Microsoft 365 E3 i E5 są szerszymi pakietami. Jeżeli oferta dotyczy Office 365 E3 lub E5, trzeba sprawdzić, czy zawiera Windows Enterprise, Intune oraz pełną warstwę zarządzania tożsamością i bezpieczeństwem – sama litera poziomu nie przesądza o zakresie. Office 365 E1 Office 365 E1 obejmuje pocztę klasy enterprise, SharePoint, OneDrive oraz webowe i mobilne wersje aplikacji Office, a w odpowiednim wariancie także Teams. Nie zawiera pełnych aplikacji desktopowych. Może służyć użytkownikom pracującym w przeglądarce, wybranym kontraktorom lub lekkim pracownikom informacyjnym, o ile Windows, urządzenia i zabezpieczenia są licencjonowane osobno. Niska cena może jednak prowadzić do rozdrobnienia stosu technologicznego. Microsoft 365 E3 Microsoft 365 E3 jest podstawowym pakietem dla zarządzanych pracowników wiedzy w dużych organizacjach. Łączy desktopowe, webowe i mobilne aplikacje z Exchange, SharePoint i OneDrive, a następnie dodaje Windows Enterprise, Microsoft Intune, Microsoft Entra ID P1 oraz bazowe funkcje bezpieczeństwa i zgodności. Rozszerzenia z 2026 roku, w tym Defender for Office 365 Plan 1 i dodatkowe narzędzia Intune, wzmacniają jego wartość dla IT. E3 sprawdza się jako standard enterprise, gdy organizacja potrzebuje spójnego zarządzania urządzeniami i tożsamością, ale nie każdy użytkownik wymaga pełnego zestawu E5. Jest też częstą licencją bazową dla dodatku Microsoft 365 Copilot za 30 dolarów. Microsoft 365 E5 Microsoft 365 E5 rozszerza E3 o zaawansowane funkcje tożsamości, bezpieczeństwa, zgodności, analityki i telefonii. Obejmuje m.in. możliwości Entra ID P2 związane z dostępem opartym na ryzyku i Privileged Identity Management, szerszy pakiet Microsoft Defender, zaawansowane Microsoft Purview, Power BI Pro oraz Teams Phone Standard w odpowiednich wariantach. Plany taryfowe i część usług telefonicznych pozostają dodatkowo płatne. E5 ma największy sens wtedy, gdy jego funkcje zastępują kilka osobnych produktów lub odpowiadają na konkretne wymagania regulacyjne. Nie trzeba przypisywać go wszystkim tylko dlatego, że firma jest duża. Częstym modelem jest E3 dla większości pracowników oraz E5 dla administratorów, kierownictwa, zespołów prawnych, bezpieczeństwa i ról wysokiego ryzyka. Microsoft 365 E3 czy E5? Obszar Microsoft 365 E3 Microsoft 365 E5 Cena z Teams w 2026 r. $39 $60 Aplikacje desktopowe i usługi chmurowe Tak Tak Windows Enterprise, Intune i Entra ID P1 Tak Tak Zaawansowana tożsamość oparta na ryzyku / PIM Ograniczona względem E5 Możliwości Entra ID P2 Ochrona przed zagrożeniami Mocna podstawa, rozszerzona w 2026 r. Szerszy pakiet Defender Zgodność Podstawowe Purview, audyt i ochrona informacji Zaawansowane Purview, eDiscovery, audyt i ryzyko Analityka i telefonia Bez pełnego pakietu E5 Power BI Pro i Teams Phone Standard w odpowiednim SKU Najlepsze zastosowanie Standard dla zarządzanej organizacji Role regulowane i wysokiego ryzyka Różnica 21 dolarów miesięcznie to 252 dolary rocznie na użytkownika. Dobra argumentacja biznesowa dla E5 powinna przypisać każde wymagane zabezpieczenie do konkretnego uprawnienia, wskazać rozwiązania możliwe do wycofania i ograniczyć E5 do ról, które rzeczywiście wykorzystują jego możliwości. Microsoft 365 Frontline: F1 czy F3? Licencje Frontline są przeznaczone dla osób, których podstawową pracą jest obsługa klienta, produkcja, logistyka, praca terenowa lub praca zmianowa. Nie powinny być traktowane jako tańszy zamiennik licencji pracownika biurowego. Microsoft stosuje kryteria kwalifikacji i zasady używania urządzeń, dlatego role powinny zostać opisane przed zakupem. Plan Do czego służy Główne ograniczenia i decyzja Microsoft 365 F1 – $3 Lekka komunikacja, tożsamość, dostęp, doświadczenia webowe i mobilne oraz podstawowe zarządzanie.Obejmuje fundament Entra ID P1 i Intune. Brak pełnego desktopowego Office. Funkcje skrzynki i usług są ograniczone; należy sprawdzić konkretny proces. Microsoft 365 F3 – $10 Szersza produktywność Frontline, prawa do Windows i zarządzania oraz obsługa współdzielonych urządzeń. Nadal nie jest to E3 i nie zawiera pełnych aplikacji desktopowych.Trzeba potwierdzić pamięć, pocztę, urządzenia i aplikacje. F1 pasuje do ról komunikacyjnych o bardzo lekkich potrzebach tworzenia treści. F3 jest lepszy, gdy pracownicy korzystają z zarządzanych urządzeń współdzielonych, szerszych aplikacji i cyfrowych procesów. Osoby regularnie tworzące złożone dokumenty lub potrzebujące pełnego profilu pracownika wiedzy powinny korzystać z E3 albo odpowiedniego planu Business. Microsoft 365 Apps a pełny pakiet Potrzeba Apps for Business Business Standard Microsoft 365 E3 Desktopowy Word, Excel, PowerPoint i Outlook Tak Tak Tak Firmowa skrzynka pocztowa Nie Tak Tak SharePoint i pełny pakiet współpracy Nie / tylko wybrane usługi aplikacyjne Tak Tak Zintegrowane zarządzanie urządzeniami i tożsamością Nie Nie Tak Prawa do Windows Enterprise Nie Nie Tak Limit użytkowników 300 w rodzinie Business 300 w rodzinie Business Skala enterprise Najlepsze zastosowanie Office obok innej platformy Pełna produktywność MŚP Zarządzana organizacja enterprise Macierz bezpieczeństwa i zgodności Słowo „zawarte” nie oznacza „skonfigurowane”. Każdy plan wymaga bezpiecznych ustawień, właścicieli procesów, monitoringu, decyzji dotyczących retencji i szkolenia użytkowników. Poniższa tabela jest przeglądem zakupowym, a nie zamiennikiem szczegółowych opisów usług i warunków licencyjnych Microsoft. Plan Tożsamość i dostęp Urządzenia i punkty końcowe Ochrona przed zagrożeniami Zgodność i ład danych Business Basic / Standard Podstawowa tożsamość i MFA Bez Intune Ochrona usług; od 2026 r. ochrona URL Podstawowe mechanizmy M365 Business Premium Entra ID P1 i dostęp warunkowy Intune i Defender for Business Ochrona, wykrywanie i reakcja dla MŚP Ochrona informacji dla MŚP Office 365 E1 Chmurowa tożsamość podstawowa Bez szerokiego pakietu zarządzania Podstawowa ochrona usług Podstawowa zgodność chmurowa Microsoft 365 E3 Entra ID P1 Intune i Windows Enterprise Podstawa enterprise; Defender for Office P1 od 2026 r. Podstawowe Purview, audyt i ochrona informacji Microsoft 365 E5 Entra ID P2 i zaawansowana tożsamość Zaawansowane zarządzanie enterprise Szerszy pakiet Defender Zaawansowane Purview, eDiscovery, audyt i ryzyko Microsoft 365 F1/F3 Entra ID P1 Intune; F3 dla szerszych scenariuszy urządzeń Podstawa Frontline; możliwe dodatki Poziom bazowy; wymagania regulacyjne do weryfikacji Licencjonowanie Microsoft 365 Copilot w 2026 roku Model Copilota składa się z trzech warstw: Copilot Chat dostępnego w kwalifikujących się subskrypcjach, płatnej licencji Microsoft 365 Copilot dodającej kontekst pracy i integrację z aplikacjami oraz kwalifikującej się licencji bazowej. Pominięcie jednej z tych warstw jest najczęstszą przyczyną błędnego budżetu. Opcja AI Cena i kwalifikacja Co zapewnia Najlepsze zastosowanie Microsoft 365 Copilot Chat Bez dodatkowej opłaty w kwalifikujących się planach. Agenci mogą generować koszty użycia. Bezpieczny czat AI, głównie oparty na sieci; może pracować na wskazanych lub przesłanych treściach. Szeroka warstwa podstawowa dla okazjonalnego użycia AI. Microsoft 365 Copilot Business $21 katalogowo; promocja w 2026 r. może wynosić $18.Plany Business, do 300 osób. Copilot oparty na danych pracy w aplikacjach Microsoft 365, z wykorzystaniem Microsoft Graph i Work IQ w granicach uprawnień. Wybrane role wiedzy w MŚP. Microsoft 365 Copilot – enterprise $30 za użytkownika miesięcznie przy zobowiązaniu rocznym.Wymaga licencji bazowej. Kontekst pracy w Wordzie, Excelu, PowerPoincie, Outlooku, Teams i innych obsługiwanych usługach. Środowiska Enterprise, Office 365 i Frontline. Plan Business z Copilotem Standard z Copilotem: $23,50; Premium z Copilotem: $32.Do 300 osób. Bazowy plan Business i Copilot w jednym SKU. Często taniej niż dwa osobne produkty. Microsoft 365 E7 $99 z Teams lub $90,45 bez Teams. Microsoft 365 E5, Microsoft 365 Copilot, Agent 365 i Entra Suite. Firmy potrzebujące całego szerszego pakietu, nie tylko Copilota. Copilot Chat a płatny Microsoft 365 Copilot Funkcja Copilot Chat Płatny Microsoft 365 Copilot Dodatkowa licencja na użytkownika Nie, przy kwalifikującej się subskrypcji Tak, chyba że Copilot jest w pakiecie Domyślny kontekst Głównie internet i treść dostarczona przez użytkownika Dane służbowe i internet, zgodnie z uprawnieniami Microsoft Graph / Work IQ Zakres ograniczony względem płatnej wersji Podstawa doświadczenia opartego na pracy Integracja z aplikacjami Wybrane funkcje czatu i agentów Głębsza integracja z Wordem, Excelem, PowerPointem, Outlookiem i Teams Agenci Dostępni; użycie danych dzierżawy może być rozliczane Szerszy zakres w cenie; część scenariuszy nadal może być mierzona Rola we wdrożeniu Kontrolowana warstwa podstawowa dla uprawnionych osób Wybrane role z mierzalnym przypadkiem użycia Copilot nie otrzymuje nieograniczonego dostępu do środowiska. Microsoft deklaruje, że korzysta wyłącznie z informacji, do których zalogowany użytkownik ma uprawnienia, a prompty, odpowiedzi i dane Microsoft Graph nie służą do trenowania modeli bazowych. Nie zwalnia to z porządkowania uprawnień. Nadmiernie udostępniona witryna SharePoint pozostaje nadmiernie udostępniona, a Copilot może jedynie ułatwić wykorzystanie istniejącego dostępu. Jak obliczyć rzeczywisty koszt? Rzetelny budżet obejmuje cztery pozycje: licencję bazową Microsoft 365, licencję Copilot lub pakiet, wpływ okresu zobowiązania i sposobu płatności oraz wdrożenie. Wdrożenie oznacza ocenę środowiska, porządkowanie uprawnień, migrację, konfigurację urządzeń, szkolenie, zarządzanie adopcją i wsparcie. Nie są to opłaty licencyjne Microsoft, ale bez nich rachunek biznesowy będzie niepełny. Scenariusz Miesięczne wyliczenie katalogowe Koszt roczny 50 osób: Business Premium 50 x $22 $13 200 50 osób: Business Premium z Copilotem 50 x $32 $19 200 100 osób: Business Standard + osobny Copilot Business 100 x ($14 + $21) $42 000 100 osób: Business Standard z Copilotem 100 x $23,50 $28 200 500 osób: Microsoft 365 E3 500 x $39 $234 000 500 osób na E3; Copilot dla 100 wybranych (500 x $39) + (100 x $30) $270 000 500 osób na E3; Copilot dla wszystkich 500 x ($39 + $30) $414 000 Przykład 100 użytkowników pokazuje, dlaczego trzeba porównywać konkretne SKU, a nie tylko ceny dodatków. Pakiet Business Standard z Copilotem może być wyraźnie tańszy niż dwa oddzielne produkty. Promocje i pakiety zmieniają się, dlatego każda oferta powinna zawierać datę końca promocji oraz cenę odnowienia. Jaka licencja pasuje do wielkości i profilu firmy? Organizacja Rekomendowany punkt wyjścia Dlaczego / co sprawdzić Mikrofirma: 1-10 osób Basic dla pracy w przeglądarce, Standard dla desktopowego Office, Premium przy wyższym ryzyku. Nie kupować jednego planu dla wszystkich z przyzwyczajenia.Doliczyć zewnętrzne zabezpieczenia. Mała firma: 20-50 osób Business Premium jako bezpieczny standard; uzasadnione wyjątki na Standard lub Basic. Dobry balans produktywności i kontroli.Copilot dla wybranych ról. Średnia firma: 100-300 osób Business Premium lub zestaw planów Business; wcześnie zaplanować wyjście poza 300. Uniknąć pośpiesznej zmiany licencjonowania przy przekroczeniu limitu. Enterprise: ponad 300 osób Microsoft 365 E3 jako standard, E5 dla ról wymagających zaawansowanych kontroli, F1/F3 dla Frontline. Segmentacja według roli i ryzyka. Organizacja regulowana E3 z dodatkami albo E5 dla ról podlegających zaawansowanym wymaganiom. Przełożyć regulacje na konkretne mechanizmy; nie kupować E5 wszystkim automatycznie. MŚP stawiające na bezpieczeństwo Business Premium. Intune, Entra ID P1 i Defender for Business tworzą spójną podstawę. Sześć praktycznych scenariuszy licencyjnych 1. Siedmioosobowa firma doradcza Pięciu konsultantów potrzebuje desktopowego Office, a dwóch współpracowników działa w przeglądarce. Standard można przypisać konsultantom, a Basic współpracownikom, jeśli urządzenia są chronione w inny sposób. Gdy umowy z klientami wymagają dostępu warunkowego i zarządzanych laptopów, prostszym standardem będzie Premium. Copilot powinien trafić do osób regularnie przygotowujących oferty i podsumowania. 2. Firma usług profesjonalnych zatrudniająca 35 osób Business Premium jest zwykle dobrym fundamentem, ponieważ poufne dane, praca zdalna i wymagania ubezpieczeniowe zwiększają znaczenie tożsamości i urządzeń. Warto porównać pakiet Premium z Copilotem dla partnerów i sprzedaży z osobnymi licencjami Copilot Business. 3. Rosnąca firma zatrudniająca 220 osób Można utrzymać opłacalny zestaw Business: Premium dla zarządzanych pracowników, Standard dla konkretnych ról o niższym ryzyku i Basic dla kont pracujących w przeglądarce. Trzeba monitorować liczbę licencji i zaprojektować przejście do E3 przed osiągnięciem limitu 300. Pilot Copilota dla 20-40 osób będzie bezpieczniejszy niż zakup dla całej firmy. 4. Przedsiębiorstwo zatrudniające 2000 osób E3 może być bazą dla pracowników wiedzy, E5 dla administratorów, prawników, bezpieczeństwa, kadry zarządzającej i ról regulowanych, a F1/F3 dla kwalifikujących się pracowników pierwszej linii. Licencje Copilot należy przydzielać według powtarzalnych procesów i regularnie odbierać nieaktywnym użytkownikom. 5. Organizacja regulowana Punktem wyjścia są wymagania: ryzyko tożsamości, dostęp uprzywilejowany, klasyfikacja, retencja, audyt, eDiscovery, ryzyko wewnętrzne i reakcja na incydenty. E5 może skonsolidować potrzebne narzędzia, ale nie powinien być przypisywany wszystkim bez mapy mechanizmów do licencji. Gotowość na Copilota obejmuje uprawnienia, etykiety i repozytoria wysokiego ryzyka. 6. Zakład produkcyjny ze współdzielonymi urządzeniami F3 często jest właściwą podstawą dla brygadzistów i pracowników korzystających z zarządzanych urządzeń współdzielonych. F1 może wystarczyć do prostych ról komunikacyjnych. Finanse, inżynieria i kierownictwo powinny pozostać na E3 lub odpowiednich planach Business. Frontline nie należy wybierać wyłącznie dlatego, że kosztuje mniej. Czy można łączyć różne licencje Microsoft 365? Tak. W jednym środowisku można łączyć plany Business, Enterprise i Frontline oraz przypisywać płatnego Copilota tylko wybranym osobom, o ile spełnione są warunki techniczne i handlowe. Taki model działa najlepiej, gdy każda rola ma opisany profil usług: aplikacje desktopowe, skrzynkę, przestrzeń danych, spotkania, typ urządzenia, poziom ryzyka, wrażliwość informacji i przypadek użycia AI. Przed zmianą licencji trzeba sprawdzić zależności. Odebranie pakietu może wyłączyć skrzynkę, aktywację aplikacji, prawa do Windows, polityki Intune lub funkcje zgodności. Zachowanie danych i działanie usług powinny zostać zweryfikowane przed zmianą, a nie dopiero po zgłoszeniu użytkownika. Praktyczny proces wyboru i wdrożenia Zinwentaryzuj użytkowników i urządzenia. Grupuj ludzi według rzeczywistego sposobu pracy, a nie tylko nazw działów. Zdefiniuj obowiązkowe zabezpieczenia. Opisz wymagania dotyczące tożsamości, urządzeń, ochrony danych, retencji, audytu i eDiscovery. Porównaj kompletne stosy. Do ceny pakietu dodaj niezbędne rozszerzenia, narzędzia zewnętrzne i koszt administracji. Sprawdź wariant Teams i zasady rozliczeń. Potwierdź SKU, zobowiązanie, częstotliwość płatności, walutę, promocję i odnowienie. Przetestuj Copilota na procesach. Wybierz od trzech do pięciu mierzalnych zastosowań, np. podsumowania spotkań, oferty, triage poczty czy cykliczne raporty. Mierz i przenoś licencje. Obserwuj aktywnych użytkowników, powtarzalność użycia, czas wykonania, jakość i poprawki. Najczęstsze błędy licencyjne Porównywanie Office 365 E3 z Microsoft 365 E3 tak, jakby zakres obu produktów był taki sam. Zakup Business Standard, a następnie odkrycie, że firma oczekiwała Intune, dostępu warunkowego i ochrony punktów końcowych. Traktowanie F1 i F3 jako tanich licencji dla osób, które nie spełniają kryteriów pracownika Frontline. Założenie, że cena wariantu bez Teams jest bezpośrednio porównywalna z pełnym SKU bez analizy potrzeb współpracy. Mnożenie ceny Copilota przez liczbę pracowników bez doliczenia licencji bazowej lub sprawdzenia tańszego pakietu. Przekonanie, że Copilot naprawi błędne uprawnienia. Copilot korzysta z dostępu, który użytkownik już posiada. Traktowanie ceny promocyjnej jako stałego kosztu odnowienia. Licencjonowanie całej organizacji przed zmierzeniem małego pilota opartego na rolach. TTMS – zaufany partner Microsoft 365 Licencjonowanie Microsoft 365 najłatwiej zoptymalizować wtedy, gdy decyzje handlowe, architektura techniczna, bezpieczeństwo i adopcja są traktowane jako jeden program. TTMS wspiera organizacje w całym cyklu Microsoft 365: od oceny środowiska i racjonalizacji licencji, przez migrację i przygotowanie zabezpieczeń, po szkolenia, rozwiązania Teams oraz automatyzację procesów za pomocą Power Automate i Power Apps. Doświadczony partner wnosi wartość jeszcze przed złożeniem zamówienia. TTMS może pomóc przypisać role do planów Business, Enterprise i Frontline, porównać pakiety z dodatkami, wykryć luki licencyjne, ocenić gotowość danych i uprawnień do Copilota oraz zaplanować etapowe wdrożenie z mierzalnymi rezultatami. Pozwala to ograniczyć zarówno nadmierne wydatki, jak i ryzyko wyboru planu, który dobrze wygląda w cenniku, lecz nie pokrywa potrzeb organizacji. Jeśli chcesz przeanalizować obecny zestaw licencji, zaplanować migrację lub przygotować pilotaż Microsoft 365 Copilot, porozmawiaj z zespołem Microsoft 365 w TTMS o kolejnym praktycznym kroku dla Twojej organizacji. Źródła i nota weryfikacyjna Ceny i zasady licencjonowania zweryfikowano w oficjalnych źródłach Microsoft 6 sierpnia 2026 roku. Microsoft może zmieniać produkty, promocje i ceny lokalne. Szczegółowa dostępność funkcji podlega przypisom i warunkom technicznym, dlatego przed zakupem należy potwierdzić konkretny SKU w centrum administracyjnym Microsoft 365, aktualnych warunkach produktowych lub ofercie partnera. Aktualizacja cen i pakietów Microsoft 365 od 1 lipca 2026 r. FAQ dotyczące aktualizacji cen i pakietów Opcje planów Microsoft 365 i Office 365 Opis usług platformy Microsoft 365 Porównanie planów Business Porównanie planów Enterprise Porównanie planów Frontline F1 i F3 Opis usługi Microsoft Entra Plany i ceny Microsoft 365 Copilot Opcje licencji Microsoft 365 Copilot Architektura i uprawnienia Microsoft 365 Copilot Raport użycia Microsoft 365 Copilot Usługi Microsoft 365 w TTMS Najczęściej zadawane pytania o licencje Microsoft 365 i Copilot Jaka jest najtańsza licencja Microsoft 365 dla firmy? Wśród pełnych planów Business najtańszy jest Business Basic: 7 dolarów za użytkownika miesięcznie w wariancie z Teams według amerykańskiej ceny katalogowej z lipca 2026 roku. Apps for Business kosztuje 10 dolarów, ale nie obejmuje firmowej skrzynki ani pełnego pakietu współpracy. Najtańszy właściwy plan zależy od potrzeby aplikacji desktopowych, poczty, urządzeń i bezpieczeństwa. Czym różni się Microsoft 365 Business Premium od Microsoft 365 E3? Business Premium to zintegrowany pakiet produktywności i bezpieczeństwa dla organizacji do 300 użytkowników Business. Microsoft 365 E3 jest pakietem w skali enterprise, obejmującym m.in. Windows Enterprise, Intune, Entra ID P1 oraz szersze prawa i mechanizmy zarządzania. Wybór zależy od skali i wymaganych uprawnień, a nie wyłącznie od rozmiaru firmy. Czy Microsoft 365 Copilot jest zawarty w Microsoft 365? Copilot Chat jest dostępny bez dodatkowej opłaty w kwalifikujących się subskrypcjach. Pełny Microsoft 365 Copilot zwykle wymaga płatnego dodatku, chyba że znajduje się w pakiecie, np. Business Standard z Copilotem, Business Premium z Copilotem lub Microsoft 365 E7. Który plan Microsoft 365 jest najlepszy dla firmy zatrudniającej 50 osób? Business Premium jest często najlepszym punktem wyjścia, ponieważ łączy aplikacje, pocztę, współpracę, Intune, Entra ID P1 i Defender for Business. Firma posiadająca dojrzałe zewnętrzne zabezpieczenia może wybrać zestaw Standard i Basic. Odpowiedź powinna wynikać z wymagań dotyczących urządzeń i kontroli. Czy firma może łączyć różne licencje Microsoft 365? Tak. Można mieszać plany Basic, Standard, Premium, Enterprise i Frontline oraz przypisywać płatnego Copilota tylko wybranym osobom. Każdy użytkownik musi mieć usługi i prawa wymagane przez jego rolę, a przed odebraniem licencji trzeba sprawdzić zależności. Kiedy firma powinna przejść z Business na Enterprise? Przejście warto zaplanować, gdy środowisko zbliża się do limitu 300 użytkowników Business albo gdy potrzebne są prawa do Windows Enterprise, zaawansowana zgodność, bezpieczeństwo, tożsamość lub zarządzanie globalne. Nie należy czekać z projektem do użytkownika numer 301. Czy Business Basic zawiera desktopowego Worda i Excela? Nie. Business Basic obejmuje wersje webowe i mobilne. Desktopowe aplikacje są dostępne w Business Standard i Business Premium. Czym różni się Office 365 E1 od Microsoft 365 E3? Office 365 E1 jest przede wszystkim pakietem produktywności w chmurze, z aplikacjami webowymi i mobilnymi. Microsoft 365 E3 dodaje desktopowe aplikacje, Windows Enterprise, Intune, Entra ID P1 oraz szersze bezpieczeństwo i zgodność. To różne rodziny produktów. Czy Microsoft 365 E5 jest wart dopłaty względem E3? Tak, jeżeli zaawansowane funkcje Entra, Defender, Purview, analityki lub telefonii zastępują inne produkty albo spełniają konkretne wymagania ryzyka i regulacji. Wiele firm przypisuje E5 tylko wybranym rolom wysokiego ryzyka, a E3 pozostawia jako standard. Czym różni się Microsoft 365 F1 od F3? F1 jest lżejszą licencją Frontline dla ról komunikacyjnych. F3 obsługuje szersze scenariusze produktywności, Windows i zarządzanych urządzeń. Żadna z nich nie powinna być traktowana jako tani zamiennik E3. Czy Apps for Business może zastąpić Business Standard? Tylko wtedy, gdy użytkownik nie potrzebuje skrzynki Exchange Online i pełnego zestawu współpracy Microsoft 365. Apps for Business ma sens, gdy desktopowy Office i OneDrive działają obok innej platformy poczty i komunikacji. Ile kosztuje płatny Microsoft 365 Copilot? Dodatek Microsoft 365 Copilot dla enterprise kosztuje 30 dolarów za użytkownika miesięcznie przy zobowiązaniu rocznym. Copilot Business ma cenę katalogową 21 dolarów i był oferowany promocyjnie za 18 dolarów. W lipcu 2026 roku Business Standard z Copilotem kosztował 23,50 dolara, a Business Premium z Copilotem 32 dolary. Należy sprawdzić aktualną cenę lokalną i odnowienie. Czym różni się Copilot Chat od płatnego Microsoft 365 Copilot? Copilot Chat jest głównie bezpiecznym czatem opartym na internecie, dostępnym z kwalifikującymi się subskrypcjami. Płatny Copilot dodaje kontekst danych służbowych i głębszą integrację z aplikacjami Microsoft 365, wykorzystując informacje, do których użytkownik ma dostęp przez Microsoft Graph i Work IQ. Czy każdy pracownik potrzebuje płatnej licencji Copilot? Nie. Copilot Chat może być szeroką warstwą podstawową, a płatne licencje powinny trafić do osób z powtarzalnymi zadaniami związanymi z pisaniem, spotkaniami, analizą lub wyszukiwaniem informacji. Copilot i proces przenoszenia niewykorzystanych licencji zwykle zapewniają lepszy zwrot. Czy Copilot wykorzystuje dane firmy do trenowania modeli? Microsoft deklaruje, że prompty, odpowiedzi i dane organizacyjne pobierane przez Microsoft Graph nie są używane do trenowania modeli bazowych Microsoft 365 Copilot. Copilot respektuje jednak istniejące uprawnienia, dlatego nadmierne udostępnienie danych i słaby ład informacyjny trzeba naprawić. Czy subskrypcja roczna jest tańsza od miesięcznej? Zobowiązanie roczne jest zwykle korzystniejsze cenowo od elastycznej umowy miesięcznej, ale miesięczna płatność i miesięczne zobowiązanie to dwie różne rzeczy. W ofercie trzeba sprawdzić okres umowy, częstotliwość płatności, zasady rezygnacji i cenę odnowienia.
Czytaj
NIS2 w farmacji: wymagania, obowiązki i wdrożenie w 2026 roku
Cyberbezpieczeństwo NIS2 w farmacji jest wymogiem odporności operacyjnej, a nie odrębnym projektem IT. Incydent cyberbezpieczeństwa może zatrzymać linię napełniającą, odizolować laboratorium, przerwać łańcuch chłodniczy, naruszyć integralność danych klinicznych albo spowodować niedostępność zwalidowanego systemu. Każdy z tych skutków może wpłynąć na jakość produktu, bezpieczeństwo pacjentów i ciągłość dostaw. Dyrektywa (UE) 2022/2555, określana jako NIS2, ustanawia wspólny unijny poziom odniesienia dla zarządzania ryzykiem cyberbezpieczeństwa, nadzoru kierownictwa i zgłaszania poważnych incydentów. Obowiązki prawne są wdrażane w przepisach krajowych. Organizacja musi więc analizować dyrektywę łącznie z zasadami, progami, procedurami rejestracyjnymi i wytycznymi właściwych organów w każdym państwie członkowskim, w którym podlega regulacji. Ten przewodnik przekłada wymogi prawne na działania i dowody dla producentów farmaceutycznych, firm biotechnologicznych, organizacji prowadzących badania i rozwój produktów leczniczych, kontraktowych organizacji produkcyjnych (CMO), kontraktowych organizacji badawczych (CRO) oraz ich krytycznych dostawców. Wyjaśnia również, gdzie NIS2 należy uzgodnić z GxP, Computerized System Validation (CSV), Computer Software Assurance (CSA), GAMP 5 i istniejącymi procesami zarządzania jakością. Artykuł koncentruje się na wdrożeniu specyficznym dla farmacji. Szczegółowy model dowodowy przedstawia lista kontrolna dokumentacji i dowodów zgodności NIS2 przygotowana przez TTMS. 1. Dlaczego działalność farmaceutyczna jest priorytetowym celem cyberataków objętym NIS2 NIS2 zalicza wytwarzanie podstawowych substancji farmaceutycznych i preparatów farmaceutycznych do sektora zdrowia w załączniku I. W tej samej kategorii znajdują się podmioty świadczące opiekę zdrowotną, laboratoria referencyjne UE oraz podmioty prowadzące badania i rozwój produktów leczniczych. Klasyfikacja odzwierciedla znaczenie systemowe: zakłócenie może wpłynąć na dostęp do leków i reagowanie w obszarze zdrowia publicznego, a nie wyłącznie na wynik jednej firmy. Obraz zagrożeń uzasadnia takie podejście. ENISA podała, że wśród incydentów dotyczących sektora zdrowia przeanalizowanych w raporcie o krajobrazie zagrożeń z 2024 r. 45% stanowiły ataki ransomware, a 28% naruszenia danych. Odrębny komercyjny zbiór danych odnotował 4198 przypadków ransomware ujawnionych w serwisach przestępczych we wszystkich sektorach w pierwszej połowie 2025 r., czyli o 49% więcej niż w porównywalnym zbiorze z 2024 r. Liczba 4198 nie dotyczy wyłącznie farmacji i nie powinna być przedstawiana jako liczba ataków na organizacje farmaceutyczne lub biotechnologiczne. Farmacja skupia zasoby, które dają napastnikom znaczną przewagę: własność intelektualną, dane kliniczne i dane związane z pacjentami, regulowaną produkcję, cenne partie produktów, logistykę wrażliwą na czas oraz rozbudowaną sieć dostawców. Ta sama platforma tożsamości, warstwa integracyjna lub kanał zdalnego utrzymania może łączyć korporacyjne IT z ERP, MES, LIMS, ELN, EDC i technologią operacyjną (OT). Atakujący nie musi przejąć każdego systemu. Zakłócenie jednej współdzielonej zależności może wystarczyć, aby zatrzymać zwolnienie serii, badania lub dystrybucję. Wpływ biznesowy należy analizować jako łańcuch zależności. Każdy krytyczny produkt lub usługę trzeba powiązać z obiektami, procesami, systemami, danymi, mediami technicznymi, personelem i stronami trzecimi. Należy określić maksymalny tolerowany czas przerwy oraz konsekwencje jakościowe utraty danych lub opóźnionego przeglądu. Taka mapa usług staje się dowodem dla analizy ryzyka, ciągłości działania, priorytetów odtwarzania i decyzji dotyczących łańcucha dostaw. 2. NIS2 w sektorze farmaceutycznym i biotechnologicznym: zakres, klasyfikacja i status prawny organizacji NIS2 rozszerzyła unijny poziom odniesienia dla cyberbezpieczeństwa względem węższego modelu NIS1. Co do zasady obejmuje średnie i duże podmioty rodzajów wymienionych w załączniku I lub II, z uwzględnieniem szczególnych przypadków włączenia i wyłączenia. W farmacji i biotechnologii analiza prawna musi wychodzić od faktycznej działalności podmiotu, a nie od sposobu prezentowania marki. Działalność może obejmować badania i rozwój produktów leczniczych, wytwarzanie API lub produktów gotowych, produkcję wyrobów medycznych, operacje kliniczne, dystrybucję, marketing, usługi cyfrowe albo ich połączenie. W jednej grupie mogą działać podmioty o różnych statusach. Samo określenie CMO lub CRO nie przesądza o objęciu regulacją. Trzeba udokumentować właściwą działalność, wielkość, miejsce prowadzenia działalności, jurysdykcję i ewentualne wyznaczenie na podstawie prawa krajowego. 2.1. Od NIS1 do NIS2: co zmieniło się dla zdrowia i farmacji NIS2 rozszerza zakres sektorowy, ujednolica minimalny zestaw środków zarządzania ryzykiem cyberbezpieczeństwa, ustanawia wieloetapowy model zgłaszania poważnych incydentów oraz wzmacnia nadzór i egzekwowanie. Wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem, nadzorowały ich wdrożenie i odbywały szkolenia. Państwa członkowskie muszą również utrzymywać krajowe strategie cyberbezpieczeństwa i struktury reagowania na incydenty. Rezultatem jest wspólny poziom odniesienia, ale nie identyczna administracja w całej UE. Rejestracja, progi, formularze, właściwe organy, język, oczekiwania audytowe i sankcje wynikają z prawa krajowego. W lipcu 2026 r. Komisja skierowała sprawy Irlandii, Hiszpanii, Francji i Niderlandów do Trybunału Sprawiedliwości z powodu niezgłoszenia pełnej transpozycji. Grupy transgraniczne nadal potrzebują rejestru jurysdykcji i lokalnej weryfikacji prawnej. Istniejący ład GMP i zarządzania jakością może zapewnić strukturę wyjściową. Przegląd zarządzania, kontrola zmian, zarządzanie odchyleniami, CAPA, kwalifikacja dostawców, szkolenia i przeglądy okresowe mają już właścicieli i pozostawiają zapisy. Procesy te należy rozszerzyć na cyberbezpieczeństwo, nie zakładając, że dowody GxP automatycznie potwierdzają zgodność z NIS2. 2.2. Podmiot kluczowy czy ważny? Klasyfikacja przed wyborem zabezpieczeń Zgodnie z art. 3 podmiot z załącznika I, który przekracza pułap dla średniego przedsiębiorstwa, jest co do zasady podmiotem kluczowym. Pozostałe średnie podmioty z załącznika I lub II są zasadniczo podmiotami ważnymi, chyba że przepis szczególny lub krajowe wyznaczenie prowadzi do innego wyniku. Niektóre rodzaje podmiotów są kluczowe niezależnie od wielkości. Mikroprzedsiębiorstwa i małe przedsiębiorstwa są co do zasady wyłączone, jednak art. 2 przewiduje wyjątki związane między innymi z krytycznością. Działalność ograniczona wyłącznie do dystrybucji lub marketingu może znaleźć się poza wymienionymi kategoriami farmaceutycznymi, jeżeli podmiot nie prowadzi objętej działalności i nie został wyznaczony na innej podstawie. Z kolei organizacja prowadząca badania i rozwój produktów leczniczych może być objęta zakresem załącznika I, nawet jeśli nie prowadzi produkcji. Zakres dotyczący wyrobów medycznych także wymaga uważnej analizy właściwej kategorii załącznika; nie każda firma z tego rynku ma ten sam status. Dla każdej osoby prawnej należy przygotować zatwierdzoną analizę zakresu. Powinna obejmować działalność, kod NACE lub równoważną klasyfikację, dane o zatrudnieniu i finansach, miejsca prowadzenia działalności, usługi, przepisy krajowe, zależności grupowe i uzasadnienie wniosku. Trzeba zapisać, kto ją zatwierdził i kiedy wymaga ponownego przeglądu. Jest to pierwszy audytowalny artefakt; folder produktowy ani założenie przyjęte dla całej grupy nie wystarczą. 3. Cztery filary zgodności NIS2 dla organizacji farmaceutycznych Program NIS2 należy oprzeć na czterech powiązanych filarach: zarządzaniu ryzykiem, zgłaszaniu poważnych incydentów, odpowiedzialności kierownictwa i bezpieczeństwie łańcucha dostaw. Każdy wymaga właściciela, procedury i dowodów działania. 3.1. Zarządzanie ryzykiem z art. 21: dziesięć obszarów minimalnych Artykuł 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych opartych na podejściu uwzględniającym wszystkie zagrożenia. Poniższe dziesięć obszarów należy mapować do usług i ryzyk, a nie traktować jako ogólną listę zakupów narzędzi. Obszar art. 21 Priorytet wdrożeniowy w farmacji Typowe dowody audytowe 1. Polityki analizy ryzyka i bezpieczeństwa systemów informacyjnych Powiązanie wpływu na produkt, pacjenta i usługę z systemami IT, OT i GxP Zatwierdzona metodyka, mapa usług, rejestr ryzyka, decyzje o postępowaniu z ryzykiem 2. Obsługa incydentów Koordynacja bezpieczeństwa, jakości, prywatności, prawa, produkcji i komunikacji Plan reagowania, macierz istotności, akta incydentów, raporty po zdarzeniu 3. Ciągłość działania, kopie zapasowe, odtwarzanie awaryjne i zarządzanie kryzysowe Priorytety dla partii, laboratoriów, zwolnienia serii i łańcucha chłodniczego BIA, RTO/RPO, plany odtwarzania, testy przywracania, raporty z ćwiczeń 4. Bezpieczeństwo łańcucha dostaw Ocena zależności od API, CMO, CRO, logistyki, chmury i utrzymania Klasyfikacja dostawców, due diligence, umowy, monitoring, plany wyjścia 5. Bezpieczne nabywanie, rozwój i utrzymanie, w tym obsługa i ujawnianie podatności Powiązanie zmian bezpieczeństwa z utrzymaniem stanu zwalidowanego i kontrolą zmian Wymagania bezpieczeństwa, modele zagrożeń, rejestry podatności, pakiety zmian 6. Ocena skuteczności zabezpieczeń Testowanie projektu, zakresu wdrożenia i wyników operacyjnych Testy kontroli, mierniki, audyty wewnętrzne, CAPA i dowody zamknięcia 7. Podstawowe praktyki cyberhigieny i szkolenia Szkolenia dopasowane do ról, w tym inżynierów, laboratoriów i kierownictwa Programy, frekwencja, ocena kompetencji, wyniki symulacji phishingu lub ćwiczeń 8. Kryptografia i szyfrowanie Ochrona danych i komunikacji wraz z zarządzaniem kluczami i certyfikatami Standard kryptograficzny, rejestr kluczy, monitoring certyfikatów, wyjątki 9. Bezpieczeństwo HR, kontrola dostępu i zarządzanie aktywami Kontrola zatrudnienia i odejść, zmian ról, dostępów uprzywilejowanych i własności systemów Rejestr aktywów, przeglądy dostępów, zapisy PAM, dowody rozdziału obowiązków 10. MFA lub ciągłe uwierzytelnianie i bezpieczna komunikacja Objęcie dostępów zdalnych, działań uprzywilejowanych i usług wystawionych na zewnątrz stosownie do ryzyka Pokrycie MFA, rejestr wyjątków, konfiguracja bezpiecznych kanałów i przeglądy Należy zbudować identyfikowalność wymagań między każdym środkiem NIS2, ryzykiem dla usługi, kontrolą, właścicielem systemu i źródłem dowodu. Istniejące procesy GxP mogą przejąć część zadań. Usuwanie podatności może korzystać z kontroli zmian, testowanie kontroli z przeglądów okresowych i CSA, a szkolenia bezpieczeństwa z kontrolowanego systemu szkoleniowego. Mapowanie musi również ujawniać luki. Zwalidowana aplikacja bez przetestowanego odtwarzania pozostaje ryzykiem dla ciągłości działania. 3.2. Zgłaszanie z art. 23: 24 godziny, 72 godziny i jeden miesiąc Dla poważnego incydentu art. 23 przewiduje zgłaszanie etapowe: wczesne ostrzeżenie bez zbędnej zwłoki i w ciągu 24 godzin od uzyskania wiedzy o incydencie, zgłoszenie incydentu bez zbędnej zwłoki i w ciągu 72 godzin oraz sprawozdanie końcowe nie później niż miesiąc po zgłoszeniu incydentu. Organ może również wymagać sprawozdań pośrednich lub z postępu prac. Jeżeli po miesiącu incydent nadal trwa, sprawozdanie z postępu zastępuje raport końcowy, który składa się w ciągu miesiąca od zakończenia obsługi incydentu. Termin biegnie od uzyskania wiedzy o incydencie, a nie od zakończenia analizy informatyki śledczej. Trzeba wskazać, kto może stwierdzić uzyskanie wiedzy, kto ocenia istotność, kto kontaktuje się z krajowym CSIRT lub właściwym organem oraz kto koordynuje równoległe obowiązki wynikające z RODO, regulacji sektorowych, umów i, gdy ma to zastosowanie, przepisów dotyczących wyrobów medycznych. Należy zachować zarówno decyzję o zgłoszeniu, jak i uzasadnioną decyzję o braku zgłoszenia. Bieżący wgląd w zdarzenia dotyczące tożsamości, sieci, urządzeń końcowych, chmury, ERP, MES, LIMS, ELN, EDC i OT zwiększa szansę dotrzymania terminów. Centralny SIEM może wspierać wykrywanie i odtworzenie chronologii, ale nie dokonuje prawnej oceny istotności. Potrzebny jest proces human-in-the-loop z dyżurnymi uprawnieniami, aktualną listą kontaktów, wcześniej zatwierdzonymi szablonami i rejestrem decyzji. W środowiskach zwalidowanych monitoring należy wdrażać przez zatwierdzoną kontrolę zmian. Pasywny monitoring OT, telemetria sieciowa i kontrolowane przekazywanie logów mogą ograniczyć ingerencję w zasoby produkcyjne. Całą ścieżkę należy przetestować podczas ćwiczenia symulacyjnego: alert, wstępna analiza techniczna, wpływ na jakość, ocena prawna, eskalacja do kierownictwa, zgłoszenie do organu i dalsze działania. 3.3. Artykuł 20: odpowiedzialność kierownictwa i dowody dla zarządu Organy zarządzające muszą zatwierdzać środki z art. 21, nadzorować ich wdrożenie i mogą odpowiadać za naruszenia zgodnie z prawem krajowym. Ich członkowie muszą odbywać szkolenia, a państwa członkowskie powinny zachęcać do regularnych szkoleń pracowników. Dowody powinny potwierdzać świadomy nadzór, a nie jedynie formalną prezentację raz w roku. Zarząd powinien otrzymywać informacje pozwalające podejmować decyzje: najważniejsze ryzyka dla usług, opóźnione działania wobec wysokiego ryzyka, skuteczność zabezpieczeń, poważne incydenty, nieudane testy odtwarzania, ekspozycję na krytycznych dostawców, istotne wyjątki i wymagane inwestycje. Należy zachowywać porządki obrad, materiały, protokoły, zatwierdzenia, zgłoszone zastrzeżenia i działania następcze. Trzeba także dokumentować treść szkoleń, obecność i ocenę skuteczności. Dyrektywa pozwala również właściwym organom, w określonych okolicznościach dotyczących podmiotów kluczowych, wystąpić o czasowe zawieszenie certyfikacji lub zezwolenia oraz czasowy zakaz wykonywania funkcji kierowniczych przez określonych menedżerów wyższego szczebla do czasu usunięcia uchybień. Jest to środek nadzorczy podlegający warunkom, a nie automatyczny osobisty zakaz po każdym incydencie. Nie należy przedstawiać go jako odpowiedzialności karnej. 3.4. Artykuł 21 ust. 2 lit. d: ryzyko API, CMO, CRO i logistyki Dostawców należy powiązać z usługami i produktami, na które mogą wpływać. Zakres powinien obejmować dostawców API i substancji pomocniczych, CMO, CRO, laboratoria badawcze, pakowanie, logistykę łańcucha chłodniczego, platformy chmurowe, usługi zarządzane, producentów sprzętu, zdalne utrzymanie i technologie pochodzące z jednego źródła. Klasyfikacja dostawców powinna uwzględniać wpływ, dostęp, możliwość zastąpienia, koncentrację i czas odtworzenia. Due diligence musi badać dowody właściwe dla usługi: zakres kontroli, historię incydentów, dostęp uprzywilejowany, podwykonawców, obsługę podatności, kopie i odtwarzanie, bezpieczny rozwój, koncentrację geograficzną i możliwość wyjścia. Kwestionariusz jest deklaracją, a certyfikat zyskuje wartość dopiero po sprawdzeniu jego zakresu, wyłączeń i okresu ważności. Umowy powinny określać minimalne zabezpieczenia, czas zgłoszenia incydentu, współpracę, prawa do audytu lub uzyskania zapewnienia, obsługę podatności, warunki podwykonawstwa, zwrot danych, ciągłość i wyjście. Zapisy umowne nie zastępują monitorowania. Należy dokumentować przeglądy, niekorzystne ustalenia, akceptację ryzyka, zabezpieczenia kompensacyjne, właścicieli i terminy wygaśnięcia. 4. Wyzwania cyberbezpieczeństwa specyficzne dla farmacji, których NIS2 nie rozwiązuje wprost NIS2 określa rezultaty i minimalne obszary ryzyka. Nie wskazuje, jak załatać zwalidowany MES, monitorować PLC w czystym obszarze produkcyjnym ani zachować zasad ALCOA+ podczas reagowania na cyberincydent. Takie decyzje wymagają współpracy bezpieczeństwa, jakości, inżynierii i regulacji w oparciu o jeden zapis ryzyka. 4.1. Zabezpieczenie systemów bez utraty stanu zwalidowanego Poprawka bezpieczeństwa lub zmiana konfiguracji może wpłynąć na stan zwalidowany MES, LIMS, QMS, systemów chromatograficznych, monitoringu środowiskowego i innych systemów GxP. Odkładanie każdej poprawki jest niebezpieczne; równie ryzykowne jest wdrażanie wszystkich zmian bez oceny. Celem kontroli jest udokumentowana decyzja oparta na ryzyku. Zarządzanie podatnościami należy połączyć z kontrolą zmian. Zapis powinien obejmować zasób i wersję, istotność podatności, możliwość wykorzystania, wpływ na pacjenta lub produkt, ekspozycję, wsparcie dostawcy, proponowaną zmianę, zakres testów, wycofanie zmiany, zabezpieczenia kompensacyjne i zatwierdzenie. Zasady GAMP 5 oraz CSV lub CSA pozwalają dostosować poziom zapewnienia do ryzyka zmienianej funkcji. Ponownie należy przetestować elementy mogące wpływać na zamierzone zastosowanie, integralność danych, zapisy elektroniczne, interfejsy i krytyczne obliczenia. Stan zwalidowany trzeba utrzymywać przez cały cykl życia. Przegląd okresowy powinien uzgadniać konfigurację, odchylenia, poprawki, dostępy, kopie, ścieżki audytowe, incydenty i zmiany dostawców. Zmiany awaryjne wymagają wcześniej określonych uprawnień oraz następczego przeglądu jakościowego. Dowody powinny zapewniać identyfikowalność sekwencji od zagrożenia przez decyzję, test i wydanie do monitorowania po wdrożeniu. 4.2. Ochrona danych badań klinicznych, własności intelektualnej i danych związanych z pacjentami NIS2 obejmuje podmioty prowadzące badania i rozwój produktów leczniczych, jeżeli spełnione są zasady dotyczące zakresu i wielkości. Ich model ryzyka musi chronić dostępność, autentyczność, integralność i poufność w projektowaniu protokołów, ośrodkach badawczych, eCOA, EDC, systemach bezpieczeństwa, biostatystyce, dokumentacji regulacyjnej i wymianie danych z partnerami. Należy stosować zasady integralności danych ALCOA+: zapisy powinny być przypisywalne, czytelne, współczesne zdarzeniu, oryginalne, dokładne, kompletne, spójne, trwałe i dostępne. Zabezpieczenia cybernetyczne muszą chronić ścieżkę audytową oraz kontekst potrzebny do interpretacji danych. Trzeba wykrywać masowe eksporty danych, nietypową aktywność uprzywilejowaną, manipulacje i nieautoryzowane zmiany interfejsów, a także testować odtworzenie danych i metadanych. Prywatność wymaga skoordynowanej, lecz odrębnej oceny. To samo zdarzenie może wymagać sprawdzenia, czy jest poważnym incydentem w rozumieniu NIS2 i czy stanowi naruszenie ochrony danych osobowych zgodnie z RODO. Testy prawne, odbiorcy zgłoszeń i terminy są różne. Organizacja powinna utrzymywać jeden zestaw faktów i chronologię, a następnie prowadzić oddzielne ścieżki decyzji prawnych. 4.3. Konwergencja IT/OT w produkcji i obszarach czystych Zasoby OT często mają długi cykl życia, ograniczenia dostawców, komunikację deterministyczną i wąskie okna utrzymaniowe. Standardowe oprogramowanie ochronne instalowane na urządzeniach końcowych może nie być wspierane. Sama przerwa w produkcji może wywołać konsekwencje jakościowe i dostawowe. OT należy traktować jako odrębną domenę ryzyka inżynieryjnego połączoną z ładem organizacji. Prace trzeba rozpocząć od pasywnego wykrywania i potwierdzenia właścicieli. Należy zdefiniować strefy i kanały komunikacyjne, ograniczyć dostęp zdalny, oddzielić funkcje bezpieczeństwa procesowego i sterowania od sieci biznesowych, chronić stacje inżynierskie, monitorować dozwoloną komunikację i kontrolować nośniki wymienne. Gdy załatanie nie jest możliwe, potrzebne są zabezpieczenia kompensacyjne. Segmentacja i zachowanie awaryjne nie mogą zakłócać sterowania w czasie rzeczywistym ani warunków środowiskowych. Każda zmiana powinna mieć kryteria akceptacji z zakresu cyberbezpieczeństwa, automatyki i jakości. Testy należy wykonywać w zatwierdzonych oknach, dokumentować wycofanie zmiany i zachowywać bazowe konfiguracje. Pakiet dowodowy powinien obejmować aktualne diagramy, reguły zapór, przeglądy dostępu zdalnego, obsługę alertów, testy kopii lub odtwarzania konfiguracji oraz zatwierdzone wyjątki. 5. NIS2, RODO, MDR i systemy jakości: jeden model zarządzania NIS2 chroni odporność i bezpieczeństwo sieci i systemów informatycznych. RODO chroni dane osobowe i ustanawia obowiązki zgłaszania naruszeń. MDR i IVDR regulują wyroby medyczne, w tym bezpieczeństwo, jakość i działania po wprowadzeniu do obrotu. GMP i GxP dotyczą jakości produktu i integralności danych. Jeden incydent może uruchomić kilka reżimów, ale ich testów prawnych nie można stosować zamiennie. Należy zbudować jeden model zarządzania z wieloma mapowaniami zgodności. Wspólny katalog usług, rejestr aktywów, metodyka ryzyka, zapis incydentu, rejestr dostawców, proces szkoleniowy, przepływ CAPA i indeks dowodów ograniczą duplikację. Każdą kontrolę trzeba powiązać z właściwym artykułem NIS2, prawem krajowym, wymaganiem RODO, procedurą jakościową i obowiązkiem dotyczącym wyrobu, bez łączenia odrębnych decyzji. Przed incydentem należy przygotować macierz decyzji regulacyjnych. Dla każdego reżimu trzeba zapisać przesłankę, właściciela decyzji, odbiorcę, termin, minimalną treść i zasady dalszych działań. Należy dodać zgłoszenia umowne oraz komunikację z organami dochodzeniowymi, ubezpieczycielami, partnerami i poszkodowanymi klientami. Podczas incydentu jedna osoba koordynująca utrzymuje zweryfikowane fakty, natomiast właściwi właściciele podejmują odrębne decyzje prawne i jakościowe. Model ogranicza sprzeczne zgłoszenia, nie pozwalając, aby najkrótszy termin zastąpił różne testy każdego reżimu. ISO/IEC 27001 może zapewnić użyteczną strukturę zarządzania bezpieczeństwem informacji, lecz samo w sobie nie potwierdza zakresu NIS2, rejestracji ani zgodności z krajową procedurą zgłoszeniową. ISO/IEC 42001 może wspierać ład, gdy AI jest używana w analizach LIMS, przeglądzie jakości lub operacjach bezpieczeństwa, jednak zabezpieczenia AI nadal wymagają walidacji, oceny integralności danych i nadzoru człowieka odpowiedniego do zastosowania. Zintegrowany formularz incydentu powinien zawierać odrębne części dotyczące wpływu na usługę, produkt i pacjenta, danych osobowych, statusu regulacyjnego, decyzji zgłoszeniowych i komunikacji. Ta sama zweryfikowana chronologia może wspierać CSIRT, organ ochrony danych, jednostkę jakości i kierownictwo bez tworzenia sprzecznych wersji. 6. Kary i egzekwowanie: koszt braku zgodności Artykuł 34 wymaga, aby państwa członkowskie przewidziały dla podmiotów kluczowych maksymalne administracyjne kary pieniężne w wysokości co najmniej 10 mln EUR albo co najmniej 2% całkowitego światowego rocznego obrotu z poprzedniego roku obrotowego, zależnie od tego, która wartość jest wyższa. Dla podmiotów ważnych odpowiednie poziomy wynoszą co najmniej 7 mln EUR albo 1,4%, zależnie od tego, która wartość jest wyższa. Prawo krajowe określa właściwy tryb egzekwowania i może przewidywać wyższe maksima lub dodatkowe środki. Kary są tylko jednym rodzajem ekspozycji. Incydent może powodować utratę sprzedaży, zniszczenie partii, opóźnienie badań, koszty odtwarzania, roszczenia umowne, konsekwencje dla prywatności i utratę zaufania. Merck podał, że atak sieciowy z 2017 r. zakłócił produkcję, badania i sprzedaż, obniżył sprzedaż w 2017 r. o około 260 mln USD oraz wygenerował 285 mln USD kosztów produkcyjnych i naprawczych po uwzględnieniu wskazanych odzyskanych środków z ubezpieczenia. Pozostałe zaległości wpłynęły na sprzedaż w 2018 r. o około 150 mln USD. Nie należy uzasadniać zabezpieczeń wyłącznie porównaniem kosztu programu z maksymalną karą. Priorytety powinny wynikać z wpływu na usługę, wiarygodnego zagrożenia, słabości kontroli i obowiązku prawnego. Zarząd powinien widzieć zarówno ekspozycję na brak zgodności, jak i scenariusz straty operacyjnej dla każdego krytycznego produktu lub usługi. 7. Mapa drogowa wdrożenia NIS2 w farmacji na 9–12 miesięcy Program trwający 9–12 miesięcy może uporządkować działania naprawcze, ale nie jest prawnym okresem przejściowym. Organizacje już podlegające krajowym przepisom wdrażającym muszą wykonywać bieżące obowiązki podczas podnoszenia dojrzałości. Prace trzeba planować według krytyczności ryzyka i zatwierdzonych okien zmian w środowiskach zwalidowanych. 7.1. Krok 1: zakres i analiza luk Należy potwierdzić status i jurysdykcję każdej osoby prawnej. Krytyczne usługi i produkty trzeba zinwentaryzować, a następnie zmapować zależności IT, OT, laboratoryjne, kliniczne, informacyjne, obiektowe, osobowe i dostawcze. Ocena powinna objąć dziesięć obszarów art. 21 oraz obowiązki krajowe. Rezultatem oceny powinny być: zatwierdzona analiza zakresu, rejestr jurysdykcji, mapa usług i zależności, bazowy rejestr aktywów, raport luk, plan naprawczy uszeregowany według ryzyka oraz indeks dowodów. Każdy nieznany zasób wystawiony na zewnątrz lub niewspierany system krytyczny wymaga natychmiastowej eskalacji. 7.2. Krok 2: ład i odpowiedzialność Należy wyznaczyć sponsora po stronie kierownictwa, właścicieli usług, właścicieli kontroli i osobę uprawnioną do zgłaszania incydentów. RACI powinno obejmować bezpieczeństwo, IT, OT, inżynierię, jakość, prywatność, prawo, zakupy, HR, komunikację i ciągłość działania. Na tym etapie organizacja powinna mieć kartę ładu, RACI, pakiet raportowy dla kierownictwa, progi akceptacji ryzyka, plan szkoleń, macierz kontaktów CSIRT oraz zdefiniowane uprawnienia do izolowania systemów produkcyjnych lub laboratoryjnych. 7.3. Krok 3: zabezpieczenia techniczne i organizacyjne Priorytetami są tożsamość, dostęp uprzywilejowany, MFA, segmentacja sieci, bezpieczny dostęp zdalny, EDR tam, gdzie jest wspierany, pasywny monitoring OT, centralne logowanie, zarządzanie podatnościami, chronione kopie i odtwarzanie. Każdą zmianę trzeba powiązać z procedurami jakości i walidacji. Zakończenie etapu potwierdzają zatwierdzone architektury, wymagania kontroli, zapisy wdrożeniowe, dowody walidacji lub zapewnienia, mierniki pokrycia, rejestr wyjątków i przetestowane wycofanie zmiany. Trzeba mierzyć objętą populację, a nie sam fakt zakupu narzędzia. 7.4. Krok 4: weryfikacja i ciągłe monitorowanie dostawców Dostawców API, CMO, CRO, laboratoriów, logistyki, chmury, oprogramowania i utrzymania należy podzielić na poziomy ryzyka. Due diligence powinno być proporcjonalne do dostępu i wpływu. Umowy wymagają uzupełnienia, a monitoring zdefiniowanych wyzwalaczy. Rezultatem operacyjnym jest utrzymywany rejestr dostawców wsparty modelem krytyczności, przeglądami dowodów, decyzjami o ryzyku, klauzulami bezpieczeństwa, kontaktami incydentowymi, harmonogramem monitorowania, analizą koncentracji i planami wyjścia. Ponowna ocena jest potrzebna po istotnej zmianie lub incydencie. 7.5. Krok 5: budowa i testowanie reagowania na incydenty Należy przygotować scenariusze działania dla ransomware, eksfiltracji danych, naruszenia zwalidowanego systemu, zakłócenia OT, incydentu dostawcy i utraty krytycznej usługi chmurowej. Muszą obejmować decyzje jakościowe i regulacyjne, a nie wyłącznie techniczne powstrzymanie ataku. Zdolność reagowania powinna być udokumentowana w planie obsługi incydentów, szablonach raportów 24/72-godzinnych i końcowych, ocenie istotności, metodzie zabezpieczenia dowodów i raporcie z ćwiczenia symulacyjnego. Ćwiczenie należy przeprowadzić z kadrą kierowniczą i personelem dyżurnym, a działania naprawcze doprowadzić do zweryfikowanego zamknięcia. 7.6. Krok 6: dokumentacja, audyt i utrzymanie Działanie kontroli należy projektować tak, aby wytwarzało dowody. Tam, gdzie jest to praktyczne, warto automatyzować kontrolowane raporty, wskazywać właścicieli zapisów i ustalać retencję na podstawie prawa krajowego, obowiązków sektorowych, potrzeb dochodzeniowych i ryzyka. Program wymaga przeglądu po incydentach, istotnych zmianach i aktualizacjach prawa. Program zamyka kontrolowany zbiór polityk, indeks dowodów, protokoły kierownictwa, rejestry szkoleń, akta incydentów i dostawców, wyniki testów odtwarzania, testy skuteczności, raport z audytu wewnętrznego i rejestr CAPA. Zamknięcie ustaleń wysokiego ryzyka powinno zostać niezależnie potwierdzone. 8. Udokumentowane cyberincydenty: praktyczne wnioski dla NIS2 Publiczne raporty o incydentach rzadko dowodzą, która konkretna kontrola wewnętrzna zawiodła. Należy wykorzystywać je do testowania wiarygodnych scenariuszy, nie do przypisywania organizacji niepotwierdzonego braku zabezpieczenia. Atak na Merck z 2017 r. pokazuje, że złośliwe oprogramowanie w przedsiębiorstwie może jednocześnie dotknąć produkcji, badań, sprzedaży i realizacji zamówień. Wnioskiem dla NIS2 jest konieczność mapowania wspólnych zależności, segmentowania środowisk, ochrony zdolności odtwarzania i ilościowej oceny ciągłości na poziomie produktu. Ćwiczenia powinny obejmować decyzję o izolacji systemu zakładowego, gdy sama izolacja może przerwać produkcję. Cyberatak na Europejską Agencję Leków z 2020 r. doprowadził do nieuprawnionego dostępu do dokumentów dotyczących leków i szczepionek przeciw COVID-19. EMA poinformowała, że część ujawnionych materiałów, w tym korespondencję, zmanipulowano przed publikacją. Wniosek wykracza poza poufność: trzeba chronić autentyczność, integralność i pochodzenie danych wymienianych z regulatorami i partnerami oraz przygotować komunikację na wypadek publikacji zmanipulowanych lub niepełnych danych. Cencora ujawniła w lutym 2024 r., że doszło do eksfiltracji danych z jej systemów informacyjnych, a część informacji mogła mieć charakter osobowy. Spółka podała wówczas, że systemy pozostały dostępne oraz że rozpoczęto ograniczanie skutków, dochodzenie i współpracę z organami ścigania, ekspertami cyberbezpieczeństwa i doradcami zewnętrznymi. Wniosek dotyczy szybkiej oceny międzyfunkcyjnej również wtedy, gdy dostępność nie została naruszona: eksfiltracja może uruchomić obowiązki NIS2, prywatności, umowne i komunikacyjne. Dla każdego scenariusza należy zachować chronologię alertów, dotknięte usługi, źródła dowodów, ocenę jakościową, decyzję zgłoszeniową, eskalację do kierownictwa i działania naprawcze. Wnioski trzeba powiązać z kontrolami art. 21 i sprawdzić, czy te same dowody wystarczyłyby do sporządzenia wczesnego ostrzeżenia w ciągu 24 godzin. 9. Wybór eksperckiego wsparcia we wdrożeniu NIS2 Partner NIS2 dla farmacji musi łączyć cyberbezpieczeństwo, regulowane zarządzanie jakością i zdolność wdrożeniową. Należy oczekiwać dowodów, że zespół potrafi klasyfikować zakres, mapować usługi, projektować zabezpieczenia IT/OT, zarządzać zmianą w systemach zwalidowanych, tworzyć dowody CSV lub CSA, oceniać dostawców, prowadzić ćwiczenia incydentowe i wyjaśniać kierownictwu ryzyko rezydualne. Trzeba ocenić model świadczenia usługi. Jednorazowy raport z analizy luk nie utrzymuje zgodności. Managed services mogą obsługiwać monitoring, wstępną ocenę podatności, zbieranie dowodów i przegląd dostawców, jednak odpowiedzialność pozostaje po stronie regulowanej organizacji i jej kierownictwa. Od początku należy określić własność, eskalację, poziomy usług, dostęp do dowodów i zasady wyjścia. Przed wyborem warto poprosić o przykładowe materiały: zanonimizowaną analizę zakresu, macierz identyfikowalności art. 21, pakiet zwalidowanej zmiany, ocenę ryzyka OT, ustalenie dotyczące dostawcy i raport z ćwiczenia incydentowego dla zarządu. Wnioski powinny wskazywać założenia, dowody i ryzyko rezydualne. Specjaliści bezpieczeństwa muszą umieć pracować z zespołami jakości, automatyki i prawa, a zapisy powinny być możliwe do przeniesienia do kontrolowanych repozytoriów organizacji. Partner powinien pozostawić działający proces i użyteczne dowody, a nie prezentację, której nie można utrzymać. TTMS łączy środowisko zarządzania bezpieczeństwem informacji zgodne z ISO/IEC 27001 z usługami walidacji farmaceutycznych systemów skomputeryzowanych według GAMP 5 i Aneksu 11. Opublikowana oferta jakościowa obejmuje CSV i CSA w całym cyklu życia systemu. W lutym 2026 r. TTMS poinformowała, że jako pierwsza polska firma uzyskała akredytowaną certyfikację ISO/IEC 42001 dla systemu zarządzania AI po audycie TÜV Nord Poland. Kompetencje te mają znaczenie tam, gdzie zabezpieczenia cybernetyczne, systemy zwalidowane i zarządzana AI muszą działać w jednym audytowalnym modelu. Aby umówić rozmowę dotyczącą zakresu osób prawnych, regulowanych usług, krytycznych produktów, systemów zwalidowanych, zależności OT i dostępnych dowodów, skontaktuj się z TTMS. Pierwszym rezultatem powinien być możliwy do obrony zakres i plan działań uszeregowany według priorytetów, a nie ogólny katalog zabezpieczeń. 10. Najczęściej zadawane pytania o cyberbezpieczeństwo NIS2 w farmacji Czy NIS2 dotyczy każdej firmy farmaceutycznej? Nie. Zakres zależy od działalności, wielkości, miejsca prowadzenia działalności, prawa krajowego i ewentualnego wyznaczenia. Wytwarzanie oraz badania i rozwój produktów leczniczych są wymienione w dyrektywie; sam marketing lub dystrybucja mogą prowadzić do innego wyniku. Wniosek należy udokumentować dla każdej osoby prawnej. Czy każdy producent farmaceutyczny jest podmiotem kluczowym? Nie. Obecność w załączniku I nie czyni automatycznie każdego producenta podmiotem kluczowym. O statusie podmiotu kluczowego, ważnego lub pozostającego poza zakresem decydują progi wielkości, zasady art. 3, wyjątki i decyzje krajowe. Spółki w tej samej grupie mogą otrzymać różne wyniki. Jakie są główne terminy zgłaszania incydentów NIS2? Dla poważnego incydentu dyrektywa przewiduje wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy, zgłoszenie incydentu w ciągu 72 godzin oraz sprawozdanie końcowe w ciągu miesiąca. Trzeba również sprawdzić procedury krajowe i równoległe obowiązki wynikające z RODO lub regulacji sektorowych. Jak NIS2, GxP i Aneks 11 współdziałają w środowisku farmaceutycznym? NIS2 reguluje ryzyko cyberbezpieczeństwa i odporność, natomiast GxP i Aneks 11 dotyczą jakości produktu, integralności danych i systemów skomputeryzowanych. Można stosować jeden model ryzyka i kontroli zmian, zachowując odrębne oceny prawne oraz dowody walidacji zmian bezpieczeństwa. Jak postępować z poprawkami bezpieczeństwa w zwalidowanych systemach GxP? Podatność należy przeprowadzić przez ocenę ryzyka i kontrolowaną zmianę. Dokumentacja powinna obejmować możliwość wykorzystania, wpływ na produkt lub pacjenta, zakres testów, wycofanie zmiany i zabezpieczenia kompensacyjne. Zapewnienie CSV lub CSA należy dostosować do ryzyka funkcji oraz zachować identyfikowalność od podatności przez zatwierdzenie do przeglądu po zmianie.
Czytaj
Dokumentacja zgodności z NIS2 – jakie dowody powinna przygotować firma?
Zgodności z NIS2 nie można wykazać samym zbiorem polityk bezpieczeństwa. Organ właściwy, audytor lub kierownictwo może potrzebować informacji nie tylko o tym, co organizacja zamierzała wdrożyć, ale również czy środki zostały zatwierdzone, uruchomione, przetestowane i udoskonalone. To rozróżnienie sprawia, że zarządzanie dowodami jest istotną częścią gotowości do NIS2 i polskiej ustawy o krajowym systemie cyberbezpieczeństwa. Polityka opisuje oczekiwany sposób działania. Dowód pokazuje, że proces został wykonany, zabezpieczenie działało, wyjątek podlegał kontroli, a istotny problem dotarł do właściwej osoby decyzyjnej. Dyrektywa (UE) 2022/2555, nazywana NIS2, nie ustanawia jednego uniwersalnego segregatora dokumentów dla każdego podmiotu. Określa rezultaty i minimalne obszary, które podmioty kluczowe i ważne powinny realizować za pomocą odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. W Polsce wymagania dyrektywy rozwija ustawa o KSC, której nowelizacja obowiązuje od 3 kwietnia 2026 r. Zakres dokumentacji zależy od ryzyka, usług, sektora, wielkości i sytuacji prawnej organizacji. Znaczenie mają także przepisy wykonawcze, regulacje sektorowe i wymagania właściwego organu. Ten przewodnik wyjaśnia, jak zbudować praktycznądokumentację zgodności z NIS2, jakie dowody mogą wspierać realizację art. 20, 21 i 23 dyrektywy oraz krajowych obowiązków KSC, a także jak przygotować uporządkowany pakiet dowodowy bez tworzenia zbędnej biurokracji. Nie jest to kolejny ogólny poradnik wdrożeniowy ani artykuł o najczęstszych lukach audytowych. 1. Czy NIS2 wskazuje konkretną listę wymaganych dokumentów? NIS2 nie zawiera jednej wyczerpującej listy zatytułowanej „dokumenty wymagane od każdego podmiotu”. Ustanawia jednak obowiązki, których wykonanie i wykazanie bez wiarygodnych zapisów byłoby bardzo trudne. Artykuł 20 wymaga zaangażowania organów zarządzających w zatwierdzanie środków zarządzania ryzykiem, nadzorowanie ich wdrożenia i odbywanie odpowiednich szkoleń. Artykuł 21 określa minimalne obszary środków zarządzania ryzykiem. Artykuł 23 wprowadza wieloetapowe zgłaszanie znaczących incydentów. Przepisy dotyczące nadzoru pozwalają właściwym organom żądać informacji, danych, dokumentów i innych dowodów potrzebnych do wykonywania ich zadań. Polska ustawa o KSC wprowadza dodatkowo krajowe obowiązki organizacyjne i proceduralne, w tym związane z samoidentyfikacją, Wykazem KSC, systemem S46 oraz systemem zarządzania bezpieczeństwem informacji. Dla podmiotów kluczowych znaczenie ma także ustawowy audyt bezpieczeństwa, który należy odróżnić od dobrowolnej analizy gotowości. Dokumentacja powinna umożliwiać odpowiedź na trzy podstawowe pytania: Jakiej decyzji, kontroli lub procesu wymagało prawo albo przyjęty system zarządzania? Kto i kiedy zatwierdził, posiadał lub wykonał dane działanie? Jaki dowód pokazuje, że środek działał i osiągnął oczekiwany rezultat? Podmioty działające w kilku państwach powinny prowadzić rejestr jurysdykcji. Jeden pakiet dowodowy może nie wystarczyć do obsługi różnych procedur rejestracyjnych, języków, formularzy i wymagań organów krajowych. Określeni dostawcy usług DNS, chmury, centrów danych, usług zarządzanych, cyberbezpieczeństwa zarządzanego, platform handlowych, wyszukiwarek, sieci społecznościowych i usług zaufania podlegają również rozporządzeniu wykonawczemu Komisji (UE) 2024/2690. Pozostałe podmioty mogą korzystać z niego i z wytycznych ENISA jako źródła dobrych praktyk, ale nie powinny przedstawiać wszystkich jego postanowień jako automatycznie wiążących poza zakresem rozporządzenia. 2. Dokument, zapis i dowód – czym się różnią? Rozdzielenie tych pojęć ułatwia kontrolę jakości materiałów. Kategoria Cel Przykłady Dokumenty zarządcze Określają oczekiwany sposób działania i odpowiedzialność Polityki, standardy, procedury, regulaminy i opisy kontroli Zapisy operacyjne Pokazują wykonanie procesu lub zabezpieczenia Przeglądy dostępu, zgłoszenia podatności, logi kopii, oceny dostawców i szkolenia Dowody decyzji Pokazują sposób rozpatrzenia ryzyka, wyjątków i priorytetów Protokoły, akceptacje ryzyka, zgody inwestycyjne i eskalacje Dowody skuteczności Pokazują, czy środki działają zgodnie z przeznaczeniem Testy, odtworzenia, mierniki, audyty i zweryfikowane działania naprawcze Dokumentacja regulacyjna Wspiera rejestrację, zgłoszenia i kontakty z organami Analiza zakresu, Wykaz KSC, raporty incydentów i korespondencja Polityka nie jest dowodem, że proces działa. Zrzut ekranu nie zawsze jest wiarygodnym materiałem, jeżeli nie wiadomo, z jakiego systemu pochodzi, kiedy został wykonany i jaki zakres danych przedstawia. Raport z testu ma ograniczoną wartość, jeśli nikt nie odpowiada za ustalenia i nie weryfikuje ich zamknięcia. Silny materiał dowodowy łączy projekt z działaniem. Powinien umożliwić prześledzenie wymagania do kontroli, kontroli do właściciela, właściciela do zapisów operacyjnych, a ewentualnej nieskuteczności do decyzji lub działania naprawczego. 3. Zbuduj mapę dowodów NIS2 Gromadzenie wszystkich dostępnych plików zwiększa koszty, utrudnia przegląd i może tworzyć dodatkowe ryzyko bezpieczeństwa. Lepszym punktem wyjścia jest mapa dowodów. Mapa łączy każde mające zastosowanie wymaganie z kontrolą, właścicielem i źródłem zapisu. Może być prowadzona w narzędziu GRC lub kontrolowanym arkuszu, jeśli zapewnione są właściwe uprawnienia, wersjonowanie i odpowiedzialność. Pole mapy dowodów Co należy zapisać Podstawa prawna lub kontrolna Artykuł NIS2, przepis KSC, akt wykonawczy albo wymaganie wewnętrzne Oczekiwany rezultat Ryzyko lub rezultat dla usługi, który ma zostać osiągnięty Opis kontroli Sposób realizacji wymagania przez organizację Właściciel i wykonawca Osoba odpowiedzialna oraz osoba lub zespół wykonujący czynność Źródło dowodu System, repozytorium albo proces generujący zapis Częstotliwość lub wyzwalacz Miesięcznie, kwartalnie, po zmianie lub po incydencie Recenzent Osoba oceniająca kompletność i skuteczność Retencja i ochrona Okres przechowywania, dostęp i zabezpieczenie integralności Status i wyjątki Wynik, otwarte luki, zaakceptowane ryzyko i działania naprawcze Mapa powinna odpowiadać usługom i systemom w zakresie. Szablon może przyspieszyć pracę, ale nie powinien prowadzić do nieuzasadnionych deklaracji. Jeżeli kontrola nie ma zastosowania, warto zapisać uzasadnienie zamiast pozostawiać pustą komórkę. 4. Dokumentacja zakresu i podlegania KSC Wiarygodny pakiet dowodowy wymaga najpierw ustalenia, które podmioty i usługi są objęte regulacją. Jest to szczególnie ważne dla grup kapitałowych, działalności transgranicznej i organizacji funkcjonujących w kilku sektorach. Dokumentacja samoidentyfikacji może obejmować: listę właściwych podmiotów prawnych i zakładów; usługi i działalności przyporządkowane do załączników nr 1 i 2 ustawy o KSC; dane o zatrudnieniu i finansach wykorzystane do klasyfikacji wielkości; analizę przedsiębiorstw partnerskich i powiązanych; wyjątki od kryterium wielkości i ewentualne decyzje administracyjne; wskazanie właściwego CSIRT i organu do spraw cyberbezpieczeństwa; ocenę relacji z regulacjami sektorowymi, na przykład DORA; opinię prawną lub interpretację wspierającą niejednoznaczny przypadek; wyzwalacze ponownego przeglądu, takie jak przejęcie, nowa usługa lub restrukturyzacja. Celem nie musi być obszerne memorandum prawne. Wniosek powinien być jednak możliwy do odtworzenia. Osoba przeglądająca powinna widzieć uwzględnione fakty, wersję przepisów, datę analizy i osobę zatwierdzającą rezultat. 4.1 Dowody wpisu do Wykazu KSC i podłączenia do S46 Podmiot powinien przechowywać kopię wniosku lub innego dowodu wpisu do Wykazu KSC, potwierdzenia, korespondencję oraz dane osób odpowiedzialnych za aktualizację informacji. Jeżeli wpis nastąpił z urzędu, należy zachować otrzymane zawiadomienia i zweryfikować prawidłowość danych. W odniesieniu do systemu S46 przydatne będą zapisy dotyczące wyznaczenia użytkowników, uprawnień, testów dostępu, procedury awaryjnej i bieżącego utrzymania danych kontaktowych. Dowód technicznego podłączenia nie zastępuje przygotowania procesu zgłoszeniowego. Dokumentacja zakresu powinna także wskazywać systemy informacyjne wspierające usługi objęte ustawą. Granice prawne nie zawsze pokrywają się z technicznymi. Jedna platforma tożsamości, środowisko chmurowe lub dostawca może obsługiwać wiele spółek i usług. 5. Dokumentacja SZBI zgodnego z KSC Polska ustawa wymaga wdrożenia systemu zarządzania bezpieczeństwem informacji. SZBI powinien łączyć polityki, odpowiedzialności, ryzyko, środki ochrony, monitorowanie, obsługę incydentów i doskonalenie. Dokumentacja SZBI może obejmować: zakres systemu i usługi objęte ochroną; zatwierdzoną politykę bezpieczeństwa informacji; metodykę oceny i postępowania z ryzykiem; strukturę odpowiedzialności i ścieżki eskalacji; wykaz polityk, standardów i procedur; cele bezpieczeństwa i mierniki; program szkoleń i podnoszenia świadomości; zasady zarządzania zmianą, wyjątkami i niezgodnościami; przeglądy kierownictwa; audyty, testy i działania korygujące; mechanizm ciągłego doskonalenia. Norma ISO/IEC 27001 może stanowić użyteczną podstawę, ale jej certyfikat nie jest automatycznym dowodem spełnienia całego KSC. Znaczenie mają zakres certyfikacji, wyłączenia, deklaracja stosowania i faktyczne pokrycie usług regulowanych. 6. Dowody odpowiedzialności kierownictwa Artykuł 20 NIS2 i przepisy krajowe czynią zaangażowanie kierownictwa elementem merytorycznym, a nie formalnym dodatkiem. 6.1 Zatwierdzanie środków bezpieczeństwa Dowodem mogą być protokoły, uchwały, materiały decyzyjne i zatwierdzone zestawy polityk. Zapis powinien wskazywać, co zatwierdzono, jaki był zakres decyzji, jakie ryzyka i ograniczenia były znane, jakie zasoby przydzielono oraz jak będzie monitorowane wykonanie. Jeżeli zatwierdzany jest duży pakiet, kontrolowany indeks powinien wskazywać dokumenty i wersje wchodzące w jego skład. Pozwala to uniknąć wątpliwości, czy konkretna procedura była objęta decyzją. 6.2 Nadzór nad wdrożeniem Dowody nadzoru mogą obejmować dashboardy, protokoły komitetów ryzyka, raporty programu, eskalacje opóźnionych działań i decyzje dotyczące ryzyka rezydualnego. Przydatne mierniki łączą zabezpieczenia z usługami, na przykład: odsetek usług krytycznych objętych przetestowanymi planami odtwarzania; krytyczne podatności po terminie naprawy; konta uprzywilejowane oczekujące na przegląd; dostawcy krytyczni bez aktualnego zapewnienia bezpieczeństwa; ustalenia wysokiego ryzyka po uzgodnionym terminie. Liczba przetworzonych alertów lub przeszkolonych osób może być pomocna, ale sama nie pokazuje zdolności do ochrony i odtworzenia usługi. 6.3 Szkolenia kierownictwa Dokumentacja powinna wskazywać uczestników, datę, zakres, prowadzącego i realizację szkolenia. Materiał powinien obejmować odpowiedzialność, profil ryzyka, eskalację poważnych incydentów, akceptację ryzyka i nadzór. Lista obecności jest silniejszym dowodem, gdy towarzyszą jej cele szkolenia, agenda, ćwiczenie lub potwierdzenie zrozumienia. 6.4 Delegowanie obowiązków Aktualny model odpowiedzialności może przyjąć formę regulaminów, opisów ról, macierzy RACI i progów akceptacji ryzyka. Delegowanie czynności do IT, zespołu bezpieczeństwa lub dostawcy nie usuwa potrzeby nadzoru i uzyskiwania zapewnienia przez kierownictwo. 7. Dokumentacja analizy ryzyka i planów postępowania Dowody powinny pokazywać, że zarządzanie ryzykiem wpływa na decyzje i inwestycje. Podstawowy zestaw może obejmować: zatwierdzoną metodykę ryzyka cyberbezpieczeństwa; kryteria wpływu, prawdopodobieństwa i akceptacji; ewidencję usług, procesów, informacji i technologii; oceny ryzyka i aktualny rejestr; plany postępowania z właścicielami, budżetem i terminami; akceptacje ryzyka i wyjątki; ponowną ocenę po zmianie lub incydencie; powiązania ryzyka z kontrolami, dostawcami i ciągłością. Rejestr nie powinien być izolowanym arkuszem zespołu bezpieczeństwa. Istotne ryzyko wymaga właściciela biznesowego i ścieżki do kierownictwa. Plan powinien wskazywać, czy ryzyko jest ograniczane, unikane, przenoszone czy akceptowane. Wyjątki wymagają szczególnej kontroli. Odroczenie poprawki, nieobsługiwany system lub niewykonany przegląd dostępu powinny mieć wskazaną usługę, uzasadnienie, zabezpieczenia kompensacyjne, zatwierdzającego, termin wygaśnięcia i datę przeglądu. 8. Dowody dla dziesięciu obszarów art. 21 NIS2 Poniższe przykłady nie stanowią uniwersalnej listy ustawowej. Pokazują jednak, jak łączyć obszar wymagania z praktycznymi zapisami. Obszar art. 21 Przykładowe dowody Analiza ryzyka i polityki bezpieczeństwa Metodyka, rejestr, zatwierdzenia, historia przeglądów i wyjątki Obsługa incydentów Plan, kryteria istotności, zgłoszenia, komunikacja, ćwiczenia i lessons learned Ciągłość, kopie i kryzys BIA, cele odtworzeniowe, plany, monitoring kopii, testy odtworzenia i ćwiczenia Łańcuch dostaw Rejestr, klasy ryzyka, due diligence, umowy, raporty zapewniające, monitoring i plany wyjścia Bezpieczne nabywanie, rozwój i utrzymanie Wymagania, przeglądy architektury, testy, zmiany, podatności i aktualizacje Ocena skuteczności Testy kontroli, testy penetracyjne, audyty, mierniki i zweryfikowane działania naprawcze Cyberhigiena i szkolenia Standardy bazowe, aktualizacje, konfiguracje, szkolenia ról i symulacje Kryptografia i szyfrowanie Polityka, standardy, ewidencja kluczy i certyfikatów, rotacja i wyjątki Personel, dostęp i aktywa Procesy kadrowe, joiner-mover-leaver, przeglądy uprawnień, konta uprzywilejowane i inwentarz MFA i bezpieczna komunikacja Pokrycie MFA, rejestracja, odzyskanie dostępu, wyjątki i testy łączności awaryjnej Dowody powinny być proporcjonalne. Mały podmiot ważny i duży podmiot kluczowy mogą realizować ten sam obszar innym modelem i poziomem szczegółowości. Liczy się wystarczająca wiarygodność w kontekście ryzyka i usług. 9. Dokumentacja poważnych incydentów NIS2 przewiduje wczesne ostrzeżenie bez zbędnej zwłoki i nie później niż w ciągu 24 godzin od uzyskania wiedzy, zgłoszenie incydentu w ciągu 72 godzin oraz zasadniczo raport końcowy w ciągu miesiąca. Polska ustawa i procedury właściwego CSIRT określają krajowy sposób realizacji obowiązku. Dokumentacja incydentu powinna wspierać działania operacyjne i decyzję zgłoszeniową. Przydatne zapisy obejmują: czas i źródło wykrycia; moment uzyskania wiedzy o incydencie; ocenę techniczną i biznesową; analizę kryteriów poważnego incydentu i osobę zatwierdzającą; dotknięte usługi, systemy i odbiorców; podejrzenie działania bezprawnego lub złośliwego; wskaźniki naruszenia i skutki transgraniczne; działania ograniczające, naprawcze i odtworzeniowe; kopie zgłoszeń, potwierdzeń i uzupełnień; komunikację z klientami, organami, ubezpieczycielem i dostawcami; dziennik decyzji z rozróżnieniem faktów i niewiadomych; analizę przyczyny, wnioski i działania korygujące. 9.1 Zachowaj oś czasu Bieg terminu może rozpocząć się przed zakończeniem analizy. Systemy powinny korzystać ze zsynchronizowanego czasu, a lider incydentu rejestrować istotne fakty i decyzje na bieżąco. Wczesne zgłoszenie może zawierać informacje niepełne, ale powinno jasno wskazywać, co potwierdzono, co jest hipotezą i co pozostaje przedmiotem badania. 9.2 Dokumentuj decyzje o braku zgłoszenia Nie każde zdarzenie jest poważnym incydentem. Jeżeli organizacja uznaje, że próg nie został osiągnięty, powinna zachować proporcjonalny zapis faktów, kryteriów i decyzji. Ułatwia to zachowanie spójności i ponowną ocenę, jeżeli skutki się zmienią. 10. Dowody bezpieczeństwa dostawców Dokumentacja powinna pokazywać, że organizacja rozumie relacje mogące wpływać na regulowane usługi i stosuje kontrolę adekwatną do ryzyka. Zestaw może obejmować: rejestr dostawców powiązany z usługami i aktywami; klasyfikację ryzyka i krytyczności; kwestionariusze oraz dokumenty źródłowe; raporty niezależne i certyfikaty wraz z oceną zakresu; wymagania bezpieczeństwa w umowach; zgłaszanie incydentów i obowiązek współpracy; informacje o podwykonawcach, lokalizacji i koncentracji; dostępy personelu dostawcy i ich przeglądy; monitoring jakości, podatności i incydentów; ponowną ocenę po zmianie lub incydencie; plany ciągłości, zastąpienia i bezpiecznego zakończenia współpracy. Certyfikatu nie należy archiwizować bez oceny. Znaczenie mają zakres, okres, wyłączenia i związek z dostarczaną usługą. Kwestionariusz jest deklaracją dostawcy, nie niezależnym dowodem. Dla wysokiego ryzyka mogą być potrzebne wywiady, materiały techniczne, raporty zapewniające lub prawa do weryfikacji. Braki powinny prowadzić do decyzji. Akceptacja ryzyka dostawcy bez właściciela, terminu i zabezpieczenia kompensacyjnego tworzy niezarządzany wyjątek. 11. Dowody ciągłości działania, kopii i odtwarzania Dokumentacja ciągłości powinna łączyć priorytety biznesowe z realną zdolnością techniczną. Łańcuch dowodowy może rozpoczynać się od analizy wpływu na działalność i mapy zależności. Powinny one uzasadniać RTO i RPO, kolejność odtwarzania, architekturę kopii, procedury alternatywne i rozwiązania dostawców. Zapisy operacyjne mogą obejmować: plany ciągłości, odtwarzania awaryjnego i zarządzania kryzysowego; konfigurację i monitoring chronionych kopii; testy wskazujące, które dane i systemy odtworzono; rzeczywisty czas odtworzenia w porównaniu z celem; ograniczenia testu, niepowodzenia i działania naprawcze; uczestników, decyzje i wnioski z ćwiczeń; kontakty awaryjne i testy eskalacji poza godzinami pracy; udział dostawców krytycznych, jeżeli był wymagany. Pomyślnie wykonana kopia nie jest tym samym co skuteczne odtworzenie. Dowód powinien pokazywać, że dane można przywrócić do działającej usługi w realistycznych warunkach. 12. Techniczne dowody działania zabezpieczeń Dowodów technicznych jest często bardzo dużo, ale trudno je interpretować. Celem nie jest eksport wszystkich logów, lecz zachowanie materiału pokazującego zakres, działanie, przegląd i reakcję. Przykłady: zatwierdzone bazowe konfiguracje i raporty zgodności; pokrycie skanowaniem podatności i zgłoszenia naprawcze; status aktualizacji powiązany z krytycznością i wyjątkami; pokrycie monitoringiem punktów końcowych, sieci i chmury; przeglądy tożsamości i dostępów uprzywilejowanych; pokrycie MFA i wyjątki; zarządzanie szyfrowaniem, kluczami i certyfikatami; zatwierdzenia zmian i testy bezpieczeństwa; wyniki bezpiecznego rozwoju i kontroli zależności; kontrola kompletności inwentarza; analizy alertów i rezultat reakcji. Zrzuty ekranu należy stosować ostrożnie. Lepsze są powtarzalne raporty lub eksporty ze wskazanym źródłem, czasem, zakresem zapytania i recenzentem. Materiał mogący wspierać dochodzenie wymaga ochrony integralności. 13. Dowody oceny skuteczności środków Artykuł 21 obejmuje zasady i procedury oceny skuteczności środków zarządzania ryzykiem. Dokumentacja nie może więc kończyć się na statusie „wdrożono”. Pakiet skuteczności może łączyć: cele kontroli i kryteria sukcesu; samooceny; testy techniczne i niezależne przeglądy; mierniki bezpieczeństwa i odporności; audyty wewnętrzne i zewnętrzne; incydenty i zdarzenia potencjalnie wypadkowe; trendy i powtarzające się słabości; działania naprawcze z właścicielem i terminem; niezależne potwierdzenie zamknięcia wysokiego ryzyka. Miernik wymaga interpretacji. Wynik „98% krytycznych systemów zaktualizowanych w terminie” powinien mieć zdefiniowaną populację, wiarygodny inwentarz, sposób obsługi wyjątków i informację o pozostałych 2%. Dobra średnia może ukrywać ekspozycję najważniejszej usługi. Raportowanie powinno rozróżniać projekt kontroli, jej wdrożenie i skuteczność. Kontrola może być poprawnie zaprojektowana, ale wykonywana nieregularnie, albo szeroko wdrożona, lecz nieskuteczna wobec realistycznego zagrożenia. 14. Jak przygotować pakiet dowodowy NIS2? Pakiet dowodowy jest kontrolowanym widokiem zapisów, a nie trwałą kopią każdego pliku operacyjnego. 1. Zacznij od indeksu Indeks powinien wskazywać wymaganie, dokument, właściciela, wersję lub okres, źródło, klasyfikację dostępu i status przeglądu. Powinien także ujawniać brakujące materiały i otwarte działania. 2. Organizuj według usług Obowiązki dotyczą podmiotów, ale skutki występują w usługach. Nawigacja oparta na usługach pomaga zrozumieć zależności, ryzyko, zabezpieczenia i priorytety odtwarzania. 3. Dobieraj reprezentatywne okresy i próbki Dowody powinny pokazywać działanie w czasie. Jeden przegląd dostępu wykonany tuż przed audytem nie potwierdza dojrzałego procesu kwartalnego. 4. Zachowaj źródło i kontekst Każdy materiał powinien wskazywać pochodzenie, autora lub zatwierdzającego, datę, zakres i znaczenie. Usuń niewyjaśnione zrzuty, nieopisane eksporty i projekty mogące zostać pomylone z wersją zatwierdzoną. 5. Ujawniaj luki rzetelnie Nie twórz zapisów wstecz, aby sugerować wykonanie czynności. Jeżeli dowodu brakuje, zapisz lukę, natychmiastowe ograniczenie ryzyka, właściciela i termin naprawy. 6. Wykonaj przegląd jakości Prawo, bezpieczeństwo, ryzyko i właściciele usług powinni sprawdzić spójność. Inwentarz musi odpowiadać pokryciu skanowaniem. Klasa dostawcy powinna determinować monitoring. Cele odtworzeniowe muszą zgadzać się z wynikami testów, a protokoły kierownictwa z ryzykiem pokazanym w raportach. 15. Siedem cech dobrego dowodu zgodności Dobry materiał jest: istotny: wspiera konkretne wymaganie lub kontrolę; autentyczny: można ustalić źródło i właściciela; kompletny: zawiera zakres i kontekst potrzebny do interpretacji; dokładny: odzwierciedla rzeczywiste zdarzenie; terminowy: dotyczy właściwego okresu i powstał we właściwym czasie; chroniony: dostęp, integralność i poufność podlegają kontroli; możliwy do odnalezienia: uprawniony zespół potrafi go szybko pobrać. Te cechy pomagają zdecydować, czy zapis zwiększa zapewnienie, czy tylko objętość archiwum. 16. Retencja i bezpieczeństwo dokumentacji NIS2 nie ustanawia jednego okresu retencji dla każdego dowodu. Organizacja powinna uwzględnić ustawę krajową, przepisy sektorowe, terminy przedawnienia, cykle audytowe, umowy, potrzeby dochodzeń i ryzyko. Materiały mogą zawierać wrażliwe informacje o architekturze, podatnościach, osobach, poświadczeniach, dostawcach lub poradach prawnych. Powinny podlegać klasyfikacji i ochronie. Przygotowanie do oceny nie uzasadnia przechowywania nieograniczonych kopii w ogólnodostępnym folderze. Należy określić: zatwierdzone repozytoria i role dostępowe; wersjonowanie i status zatwierdzenia; retencję i bezpieczne usuwanie; legalhold i procedury dochodzeń; integralność i kopie zapasowe; bezpieczne przekazanie audytorowi lub organowi; obsługę danych osobowych i tajemnic; zwrot lub usunięcie kopii po ocenie. Minimalizacja danych pozostaje ważna. Dowód powinien być wystarczający, ale nie powinien ujawniać zbędnych danych osobowych, sekretów ani kompletnej konfiguracji zabezpieczeń. 17. Najczęstsze błędy w dokumentacji NIS2 17.1 Uznawanie polityki za dowód działania Polityka wymaga zapisów wykonania: przeglądów, logów, testów, decyzji i działań korygujących. 17.2 Gromadzenie zrzutów bez kontekstu Zrzut może nie wskazywać systemu, daty, populacji, filtrów ani recenzenta. W miarę możliwości stosuj kontrolowane eksporty i opisy. 17.3 Budowanie pakietu dopiero przed audytem Zbieranie w ostatniej chwili prowadzi do luk i niespójności. Generowanie dowodów powinno wynikać z normalnego działania kontroli. 17.4 Pozostawianie wygasłych wyjątków Wyjątek potrzebuje właściciela, zabezpieczenia kompensacyjnego i terminu wygaśnięcia. Kolejne przedłużenie wymaga odpowiedniej eskalacji. 17.5 Zbyt szeroki dostęp do wrażliwych materiałów Centralizacja ułatwia odszukanie, ale tworzy atrakcyjny cel. Stosuj klasyfikację, najmniejsze uprawnienia, rejestrowanie dostępu i bezpieczny transfer. 17.6 Ignorowanie sprzecznych zapisów Polityka może wymagać przeglądu kwartalnego, a zapis operacyjny pokazywać czynność roczną. Rozbieżność należy rozwiązać, a nie przedstawiać jako dwie niezależne prawdy. 17.7 Uznawanie certyfikacji za kompletny dowód KSC ISO/IEC 27001 może dostarczyć wartościowych zapisów. Nie dowodzi automatycznie prawidłowej samoidentyfikacji, rejestracji, krajowych procedur incydentowych i wszystkich obowiązków KSC. 18. Checklista dokumentacji zgodności z NIS2 Lista wspiera planowanie i wymaga dostosowania do sytuacji podmiotu. [ ] Analiza podlegania i właściwości organów jest zatwierdzona i aktualna. [ ] Zachowano dowody wpisu do Wykazu KSC i aktualizacji danych. [ ] Role oraz dostęp do S46 są przygotowane i przetestowane. [ ] Usługi, systemy, dane, personel, lokalizacje i dostawcy są zmapowani. [ ] SZBI ma określony zakres, właścicieli, polityki, cele i mechanizm przeglądu. [ ] Zatwierdzenie środków przez kierownictwo pozostawia wiarygodny ślad. [ ] Dokumentacja nadzoru i szkoleń kierownictwa jest aktualna. [ ] Role, eskalacja i uprawnienia do akceptacji ryzyka są zdefiniowane. [ ] Metodyka, oceny, rejestr i plany postępowania z ryzykiem są utrzymywane. [ ] Polityki są wersjonowane, zatwierdzane i połączone z procedurami. [ ] Zapisy incydentów zachowują czas, decyzje, działania i zgłoszenia. [ ] Decyzje o braku zgłoszenia istotnych zdarzeń mają uzasadnienie. [ ] Dokumentacja ciągłości odpowiada usługom krytycznym. [ ] Testy kopii i odtwarzania pokazują rzeczywistą zdolność odzyskania usługi. [ ] Rejestr, klasyfikacja, due diligence i monitoring dostawców są aktualne. [ ] Umowy i plany wyjścia odpowiadają krytyczności dostawcy. [ ] Zapisy podatności, aktualizacji, konfiguracji i zmian pokazują działanie kontroli. [ ] Dostępy, konta uprzywilejowane i wyjątki MFA podlegają przeglądowi. [ ] Klucze i certyfikaty kryptograficzne są ewidencjonowane oraz monitorowane. [ ] Szkolenia są dopasowane do ról i mają mierniki skuteczności. [ ] Testy i audyty prowadzą do działań z właścicielem i terminem. [ ] Zamknięcie wysokiego ryzyka jest niezależnie weryfikowane. [ ] Retencja, dostęp, integralność i transfer dowodów są zdefiniowane. [ ] Indeks wskazuje brakujące lub nieaktualne materiały. [ ] Pakiet jest aktualizowany po incydentach, zmianach i aktualizacji prawa. 19. Pakiet dowodowy a wdrożenie i audyt Dokumentacja powinna wynikać z działających kontroli. Organizacje projektujące program mogą skorzystać z poradnika TTMS jak skutecznie wdrożyć dyrektywę NIS2. Ogólny katalog obowiązków omawia artykuł obowiązki przedsiębiorcy w zakresie cyberbezpieczeństwa – NIS2. Wdrożenie tworzy i uruchamia kontrole. Program dowodowy sprawia, że można wykazać ich właścicieli, decyzje, działanie i rezultaty. Audyt lub ocena sprawdza następnie, czy środki i dowody spełniają przyjęte kryteria. Pakiet dowodowy nie jest ustawowym audytem bezpieczeństwa z art. 15 KSC. Podmiot kluczowy powinien realizować obowiązek audytowy zgodnie z wymaganiami dotyczącymi częstotliwości, zakresu, kwalifikacji i niezależności audytorów. Dobrowolna analiza dokumentacji może przygotować organizację, ale nie zastępuje audytu, gdy ustawa go wymaga. 19. Dlaczego TTMS? Budowa modelu dowodowego NIS2 wymaga rozumienia regulacji, zarządzania i technologii generującej zapisy operacyjne. TTMS może wspierać organizacje w mapowaniu wymagań do usług, kontroli, właścicieli i źródeł dowodów, a następnie włączaniu zapisów do codziennych procesów. Wsparcie może obejmować ocenę gotowości dokumentacyjnej, projekt odpowiedzialności, mapowanie kontroli, ramy SZBI, zapewnienie dostawców, ćwiczenia incydentowe i odtworzeniowe, techniczną weryfikację środków oraz planowanie działań naprawczych. Celem nie jest tworzenie dokumentów dla samego ich posiadania. Organizacja potrzebuje zapisów odzwierciedlających działające zabezpieczenia i zapewniających kierownictwu wiarygodną informację. Zakres współpracy powinien odpowiadać sytuacji prawnej, obowiązkom KSC, ryzyku i istniejącym systemom zarządzania. Wnioski prawne powinny być potwierdzone przez właściwie wykwalifikowanych doradców, a dowody techniczne i organizacyjne rzetelnie je wspierać. 20. Przygotuj wiarygodny pakiet dowodowy NIS2 Nie warto czekać na wezwanie organu albo zapowiedź audytu. Zacznij od usług w zakresie, decyzji kierownictwa i kontroli chroniących te usługi. Następnie wskaż wiarygodne zapisy potwierdzające działanie oraz skuteczność. Skontaktuj się z TTMS, aby omówić ocenę gotowości dokumentacji i dowodów NIS2 dopasowaną do Twojej organizacji. Autorytatywne informacje można znaleźć w serwisie Komisji Europejskiej dotyczącym NIS2, materiałach ENISA wspierających wdrożenie NIS2 oraz oficjalnym tekście dyrektywy (UE) 2022/2555 w EUR-Lex. 21. Najczęściej zadawane pytania o dokumentację NIS2 Jakiej dokumentacji wymaga NIS2? NIS2 nie ustanawia jednego uniwersalnego pakietu. Podmiot powinien posiadać zapisy wystarczające do wykazania zaangażowania kierownictwa, proporcjonalnych środków zarządzania ryzykiem, zgłaszania poważnych incydentów i realizacji procedur krajowych. Typowe dowody obejmują analizę zakresu, SZBI, decyzje, ryzyko, kontrole operacyjne, dostawców, ciągłość, incydenty, mierniki, audyty i działania naprawcze. Czy sama polityka bezpieczeństwa wystarczy? Nie. Polityka opisuje oczekiwane działanie. Potrzebne mogą być zatwierdzenia, zapisy systemowe, przeglądy, wyniki testów, wyjątki, incydenty i działania korygujące łączące dokument z realną kontrolą. Czy polska ustawa wymaga SZBI? Tak. Podmioty kluczowe i ważne objęte KSC powinny wdrożyć system zarządzania bezpieczeństwem informacji zgodnie z wymaganiami ustawy. Zakres i środki muszą odpowiadać usługom, ryzyku i sytuacji podmiotu. Czy ISO 27001 wystarczy jako dowód? Nie automatycznie. Certyfikacja może dostarczyć wartościowych dowodów, lecz znaczenie mają jej zakres, wyłączenia i deklaracja stosowania. Samoidentyfikacja, Wykaz KSC, S46, procedury krajowe i obowiązki incydentowe wymagają odrębnej weryfikacji. Jak długo przechowywać dowody NIS2? Nie ma jednego okresu dla każdego materiału. Retencję należy określić na podstawie prawa krajowego, wymagań sektorowych, cyklu audytowego, przedawnienia, umów, potrzeb dochodzeń i ryzyka. Po ustaniu celu wrażliwe dane trzeba bezpiecznie usunąć. Czy wszystkie logi powinny trafić do pakietu? Nie. Logi mogą pozostać w systemach źródłowych, a indeks powinien wskazywać właściciela, zakres, retencję i sposób pobrania. Eksportuj tylko materiał potrzebny i odpowiednio chroń szczegóły techniczne. Jakie dowody powinno otrzymywać kierownictwo? Kierownictwo powinno otrzymywać informacje potrzebne do zatwierdzania i nadzoru: istotne ryzyko, status środków, poważne incydenty, nieskuteczne kontrole, dostawców krytycznych, testy, opóźnione działania i decyzje wymagające inwestycji lub akceptacji. Jak dokumentować decyzję o zgłoszeniu incydentu? Zapisz czas uzyskania wiedzy, dotknięte usługi, wpływ, kryteria, potwierdzone i niepotwierdzone fakty, osobę decyzyjną oraz podstawę zgłoszenia albo jego braku. Zachowaj kopie zgłoszeń, potwierdzeń i aktualizacji. Jakie dowody dotyczące dostawców są przydatne? Przydatne są klasyfikacja krytyczności, due diligence, raporty zapewniające, klauzule umowne, przeglądy dostępu, monitoring, współpraca incydentowa, ciągłość i plan wyjścia. Szczegółowość powinna odpowiadać dostępowi dostawcy i możliwemu wpływowi na usługi. Jak często aktualizować pakiet dowodowy? Należy ustalić harmonogram oparty na ryzyku i aktualizować materiały w toku normalnych działań. Dodatkowy przegląd jest potrzebny po poważnym incydencie, przejęciu, istotnej zmianie systemu lub usługi, rozpoczęciu współpracy z krytycznym dostawcą i zmianie prawa. Kto odpowiada za dokumentację zgodności? Odpowiedzialność jest rozproszona. Prawo lub compliance może utrzymywać mapę wymagań, natomiast bezpieczeństwo, IT, właściciele usług, zakupy, HR i ciągłość odpowiadają za własne zapisy. Centralny koordynator powinien utrzymywać indeks, kontrolę jakości i eskalację, ale nie stawać się sztucznym właścicielem każdej kontroli. Czy pakiet dowodowy zastępuje ustawowy audyt KSC? Nie. Pakiet ułatwia przygotowanie i wykazanie zgodności, ale nie zastępuje audytu bezpieczeństwa z art. 15, gdy taki obowiązek dotyczy podmiotu. Ustawowy audyt musi spełniać wymagania dotyczące zakresu, audytorów i niezależności.
Czytaj