NIS2 and GDPR: How Penetration Testing Proves Compliance

A procurement manager at a Chișinău fintech opens an email from a German partner and reads a single line that will shape her next quarter: "Please provide evidence that your systems have been penetration tested." There is no law in Moldova that says she must. There is no regulator knocking on her door. And yet the requirement is real, contractual, and non-negotiable — because her partner answers to NIS2, and NIS2 asks its supply chain to prove the same thing. This is the quiet way European cyber regulation travels: not through a parliament vote, but through a signature on a vendor agreement.

This guide explains how NIS2 and GDPR each answer the question "can you prove your systems were tested?" — and how a penetration test produces exactly the evidence both frameworks are looking for.

Does NIS2 apply to Moldovan companies?

The short answer is no, not directly. NIS2 is a European Union directive, and directives bind member states, not third countries. Moldova is not in the EU, so no Moldovan company wakes up one morning as a legally designated "essential entity" under European law. If that were the whole story, this article would end here.

It is not the whole story. The requirement reaches Moldovan companies through three concrete channels, and most organizations discover them the hard way — mid-tender, or mid-audit.

• Operations or subsidiaries in the EU. If you deliver services on the European market or run an entity registered there, you can fall directly inside the scope of "essential" or "important" entities, with all the obligations that follow.
• The supply chain. If you are a supplier to a regulated EU entity, that entity must demonstrate its own NIS2 compliance — and it cannot do so while ignoring its vendors. The requirement propagates upstream, to you, in the form of security questionnaires, contractual clauses, and evidence requests.
• Legislative alignment. Moldova is progressively aligning its cybersecurity framework with European standards. Companies that adopt the requirements proactively gain a genuine competitive advantage in public tenders and partnership negotiations.

Put plainly: do not wait for NIS2 to become local law. If you sell into the EU, or sit in the supply chain of someone who does, the requirement already touches you — through contract, not through statute.

Note: NIS2's supply-chain logic is deliberately recursive. A regulated entity must manage the risk its suppliers introduce, which means it must collect evidence from them. Your compliance file is, in effect, a component of your customer's compliance file.

What NIS2 requires when it comes to testing

Article 21 of NIS2 requires organizations to adopt "appropriate and proportionate technical, operational and organizational measures" for managing cyber risk. The language is deliberately broad — it does not prescribe a specific tool or vendor. But buried in the list of required measures is a clause that changes everything: the evaluation of the effectiveness of those security measures.

Read that again, because it is the hinge on which the entire compliance argument turns. It is not enough to have defenses. You must be able to demonstrate that your defenses work. A firewall rule, an access policy, an encrypted database — none of these are evidence on their own. They are claims. And in an audit, a claim without verification is just a sentence in a policy document.

A penetration test produces precisely the missing piece: a practical, adversarial verification of your defenses against realistic attack scenarios, documented in a report that auditors and partners accept as evidence. It converts "we have controls" into "we tested our controls and here is what happened."

How GDPR connects to penetration testing

GDPR operates on a different axis. It does not care about your network architecture for its own sake; it cares about the personal data flowing through it. Article 32 requires appropriate technical measures to ensure the confidentiality, integrity, and availability of personal data — and, crucially, "a process for regularly testing, assessing and evaluating the effectiveness" of those measures.

That phrase is not decorative. It is an explicit expectation that testing happens, repeatedly, and that the results are assessable. A penetration test identifies exactly where personal data can be exposed: a vulnerable web application, an unauthenticated API endpoint, a misconfigured cloud storage bucket, an internal service trusting the network too generously. Each finding is a potential personal data breach waiting for the right attacker — and each finding, once documented and remediated, is direct audit evidence for the Data Protection Officer.

The difference between the two frameworks is a matter of framing rather than substance. NIS2 asks whether your risk management is effective. GDPR asks whether the personal data you hold is actually protected. A single well-scoped penetration test answers both, because an attacker does not distinguish between a compliance obligation and a data protection duty — they simply walk through whichever door is open.

What each framework asks for — and what a pentest delivers

The table below maps the requirement to the deliverable. This is the mapping auditors ask for, and it is the mapping that turns a technical report into a compliance artifact.

Notice the fourth row. Sector-specific regimes — banking, payments, insurance — tend to be stricter and more prescriptive than NIS2 or GDPR alone. In Moldova, financial institutions and payment processors have used exactly these deliverables to support audit processes and registration with the National Bank of Moldova. Where a supervisor has its own expectations, the report must speak the supervisor's language, not just the tester's.

Deliverables that go straight into your compliance file

Here is where many organizations get an unpleasant surprise. A penetration test is not a single PDF, and a raw list of vulnerabilities is not a compliance document. What auditors, partners, and supervisors actually want is a structured set of artifacts that tell a coherent story from finding to fix.

• A technical report with the vulnerabilities identified, a risk assessment for each, and concrete remediation steps.
• An executive summary written for management and the board — no exploit code, just risk, impact, and priorities.
• Mapping of findings to NIS2 and GDPR requirements, on request, so each finding can be traced to the obligation it touches.
• A retest after remediation, as proof that the issues were actually closed rather than merely acknowledged.

That last item is the one people underestimate. A report showing ten critical vulnerabilities is, on its own, evidence of a problem — not evidence of good security. The retest is what closes the loop and demonstrates a functioning remediation process. It is the difference between "we found issues" and "we find, fix, and verify." Auditors know this distinction well, and they look for it.

Important: A penetration test report is a sensitive document. It describes exactly how your systems can be broken. Treat it as confidential material with controlled distribution, and never attach it in full to a broad vendor questionnaire — provide the executive summary and the remediation status instead.

How often should you test?

The honest answer is that there is no single number, but there is a defensible baseline: at least annually, and after any significant change to your systems — a major release, new infrastructure, a cloud migration, an acquisition, or a new public-facing service. Regulated environments often test more frequently, or move toward continuous testing, precisely because their systems do not hold still for twelve months at a time.

The reasoning is straightforward. A penetration test is a snapshot of a moving target. The moment your architecture changes, the snapshot starts to age. If your last test predates your last major deployment, you do not have evidence of your current security posture — you have evidence of a system that no longer exists. An auditor who notices that gap will ask about it, and "we were planning to schedule something" is not an answer that closes the finding.

A practical cadence many organizations adopt looks like this: an annual full-scope test, targeted tests around significant changes, and a retest after each remediation cycle. It is not glamorous, but it produces a continuous, dated, verifiable trail — which is exactly what a compliance file is supposed to be.

The strategic view: compliance as a byproduct

There is a temptation to treat NIS2 and GDPR as paperwork exercises — boxes to tick, documents to file, questionnaires to survive. That framing is understandable and almost always counterproductive. The frameworks were written by people who had watched real breaches unfold, and their requirements are, at bottom, a request for honesty: prove that you know your own weaknesses and that you are doing something about them.

A penetration test is one of the few activities that satisfies that request genuinely rather than performatively. It does not ask you to assert that you are secure. It asks an adversarial expert to try to prove you are not, and then documents what happened. When the answer comes back with findings, you fix them. When it comes back clean, you have earned a claim you can actually defend.

For Moldovan companies, the practical conclusion is this: the regulatory pressure is arriving through contracts and supply chains long before it arrives through legislation, and the organizations that treat testing as a competitive asset rather than a compliance cost will be the ones that win the tenders, pass the audits, and keep the European partners. The question your counterpart will eventually ask is not whether you have policies. It is whether you can prove your systems were tested. The answer should already be in a file, dated, signed, and ready to send.

This material is informational and does not constitute legal advice. The applicability of NIS2 and GDPR depends on each organization's specific situation; consult a legal specialist for interpretation.