Penetration testing for NIS2, DORA, ISO 27001 & PCI-DSS.
Most frameworks expect — or require — independent penetration testing. We do that testing and hand you a report an auditor can use. We test; we don't audit.
We secure the Czech tech companies that made it globally.
Penetration testing for compliance
Compliance frameworks don't certify themselves on the strength of a scan. They expect evidence that someone competent tried to break in and wrote down what they found. Here's how our testing maps to the four frameworks we're asked about most.
PCI-DSS — testing is mandatory
PCI-DSS v4.x makes penetration testing explicit: Requirement 11.4 mandates internal and external penetration tests at least every 12 months and after any significant change, with a documented methodology, CVSS-rated findings, and a retest to confirm remediation. The application layer must cover the vulnerability classes in Requirement 6.2.4 (closely aligned to the OWASP Top 10). We deliver exactly this scope — and a report structured the way a QSA expects to see it.
DORA — from ICT testing to TLPT
DORA requires financial entities to test their ICT systems regularly, and designated entities to undergo Threat-Led Penetration Testing (TLPT) under the TIBER-EU methodology. We cover the testing side across that range — from standard application and infrastructure pentests toward DORA's resilience-testing expectations, up to acting as the independent red team for a full TLPT.
NIS2 — security testing as evidence
NIS2 — in the Czech Republic, the Cybersecurity Act No. 264/2025 Coll., in force since 1 November 2025 and enforced by NÚKIB — requires essential and important entities to manage risk with appropriate technical measures, including security testing. Penetration testing is how you evidence that your controls were actually tested, not just documented. (For financial entities, DORA takes precedence over NIS2 on ICT-risk testing.)
ISO 27001 — technical verification for your ISMS
ISO 27001 doesn't prescribe a pentest by name, but technical vulnerability management and control verification sit at the heart of a credible ISMS — and certification auditors expect to see independent testing behind those controls. Our test and report give you that evidence, ready to reference in your Statement of Applicability and surveillance audits.
What you get
Whichever framework you're working toward, the deliverable is the same: a clear report with findings ranked by severity (CVSSv3), the evidence behind each one, concrete remediation steps, and a retest to confirm they're fixed. It's written to be read by both your engineers and your auditor.
Every test is run by certified senior specialists — no junior hands learning on your systems.
We test, we don't audit
One thing to be clear about: we're the testers, not your auditor or certification body. That separation is the point — an independent technical test is exactly the evidence auditors and regulators want to see. We hand you the results; you (and your auditor) take them into the compliance process.
Frequently asked, always answered.
Do you certify us as compliant?
No — we perform the penetration testing that frameworks require or expect, and give you a report to use as evidence. Certification is done by your auditor or certification body.
Does PCI-DSS really require a pentest?
Yes, unambiguously — Requirement 11.4, internal and external, at least annually and after significant change.
We're a financial entity — NIS2 or DORA?
For ICT-risk testing, DORA takes precedence over NIS2 as the more specific law; we can test toward either.
Will the report satisfy our auditor?
It's structured for exactly that — severity-ranked findings, evidence, remediation, and retest. Auditors and QSAs are the intended second reader.
Let's talk it through.
Tell us what you need tested — we'll set up a no-obligation call and propose a scope.
Book a free consultation ›