NIS2 and DORA Penetration Testing: A Practical Guide for Bulgarian Businesses
Requirements for NIS2 penetration testing, DORA penetration testing, PCI DSS, and SOC 2 differ in scope, frequency, and independence. These differences affect security budgets. For business leaders and security teams in Bulgaria, the key question is not whether testing is needed, but what scope, frequency, and evidence the applicable framework requires.
This guide covers NIS2 penetration testing under the amended Cybersecurity Act and DORA requirements — the two most relevant areas for Bulgarian organizations in 2026. It also addresses PCI DSS and SOC 2 for companies with international exposure. Testing gaps can lead to financial losses, liability, reputational damage, and disruption. We therefore start with the business case before reviewing each framework. Finally, we show how PTaaS (Penetration Testing as a Service) can turn penetration testing compliance into a controlled, verifiable, and cost-effective process.
Why Is This a Business Risk Question, Not Just a Compliance One?
A data breach can cost far more than regulatory fines. IBM reports an average global breach cost of USD 4.99 million, with detection and lost business making up 63% of the total.
The Cost Of A Data Breach
IBM includes the main costs a company faces after a data breach:
- $1.64M — Detection and escalation. Investigation, forensic analysis, identifying the source and scope of the breach, and involving security teams or external experts.
- $1.54M — Lost business. Downtime, lost sales, customer loss, and reputational damage.
- $1.36M — Post-breach response. Fixing vulnerabilities, restoring systems, legal support, regulatory work, compensation, and remediation.
- $0.45M — Notification. Informing customers, partners, employees, and regulators, and handling the related communication and legal steps.
Containment speed also matters: breaches resolved within 200 days cost significantly less, while AI is helping attackers move faster and leaving organizations less time to detect and fix vulnerabilities.
- Direct financial loss. A breach can create costs well beyond regulatory fines, including third-party liability. Under GDPR Article 82, organizations may remain exposed even when a security failure originates in a vendor’s systems. This is one reason enterprise customers and insurers increasingly ask for current penetration testing evidence before signing or renewing contracts.
- Reputational damage. IBM includes reputational impact within “lost business” alongside customer loss. For B2B technology providers, a publicized breach or failed security due-diligence review can put a deal or renewal at risk before an incident translates into direct customer loss.
- Business disruption. Ransomware has cost manufacturers an estimated USD 17 billion in cumulative downtime since 2018, with recovery costs commonly reaching USD 1.8–5 million per incident. This is why business continuity sits alongside vulnerability management in NIS 2, while DORA focuses explicitly on operational resilience: organizations need to understand what can fail, how quickly they can recover, and how they can demonstrate it.
NIS2 Penetration Testing in Bulgaria: From Legal Text to Reliable Evidence
Direct answer: NIS 2 doesn’t explicitly require penetration testing. Transposed in Bulgaria through the amended Cybersecurity Act, which entered into force on 13 February 2026, it requires risk-based technical, operational and organizational measures instead. Penetration testing is one practical way to validate relevant technical controls and provide evidence of their effectiveness.
The Act covers “essential” and “important” entities across sectors including energy, transport, banking, healthcare, water, digital infrastructure and ICT, manufacturing, and digital services. Required risk-management measures include vulnerability handling and disclosure, security in system acquisition and maintenance, business continuity management, and assessing the effectiveness of these measures. Penetration testing can support this assessment by validating relevant controls and producing evidence, although the law does not prescribe a universal testing scope or cadence.
Penalties follow the Directive’s model: up to €10 million or 2% of global turnover for essential entities and up to €7 million or 1.4% for important entities, alongside potential personal fines for managers who fail to meet their obligations.
The practical challenge is turning these requirements into defensible evidence. That means connecting risk-based scope to validated testing, documented findings, tracked remediation, retesting, and retained evidence — rather than relying on a one-off report that becomes outdated as the environment changes. It also means keeping legal requirements and recommended security practices clearly distinct in evidence presented to auditors, insurers, or regulators.
Penetration Testing Requirements at a Glance
| Framework | NIS 2 (BG: Cybersecurity Act) | DORA | PCI DSS 4.0.1 | SOC 2 |
|---|---|---|---|---|
| Who it applies to | Essential and important entities in critical sectors | Financial entities (banks, investment firms, insurers, pension providers, crypto-asset providers, and others) | Organizations storing, processing or transmitting cardholder data | Service organizations undergoing a SOC 2 examination |
| Pentesting expectation | Risk-based NIS2 penetration testing supports effectiveness assessment; no identical pentest mandated for every entity | Risk-based digital operational resilience testing; TLPT only for identified significant entities | Internal and external penetration testing explicitly required | May support assurance evidence; not universally mandatory |
| Scope | The scope should be risk-based rather than defined by a fixed list in the Directive | ICT systems supporting critical functions; TLPT — live production only | Cardholder data environment, connected systems, segmentation | Systems and controls tied to selected Trust Services Criteria |
| Frequency/trigger | No universal cadence in the law | Risk-based programme; TLPT at least every 3 years | Scheduled cadence plus significant-change triggers | Based on risk, control design and auditor expectations |
| Remediation/retest | Requires vulnerability handling and effectiveness checks, but no fixed pentest or retest cycle | Closure/retest requirements vary by test type | Documented correction and retest of exploitable findings | Findings and closure evidence can support the examination |
DORA Penetration Testing and TLPT — What Applies Locally
DORA has applied directly in Bulgaria since 17 January 2025. It focuses on operational resilience — keeping critical functions running through ICT disruptions — which is why resilience testing, business continuity, and disaster recovery sit alongside penetration testing within its requirements.
Supervision in Bulgaria is split between the Bulgarian National Bank (BNB) and the Financial Supervision Commission (FSC/KFN), depending on the type of financial entity. The FSC can also initiate penetration testing for certain supervised organizations, making testing more than an internal security practice for parts of the financial sector.
DORA’s regular testing requirements should not be confused with TLPT (Threat-Led Penetration Testing), which applies only to identified significant financial entities. TLPT must be performed at least every three years and targets live production systems supporting critical functions. It follows a structured process that includes scoping, threat intelligence, attack simulation, and remediation, with specific requirements for tester independence.
PCI DSS, SOC 2 and Where the Comparisons Matter
For organizations processing card payments, PCI DSS 4.0.1 is the one framework here that explicitly and unambiguously requires PCI DSS penetration testing, internal and external, across the cardholder data environment, connected systems and segmentation controls, on a scheduled cadence plus after significant changes — with every exploitable finding documented, corrected and retested before closure.
SOC 2, by contrast, sets no single universal pentesting requirement: results may support control assessment and assurance evidence depending on the selected Trust Services Criteria and the auditor’s expectations, but most enterprise-grade SOC 2 engagements include penetration testing anyway because auditors and customers expect it as reasonable practice.
Put side by side, the practical differences come down to five questions: how wide the scope is, who sets the cadence, how independent the tester must be, how much formal documentation is expected, and how much of the process includes retesting rather than just a findings report. An organization that builds one defensible, well-documented Find → Fix → Verify → Prove cycle can reuse much of that structure and evidence across NIS 2, DORA, PCI DSS, and SOC 2 engagements — without claiming that one test automatically covers every framework at once.
How IBA Group Approaches Penetration Testing for Compliance and Active Risk Management
A report by itself doesn’t reduce risk. A point-in-time report goes stale the moment the environment changes, findings scatter across emails and tickets, and evidence gets assembled at the last minute when an auditor, insurer, or regulator asks for it. IBA Group structures penetration testing compliance as a controlled lifecycle — Find → Fix → Verify → Prove — instead of a one-time document delivery.
Find
IBA specialists translate applicable requirements, critical business services and technical exposure into a risk-based scope, then focus on manual, expert-led penetration testing techniques across infrastructure, web applications, APIs, cloud, identity, AI systems and other relevant assets — using automated tools alongside this to surface non-trivial vulnerabilities beyond their reach, not as a replacement for manual testing.
Fix
Every validated finding enters a shared workspace with technical detail, evidence, an owner, a target date, and remediation guidance, so security and engineering teams work from the same data.
Verify
Closing a ticket doesn't prove a vulnerability is gone. IBA retests the original attack path and records a clear outcome — verified closed, failed, or reopened.
Prove
Executive, technical, and retest evidence is organized for audits, insurers, enterprise customers, and internal governance, mapped to NIS 2, DORA, ISO 27001, SOC 2, and PCI DSS — without implying that testing itself constitutes certification or guarantees compliance.
Three engagement models cover different points on that curve. For a one-off event — a release, an audit, a major change — a focused penetration test covers an agreed scope, validated findings, a technical report and a final validation statement, and can typically start within two weeks of scoping. For organizations that need visibility between regulatory cycles, recurring PTaaS adds planned testing cycles, a shared evidence workspace, structured retest capacity and regular checkpoints. And for regulated, multi-asset or business-critical environments — the profile of most NIS 2 essential entities and DORA-supervised financial institutions — a managed penetration testing programme adds multiple technical scopes, named service governance and custom retest commitments. All three are delivered by an EU-based team (with an EU hosting option) holding credentials such as OSCP, OSEP, OSED and CRTO, using a methodology built on PTES, NIST SP 800-115 and OWASP standards. Humans make every testing decision and validate every finding; AI supports preparation, triage and report quality, but runs no autonomous tests against client systems.
Why Is This the Resilient, Cost-Effective Way to Manage the Risk?
A fragmented approach — separate one-off tests for different audits, reports scattered across systems, and no shared remediation history — creates duplicated effort and makes it harder to demonstrate that vulnerabilities have actually been resolved.
Cost-effectiveness comes from reuse, not a lower day rate. A shared testing and evidence process allows organizations to reuse relevant findings, remediation history, retest results, and supporting evidence across multiple compliance and assurance activities, where applicable, instead of starting from zero with every engagement. IBM found a USD 1.3 million cost difference between breaches with lifecycles below and above 200 days, reinforcing the business value of identifying and addressing security weaknesses earlier.
Resilience comes from the Verify step, not the Find step. Finding vulnerabilities is only the beginning. Retesting confirms whether remediation actually closed the attack path, while a retained testing history and defined retest process provide evidence that risks are being addressed over time.
This turns penetration testing from a series of isolated assessments into a continuous Find → Fix → Verify → Prove process that supports both risk management and compliance evidence.
NIS2 Penetration Testing Checklist
Conclusion
The requirements for NIS2 penetration testing and DORA penetration testing are not identical — but both frameworks expect a risk-based, documented, verifiable process, not a one-off report. For Bulgarian organizations under the amended Cybersecurity Act, or under BNB/FSC supervision for DORA, the difference between “we have last year’s report” and “we have a defensible, current cycle from finding to verified closure” can decide the outcome of an audit, an insurance assessment, or a regulatory review. If you’re preparing your scope for NIS 2, DORA, or a combination of frameworks, IBA Group can review your environment and propose a risk-based testing plan tied to the requirements that actually apply to you.
Book a workspace demo or Discuss your assurance needs.
Penetration testing and the related evidence support compliance and assurance activities, but do not by themselves constitute certification or guarantee regulatory compliance.
FAQ
Bulgaria’s amended Cybersecurity Act, which transposes NIS 2, has been in force since 13.02.2026. Part of the Act’s secondary legislation, including an implementing ordinance and a national register of covered entities, is still being finalized.
No. Neither the NIS 2 Directive nor Bulgaria’s Cybersecurity Act sets a universal penetration testing frequency or scope. NIS 2 requires a risk-based approach, supported with evidence on request.
DORA supervision in Bulgaria is split between the Bulgarian National Bank (BNB) and the Financial Supervision Commission (FSC/KFN). The BNB oversees credit and payment institutions, while the FSC/KFN covers investment firms, insurers, pension providers and crypto-asset service providers. The FSC can initiate penetration testing of investment firms, regulated markets and crowdfunding providers.
TLPT (Threat-Led Penetration Testing) is DORA’s most rigorous testing level, combining real threat intelligence, red and blue team components, and live production systems. TLPT applies only to identified significant entities, not every financial institution subject to DORA, and must be repeated at least every three years.
No. A single penetration test produces evidence that supports compliance and assurance activities, but compliance also depends on the applicable framework, scope, governance, controls, remediation and documentation.
A single penetration test can cover some requirements across several frameworks when its scope and documentation are carefully designed. However, each framework has its own requirements. For example, TLPT requires live production systems and external threat intelligence, so one test rarely provides complete coverage across every framework.
A penetration testing provider for a compliance engagement should have relevant technical expertise, appropriate tester credentials, the required level of independence, and a clear process for evidence, remediation and retesting. The provider should also distinguish clearly between legal requirements and recommended practice.