Jakie regulacje wymagają skanów podatności? Skany podatności wymagają wprost dwa reżimy: PCI DSS (skany wewnętrzne i zewnętrzne ASV co najmniej raz na 3 miesiące) oraz DORA (przez RTS 2024/1774 – automatyczne skany co najmniej raz w tygodniu dla aktywów wspierających funkcje krytyczne). NIS2, Cyber Resilience Act, ISO 27001:2022 i SOC 2 nie podają częstotliwości, ale wymagają udokumentowanego procesu identyfikacji i usuwania podatności, którego skany są jedynym skalowalnym źródłem.
Organizacja podlegająca kilku reżimom naraz nie potrzebuje kilku programów skanów – potrzebuje jednego, zaprojektowanego pod najostrzejszy wymóg i dokumentowanego pod każdy audyt. Czym jest skan podatności i jak go konfigurować, opisaliśmy w hubie Skany podatności infrastruktury.
Definicja kanoniczna: Program zarządzania podatnościami to udokumentowany, ciągły zestaw procedur obejmujący inwentaryzację aktywów, skanowanie, priorytetyzację, remediację i weryfikację podatności, wymagany w różnej formie przez PCI DSS, DORA, NIS2, CRA, ISO 27001 i SOC 2.
Skany podatności a compliance – w skrócie:
- PCI DSS v4.0.1 (wymogi 11.3.1-11.3.2) to jedyny standard z liczbowo określoną częstotliwością skanów dla wszystkich podmiotów w zakresie: co 3 miesiące i po istotnej zmianie, wewnętrzne uwierzytelnione od 31 marca 2025.
- DORA przez RTS 2024/1774 art. 10 wymaga skanów co najmniej raz w tygodniu dla aktywów wspierających funkcje krytyczne lub istotne oraz śledzenia bibliotek open source.
- NIS2 (art. 21 ust. 2 lit. e) i ISO 27001:2022 (A.8.8) wymagają procesu obsługi podatności bez podanej częstotliwości – audytor oceni, czy częstotliwość wynika z analizy ryzyka.
- CRA przenosi obowiązek na producentów oprogramowania: SBOM, obsługa podatności w cyklu życia produktu, a od 11 września 2026 zgłaszanie aktywnie wykorzystywanych podatności do ENISA i CSIRT w 24 godziny.
- Jeden program skanów zaprojektowany pod DORA (tygodniowy rytm, uwierzytelnienie, rejestr, SBOM) spełnia jednocześnie wymogi PCI DSS, NIS2, ISO 27001 i SOC 2 – różnią się tylko dowody.
- Patronusec jako akredytowany QSA i audytor ISO 27001 projektuje programy skanów tak, aby jeden zestaw raportów służył wszystkim audytom, i realizuje skany wewnętrzne, zewnętrzne oraz ASV.
Spis treści
Które regulacje wymagają skanów podatności i co dokładnie mówią?
Sześć reżimów odnosi się do skanów podatności w trzech różnych trybach: PCI DSS i DORA określają częstotliwość i zakres, NIS2 i ISO 27001 wymagają procesu opartego na ryzyku, a CRA i SOC 2 wymagają udokumentowanych procedur obsługi podatności bez wskazania narzędzia. Poniższa tabela mapuje każdy wymóg na konkretny artykuł lub kontrolę.
| Reżim | Przepis / kontrola | Co wymaga | Częstotliwość | Uwierzytelnienie | Rescan / weryfikacja |
|---|---|---|---|---|---|
| PCI DSS v4.0.1 | 11.3.1, 11.3.1.1, 11.3.1.2, 11.3.1.3 | skany wewnętrzne wszystkich komponentów w zakresie; usunięcie podatności wysokich i krytycznych; pozostałe wg analizy ryzyka | co 3 miesiące + po istotnej zmianie | wymagane od 31 mar 2025 | wymagany dla wysokich i krytycznych |
| PCI DSS v4.0.1 | 11.3.2, 11.3.2.1 | skany zewnętrzne przez ASV; po istotnej zmianie mogą być wewnętrzne | co 3 miesiące + po istotnej zmianie | nie dotyczy (zewnętrzny) | do uzyskania wyniku pozytywnego (brak CVSS ≥ 4,0) |
| PCI DSS v4.0.1 | 6.3.1, 6.3.2, 6.3.3 | identyfikacja podatności w oprogramowaniu, inwentarz komponentów (SBOM), poprawki krytyczne i wysokie w ciągu miesiąca | ciągłe | – | – |
| DORA | art. 25 rozporządzenia 2022/2554 | program testowania obejmujący m.in. oceny i skany podatności | co najmniej raz w roku dla systemów wspierających funkcje krytyczne (test) | – | – |
| DORA | RTS (UE) 2024/1774 art. 10 ust. 2 | procedury zarządzania podatnościami; automatyczne skany proporcjonalne do klasyfikacji aktywów; śledzenie bibliotek zewnętrznych; weryfikacja dostawców ICT; rejestr podatności | co najmniej raz w tygodniu dla aktywów wspierających funkcje krytyczne lub istotne | wynika z celu (pełny skan aktywa) | monitorowanie i weryfikacja remediacji |
| NIS2 | art. 21 ust. 2 lit. e dyrektywy 2022/2555 | bezpieczeństwo nabywania, rozwoju i utrzymania systemów, w tym postępowanie z podatnościami i ich ujawnianie | oparta na ryzyku | – | – |
| NIS2 | rozp. wykonawcze (UE) 2024/2690 (dostawcy usług cyfrowych) | procedury zarządzania podatnościami, w tym skanowanie i ocena | „regularnie”, proporcjonalnie do ryzyka | – | – |
| CRA | rozp. (UE) 2024/2847, zał. I część II | producenci: identyfikacja komponentów (SBOM), regularne testy i przeglądy bezpieczeństwa, usuwanie podatności, skoordynowane ujawnianie | w cyklu życia produktu | – | – |
| CRA | art. 14 | zgłaszanie aktywnie wykorzystywanych podatności: wczesne ostrzeżenie w 24 h, powiadomienie w 72 h, raport końcowy w 14 dni | od 11 wrz 2026 | – | – |
| ISO/IEC 27001:2022 | zał. A, A.8.8 | uzyskiwanie informacji o podatnościach technicznych, ocena narażenia, odpowiednie środki | oparta na ryzyku | – | – |
| ISO/IEC 27001:2022 | A.8.9, A.8.29 | zarządzanie konfiguracją; testy bezpieczeństwa w rozwoju i akceptacji | – | – | – |
| SOC 2 (AICPA TSC 2017, rev. 2022) | CC7.1 | procedury wykrywania i monitorowania podatności oraz zmian konfiguracji | zdefiniowana przez organizację | – | – |
| CIS Controls v8 | 7.1-7.7 | proces zarządzania podatnościami, skany uwierzytelnione wewnętrzne, zewnętrzne, remediacja | co najmniej co kwartał (7.5, 7.6) | tak (7.5) | tak (7.7) |
| TISAX (VDA ISA 6) | kontrola dot. zarządzania podatnościami | identyfikacja i usuwanie podatności w systemach IT | oparta na ryzyku | – | – |
Spośród głównych reżimów compliance tylko PCI DSS i DORA określają liczbowo częstotliwość skanów podatności – odpowiednio co 3 miesiące oraz co najmniej raz w tygodniu dla aktywów wspierających funkcje krytyczne lub istotne – pozostałe wymagają częstotliwości uzasadnionej analizą ryzyka.
Dwie obserwacje z tabeli. Po pierwsze, DORA jest najostrzejsza pod względem rytmu, PCI DSS – pod względem dowodów (rescan, wynik pozytywny ASV). Po drugie, wymogi „oparte na ryzyku” nie są łagodniejsze: audytor ISO 27001 lub kontrola NIS2 zapyta, dlaczego skanujesz co kwartał, i oczekuje odpowiedzi opartej na klasyfikacji aktywów, nie na wygodzie.
Jak zbudować jeden program skanów spełniający wszystkie reżimy naraz?
Jeden program budujesz metodą najostrzejszego wspólnego mianownika: przyjmujesz tygodniowy rytm dla aktywów krytycznych (DORA), kwartalny dla wszystkich pozostałych z rescanem podatności wysokich (PCI DSS), uwierzytelnienie wszędzie, gdzie to możliwe (PCI DSS, CIS), inwentarz komponentów i SBOM (PCI DSS 6.3.2, DORA, CRA) oraz rejestr podatności z właścicielem i terminem (DORA, ISO 27001). Różnice między reżimami obsługujesz warstwą dowodów, nie osobnymi skanami.
Osiem elementów wspólnego programu i reżimy, które spełniają:
| Element programu | PCI DSS | DORA | NIS2 | CRA | ISO 27001 | SOC 2 |
|---|---|---|---|---|---|---|
| 1. Rejestr aktywów z klasyfikacją (krytyczne / w zakresie / pozostałe) | 12.5.1 | art. 8 DORA | art. 21 | – | A.5.9 | CC6.1 |
| 2. Skan tygodniowy aktywów krytycznych | ponad wymóg | RTS art. 10 | dowód „regularności” | – | dowód A.8.8 | dowód CC7.1 |
| 3. Skan kwartalny wszystkich aktywów w zakresie + po zmianie | 11.3.1, 11.3.1.3 | uzupełnia | tak | – | tak | tak |
| 4. Skan zewnętrzny ASV kwartalny | 11.3.2 | dowód perymetru | tak | – | tak | tak |
| 5. Uwierzytelnienie skanów wewnętrznych | 11.3.1.2 | pełny skan aktywa | tak | – | tak | tak |
| 6. Inwentarz komponentów / SBOM | 6.3.2 | RTS art. 10 ust. 2 lit. d | art. 21 ust. 2 lit. e | zał. I cz. II | A.8.8 | tak |
| 7. Priorytetyzacja i SLA remediacji (CVSS + EPSS + KEV + kontekst) | 11.3.1.1, 6.3.3 | RTS art. 10 ust. 2 lit. f | tak | zał. I cz. II | A.8.8 | CC7.1 |
| 8. Rejestr podatności, rescan, raport dla zarządu | 11.3.1 (rescan) | RTS art. 10 ust. 2 lit. g-h | art. 20 (odpowiedzialność zarządu) | – | 9.1, 9.3 | CC4.1 |
Program skanów zaprojektowany pod najostrzejszy reżim – tygodniowy rytm i rejestr podatności z DORA oraz rescan i skany ASV z PCI DSS – spełnia jednocześnie wymogi NIS2, ISO 27001 i SOC 2, ponieważ te ostatnie wymagają procesu opartego na ryzyku, a nie konkretnej częstotliwości.
Dla organizacji, które nie podlegają DORA ani PCI DSS, „najostrzejszy mianownik” to CIS Controls v8: kwartalne skany uwierzytelnione i zewnętrzne z procesem remediacji (kontrole 7.1-7.7). To wystarczający punkt odniesienia dla audytu ISO 27001, SOC 2 i kontroli NIS2 – pod warunkiem, że częstotliwość zapisano w analizie ryzyka.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że organizacje podlegające jednocześnie PCI DSS i DORA najczęściej prowadzą dwa równoległe procesy: kwartalny „pod QSA” i tygodniowy „pod DORA”, z dwoma zestawami raportów i dwoma właścicielami. Efekt to podwójny koszt i rozjazd wyników. Jako akredytowany QSA i audytor ISO 27001 projektujemy program tak, aby tygodniowy skan generował również kwartalny „snapshot” z rescanem w formacie oczekiwanym przez wymóg 11.3.1 – a raport dla zarządu z DORA służył jako dowód przeglądu dla ISO 27001 (klauzula 9.3). Patronusec realizuje takie skany podatności jako usługę z gotowym pakietem dowodów per reżim.
Czym różnią się wymogi PCI DSS od DORA w praktyce dowodowej?
PCI DSS i DORA różnią się nie tyle tym, co skanujesz, ile tym, co musisz pokazać: QSA oczekuje czterech kwartalnych raportów pokrywających każdy adres w zakresie, dowodu rescanu każdej podatności wysokiej oraz raportów ASV z wynikiem pozytywnym; nadzór DORA oczekuje procedury, rejestru podatności z monitorowaniem, dowodu tygodniowego rytmu dla funkcji krytycznych i dowodu, że dostawcy ICT zgłaszają podatności krytyczne.
| Obszar dowodowy | PCI DSS v4.0.1 (ocena QSA) | DORA (nadzór KNF / audyt wewnętrzny) |
|---|---|---|
| Zakres | wszystkie komponenty w CDE i połączone; zgodność listy hostów z diagramem sieci (1.2.4) | aktywa ICT sklasyfikowane wg art. 8 DORA; szczególnie wspierające funkcje krytyczne lub istotne |
| Dowód częstotliwości | 4 raporty kwartalne z 12 miesięcy + skany po istotnych zmianach | harmonogram i logi skanera potwierdzające rytm tygodniowy |
| Dowód uwierzytelnienia | raport powodzenia uwierzytelnienia; udokumentowane wyjątki (11.3.1.2) | pełność skanu aktywa (RTS art. 10 ust. 2 lit. b) |
| Dowód remediacji | rescan potwierdzający usunięcie wysokich i krytycznych; analiza ryzyka dla pozostałych (11.3.1.1) | rejestr podatności z datą wykrycia, priorytetem, właścicielem, statusem (lit. g-h) |
| Dowód zewnętrzny | raporty ASV „passing” x4; atestacja ASV | weryfikacja, czy dostawcy ICT obsługują i zgłaszają podatności (lit. c) |
| Dowód oprogramowania | inwentarz komponentów (6.3.2), poprawki w 30 dni (6.3.3) | śledzenie bibliotek open source w usługach krytycznych (lit. d) |
| Odpowiedzialność | osoba odpowiedzialna za wymóg (12.4) | organ zarządzający zatwierdza ramy zarządzania ryzykiem ICT (art. 5 DORA) |
W ocenie PCI DSS dowodem zgodności z wymogiem 11.3.1 są cztery kwartalne raporty skanów pokrywające wszystkie komponenty w zakresie oraz rescany potwierdzające usunięcie podatności wysokich i krytycznych, natomiast w DORA dowodem jest procedura zarządzania podatnościami i rejestr z monitorowaniem remediacji.
Największa różnica praktyczna dotyczy podatności poniżej progu „wysokie”: PCI DSS pozwala zarządzać nimi na podstawie ukierunkowanej analizy ryzyka, DORA wymaga zarejestrowania każdej wykrytej podatności i monitorowania jej rozwiązania. Organizacja pod oboma reżimami prowadzi więc pełny rejestr (DORA), z którego wynika, które pozycje objęto analizą ryzyka (PCI DSS).
Masz audyt PCI DSS, przegląd nadzorczy DORA lub certyfikację ISO 27001 w ciągu najbliższych 6 miesięcy?
Patronusec wykonuje audit-readiness review programu skanów: w ciągu 10 dni roboczych otrzymujesz mapę luk dowodowych względem konkretnych wymogów (11.3.x PCI DSS, RTS art. 10, A.8.8), listę brakujących raportów i rescanów oraz plan uzupełnienia przed terminem audytu.
Zamów audit-readiness review programu skanów
Czy Twoja organizacja podlega wymogom skanowania – i którym?
O tym, które wymogi Cię obejmują, decyduje działalność, a nie wielkość: przetwarzanie kart płatniczych uruchamia PCI DSS, status podmiotu finansowego – DORA, przynależność do sektorów z załączników NIS2 – obowiązki podmiotu kluczowego lub ważnego, wytwarzanie produktów z elementami cyfrowymi – CRA, a certyfikacja ISO 27001 lub raport SOC 2 – odpowiednie kontrole. Większość organizacji podlega dwóm lub trzem reżimom naraz.
Drzewo decyzyjne – które wymogi skanowania Cię obejmują?
- Czy przechowujesz, przetwarzasz lub przesyłasz dane kart płatniczych (lub wpływasz na ich bezpieczeństwo)?
→ TAK: PCI DSS 11.3 – skany kwartalne wewnętrzne uwierzytelnione i ASV. Zakres wyznacza CDE – patrz zakres PCI DSS i segmentacja. Przejdź do pkt 2. - Czy jesteś podmiotem finansowym w rozumieniu art. 2 DORA (bank, instytucja płatnicza, ubezpieczyciel, firma inwestycyjna, dostawca usług kryptoaktywów itd.)?
→ TAK: RTS 2024/1774 art. 10 – skany tygodniowe dla aktywów krytycznych, rejestr, SBOM, weryfikacja dostawców. Przejdź do pkt 3. - Czy działasz w sektorze z załącznika I lub II NIS2 (energia, transport, zdrowie, infrastruktura cyfrowa, produkcja, żywność itd.) i zatrudniasz ≥ 50 osób lub masz obrót ≥ 10 mln EUR?
→ TAK: obowiązki podmiotu kluczowego lub ważnego, w tym art. 21 ust. 2 lit. e – sprawdź klasyfikację w artykule NIS2 – podmiot kluczowy czy ważny. Przejdź do pkt 4. - Czy wytwarzasz lub wprowadzasz na rynek UE oprogramowanie lub urządzenia z elementami cyfrowymi?
→ TAK: CRA – SBOM, obsługa podatności, zgłaszanie od 11 wrz 2026; szczegóły w CRA dla software house’u. Przejdź do pkt 5. - Czy masz lub planujesz certyfikat ISO 27001, raport SOC 2 lub etykietę TISAX?
→ TAK: kontrole A.8.8 / CC7.1 / VDA ISA – częstotliwość z analizy ryzyka, minimum CIS 7.5-7.6.
→ NIE (i nie w pkt 1-4): brak twardego wymogu, ale kwartalne skany uwierzytelnione pozostają podstawową higieną.
Obowiązek skanowania podatności wynika z rodzaju działalności organizacji – przetwarzania kart, statusu podmiotu finansowego, sektora NIS2 lub roli producenta pod CRA – a nie z jej wielkości, dlatego większość średnich przedsiębiorstw podlega co najmniej dwóm reżimom jednocześnie.
W praktyce oznacza to, że fintech obsługujący płatności kartowe podlega PCI DSS, DORA i często NIS2 (infrastruktura cyfrowa) jednocześnie – i to jego program powinien być punktem odniesienia dla najostrzejszego mianownika z poprzedniej sekcji.
Jak wymogi dotyczące dostawców ICT i łańcucha dostaw zmieniają zakres skanów?
Wymogi dotyczące dostawców rozszerzają program skanów poza własne systemy: DORA (RTS art. 10 ust. 2 lit. c) każe zweryfikować, czy dostawcy ICT obsługują podatności i zgłaszają krytyczne, NIS2 (art. 21 ust. 2 lit. d) wymaga bezpieczeństwa łańcucha dostaw, PCI DSS (12.8-12.9) – nadzoru nad dostawcami usług, a CRA – SBOM od producentów. Skanujesz to, czym zarządzasz; od reszty żądasz dowodów.
Trzy modele w zależności od rodzaju dostawcy:
| Rodzaj dostawcy | Co skanujesz sam | Czego żądasz od dostawcy | Podstawa |
|---|---|---|---|
| Kolokacja / IaaS | systemy operacyjne, aplikacje, konfiguracja własnych zasobów | raporty z zarządzania podatnościami warstwy fizycznej i hypervisora; certyfikaty (SOC 2, ISO 27001, PCI DSS AOC) | PCI DSS 12.8.4-12.8.5, DORA art. 28-30 |
| SaaS / usługa zarządzana | integracje, konfiguracja po swojej stronie, tożsamości | dowód regularnych skanów i pentestów, SLA remediacji, zgłaszanie podatności krytycznych | RTS DORA art. 10 ust. 2 lit. c, NIS2 art. 21 ust. 2 lit. d |
| Dostawca oprogramowania / komponentów | oprogramowanie w swoim środowisku (SCA na dostarczonych artefaktach) | SBOM, proces obsługi podatności, kanał zgłoszeń, terminy poprawek | CRA zał. I cz. II, PCI DSS 6.3.2 |
Zgodnie z art. 10 ust. 2 lit. c RTS 2024/1774 podmiot finansowy weryfikuje, czy zewnętrzni dostawcy usług ICT obsługują podatności dotyczące świadczonych usług i czy zgłaszają mu terminowo co najmniej podatności krytyczne oraz statystyki i trendy.
Umowa z dostawcą powinna zawierać klauzulę o skanowaniu: prawo do skanowania własnych zasobów u dostawcy (lub obowiązek dostawcy do skanowania z raportem), definicję podatności krytycznej, termin zgłoszenia i termin usunięcia. Wzorce klauzul i model klasyfikacji dostawców opisaliśmy w artykule o zarządzaniu ryzykiem dostawców, a proces oceny nowego dostawcy – w audycie bezpieczeństwa dostawcy.
W praktyce oznacza to, że zakres Twojego programu skanów definiuje mapa odpowiedzialności per dostawca, a nie lista adresów IP – i tę mapę audytor DORA lub QSA zobaczy jako pierwszą.
Jakie terminy obowiązują w latach 2026-2027 i co zmieniają w programie skanów?
W okresie 2026-2027 najważniejsze są trzy daty: 11 wrz 2026 (CRA – obowiązek zgłaszania aktywnie wykorzystywanych podatności przez producentów), 11 gru 2027 (pełne stosowanie CRA, w tym SBOM i obsługa podatności jako warunek oznakowania CE) oraz bieżące stosowanie DORA i PCI DSS v4.0.1, w których wszystkie wymogi przyszłe obowiązują od 31 mar 2025. Krajowa implementacja NIS2 w Polsce nakłada dodatkowe terminy na podmioty kluczowe i ważne.
| Data | Reżim | Co się zmienia | Wpływ na program skanów |
|---|---|---|---|
| 17 sty 2025 | DORA | pełne stosowanie rozporządzenia i RTS 2024/1774 | tygodniowe skany aktywów krytycznych, rejestr podatności, SBOM usług krytycznych |
| 31 mar 2025 | PCI DSS v4.0.1 | wymogi przyszłe stają się obowiązkowe: 11.3.1.2 (uwierzytelnienie), 6.3.2 (inwentarz komponentów), 6.4.2 (ochrona aplikacji) | skany wewnętrzne wyłącznie uwierzytelnione; SBOM dla aplikacji w CDE |
| 31 paź 2025 | ISO/IEC 27001:2022 | koniec okresu przejściowego z wersji 2013 | audyty wyłącznie wg A.8.8 (nowa numeracja kontroli) |
| 11 wrz 2026 | CRA art. 14 | obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów (24 h / 72 h / 14 dni) | producenci: proces triage podatności z własnych skanów i zgłoszeń zewnętrznych, gotowy do raportowania na platformę ENISA |
| 11 gru 2027 | CRA – pełne stosowanie | wymogi zał. I (w tym SBOM, obsługa podatności, aktualizacje bezpieczeństwa) warunkiem oznakowania CE | producenci: SCA i SBOM w potoku jako dowód zgodności; skany w cyklu życia produktu |
| 2 kwietnia 2027 | NIS2 – Polska (nowelizacja ustawy o KSC) | terminy rejestracji podmiotów i wdrożenia środków z art. 21 | udokumentowana częstotliwość skanów w analizie ryzyka; obsługa podatności i ich ujawnianie |
Cyber Resilience Act od 11 wrz 2026 nakłada na producentów produktów z elementami cyfrowymi obowiązek zgłoszenia aktywnie wykorzystywanej podatności w ciągu 24 godzin od uzyskania o niej wiedzy – co wymaga, aby wyniki własnych skanów i zgłoszenia zewnętrzne trafiały do jednego procesu triage.
Dla większości organizacji terminy DORA i PCI DSS już minęły – program skanów albo spełnia je dziś, albo generuje niezgodność przy najbliższym audycie. Termin CRA jest jedynym „przed nami” i dotyczy tych, którzy wytwarzają oprogramowanie; szczegółową listę przygotowań opisaliśmy w artykule o obowiązkach CRA od 11 września 2026, a relację CRA do NIS2 – w mapie obowiązków CRA a NIS2.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że po 31 mar 2025 najczęstszą niezgodnością w ocenach PCI DSS w obszarze wymogu 11 jest brak dowodu uwierzytelnienia skanów wewnętrznych – organizacje przeszły na v4.0.1 formalnie, ale konfiguracja skanera pozostała z czasów v3.2.1. Drugą jest brak inwentarza komponentów (6.3.2) dla aplikacji własnych. Oba braki da się usunąć w kwartał, pod warunkiem, że wykryje się je przed audytem, a nie w jego trakcie – stąd nasze audit-readiness review obejmuje weryfikację konfiguracji skanera, nie tylko przegląd raportów.
Które przekonania o skanach podatności i compliance są mitami?
MIT: ISO 27001 wymaga skanów podatności co kwartał.
FAKT: ISO/IEC 27001:2022 (A.8.8) nie określa częstotliwości; wymaga uzyskiwania informacji o podatnościach i podejmowania odpowiednich środków. Częstotliwość musi wynikać z analizy ryzyka organizacji.
MIT: Skan ASV z wynikiem pozytywnym oznacza zgodność z wymogiem 11.3 PCI DSS.
FAKT: Skan ASV spełnia tylko 11.3.2 (zewnętrzny). Wymóg 11.3.1 dotyczy skanów wewnętrznych uwierzytelnionych z rescanem – to odrębny obowiązek.
MIT: DORA wymaga skanów co tydzień dla wszystkich systemów.
FAKT: RTS 2024/1774 art. 10 wymaga rytmu tygodniowego dla aktywów wspierających funkcje krytyczne lub istotne; dla pozostałych częstotliwość ma być proporcjonalna do klasyfikacji i profilu ryzyka.
MIT: NIS2 nie dotyczy skanów, bo nie wymienia ich w art. 21.
FAKT: Art. 21 ust. 2 lit. e wymaga „postępowania w przypadku podatności i ich ujawniania” jako środka zarządzania ryzykiem; organ nadzoru oceni, czy organizacja identyfikuje podatności w sposób regularny i udokumentowany – skany są tego podstawowym dowodem.
MIT: CRA dotyczy tylko producentów sprzętu.
FAKT: CRA obejmuje produkty z elementami cyfrowymi, w tym oprogramowanie wprowadzane na rynek UE jako samodzielny produkt – także software house’y i dostawców SaaS z komponentem dystrybuowanym.
FAQ – jakie regulacje wymagają skanów podatności
Czy jeden skan może spełnić wymogi PCI DSS i DORA jednocześnie?
Tak, jeśli program jest zaprojektowany pod DORA (tygodniowy rytm, rejestr, uwierzytelnienie) i generuje kwartalne snapshoty z rescanem dla PCI DSS. Różnica polega na dowodach: QSA potrzebuje czterech raportów kwartalnych i raportów ASV, nadzór DORA – procedury i rejestru z monitorowaniem.
Jak często ISO 27001 wymaga skanów podatności?
ISO 27001:2022 nie określa częstotliwości. Kontrola A.8.8 wymaga uzyskiwania informacji o podatnościach i odpowiednich działań, a audytor oczekuje, że częstotliwość wynika z analizy ryzyka. Punktem odniesienia jest CIS Controls v8: co najmniej co kwartał, uwierzytelnione wewnętrzne i zewnętrzne.
Czy NIS2 wymaga skanów podatności?
Nie wprost, ale art. 21 ust. 2 lit. e wymaga postępowania z podatnościami i ich ujawniania jako środka zarządzania ryzykiem. Kontrola organu nadzoru oceni regularność i dokumentację; dla dostawców usług cyfrowych rozporządzenie wykonawcze 2024/2690 doprecyzowuje wymogi zarządzania podatnościami.
Co CRA zmienia dla firmy, która tylko kupuje oprogramowanie?
Bezpośrednio niewiele – obowiązki CRA spoczywają na producentach. Pośrednio: od 11 gru 2027 możesz żądać SBOM i procesu obsługi podatności jako warunku zakupu, a producent musi dostarczać aktualizacje bezpieczeństwa przez okres wsparcia. To wzmacnia Twoją pozycję w klauzulach umownych z art. 10 RTS DORA i art. 21 NIS2.
Czy raporty ze skanów trzeba przechowywać, a jeśli tak – jak długo?
Tak. PCI DSS wymaga dowodów z ostatnich 12 miesięcy (cztery kwartały), DORA – rejestru podatności bez ograniczenia czasowego, ISO 27001 – udokumentowanych informacji jako dowodu działania ISMS. Praktyka: raporty i rescany przez minimum 3 lata, rejestr podatności bezterminowo.
Ile kosztuje audit-readiness review programu skanów w Patronusec?
Review wykonujemy w 10 dni roboczych; cena zależy od liczby reżimów, wielkości środowiska i liczby narzędzi skanujących. Po bezpłatnej rozmowie o zakresie przedstawiamy stałą wycenę. Dla klientów, którzy zlecają nam skany lub audyt PCI DSS, review jest elementem pakietu.
Warto przeczytać
- Skany podatności infrastruktury – hub definicji; rodzaje skanów, uwierzytelnienie, priorytetyzacja CVSS/EPSS/KEV.
- Skany podatności aplikacji – DAST, SAST, SCA – warstwa aplikacyjna, SBOM i bramki w CI/CD.
- NIS2 – podmiot kluczowy czy ważny – klasyfikacja i obowiązki z art. 21.
- CRA a NIS2 – mapa obowiązków – jak obowiązki producenta i użytkownika łączą się w łańcuchu dostaw.
- ISO 27001 czy PCI DSS – który certyfikat wybrać – jak oba reżimy nakładają się w obszarze testów i skanów.
- Testy TLPT pod DORA – jak zacząć – najwyższy poziom programu testów DORA, do którego skany są warstwą podstawową.
Skany podatności a compliance – bezpłatna konsultacja
Patronusec jako akredytowany QSA i audytor ISO 27001 projektuje programy skanów podatności tak, aby jeden zestaw dowodów służył ocenie PCI DSS, przeglądowi nadzorczemu DORA i certyfikacji ISO 27001 – i realizuje skany wewnętrzne, zewnętrzne i ASV jako usługę. Pracujemy z klientami z sektorów fintech, finansowego, e-commerce i retail.
W bezpłatnej 30-minutowej konsultacji pomożemy Ci:
- ustalić, którym reżimom podlega Twoja organizacja i który wyznacza „najostrzejszy mianownik” programu,
- zmapować obecne skany i raporty na konkretne wymogi (11.3.x, RTS art. 10, A.8.8, CC7.1),
- wskazać luki dowodowe, które audytor wykryje jako pierwsze,
- zaplanować przejście na jeden program skanów z pakietem dowodów per audyt.
Umów bezpłatną konsultację | Skany podatności | Skanowanie ASV | Wdrożenie DORA | ISO 27001
