Penetration testing compliance: Jak zajistit shodu a účinnost

Ne každý report z penetračního testu projde u auditora. To tvrzení zní překvapivě, ale v praxi přesně tenhle problém potkává významnou část bezpečnostních týmů v Evropě. Firmy investují do pentestů, dostanou dokumenty se seznamem zranitelností a pak se ukáže, že to neplní požadavky ISO 27001, GDPR ani žádného jiného standardu. Pentest sám o sobě není compliance. Compliance je sada požadavků na rozsah, autorizaci, metodiku a dokumentaci - bez nich žádný test nemá důkazní hodnotu.

Obsah

• Co je penetration testing compliance a proč se ne každý pentest počítá

• Které předpisy a standardy v Evropě vyžadují compliance pentesty

• Pentest vs assessment: co splňuje požadavky a co ne?

• Efektivní realizace: jak připravit a uzavřít compliance pentest

• Co chybí ve většině pentestů pro compliance - naše zkušenosti

• Nástroje a podpora pro efektivní compliance pentesty

• Často kladené otázky

Klíčové závěry

Co je penetration testing compliance a proč se ne každý pentest počítá

Začněme jasným rozlišením. Penetration testing compliance je víc než samotné provedení testu. SANS Glossary definuje samotný pentest jako kontrolovanou simulaci útoku za účelem ověření odolnosti systému - pojem "penetration testing compliance" jde nad rámec této definice a znamená sladění takových testů s konkrétními regulacemi a politikami: s legálním, autorizovaným a kontrolovaným průběhem a s důkazní hodnotou pro audit. Nejde o to, jestli někdo spustil Nmap a Metasploit. Jde o to, jestli celý proces splňuje formální a procedurální požadavky regulátora nebo standardu.

V praxi compliance vyžaduje několik prvků, které běžný penetrační test nemusí obsahovat:

• Písemná autorizace: každý test musí mít výslovné povolení vlastníka systému. Bez autorizačního dokumentu test pro auditora neexistuje.

• Definovaný rozsah (scope): co přesně se testuje, jaké IP adresy, systémy, aplikace a v jakém časovém okně.

• Rules of engagement: pravidla určující, jaké techniky jsou dovolené, co je zakázané a kdo je kontaktní osoba v krizových situacích.

• Metodika: odkaz na uznanou metodiku. Pro webové aplikace - OWASP WSTG (Web Security Testing Guide); pro mobilní - OWASP MASTG. Pro infrastrukturu, sítě a Active Directory - PTES (Penetration Testing Execution Standard), NIST SP 800-115 nebo OSSTMM. Pro finanční sektor pod DORA - TIBER-EU/TLPT.

• Dokumentace výsledků: ne seznam zranitelností, ale zdokumentované důkazy exploitace, reálné cesty útoku a posouzení rizika.

Klíčový rozdíl mezi compliance pentestem a běžným assessmentem je v tom, že compliance vyžaduje důkazy, ne jen výsledky. Auditor se neptá "byl test", ale "co prokázal a jak proběhl".

Čím se compliance pentest liší od vulnerability assessmentu? Vulnerability assessment je ve zkratce automatizované nebo částečně manuální zjištění známých chyb na základě databáze CVE. Pentest jde dál. Pentester aktivně zkouší zranitelnosti zneužít, řetězí je do útočných cest a prokazuje reálné riziko. Pro compliance se počítá právě ten prvek simulace skutečného útočníka.

Stojí za to zdůraznit, že "odškrtnutí" pentestu na seznamu úkolů je jedna z nejčastějších chyb. Organizace zadají test, dostanou PDF report a uloží ho do compliance složky. Auditor se ptá na rozsah, autorizaci, rules of engagement a důkazy exploitace. Pokud tyhle prvky chybí, je report z hlediska compliance bezcenný.

Které předpisy a standardy v Evropě vyžadují compliance pentesty

Definici už známe. Teď konkrétní regulace a normy, které stavějí reálné požadavky v této oblasti.

GDPR (Obecné nařízení o ochraně osobních údajů)

Článek 32 GDPR zavazuje organizace zpracovávající osobní údaje k zavedení "procesu pravidelného testování, měření a vyhodnocování účinnosti technických a organizačních opatření". GDPR slovo "pentest" nepoužívá, ale evropští regulátoři a dozorové orgány tento předpis opakovaně vykládali jako požadavek na pravidelné technické bezpečnostní testy. Jak poznamenává GDPR cybersecurity requirements, GDPR podporuje pravidelné testování účinnosti bezpečnostních opatření, což se často vykládá jako požadavek pentestů.

Co to znamená pro pentestera? Pokud děláš test pro organizaci spadající pod GDPR, musí report jasně ukázat, jaká opatření na ochranu dat se testovala a jak jsou účinná. Pouhý seznam CVE tady nic neprokazuje.

ISO 27001

ISO/IEC 27001:2022 je aktuální verze standardu řízení informační bezpečnosti (přechodné období z verze 2013 skončilo 31. října 2025 - auditoři se dnes odvolávají na nové číslování). Kontrola A.8.8 "Management of technical vulnerabilities" (dříve A.12.6.1 z verze 2013) se týká řízení technických zranitelností, a kontrola A.5.36 "Compliance with policies, rules and standards for information security" (dříve A.18.2.3) výslovně vyžaduje technický přezkum z hlediska shody. ISO 27001 pentesty výslovně nevyžaduje, ale auditoři očekávají objektivní důkazy účinnosti kontrol. V praxi to znamená, že pokud tvůj ISMS (Information Security Management System) tvrdí, že jsou kontroly účinné, musíš to prokázat. A pentest se správnou dokumentací je přesně takový důkaz.

NIST SP 800-115

NIST Special Publication 800-115 je technický dokument popisující metodiku provádění bezpečnostních testů. Definuje čtyři fáze: plánování, objevení, útok a reporting. Pro compliance je důležité, že NIST vyžaduje dokumentaci každé fáze procesu s přesností umožňující výsledky reprodukovat.

Evropský kontext

DORA (Digital Operational Resilience Act), platná pro finanční sektor od 17. ledna 2025, ukládá kritickým institucím povinnost provádět Threat-Led Penetration Testing (TLPT). TLPT vychází z frameworku TIBER-EU vypracovaného Evropskou centrální bankou - operační dokument definuje požadavky na scope, threat intelligence a red teaming pod dohledem národního regulátora.

NIS2 (Směrnice EU 2022/2555) je dnes hlavním driverem pentestů v EU pro klíčové a důležité subjekty: energetika, doprava, zdravotnictví, voda, digitální infrastruktura, poskytovatelé ICT služeb, veřejná správa. V Polsku implementována zákonem o národním systému kybernetické bezpečnosti (KSC). Článek 21 vyžaduje řízení kybernetických rizik včetně hodnocení účinnosti opatření - regulátoři to vykládají jako požadavek pravidelného technického testování. Sankce: až 10 mil. EUR nebo 2 % globálního obratu (klíčové subjekty), až 7 mil. EUR nebo 1,4 % (důležité subjekty).

CRA (Cyber Resilience Act, Nařízení EU 2024/2847) vstoupil v platnost v prosinci 2024 (hlavní povinnosti od 11. prosince 2027). Ukládá požadavky security-by-design a bezpečnostního testování výrobcům produktů s digitálními prvky - IoT hardware, software, připojená zařízení. Pentest se stává součástí posouzení shody před uvedením produktu na trh EU.

Pentest vs assessment: co splňuje požadavky a co ne?

Už víš, které předpisy jsou důležité. Čas na praktické rozlišení, jaké činnosti reálně splňují compliance požadavky.

Pentest a vulnerability assessment znějí podobně. V praxi jsou to dvě různé služby s úplně jinou důkazní hodnotou. Jak uvádí SANS pentest vs. assessment, pentest je simulace útoku, assessment je identifikace známých zranitelností a compliance žádá spíše to první.

Co přesně auditor compliance hledá v reportu z pentestu? Tady je seznam klíčových prvků, které v dokumentaci musí být:

1. Autorizační dokument podepsaný vlastníkem systému nebo vedením.

2. Rozsah (scope) s přesným seznamem systémů, sítí a aplikací zahrnutých do testu.

3. Rules of engagement s popisem dovolených a zakázaných technik.

4. Odkaz na metodiku (PTES, OWASP, NIST SP 800-115 nebo jiný uznaný standard).

5. Důkazy exploitace: snímky obrazovky, logy, PoC (proof of concept) pro každou kritickou zranitelnost.

6. Posouzení obchodního rizika v kontextu testovaného prostředí.

7. Doporučení remediace s prioritizací.

8. Datum a verze reportu se jménem odpovědné osoby.

NIST a pokyny ENISA pro regulace EU se v tomto bodě shodují: compliance vyžaduje důkaz testu v adversariálních podmínkách. To znamená, že čistě automatický sken, byť s tisíci výsledky, nenahradí zdokumentovaný pokus o exploitaci.

Pro tip: než začneš s testem, připrav si šablonu dokumentace odpovídající standardu, který musíš splnit. Vyplňuj ji průběžně, ne až po skončení testu. Auditoři rozeznají dokumentaci psanou "naživo" od té vytvořené post factum.

Užitečné je také pročíst průvodce fuzzingem, který ukazuje pokročilé techniky odhalování zranitelností přímo využitelné při prokazování reálnosti útoků.

Efektivní realizace: jak připravit a uzavřít compliance pentest

Když jsme prošli rozdíly i standardy, je čas prakticky ukázat, jak compliance pentest probíhá krok za krokem.

Správně zorganizovaný compliance pentest projde šesti fázemi:

1. Plánování a autorizace: schůzka s klientem, definice obchodních a technických cílů, podpis autorizačního dokumentu. V této fázi se nastavuje právní rámec. Bez tohoto kroku nemá žádný další smysl.

2. Definice rozsahu a rules of engagement: přesný seznam systémů, vyřazené produkční systémy citlivé na výpadky, časová okna testů, kontaktní údaje. Rozsah musí být tak detailní, aby šel po skončení testu ověřit.

3. Průzkum a objevení: sběr informací o infrastruktuře, mapování sítě, identifikace potenciálních útočných vektorů. Výsledky této fáze musí být zdokumentované, protože ukazují, co bylo pro hypotetického útočníka k dispozici.

4. Exploitace a důkaz: aktivní pokusy zranitelnosti zneužít, řetězit je do útoků a eskalovat oprávnění. Každá úspěšná exploitace musí být zdokumentovaná snímkem obrazovky nebo logem s přesným časovým razítkem a verzí nástroje.

5. Post-exploitace a posouzení rizika: co by reálně útočník mohl udělat po prolomení zabezpečení? Mohl by se dostat k osobním údajům, platebním systémům, kritické infrastruktuře? Tato fáze je pro compliance nejdůležitější, protože ukazuje skutečné obchodní riziko.

6. Reporting a review: příprava reportu ve dvou vrstvách - technické (pro pentestery a vývojáře) a executive summary (pro vedení a auditory). Report musí umožnit obhajobu výsledků u auditu.

Jak uvádějí pokyny CREST k "defensible penetration test", klíčová je kvalita důkazů: rozsah, pravidla hry, přesná dokumentace a obhajitelnost reportu u auditu.

Co auditoři v dokumentaci hledají? Především konzistenci. Rozsah definovaný na začátku musí odpovídat systémům probíraným v reportu. Důkazy exploitace musí být propojené s konkrétními zranitelnostmi. Doporučení musí být akční a navázaná na rizika.

Nejčastější chyby v pentestech pro compliance:

• Chybějící autorizační dokument nebo autorizace od osoby bez odpovídajících pravomocí.

• Rozsah příliš obecný: "celá IT infrastruktura" bez seznamu IP adres a názvů systémů.

• Chybějící timestampy v důkazech exploitace.

• Report pouze technický bez posouzení obchodního rizika a executive summary.

• Chybějící odkaz na metodiku: auditor neví, jakými kritérii se pentester řídil.

• Test provedený výhradně automaticky: skenery nenahradí ruční ověření a exploitaci.

Pro tip: pokud chceš, aby tvůj report obstál i pod tlakem otázek auditora, přidej sekci "Limitations" popisující, co test nepokrýval a proč. Ukazuje to metodickou zralost a zabraňuje nedorozuměním kolem rozsahu.

Pokročilé techniky jako fuzzing mají přímé využití při dokumentování reálnosti exploitace. Detailní postup popisuje článek o využití fuzzingu v pentestech, který stojí za to doplnit jako součást metodiky.

Co chybí ve většině pentestů pro compliance - naše zkušenosti

Při práci s bezpečnostními specialisty a sledování reportů, které přistávají u auditorů, vidíme jasný vzorec. Většina problémů s compliance nepramení z nedostatečné technické kvality testu. Pramení z nedostatku dokumentační disciplíny a špatného pochopení toho, co auditor vlastně hledá.

První a nejčastější problém je rozsah popsaný příliš obecně. "Testovali jsme síťovou infrastrukturu klienta" je věta, která nic neprokazuje. Auditor potřebuje seznam: které servery, které aplikace, které IP rozsahy, v jakém časovém okně. Bez té přesnosti nemůže být ani technicky vynikající test přijat jako compliance důkaz.

Druhý problém je chybějící ověření exploitability. Mnoho reportů obsahuje dlouhé seznamy zranitelností s CVSS 9.0+, ale ani jediný důkaz, že některá z nich je v testovaném prostředí skutečně zneužitelná. Compliance vyžaduje simulaci skutečného útoku, ne seznam teoretických hrozeb. Auditoři tento rozdíl chápou stále lépe a stále častěji odmítají reporty postavené pouze na automatickém skenu.

Třetí problém jsou reporty psané výhradně pro techniky. Compliance se týká celé organizace a rozhodnutí dělá vedení. Report bez executive summary a posouzení obchodního rizika je pro rozhodující osobu k ničemu a často blokuje akceptaci auditorem.

Podle nás je nejdůležitější parametr pentest compliance to, jak realistická je simulovaná útočná situace. Nezáleží na tom, jestli pentester použil nejnovější techniku. Záleží na tom, jestli test odrážel reálné hrozby pro konkrétní prostředí. Útočníci, kteří evropské firmy skutečně ohrožují, nejsou akademičtí výzkumníci. Používají jednoduché, osvědčené vektory: phishing, slabá hesla, neaktualizované veřejné služby. Pentest, který se soustředí pouze na exotické exploity a tyhle vektory přehlíží, vytváří falešný pocit bezpečí.

Samostatným tématem je kvalita úvodních dohod. Rules of engagement, scope a obchodní cíl testu by měly být sjednány písemně před startem. Vidíme příliš mnoho případů, kdy pentesteři začínají bez jasných pravidel a pak musí dokumentaci "dopasovat" k hotovému reportu. Je to vždy vidět. Zkušení auditoři to poznají.

Pokud jde o nástroje, kvalitní laboratorní vybavení má zásadní vliv na kvalitu důkazů. Zařízení pro testování Wi-Fi, vybavení na analýzu RFID/NFC nebo dedikované akcesory pro simulaci útoků umožňují získat reproducible evidence, tedy důkazy, které lze ověřit a zopakovat. Přesně to je standard, který solidní compliance pentest vyžaduje. Více o pokročilých technikách shromažďování důkazů najdeš v praktickém průvodci fuzzingem, který popisuje metody přímo se promítající do důkazní hodnoty reportu.

Nástroje a podpora pro efektivní compliance pentesty

Vědomosti máš. Teď je čas vybavit se nářadím, které ti umožní je využít v praxi a získat důkazy, jaké auditoři přijmou.

Sapsan je evropský distributor specializovaného vybavení pro pentestery a profesionály v IT bezpečnosti. V nabídce najdeš nástroje pro testování Wi-Fi sítí, zařízení pro analýzu RFID a NFC, SDR (Software Defined Radio) techniku, BadUSB akcesory a rozšíření pro Flipper Zero. Je to vybavení pro reálné testy v laboratorních i produkčních podmínkách, generující důkazy exploitace ve formě, jakou auditoři compliance přijímají. Každé zařízení dostupné na sapsan-sklep.pl je vybrané s ohledem na profesionální použití: pentesty bezdrátových sítí, testy fyzické bezpečnosti přístupových systémů, analýzu rádiových protokolů a simulaci útoků na IoT zařízení. Zásilky míří po celé Evropě.

Často kladené otázky

Stačí pro compliance jakékoli pravidelné skenování zranitelností?

Ne, compliance vyžaduje spíše realistické testy typu pentest než jen automatické skenování. Jak uvádí SANS pentest vs. assessment, compliance vyžaduje simulaci skutečných útoků, ne jen detekci děr.

Vyžaduje GDPR pentest jmenovitě?

GDPR pentest přímo nezmiňuje, ale článek 32 ukládá povinnost pravidelného testování účinnosti bezpečnostních opatření. Jak zdůrazňují požadavky GDPR v oblasti kybernetické bezpečnosti, povinnost pravidelně testovat účinnost kontrol je regulátory vykládána jako nutnost provádět pentesty.

Jakou formu reportu z pentestu auditoři compliance přijímají?

Auditoři dávají přednost reportům s jasným rozsahem, písemnými dohodami, důkazy z realistických testů a konkrétními doporučeními. Podle penetration testing code compliance musí kvalita reportu umožnit obhajobu výsledků u auditu.

Jak často je třeba provádět compliance pentesty?

Frekvence by měla vycházet z analýzy rizik: proměnlivosti prostředí, citlivosti dat a tempa změn v IT systémech. Evropský kontext žádá risk-based přístup, ne pevný kalendář testů.