PXL Security LTD, Sofia, Bulgaria Offensive security since 2014[email protected]

By requirement

What NIS2 actually asks of your security testing

NIS2 does not prescribe a penetration test. It requires risk-management measures and a way to assess whether they work. Here is how Article 21 translates into testing that gives your management body and supervisor real evidence.

2014Offensive testing since
Art. 21Findings mapped to 21(2)
SofiaEU-based testing team

What it asks for

What NIS2 says about testing

Article 21(1) requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage risks to their network and information systems, taking the state of the art into account. Article 21(2) sets the minimum, including supply chain security (point d), security in acquisition, development and maintenance with vulnerability handling and disclosure (point e) and, in point (f), policies and procedures to assess the effectiveness of those measures. The Directive does not name penetration testing, but testing is a direct way to show measures work. Under Article 20, management bodies approve and oversee the measures.

For certain digital infrastructure, ICT service management and digital provider entities, Implementing Regulation (EU) 2024/2690 goes further. It requires a security testing policy, with the need, scope, frequency and type of tests based on risk assessment, a documented methodology, recorded results and mitigation of critical findings. Its recitals give penetration tests, vulnerability scanning and application security tests as examples. Separately, Articles 32 and 33 let supervisors use security audits, security scans and requests for evidence. Because NIS2 is a directive, the binding detail comes from each Member State's transposing law.

  • Art. 21(1) – Appropriate and proportionate measures

    Measures must reflect the state of the art and the entity's risk exposure, size and likelihood of incidents. Testing should follow the same logic: more critical and exposed systems warrant deeper and more frequent testing.

  • Art. 21(2)(d) – Supply chain security

    Entities must address security in relationships with direct suppliers and service providers, considering supplier vulnerabilities and secure development practices. Testing integrations, supplier access paths and managed-service connections gives that assessment substance.

  • Art. 21(2)(e) – Acquisition, development and maintenance

    Covers security when acquiring, developing and maintaining systems, including vulnerability handling and disclosure. Application testing, code review and a working process for triaging reported vulnerabilities all support this measure.

  • Art. 21(2)(f) – Assessing effectiveness

    Entities need policies and procedures to assess whether their risk-management measures actually work. Penetration tests, red-team exercises and control validation provide independent, evidence-based input to that assessment.

  • Art. 20 – Governance

    Management bodies must approve the risk-management measures, oversee their implementation and can be held liable for infringements. Test results written for that audience help them exercise oversight with real information.

  • Arts. 32 and 33 – Supervision

    Supervisors can use security audits, security scans and requests for evidence, proactively for essential entities and after the fact for important entities. Well-kept test records let you answer with documented evidence.

What to test

What a NIS2-aligned test should cover

  • Services in scope

    Start from the services that bring you into NIS2 and the network and information systems that support them, including the physical environment where it matters under the all-hazards approach of Article 21(2).

  • External attack surface

    Internet-facing applications, remote access, email and cloud tenants are common initial access routes. Test them for exploitable weaknesses, not only missing patches, and confirm multi-factor authentication works as intended.

  • Internal network and identity

    Assume a foothold and test lateral movement, privilege escalation and Active Directory or cloud identity weaknesses. This shows whether access control and segmentation measures actually limit an intruder.

  • Suppliers and people

    Test supplier connections, managed-service access and third-party integrations, and consider social engineering to check that training and cyber hygiene measures change behaviour, within agreed rules of engagement.

What you receive

What PXL delivers and how it supports your evidence

  • Findings mapped to Article 21

    Reports reference each finding to the relevant Article 21(2) measure, so your effectiveness assessment can show which measures held, which failed and what changed as a result.

  • Management-body summary

    A plain-language summary of risk, root causes and remediation status gives management bodies the information they need to approve measures and oversee their implementation under Article 20.

  • Documented scope and method

    Each report records scope, dates, methodology, testers and limitations, matching what a security testing policy should document and what a supervisor may ask to see.

  • Retest and closure

    We retest remediated findings and confirm closure in writing, supporting the corrective measures Article 21(4) requires and giving you a traceable record from discovery to fix.

Common pitfalls

Common mistakes

Mistakes that cost time at audit, and how to avoid them.

  • Assuming one yearly test is enough

    NIS2 sets no fixed testing frequency. If your risk assessment, a significant change or an incident calls for testing, a calendar-driven yearly test may not satisfy your own effectiveness policy.

  • Ignoring national law

    NIS2 is a directive, so binding obligations come from national transposition. Check your Member State's law and any secondary rules, which may add detail on registration, audits or reporting.

  • Scanning instead of testing

    Automated scans find known issues but rarely show whether controls stop a determined attacker. Assessing effectiveness usually needs manual testing of how weaknesses chain together into real impact.

  • Leaving suppliers out of scope

    Article 21(2)(d) places supply chain security inside your risk-management measures. Excluding supplier access, managed services and integrations from testing leaves a known route into your environment unassessed.

Who decides what counts

PXL Security is an independent offensive-security firm, not an auditor, assessor, certification body or regulator. We deliver the testing and the evidence; your auditor, assessor or competent authority decides what they accept. This page is general guidance, not legal advice.

FAQ

Questions we're often asked

Does NIS2 require penetration testing?

The Directive does not mandate penetration testing by name. Article 21(2)(f) requires policies and procedures to assess the effectiveness of your measures, and testing is a practical way to do that. For entities covered by Implementing Regulation (EU) 2024/2690, a security testing policy is explicitly required, and its recitals list penetration tests as one example.

Are we an essential or an important entity?

Broadly, Annex I entities above the medium-sized enterprise ceilings are essential, and other Annex I or II entities of at least medium size are important. Some entities are covered regardless of size, and Member States can designate others. Confirm your classification with your national competent authority.

How has Bulgaria transposed NIS2?

Bulgaria transposed NIS2 by amending its Cybersecurity Act; the amending law was published in State Gazette No. 17 of 13 February 2026. It distinguishes essential and important entities and provides for targeted security audits. Check the consolidated text and any implementing rules for your specific obligations.

We are a financial entity under DORA. Does NIS2 apply?

For financial entities covered by DORA, the NIS2 recitals state that DORA's provisions on ICT risk management, incident reporting and resilience testing apply instead of the equivalent NIS2 rules. In practice, your DORA testing programme is the framework to work to.

Is PXL an auditor or competent authority?

No. PXL is a security testing firm, not an auditor, certification body or regulator, and we do not certify NIS2 compliance. Our reports are evidence you can use in your own effectiveness assessment, management reporting and dealings with supervisors.

Is this legal advice?

No. This page is general guidance based on the Directive and related EU texts. Your obligations depend on national transposition, your sector and your classification, so confirm them with your legal advisers and your competent authority.

Scope your NIS2 test.

Send a short description of your environment and goals. A senior tester, not a salesperson, will reply with questions, a proposed approach and a quote.

Scoping details

Optional — helps us scope faster.

Prefer email? Write to [email protected]. We usually reply within one business day.