Penetration testing for NIS2, DORA, ISO 27001 & PCI-DSS.
Regulations and standards require or expect independent security testing — and evidence that it happened. We deliver the test and a report you can put in front of an auditor, a QSA or a supervisor. We test; we don't audit.
We secure the Czech tech companies that made it globally.
Penetration testing for compliance
Compliance is not evidenced by an automated scan. An auditor expects proof that a qualified tester actually attacked the system, what was found, how severe it was and that it was fixed. Penetration testing for compliance at insighti means a test against a recognised methodology and a report structured around what the auditor checks: scope, methodology, findings with evidence and severity, remediation and retest. Below is how the test maps to the frameworks we are 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, following a documented methodology based on industry-accepted approaches, with severity-rated findings and a retest confirming remediation; segmentation controls around the cardholder data environment are tested separately. The application layer must cover the vulnerability classes in Requirement 6.2.4 (aligned with the OWASP Top 10). We deliver the test in that scope and a report structured the way a QSA expects.
DORA — from ICT testing to TLPT
DORA requires financial entities to run a digital operational resilience testing programme (Art. 24–25): ICT systems supporting critical or important functions are tested at least yearly, penetration tests included, and identified weaknesses are remediated and verified. Entities designated by their supervisor additionally undergo Threat-Led Penetration Testing (TLPT, Art. 26–27) under the TIBER-EU methodology, performed by independent testers meeting the regulation's requirements. We cover the whole range: the yearly application and infrastructure tests under Art. 25, and the independent red team role in a TLPT.
NIS2 — security testing as evidence
In the Czech Republic NIS2 is implemented by the Cybersecurity Act No. 264/2025 Coll., in force since 1 November 2025 and supervised by NÚKIB. Providers of regulated services fall under the higher or lower obligations regime (Decree No. 408/2025 Coll.) and implement security measures under Decrees No. 409/2025 and 410/2025 Coll. — among them acquisition, development and maintenance, and cybersecurity auditing. A penetration test is the evidence that the measures were verified against a real attack, not merely documented. (For financial entities, DORA takes precedence on ICT-risk testing.)
ISO 27001 — technical verification for your ISMS
ISO/IEC 27001:2022 does not prescribe a penetration test by name, but its Annex A controls presuppose one: 8.8 management of technical vulnerabilities and 8.29 security testing in development and acceptance. A certification auditor expects independent evidence that these controls work. Our report provides that evidence, ready for your Statement of Applicability (SoA) and surveillance audits.
AI Act — cybersecurity of high-risk AI systems
The EU AI Act, Art. 15, requires high-risk AI systems to be resilient against attempts by third parties to alter their use, outputs or performance by exploiting vulnerabilities — naming data and model poisoning, adversarial inputs (model evasion) and confidentiality attacks. Those are the attacks our AI & LLM penetration testing performs.
What you get
Whichever framework you are working toward, the deliverable is the same: a report with defined scope and methodology, findings ranked by severity (CVSSv3) with proof of concept and impact, concrete remediation steps and a retest confirming the fix. It is written for two readers — 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
We are the testers, not your auditor or certification body. That separation is what gives the test its value: an independent technical test is the evidence auditors and regulators ask for. We deliver 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 ›