Zakup oprogramowania w modelu secure-by-demand w 2026 roku

Jest wtorkowy poranek na początku 2026 roku. Maria, CISO szybko rozwijającej się europejskiej spółki płatniczej, prezentuje materiał zarządowi. Ostatni punkt agendy powinien być rutynowy: zatwierdzenie nowej platformy do wykrywania oszustw wspieranej przez AI. Dostawca ma przekonujące demo, rabat ograniczony czasowo, jednostronicowy opis zabezpieczeń i standardową umowę.

Wtedy zaczynają się pytania.

CEO pyta: „Skąd wiemy, że ta platforma jest bezpieczna? Nasi klienci z sektora usług finansowych proszą o dowody zgodności z DORA, a ten dostawca staje się częścią naszej krytycznej infrastruktury”.

Dział prawny pyta, czy umowa powierzenia przetwarzania danych (DPA) jest gotowa, gdzie będą przetwarzane dane klientów z UE i czy ujawniono podwykonawców przetwarzania. Osoba odpowiedzialna za odporność operacyjną pyta o plan wyjścia, eksport kopii zapasowych i ciągłość działania dla funkcji krytycznych. Inżynier bezpieczeństwa produktu pyta o ujawnianie podatności, dowody wdrażania poprawek oraz SBOM albo równoważne oświadczenie o przejrzystości komponentów. Zakupy zadają pytanie, które sprawia, że ryzyko dostawcy zaczyna generować realny koszt: „Czy możemy zatwierdzić teraz i zebrać dokumenty po podpisaniu umowy?”.

To moment, w którym nowoczesny zakup oprogramowania staje się albo zabezpieczeniem, albo przyszłym raportem z incydentu.

W 2026 roku bezpieczny zakup oprogramowania nie może opierać się na dobrej woli po zawarciu umowy. Bezpieczeństwo łańcucha dostaw w NIS2, ryzyko ICT stron trzecich w DORA, rozliczalność podmiotu przetwarzającego w GDPR oraz oczekiwania Cyber Resilience Act dotyczące bezpieczeństwa produktu przesunęły zapewnienie dostawców do punktu podejmowania decyzji zakupowej. Kupujący potrzebują zakupu oprogramowania w modelu secure-by-demand, w którym klient definiuje dowody bezpieczeństwa, klauzule umowne, bramki onboardingu i odpowiedzialności operacyjne przed zakupem.

Dla klientów Clarysec odpowiedzią nie jest kolejny arkusz kalkulacyjny, który ginie w poczcie elektronicznej. Jest nią system kontroli procesu zakupowego dostosowany do ISO/IEC 27001:2022, zmapowany przez polityki Clarysec, Zenith Blueprint: 30-etapową mapę drogową audytora oraz Zenith Controls, tak aby każdy zakup oprogramowania lub SaaS miał możliwą do obrony ścieżkę od potrzeby biznesowej do decyzji dotyczącej ryzyka dostawcy.

Secure-by-demand to nowe zabezpieczenie w procesie zakupu oprogramowania

Secure-by-design jest zwykle omawiane z perspektywy dostawcy. Secure-by-demand to dyscyplina po stronie kupującego: organizacja odmawia zakupu oprogramowania, jeżeli dostawca nie potrafi wykazać, że bezpieczeństwo, prywatność, odporność, obsługa podatności i audytowalność są wbudowane w ofertę.

Zmienia to rozmowę zakupową. Zamiast pytać: „Czy macie bezpieczeństwo?”, zakupy zadają precyzyjniejsze pytania:

• Jakie dane będziecie przetwarzać, gdzie i w jakiej roli prawnej?
• Która funkcja biznesowa będzie od was zależna i jak krytyczna jest ta zależność?
• Jakie dowody potwierdzają, że wasze zabezpieczenia działają, a nie tylko są udokumentowane?
• Do jakich terminów powiadamiania o incydentach zobowiążecie się umownie?
• Jakie dowody dotyczące ujawniania podatności, wdrażania poprawek, SBOM lub VEX możecie przedstawić?
• Którzy podwykonawcy lub podwykonawcy przetwarzania będą mieli kontakt z naszymi danymi lub usługą?
• Czy możemy audytować, kontrolować lub żądać dowodów w okresie obowiązywania umowy?
• Co dzieje się przy zakończeniu współpracy, migracji, naruszeniu, niewypłacalności lub zapytaniu organu regulacyjnego?

ISO/IEC 27001:2022 daje temu przesunięciu podstawę w systemie zarządzania. Klauzula 4 wymaga, aby organizacja rozumiała kontekst, strony zainteresowane i zakres SZBI, w tym zewnętrzne wymagania regulacyjne i wymagania dotyczące dostawców. Klauzula 5 przekształca ryzyko dostawcy w odpowiedzialność kierownictwa i element ładu zarządczego. Klauzula 6 wymaga oceny ryzyka, postępowania z ryzykiem, doboru zabezpieczeń, Deklaracji Stosowania i decyzji dotyczących ryzyka szczątkowego. Klauzula 8 wymaga kontrolowanej realizacji procesów, w tym procesów dostarczanych z zewnątrz. Klauzula 9 wymaga monitorowania, audytu wewnętrznego i przeglądu zarządzania.

Oznacza to, że zakup oprogramowania nie jest wyłącznie komercyjnym workflow. Staje się zarządzanym i audytowalnym procesem SZBI. Organy regulacyjne i audytorzy coraz częściej pytają, dlaczego organizacja zaakceptowała dostawcę, zanim zrozumiała ryzyko. Zakupy secure-by-demand dają jasną odpowiedź: ryzyko zostało ocenione, poddane postępowaniu, uregulowane umownie i przypisane, zanim powstała zależność.

Dlaczego NIS2, DORA, GDPR i CRA zbiegają się przy wyborze dostawcy

Zarząd Marii zadaje właściwe pytania, ponieważ jeden dostawca oprogramowania może uruchomić kilka obowiązków jednocześnie.

NIS2 ma zastosowanie według sektora, wielkości i krytyczności, a Annex I i Annex II obejmują wiele organizacji cyfrowych, finansowych, infrastrukturalnych, korzystających z dostawców usług zarządzanych oraz zależnych od chmury. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym bezpieczeństwa łańcucha dostaw, bezpiecznego pozyskiwania, bezpiecznego rozwoju i utrzymania, obsługi podatności, kontroli dostępu, zarządzania aktywami, ciągłości działania, obsługi incydentów oraz oceny skuteczności zabezpieczeń. Article 21(3) wymaga w szczególności uwzględnienia podatności bezpośrednich dostawców i praktyk cyberbezpieczeństwa stosowanych przez dostawców. Article 23 ustanawia stopniowane oczekiwania dotyczące zgłaszania znaczących incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin i powiadomienie w ciągu 72 godzin.

DORA ma zastosowanie od 17 stycznia 2025 roku do objętych zakresem podmiotów finansowych. Wprowadza jednolite wymagania dotyczące zarządzania ryzykiem ICT, zgłaszania incydentów związanych z ICT, testowania cyfrowej odporności operacyjnej oraz zarządzania ryzykiem ICT stron trzecich. DORA jest szczególnie nakazowa w obszarze zakupów. Podmioty finansowe potrzebują strategii ryzyka ICT stron trzecich, rejestrów ustaleń umownych dotyczących usług ICT, due diligence, analizy ryzyka koncentracji, pisemnych umów z postanowieniami dotyczącymi bezpieczeństwa i odporności, prawa do audytu i dostępu, obowiązków współpracy, praw wypowiedzenia oraz planów wyjścia. Articles 28 i 30 są kluczowe dla ryzyka ICT stron trzecich i kontroli umownych, natomiast Articles 17 do 23 kształtują zarządzanie incydentami i raportowanie.

GDPR dodaje bramkę rozliczalności podmiotu przetwarzającego. Articles 5, 28, 32, 33 i 34 wymagają rozliczalności, umów z podmiotami przetwarzającymi, odpowiedniego bezpieczeństwa, współpracy przy zgłaszaniu naruszeń oraz obsługi wpływu na osoby, których dane dotyczą. Dostawca SaaS przetwarzający dane osobowe nie jest tylko dostawcą. Staje się częścią postawy zgodności administratora. DPA, środki techniczne i organizacyjne, lista podwykonawców przetwarzania, zabezpieczenia transferu, reguły retencji i obowiązki usuwania muszą być zrozumiane przed rozpoczęciem przetwarzania.

Oczekiwania CRA dodają zapewnienie bezpieczeństwa produktu. Nawet gdy kupujący nie jest producentem, zespoły zakupowe powinny wymagać dowodów bezpiecznego rozwoju oprogramowania, obsługi podatności, wsparcia produktu, aktualizacji bezpieczeństwa, skoordynowanego ujawniania podatności i przejrzystości komponentów, takich jak SBOM lub równoważne oświadczenie. Te wymagania należą do RFP, załączników bezpieczeństwa i bramek akceptacji.

Wspólny motyw jest prosty: organizacja kupująca musi wiedzieć, co kupuje, jakie ryzyko wprowadza i jakie dowody może przedstawić, gdy zapytają o nie organy regulacyjne, klienci lub audytorzy.

Kręgosłup zabezpieczeń ISO 27001 dla zapewnienia dostawców

Najskuteczniejszy model zakupów secure-by-demand nie działa regulacja po regulacji. Jest oparty najpierw na zabezpieczeniach. Clarysec wykorzystuje ISO/IEC 27001:2022 jako kręgosłup SZBI, wspierany wytycznymi dotyczącymi zabezpieczeń ISO/IEC 27002:2022 oraz mapowaniem zgodności krzyżowej w Zenith Controls.

W Zenith Controls zapewnienie dostawców jest osadzone wokół zabezpieczeń ISO/IEC 27002:2022 5.19, 5.20 i 5.21. Nie są to odizolowane pozycje listy kontrolnej. Tworzą cykl życia procesu zakupowego.

Zenith Controls mapuje te zabezpieczenia ISO na oczekiwania regulacyjne i audytowe. Nie tworzy oddzielnych autorskich zabezpieczeń nazwanych Zenith Controls. Pomaga zespołom zrozumieć, w jaki sposób zabezpieczenia ISO/IEC 27002:2022 wspierają NIS2, DORA, GDPR, NIST CSF 2.0 oraz zapewnienie ukierunkowane na COBIT.

Znaczenie ma również wspierająca sieć zabezpieczeń. Zapewnienie dostawców łączy się z zarządzaniem aktywami, kontrolą dostępu, bezpieczeństwem chmury, zarządzaniem podatnościami, rejestrowaniem, zarządzaniem incydentami, gotowością ICT do zapewnienia ciągłości działania, bezpiecznym rozwojem oprogramowania, bezpieczeństwem aplikacji, zarządzaniem konfiguracją, kopiami zapasowymi, redundancją, zgodnością prawną, prywatnością, zarządzaniem zmianą i niezależnym przeglądem. Zakupy koordynują proces, ale właścicielstwo ryzyka musi obejmować właściciela biznesowego, bezpieczeństwo informacji, dział prawny, prywatność, IT, finanse i właściciela usługi.

Bramki polityk Clarysec przed podpisaniem umowy

Model polityk Clarysec celowo przesuwa zapewnienie dostawców na wcześniejszy etap. Najmocniejsze wymagania znajdują się tam, gdzie powinny: przed podpisaniem umów, przed aktywacją subskrypcji chmurowych i przed udostępnieniem danych.

Wersja SME polityki Clarysec Polityka bezpieczeństwa dostawców i stron trzecich stanowi:

Oceniaj i dokumentuj ryzyka dostawców przed podpisaniem umów lub przyznaniem dostępu.

Pochodzi to z sekcji „Cele”, klauzula polityki 3.3. Klauzula jest krótka, ponieważ intencja kontrolna jest nienegocjowalna: brak oceny ryzyka, brak umowy, brak dostępu.

Dla środowisk korporacyjnych polityka Clarysec Polityka bezpieczeństwa dostawców i stron trzecich wzmacnia bramkę przedumowną:

Wszyscy nowi dostawcy muszą przejść udokumentowaną ocenę bezpieczeństwa przed zawarciem umowy.

Pochodzi to z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1. Ta sama polityka wskazuje również „Prawo do audytu, inspekcji i żądania dowodów bezpieczeństwa” w sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.4.

W przypadku zakupu rozwiązań chmurowych i SaaS wersja SME Polityki korzystania z chmury obliczeniowej dodaje praktyczną bramkę akceptacji:

Każde korzystanie z usług chmurowych musi zostać przejrzane i zatwierdzone przez Dyrektora Generalnego (GM) przed wdrożeniem lub subskrypcją.

Pochodzi to z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1. W małej organizacji taka akceptacja może być odpowiednikiem komitetu zarządzania chmurą. W przedsiębiorstwie staje się procesem obejmującym zakupy, bezpieczeństwo, prywatność i architekturę. Korporacyjna Polityka korzystania z chmury obliczeniowej wspiera również umowne wymagania chmurowe, w tym egzekwowalne postanowienia w umowach z CSP.

W przypadku pozyskiwania oprogramowania korporacyjna Polityka wymagań bezpieczeństwa aplikacji jest jednoznaczna:

Pozyskiwanie oprogramowania lub uzgodnienia outsourcingowe muszą obejmować wymagania bezpieczeństwa w RFP, umowach i SLA, w tym postanowienia dotyczące terminów usuwania podatności oraz prawa do audytu przez stronę trzecią.

Pochodzi to z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.4. Zwróć uwagę na kolejność: RFP, umowy i SLA. Bezpieczeństwo pojawia się na etapie kontaktu z rynkiem, a nie jako załącznik po udzieleniu zamówienia.

W przypadku zakupów motywowanych GDPR wersja SME polityki Clarysec Polityka zgodności prawnej i regulacyjnej wymaga:

Klauzule umowy powierzenia przetwarzania danych (DPA) lub równoważne postanowienia umowne muszą zostać uzgodnione przed udostępnieniem jakichkolwiek danych osobowych lub wrażliwych.

Pochodzi to z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.2. Zapobiega to jednej z najczęstszych nieskuteczności onboardingu SaaS: przesłaniu danych osobowych do narzędzia przed uzgodnieniem warunków przetwarzania, obowiązków dotyczących naruszeń i warunków dotyczących podwykonawców przetwarzania.

W przypadku bezpieczeństwa aplikacji dostawcy wersja SME Polityki wymagań bezpieczeństwa aplikacji wymaga, aby zakupy:

określały obowiązki dotyczące ujawniania podatności, czasów reakcji i wdrażania poprawek.

Pochodzi to z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.2. Polityka stanowi również:

GM musi żądać dokumentacji lub certyfikacji (np. SOC 2, ISO 27001, raportów z testów bezpieczeństwa) jako dowodu zgodności dostawcy, tam gdzie ma to zastosowanie.

Pochodzi to z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.2. Kluczowym słowem jest dowód. Zakupy secure-by-demand nie opierają się na deklaracjach zaufania. Opierają się na artefaktach możliwych do przeglądu.

Bramka zakupowa Zenith Blueprint

Zenith Blueprint traktuje bezpieczeństwo dostawców jako działające zabezpieczenie, a nie hasło zakupowe. W fazie Controls in Action, Step 23 obejmuje zabezpieczenia organizacyjne 5.19 do 5.37, w tym bezpieczeństwo informacji w relacjach z dostawcami.

Blueprint wyjaśnia:

Zaczyna się od klasyfikacji dostawcy. Nie wszyscy dostawcy niosą takie samo ryzyko. Firma sprzątająca może mieć fizyczny dostęp do biur, ale nie do sieci. Firma wykonująca testy penetracyjne albo dostawca hostingu chmurowego może natomiast mieć głęboki techniczny dostęp do samego serca infrastruktury. Klasyfikacja powinna uwzględniać, czy dostawca bezpośrednio obsługuje lub przetwarza informacje, czy dostarcza infrastrukturę lub platformy, na których organizacja działa, czy zarządza systemami lub utrzymuje je w imieniu organizacji oraz czy jego naruszenie mogłoby wpłynąć na cele dotyczące poufności, integralności lub dostępności.

Dla zabezpieczenia 5.20 Blueprint jest bezpośredni:

Kluczowe obszary zwykle ujmowane w umowach z dostawcami obejmują obowiązki dotyczące poufności; odpowiedzialności w zakresie kontroli dostępu; środki techniczne i organizacyjne dla ochrony danych, szyfrowania, bezpiecznej transmisji, kopii zapasowych i zobowiązań dostępności; terminy i protokoły zgłaszania incydentów; prawo do audytu, w tym częstotliwość, zakres i dostęp do odpowiednich dowodów; kontrole podwykonawców; oraz postanowienia końcowe, takie jak zwrot lub zniszczenie danych, odzyskanie aktywów i dezaktywacja kont.

Blueprint stwierdza, że zabezpieczenie 5.20 jest „ostatnią linią wpływu” i „należy do bramki zakupowej”. Po podpisaniu umowy siła negocjacyjna spada. Przed podpisaniem dowody i obowiązki mogą stać się warunkami zakupu.

Dla rozwoju oprogramowania w modelu outsourcingowym faza Controls in Action, Step 21, zabezpieczenie 8.30, dodaje kolejne wymaganie zakupowe. Blueprint stwierdza:

U podstaw tego zabezpieczenia leży zasada, że bezpieczeństwo musi być wymogiem umownym, a nie ustnym oczekiwaniem.

Zespoły outsourcingowe powinny spełniać te same standardy bezpiecznego rozwoju oprogramowania co zespoły wewnętrzne, w tym analizę statyczną, przegląd wzajemny, szyfrowanie, MFA do repozytoriów oraz widoczność kodu, decyzji architektonicznych, podatności, wniosków o zmianę, logów CI/CD i wyników skanowania.

Zbuduj bramkę RFP secure-by-demand w jedno popołudnie

Załóżmy, że organizacja chce platformy analityki klientów. Będzie ona przyjmować identyfikatory klientów, zdarzenia behawioralne, metadane wsparcia i referencje transakcji. Właściciel biznesowy chce szybkiej akceptacji. Zespół bezpieczeństwa ma tydzień.

Zacznij od zapisu bramki zakupowej, korzystając z Polityki bezpieczeństwa dostawców i stron trzecich, Polityki wymagań bezpieczeństwa aplikacji, Polityki korzystania z chmury obliczeniowej, Polityki zgodności prawnej i regulacyjnej oraz Step 23 Zenith Blueprint jako dokumentów źródłowych.

Dołącz do RFP kwestionariusz secure-by-demand. Unikaj ogólnych pytań typu „Czy szyfrujecie dane?”. Zadawaj pytania oparte na dowodach:

1. Przedstaw aktualny niezależny raport zapewnienia bezpieczeństwa, certyfikat lub równoważne dowody skuteczności zabezpieczeń.
2. Wskaż lokalizacje hostingu, opcje rezydencji danych, lokalizacje kopii zapasowych oraz lokalizacje dostępu wsparcia.
3. Przedstaw DPA, listę podwykonawców przetwarzania i proces powiadamiania o zmianach podwykonawców przetwarzania.
4. Potwierdź terminy powiadamiania o incydentach, w tym wsparcie dla wczesnego ostrzeżenia w ciągu 24 godzin, gdy mogą zostać uruchomione procesy NIS2, oraz wsparcie raportowania etapowego dla klientów regulowanych DORA.
5. Przedstaw politykę ujawniania podatności, SLA dla poprawek według wagi oraz dowody bieżącego nadzoru nad usuwaniem podatności.
6. Przedstaw dowody bezpieczeństwa produktu, takie jak opis cyklu życia bezpiecznego rozwoju oprogramowania, podsumowanie testów penetracyjnych, SBOM lub oświadczenie o przejrzystości komponentów oraz okres wsparcia aktualizacji bezpieczeństwa.
7. Potwierdź MFA, zasadę najmniejszych uprawnień, rejestrowanie, monitorowanie dostępu administracyjnego oraz prawa klienta do audytu lub żądania dowodów.
8. Opisz eksport, usuwanie, zwrot, wsparcie zakończenia współpracy i pomoc w przejściu.
9. Wymień istotnych podwykonawców i zależności ICT wspierające usługę.
10. Potwierdź, czy dane klienta są używane do trenowania, analityki, doskonalenia produktu lub rozwoju modeli AI, oraz wskaż podstawę prawną lub model polecenia podmiotu przetwarzającego.

Następnie oceń dostawcę przed negocjacjami.

Na koniec zaktualizuj rejestr ryzyk i Deklarację Stosowania. Zapis postępowania z ryzykiem powinien pokazywać, dlaczego zabezpieczenia ISO/IEC 27002:2022 5.19, 5.20 i 5.21 mają zastosowanie, które wymagania umowne i techniczne zostały wybrane, kto jest właścicielem ryzyka szczątkowego oraz jaka częstotliwość monitorowania obowiązuje. Jeżeli biznes chce kontynuować mimo luk, użyj formalnego zapisu akceptacji ryzyka z datą wygaśnięcia, środkami kompensującymi i zatwierdzeniem przez kierownictwo wykonawcze.

Klauzule umowne, które zamieniają regulacje w egzekwowalne obowiązki

Oczekiwania bezpieczeństwa muszą stać się zobowiązaniami umownymi. Certyfikat może być przydatny, ale rzadko odpowiada na każde pytanie dotyczące konkretnej usługi, lokalizacji danych, podwykonawców, modelu wsparcia, zobowiązań incydentowych lub praw wyjścia.

Ta tabela jest praktycznym pomostem między obowiązkami prawnymi a pracą zakupową. Pomaga również działom prawnym, bezpieczeństwa i zakupów negocjować z tej samej bazowej konfiguracji zabezpieczeń.

Mapowanie zgodności krzyżowej: jeden plik dostawcy, wiele obowiązków

Zaletą wykorzystania ISO/IEC 27001:2022 jako kręgosłupa jest to, że jeden plik zapewnienia dostawcy może wspierać wiele rozmów regulacyjnych.

NIST CSF 2.0 jest użyteczny jako warstwa komunikacyjna. Jego funkcja GOVERN podkreśla świadomość prawną, regulacyjną, umowną, prywatnościową i zależnościową. Wyniki GV.SC dotyczące łańcucha dostaw wymagają procesów zarządzania ryzykiem łańcucha dostaw, ról dostawców, priorytetyzacji dostawców według krytyczności, wymagań umownych, due diligence, monitorowania, planowania incydentów i planowania zakończenia współpracy.

Mapuje się to wprost na Step 23 Zenith Blueprint oraz zabezpieczenia ISO/IEC 27002:2022 5.19 do 5.21, zgodnie z mapowaniem w Zenith Controls. Daje też zarządom język, który rozumieją: stan obecny, stan docelowy, luka, ryzyko, działanie, właściciel i data.

O co zapytają audytorzy

Silny proces zakupów secure-by-demand powinien wytrzymać różne perspektywy audytowe.

Audytor ISO/IEC 27001:2022 zacznie od kontekstu i zakresu SZBI. Zapyta, czy interfejsy i zależności dostawców są ujęte, czy wymagania stron zainteresowanych obejmują NIS2, DORA, GDPR i umowy z klientami oraz czy ryzyka dostawców są konsekwentnie oceniane zgodnie z metodyką ryzyka. Następnie przejdzie ścieżką do postępowania z ryzykiem, Deklaracji Stosowania, zabezpieczeń dostawców, dowodów operacyjnych, audytu wewnętrznego i przeglądu zarządzania.

Recenzent DORA skoncentruje się na funkcjach biznesowych wspieranych przez ICT, funkcjach krytycznych lub ważnych, zapisach zależności od stron trzecich, klauzulach umownych, prawach audytu i dostępu, współpracy przy incydentach, testowaniu odporności, strategiach wyjścia i ryzyku koncentracji. Jeżeli SaaS wspiera funkcję krytyczną lub ważną, lekki kwestionariusz dostawcy nie wystarczy.

Organ właściwy dla NIS2 zapyta, w jaki sposób organizacja oceniła praktyki cyberbezpieczeństwa dostawców, podatności bezpośrednich dostawców, wsparcie powiadamiania o incydentach, zależności ciągłości działania i decyzje dotyczące bezpiecznego pozyskiwania. Sprawdzi, czy zapewnienie dostawców wspiera własne obowiązki organizacji wynikające z Article 21 i Article 23.

Recenzent GDPR zapyta, czy role administratora i podmiotu przetwarzającego zostały zrozumiane przed rozpoczęciem przetwarzania, czy DPA lub równoważne warunki zostały uzgodnione przed udostępnieniem danych, czy podwykonawcy przetwarzania zostali ujawnieni, czy środki bezpieczeństwa były odpowiednie, czy współpraca przy naruszeniach jest umowna oraz czy zwrot lub usunięcie danych jest egzekwowalne.

Audytor w stylu COBIT 2019 lub ISACA skoncentruje się na ładzie i rozliczalności: kto zatwierdził dostawcę, jakie ryzyko zaakceptowano, czy wymagania polityki były przestrzegane, czy wyjątki są śledzone oraz czy zrównoważono korzyści, ryzyko i zasoby.

Pakiet dowodów powinien obejmować klasyfikację dostawcy, akceptację właściciela biznesowego, ocenę ryzyka, wymagania bezpieczeństwa w RFP, odpowiedzi dostawcy, DPA, załącznik bezpieczeństwa, SLA, prawo do audytu, rejestr podwykonawców przetwarzania, zobowiązania dotyczące podatności, klauzule incydentowe, dowody lokalizacji chmury, dowody rejestrowania i szyfrowania, warunki wyjścia, zapisy ponownej oceny, wyjątki oraz mapowanie Deklaracji Stosowania.

Typowe wzorce nieskuteczności przy zakupie oprogramowania

Pierwszym błędem jest traktowanie zakupów jako procesu komercyjnego, a bezpieczeństwa jako procesu technicznego. Zanim bezpieczeństwo otrzyma umowę, biznes jest już psychologicznie zaangażowany, data wdrożenia została ogłoszona, a siła negocjacyjna jest słaba.

Drugim błędem jest zastępowanie dowodów. Dostawca przedstawia certyfikat, a kupujący zakłada, że odpowiada on na każde pytanie. Certyfikacja może pomóc, ale może nie obejmować konkretnego produktu, regionu hostingu, modelu wsparcia, łańcucha podwykonawców, obowiązków incydentowych, wykorzystania danych przez AI ani wymagań wyjścia.

Trzecim błędem jest pominięcie ryzyka niższego szczebla. Dostawca SaaS może polegać na hostingu chmurowym, narzędziach analitycznych, platformach wsparcia, zagranicznych zespołach rozwoju oprogramowania, dostawcach modeli AI i podmiotach przetwarzających płatności. Zabezpieczenie ISO/IEC 27002:2022 5.21 wymaga uwzględnienia łańcucha dostaw ICT stojącego za bezpośrednim dostawcą. W DORA łączy się to z podwykonawstwem i ryzykiem koncentracji. W GDPR łączy się to z podwykonawcami przetwarzania. W NIS2 łączy się to z podatnościami bezpośrednich dostawców i praktykami cyberbezpieczeństwa dostawców.

Czwartym błędem jest słaby język incydentowy. Umowa, która stanowi, że „dostawca niezwłocznie powiadomi klienta”, może nie wspierać wczesnego ostrzeżenia NIS2, etapowego raportowania DORA, komunikacji z klientami ani wewnętrznej eskalacji. Klauzule incydentowe wymagają terminów, wyzwalaczy, kontaktów, obowiązków współpracy i obowiązków dowodowych.

Piątym błędem są niejasne prawa wyjścia. Jeżeli dostawca staje się niebezpieczny, niezgodny, przejęty, niewypłacalny lub strategicznie nieodpowiedni, kupujący potrzebuje eksportu, usunięcia, wsparcia przejścia, dezaktywacji kont i dowodu zniszczenia. Wyjście nie jest prawnym dodatkiem po fakcie. Jest zabezpieczeniem odporności.

Od bramki zakupowej do żywego zapewnienia dostawców

Zakupy secure-by-demand nie kończą się w momencie podpisania umowy. Dojrzały cykl życia dostawcy w stylu Clarysec ma pięć etapów.

W przypadku dostawców wysokiego ryzyka monitorowanie powinno obejmować odświeżanie dowodów, spotkania przeglądu bezpieczeństwa, udział w ćwiczeniach typu tabletop dotyczących incydentów, przegląd praw dostępu, raportowanie podatności i poprawek, przegląd zmian w usłudze oraz aktualizacje dotyczące podwykonawców przetwarzania. W przypadku dostawców niższego ryzyka wystarczający może być coroczny przegląd. Skalowalność ISO 27001, proporcjonalność NIS2 i proporcjonalność DORA wspierają dostosowanie, ale dostosowanie musi być uzasadnione i udokumentowane.

Następny krok z Clarysec

Następny ryzykowny zakup SaaS nie zaczeka na idealne przeprojektowanie ładu zarządczego. Zacznij od kolejnego wniosku zakupowego.

Wykorzystaj Zenith Blueprint: 30-etapową mapę drogową audytora, aby wdrożyć Step 23 dotyczący zabezpieczeń relacji z dostawcami oraz Step 21 dotyczący zabezpieczeń rozwoju oprogramowania w modelu outsourcingowym. Użyj Zenith Controls, aby zmapować zabezpieczenia ISO/IEC 27002:2022 5.19, 5.20 i 5.21 na NIS2, DORA, GDPR, NIST CSF 2.0 oraz oczekiwania audytowe ukierunkowane na COBIT. Skorzystaj z biblioteki polityk Clarysec, w tym Polityki bezpieczeństwa dostawców i stron trzecich, Polityki wymagań bezpieczeństwa aplikacji, Polityki korzystania z chmury obliczeniowej i Polityki zgodności prawnej i regulacyjnej, aby uczynić bramkę egzekwowalną.

Przed podpisaniem kolejnej umowy wymagaj klasyfikacji dostawcy, dowodów bezpieczeństwa, gotowości DPA, zobowiązań incydentowych, obsługi podatności, przejrzystości podwykonawców, prawa do audytu i warunków wyjścia.

To właśnie są zakupy secure-by-demand. Tak CISO zamieniają presję regulacyjną w siłę zakupową. Tak menedżerowie zgodności przekształcają nakładające się obowiązki w jeden plik dowodowy. Tak audytorzy widzą, że ryzyko dostawcy zostało rozważone, zanim powstała zależność. I tak właściciele biznesowi kupują oprogramowanie szybciej, nie przejmując niezarządzanego ryzyka.

Chcesz przekształcić kolejny zakup oprogramowania w zabezpieczenie gotowe do audytu? Poznaj zintegrowany pakiet polityk Clarysec, pobierz Zenith Blueprint, przejrzyj Zenith Controls albo umów demo, aby zbudować program zakupów secure-by-demand odporny na NIS2, DORA, GDPR, oczekiwania CRA i rzeczywistą kontrolę audytora.