Wdrażanie nowych systemów IT to jeden z najważniejszych momentów decyzyjnych w każdej organizacji.
Od trafności tych decyzji zależy nie tylko efektywność działania firmy, ale też podatność na zagrożenia
i zgodność z przepisami. Niestety, zbyt często bezpieczeństwo IT bywa traktowane jako dodatek – coś, czym "zajmiemy się później". To błąd, który kosztuje.
W tym artykule chcę Ci pokazać bezpieczne pozyskiwanie systemów IT. Niezależnie od tego, czy przygotowujesz zapytanie ofertowe (RFP), oceniasz dostawcę, czy właśnie szykujesz się do wdrożenia. Znajdziesz tu konkretne wskazówki, które pozwolą Ci działać pewnie i świadomie.
Nowy system IT to nie tylko technologia. To również zmiana sposobu przetwarzania danych, nowe interfejsy, nowe odpowiedzialności – a także nowe wektory ataku. Jeśli nie uwzględnisz tych kwestii w fazie planowania, ryzyko wzrośnie już na starcie. Dotyczy to zarówno dużych korporacji, jak i mniejszych firm, które często niedoszacowują zagrożeń w obliczu ograniczonych zasobów.
Bezpieczne pozyskiwanie zaczyna się od:
• analizy potrzeb i ryzyka, a nie katalogu funkcjonalności,
• jasnych wymagań bezpieczeństwa w zapytaniu ofertowym (RFP),
• weryfikacji dostawców pod kątem bezpieczeństwa, a nie tylko ceny, warunków umownych, które uwzględniają incydenty, ciągłość działania i odpowiedzialność.
Nie wystarczy wiedzieć, co ma robić system. Trzeba też określić:
• jakie dane będzie przetwarzał (czy zawiera dane osobowe, finansowe, tajemnice przedsiębiorstwa),
• jakie przepisy go obejmują (RODO, KRI, ustawa o KSC, NIS2),
• jakie scenariusze zagrożeń należy wziąć pod uwagę (np. ataki supply chain, błędy dostawcy, wycieki danych).
Warto w tym miejscu zaangażować nie tylko IT, ale również dział prawny, bezpieczeństwa i właścicieli procesów.
Dla mniejszych firm, które często działają z ograniczonymi zasobami, kluczowe jest skupienie się na fundamentach bezpieczeństwa.
Zamiast skomplikowanych analiz, warto zadać sobie podstawowe pytania:
• jakie dane są najcenniejsze (np. dane klientów, finansowe, handlowe),
• kto ma do nich dostęp i co by się stało, gdyby te dane wyciekły lub zostały zaszyfrowane?
Ogólnodostępne uproszczone szablony wymagań bezpieczeństwa mogą być dobrym punktem wyjścia.
Nawet krótka konsultacja z ekspertem ds. cyberbezpieczeństwa na wczesnym etapie może pomóc zidentyfikować największe ryzyka i uniknąć kosztownych błędów w przyszłości, co w dłuższej perspektywie jest inwestycją, a nie wydatkiem.
W dobrze przygotowanym zapytaniu powinny się znaleźć:
• wymagania dotyczące kontroli dostępu, szyfrowania, logowania zdarzeń, backupu, testów bezpieczeństwa,
• informacje o oczekiwanych certyfikacjach (np. ISO/IEC 27001, SOC2),
• zasady integracji z innymi systemami i ich wpływu na bezpieczeństwo,
• wymagania umożliwiające przeprowadzenie audytu oraz zapewnienie zgodności z przepisami.
To także moment, by zaznaczyć oczekiwania dotyczące transparentności i zabezpieczenia ciągłości działania.
Należy rozważyć i określić wymagania w zakresie:
• dostępu do dokumentacji technicznej i kodu źródłowego: w przypadku systemów dedykowanych lub rozwiązań open source warto dążyć do uzyskania pełnego dostępu do kodu źródłowego, w przypadku oprogramowania komercyjnego (COTS) kluczowy jest depozyt kodu (escrow), który gwarantuje dostęp do niego w określonych sytuacjach (np. upadłość dostawcy, zaprzestanie wsparcia);
• wglądu w wyniki testów bezpieczeństwa (np. testów penetracyjnych, skanów podatności);
• pełnej dokumentacji systemu, jego architektury i zasad działania.
Dobry dostawca systemu IT to taki, który:
• ma udokumentowane procesy zarządzania bezpieczeństwem,
• potrafi pokazać wyniki audytów i testów penetracyjnych,
• rozumie, czym jest DevSecOps i ma doświadczenie w pracy z klientami regulowanymi (czyli organizacjami podlegającymi specjalnym regulacjom prawnym – np. bankami, instytucjami publicznymi czy operatorami usług kluczowych),
• zapewnia wsparcie posprzedażowe i reagowanie na incydenty.
Nie bój się zadawać trudnych pytań – np. o wcześniejsze incydenty, politykę zarządzania lukami bezpieczeństwa czy szczegóły procesu aktualizacji.
W kontrakcie powinny się znaleźć:
• SLA (Service Level Agreement) z czasem reakcji i przywrócenia działania systemu,
• zasady testowania i wdrażania aktualizacji (kto testuje? na jakim środowisku?),
• opis procedur awaryjnych i komunikacji podczas incydentu,
• zasady przeniesienia praw do kodu źródłowego (lub depozytu kodu),
• kary umowne za niedotrzymanie poziomu bezpieczeństwa.
Wyobraź sobie sytuację: Twoja firma wdraża nowy system do zarządzania projektami. W umowie zabrakło jasnych zapisów o tym, kto odpowiada za usuwanie luk bezpieczeństwa odkrytych już po wdrożeniu, zwłaszcza tych
w komponentach open-source, na których system bazuje. Miesiąc po uruchomieniu, zewnętrzny audyt wykrywa krytyczną podatność w jednej z bibliotek. Dostawca odmawia bezpłatnej poprawki, twierdząc, że to nie jego kod, a Ty zostajesz z systemem obarczonym poważnym ryzykiem i koniecznością ponoszenia dodatkowych kosztów na własną rękę. Jasne określenie odpowiedzialności za takie scenariusze już na etapie RFP i umowy jest kluczowe.
Zanim podpiszesz odbiór systemu:
• zweryfikuj spełnienie wymagań bezpieczeństwa,
• przeprowadź testy penetracyjne lub przynajmniej skan podatności,
• sprawdź zgodność z wymaganiami prawnymi (np. logowanie zgodne z RODO, uwierzytelnianie dwuskładnikowe),
• upewnij się, że dokumentacja i szkolenie użytkowników są kompletne – obejmują zarówno obsługę systemu, jak i dobre praktyki bezpieczeństwa oraz procedury awaryjne.
W lipcu 2024 r. błędna aktualizacja od CrowdStrike doprowadziła do globalnej awarii komputerów z Windows – w tym również w Polsce. Wiele firm nie miało w umowach mechanizmów awaryjnych, procedur reagowania ani zapisów o odpowiedzialności dostawcy. Efekt? Przestoje, ręczna obsługa procesów, straty liczone w milionach złotych.
To pokazuje, że bezpieczeństwo systemu to nie tylko technologia, ale też warunki umowy i gotowość organizacji do działania w kryzysie.
Co z utrzymaniem? Planowanie bezpieczeństwa to też inwestycja w przyszłość.
Choć ten artykuł skupia się na etapie pozyskiwania, warto pamiętać, że decyzje podjęte dziś będą miały wpływ na to, jak bezpieczne i odporne będą Twoje systemy za rok, dwa i pięć lat.
Bezpieczeństwo nie kończy się na wdrożeniu. To także odpowiedzialne utrzymanie – obejmujące monitorowanie, reagowanie, testowanie i ciągłe doskonalenie.
Dlatego już teraz zaplanuj:
• sposób zarządzania zmianami i aktualizacjami,
• procesy reagowania na incydenty,
• odpowiedzialność właścicieli systemów,
• systematyczne testowanie zabezpieczeń i przeglądy konfiguracji, mechanizmy raportowania i przeglądów zgodności z przepisami.
Bezpieczne pozyskiwanie systemów IT to nie tylko działanie zgodne z procedurami – to przede wszystkim świadome zarządzanie ryzykiem na etapie, gdy najłatwiej można mu zapobiec. Dobrze zaplanowane zapytanie ofertowe (RFP), rzetelna ocena dostawcy, wymagania bezpieczeństwa i mądrze skonstruowana umowa – to fundamenty skutecznego wdrożenia.
W świecie, gdzie cyfrowe incydenty mogą zatrzymać całą organizację, bezpieczny proces zakupowy to inwestycja strategiczna, a nie wydatek. Nie pozwól, by temat cyberbezpieczeństwa wypłynął wyłącznie w formie bolesnego post mortem po kryzysie. Działaj proaktywnie, tworząc cyfrową przyszłość swojej firmy na solidnych
i odpornych podstawach.
Planując bezpieczne pozyskiwanie systemów IT, warto znać i stosować się do poniższych dokumentów:
Normy i dobre praktyki:
• ISO/IEC 27001 – system zarządzania bezpieczeństwem informacji (wymagania),
• ISO/IEC 27002 – wytyczne dotyczące zabezpieczeń technicznych i organizacyjnych,
• ISO/IEC 27005 – zarządzanie ryzykiem w obszarze bezpieczeństwa informacji,
• ISO/IEC 27036 – bezpieczeństwo informacji w relacjach z dostawcami (w tym część 3: pozyskiwanie rozwiązań IT),
• CIS Controls – zbiór praktycznych zaleceń poprawiających bezpieczeństwo systemów IT,
• OWASP ASVS – standardy bezpieczeństwa aplikacji (szczególnie przydatne przy odbiorze systemów webowych).
Polskie i europejskie regulacje:
• Ustawa o krajowym systemie cyberbezpieczeństwa (KSC) – obowiązuje operatorów usług kluczowych i niektóre jednostki sektora publicznego, nakłada obowiązek analizy ryzyka, stosowania środków technicznych
i formalnych oraz zawierania umów z dostawcami IT;
• Rozporządzenie RODO (UE 2016/679) – dotyczy przetwarzania danych osobowych w systemach IT;
• Ustawa o ochronie danych osobowych (Dz.U. 2018 poz. 1000) – krajowe uzupełnienie przepisów RODO;
• NIS2 – nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa zaimplementuje wymagania NIS2 na grunt polskiego prawodawstwa, rozszerzając obowiązki w zakresie bezpieczeństwa systemów IT;
• KRI – Krajowe Ramy Interoperacyjności – obowiązujące w administracji publicznej, określają minimalne wymagania dla systemów IT w zakresie bezpieczeństwa i interoperacyjności.
Po więcej sprawdzonych wskazówek i pogłębionej wiedzy na temat cyberbezpieczeństwa zapraszam na cybershieldon.pl - miejsce dla tych, którzy tak jak my, traktują bezpieczeństwo poważnie.
Marta Gach
Specjalistka PMO | Zarządzanie projektami |Edukacja cyberświadomości |Media i kreacja
Ten blog ma charakter prywatny. Zamieszczane treści wyrażają osobiste poglądy autorów i nie są powiązane z żadną firmą ani instytucją.
© 2025 Wszelkie prawa zastrzeżone.
Strona www stworzona w kreatorze WebWave.