The KSC/NIS2 implementation project is entering a critical phase. Over the past months, as a technical team, you have been designing and implementing a number of “appropriate measures”: from multi-factor authentication (MFA) to EDR systems to a complex network segmentation project. The systems are working, the configurations are in place, and the policies are written. Now comes the key question the CISO and management will ask you: “How do we know it works?”.
In the world of cyber security, there is no room for faith; there is only room for evidence. The new KSC/NIS2 law explicitly requires “regular security tests and audits.” For you, as engineers and professionals, this means that your work must be subjected to the ultimate test - a penetration test. This is no longer an optional “bug search,” but a fundamental part of the compliance process that takes you from the level of “I think we are secure” to the level of “I know where we have vulnerabilities and how to manage them.”
Shortcuts
- Why is a configuration audit (like CIS Benchmarks) not the same as a penetration test?
- What does the requirement for “regular tests and audits” of security from KSC/NIS2 mean in practice?
- What types of penetration tests does the KSC/NIS2 verification plan need to include?
- What is an external penetration test and what does it verify?
- Why is an internal penetration test crucial to assessing network segmentation?
- How does KSC/NIS2 affect the need to test web applications and APIs?
- Types of Penetration Tests vs Verification of KSC/NIS2 Requirements
- Is social engineering (phishing) testing also part of technical verification?
- What is the process of a penetration test conducted by an external partner?
- How does a pentest report become proof of compliance for the CISO and the board?
- What to do with the results of the penetration test to comply with the law?
- Why shouldn’t an internal IT team perform penetration testing on its own?
Why is a configuration audit (like CIS Benchmarks) not the same as a penetration test?
This is the first and most important distinction you need to understand. Audit and pentest are two different, though complementary, tools. Both are critical to KSC/NIS2 compliance, but they answer different questions. Independent partners such as nFlo offer both services because they address different risks.
A configuration audit, often based on hard standards (e.g., CIS Benchmarks), is a “white-box” activity. It involves analyzing the configuration of your systems (e.g. Windows server, database, AWS cloud) and comparing it to best practices. It answers the question, “Is the system built correctly and according to standards?” It’s like a building inspection to see if the foundation is solid and the walls are the right thickness.
A penetration test is a “black-box” or “gray-box” operation. The tester does not analyze how the system is built, but tries to break it. He answers the question, “Can the system be compromised in practice by exploiting gaps in configuration, logic or software?” It’s like trying to break into a building - the foundation may be solid, but a pentester will find an open window on the first floor that a configuration audit wouldn’t detect. KSC/NIS2 requires both: a solid foundation (audit) and a check to make sure no one gets in through the window (pentest).
📚 Read the complete guide: NIS2: Kompletny przewodnik po dyrektywie NIS2 - obowiązki, kary, terminy
What does the requirement for “regular tests and audits” of security from KSC/NIS2 mean in practice?
For the technical team, this requirement marks a fundamental change: security ceases to be a one-time “implementation project” and becomes an ongoing process. This is the heart of the RESILIENCE Package - maintaining resilience. The regulator doesn’t expect you to be 100% secure - that’s impossible. It expects you to manage your risks in a continuous and documented way.
“Regular testing” means that you need to incorporate cyclical verification activities into your IT calendar. This includes both quarterly vulnerability scans and (at a minimum) annual in-depth penetration testing by an independent third party.
Having a test schedule and reports from previous years is key proof of due diligence for the CISO and the board. In the event of an incident, you will be able to show the regulator: “Yes, we knew about the risks, tested them regularly and acted on the results.” This completely changes your legal and business position.
What types of penetration tests does the KSC/NIS2 verification plan need to include?
Verification of a KSC/NIS2 implementation cannot be based on a single, generic test. Your “attack surface” is complex, and every element of it must be tested. A professional test plan, consistent with nFlo’s portfolio of services, must cover at least three major attack vectors.
First, external penetration tests. These simulate an Internet-based attacker trying to penetrate your first line of defense - firewalls, public servers, VPNs. This is a test of your “perimeter.”
Second, internal penetration tests. These simulate a scenario in which an attacker is already inside - for example, through phishing they have taken over an employee’s laptop or it is a disgruntled employee. This is a key test for measures implemented under KSC/NIS2, such as network segmentation.
Third, penetration testing of web, mobile and API applications. If your company provides digital services (which includes many KSC/NIS2 entities), your applications are part of a regulated service. They must be tested for software-specific vulnerabilities, such as according to the OWASP standard.
What is an external penetration test and what does it verify?
An external penetration test is the most fundamental form of verification. The pentester takes on the role of an anonymous attacker from the Internet. His goal is to find any “crack” in your publicly accessible IT infrastructure.
The process begins with a reconnaissance (information gathering) phase - what IP addresses you have, what domains, what services you expose to the outside world. Testers then try to identify vulnerabilities in these services: outdated software on the web server, a misconfigured mail server, weak passwords for the VPN panel.
For you, as a technical team, this is the ultimate test of the configuration of your firewalls and edge systems. It is this test that answers the question, “Is the ‘door’ to our business locked?” In the context of KSC/NIS2, this is the primary verification that you are protecting your perimeter from outside threats.
Why is an internal penetration test crucial to assessing network segmentation?
This is a test whose importance cannot be overstated, and which is directly related to one of the most important technical implementations of KSC/NIS2 - network segmentation. You have implemented VLANs and firewall rules to isolate the finance department from the marketing department, and most importantly - to isolate the IT corporate network from the OT production network. But how do you know that these rules work and that there is no vulnerability?
An internal penetration test verifies exactly that. The pentester is given access to the network at a low-trust point (e.g., a conference room outlet or a guest account on Wi-Fi). Its target is lateral movement (lateral movement). It tries to escalate privileges and get into your “crown jewels” - servers with data, domain controllers or SCADA systems in your OT network.
This test is the only practical way to validate the Zero Trust architecture. If a pentester from a “guest” network is able to reach a PLC in production, it means that your segmentation design (a key requirement of KSC/NIS2) has failed, even though everything looked good on paper.
How does KSC/NIS2 affect the need to test web applications and APIs?
If your company is a “digital service provider,” or if your “core services” are application-based (e.g., e-banking, a customer portal in the energy industry, a reservation system in transportation), then the security of these applications becomes a focal point for KSC/NIS2 compliance.
The new law requires the use of “security by design” and supply chain verification - which includes code that you create yourself or that someone creates for you. It’s no longer enough to test the server that hosts the application. You have to test the application itself.
Penetration tests of web applications and APIs, most often based on the OWASP Testing Guide methodology, look for software-specific vulnerabilities: SQL Injection, Cross-Site Scripting (XSS), business logic errors or unsafe API configuration. For you, as a technical team, this is a key part of verifying a secure software development process (Secure SDLC).
Types of Penetration Tests vs Verification of KSC/NIS2 Requirements
The following table maps the key types of penetration tests to the specific technical measures and KSC/NIS2 requirements they verify.
Penetration Test TypeMain Purpose of the TestKey KSC/NIS2 requirement that is verifiedExternal Penetration TestCan an Internet attacker penetrate perimeter defenses and get into the network?Verify “adequate resources” at the network edge (firewall, VPN, public services).Internal Penetration TestCan an attacker who is on the network (e.g., a seized laptop) get to critical resources?Final test of network segmentation (IT/OT) and minimum authority rules (IAM).Web Application / API TestingAre the applications and APIs used by customers and partners resilient to attacks?Verifying the security of the “key service,” verifying the Secure SDLC process.Wi-Fi Network TestsIs it possible to unauthorized access the internal network through poorly secured Wi-Fi?Verification of network access control.Sociotechnical TestsAre employees vulnerable to phishing, vishing or physical attacks?Verify the effectiveness of cyber hygiene training (KSC/NIS2 procedural requirement).
Is social engineering (phishing) testing also part of technical verification?
Yes, although they test a different system. Social engineering tests, such as simulated phishing or vishing campaigns, are a form of penetration testing against your “human firewall.” KSC/NIS2 requires organizations to conduct cyber hygiene training. But how do you know if these trainings are effective?
A social engineering test is a verification tool. It provides you with hard data (metrics) on what percentage of your employees are susceptible to attack. It is a test of the effectiveness of your procedural controls (training).
Moreover, it is also a test of your technical controls. What happens when an employee clicks on a link? Does your EDR system detect and block the malicious script attempt? Does your spam filter even let the message through? A social engineering test thus verifies the entire chain of defense - from human to technology.
What is the process of a penetration test conducted by an external partner?
It is crucial for the technical team to understand that professional pentest is not chaos and “wild” attacks. It is an orderly engineering process that must be safe for your production environment.
The process always starts with a Scoping Determination (Scoping). Together with the pentesters (e.g., from nFlo), you have to define precisely what is subject to the test (what IP addresses, what applications) and what is absolutely excluded. Then you go through the phases: Reconnaissance (information gathering), Vulnerability Scanning and Identification and, most importantly, Exploitation.
It is during the exploitation phase that pentester tries to actively exploit the vulnerability found to gain access. This distinguishes pentest from a regular vulnerability scan. Once access is gained, the Post-Exploitation phase (a lateral movement attempt) follows. The whole process ends with Reporting - that is, providing you with a detailed document.
How does a pentest report become proof of compliance for the CISO and the board?
The penetration test report is the most important product of the entire exercise. A professional report is not just a list of bugs found. It is a strategic document that serves three purposes and three different audiences in your company.
For you, the technical team, this is a roadmap for remediation. The report must include detailed, technical descriptions of the vulnerabilities with recommendations on exactly how to fix them (step by step).
For CISOs, the report is a risk management tool. It shows which gaps are business-critical and helps prioritize tasks for your team.
For the Board and the Regulator, the report is proof of due diligence. It shows that the organization proactively and regularly tests its security, identifies gaps and manages them. This is exactly what KSC/NIS2 requires.
What to do with the results of the penetration test to comply with the law?
Receiving a report full of red critical vulnerabilities is not a failure. Failure is not taking any action after receiving it. KSC/NIS2 is about the risk management process, and that process does not end with identification.
As a technical team, it is your responsibility to immediately analyze the report and prepare, together with the CISO, a remediation (repair) plan. You must prioritize - critical and high gaps must be patched immediately. Medium and low gaps go into the backlog with a specific due date.
Documenting this process is key. You must be able to show the auditor not only the pentest report, but also the “corrective action plan” and evidence of its execution (e.g., through a re-test by the pentester that confirms that the vulnerabilities have been closed). Only this closed cycle (Test -> Report -> Remediation -> Verification) constitutes full compliance with the “regular testing” requirement.
Why shouldn’t an internal IT team perform penetration testing on its own?
This is a common temptation in technical teams: “We are the experts ourselves, we will test ourselves.” However, this is a fundamental mistake for several reasons.
First, conflict of interest and lack of objectivity. No one is a good judge in his own case. You are testing systems that you have configured yourself. You will subconsciously avoid areas that you know are vulnerable, or you will test according to patterns you know. You lack the “attacker’s perspective.”
Second, the curse of knowledge (curse of knowledge). You guys know how the system is built. A real attacker doesn’t know that - he will try out-of-the-box methods that you wouldn’t have come up with. An outside pentester (like the nFlo team) brings just that creativity and experience from dozens of other networks.
Third, and most important from a KSC/NIS2 perspective, evidentiary credibility. A “self-testing” report has almost zero value to a regulator or board. It is perceived as biased. Only a report from an independent, external audit by a reputable cybersecurity firm provides hard, irrefutable proof of due diligence.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- NIS2 — NIS2 (Network and Information Security Directive 2) is an EU directive…
- IT Infrastructure Penetration Testing — IT infrastructure penetration testing is a controlled and ethical process of…
- Wi-Fi Network Penetration Testing — Wi-Fi network penetration testing is the process of assessing the security of…
- Penetration Testing — Penetration testing, also known as pentesting, is a controlled process of…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
Learn More
Explore related articles in our knowledge base:
- Communication During Penetration Tests: How to Collaborate with Clients
- DORA compliance: the role of penetration testing and advanced TLPT testing
- How to choose a penetration service provider in Poland? Key evaluation criteria.
- KSC NIS2 vs. software house: Why is audit from the customer the new business reality?
- Penetration Test Process - Phases, Techniques, Actions, Key Elements
Explore Our Services
Need cybersecurity support? Check out:
- Security Audits - comprehensive security assessment
- Penetration Testing - identify vulnerabilities in your infrastructure
- SOC as a Service - 24/7 security monitoring
