• NIS2 and Pentest Data Residency: What Security Teams Need to Know
  • What NIS2 Article 21 actually says about supply chain security
  • Why pentest tooling is now in the supply chain audit scope
  • The honest answer: NIS2 does not mandate self-hosting
  • What closes the question vs. what leaves it open
  • The open-source auditability angle auditors actually care about
  • This applies if / skip this if
  • What to do next
  • Related content
  • Frequently asked questions

NIS2 and Pentest Data Residency: What Security Teams Need to Know

Your procurement team just flagged every third-party tool that touches vulnerability data. Or a client's security questionnaire now has a section specifically about NIS2 Article 21 supply chain controls, and you need to answer it for the platform where your pentest findings live. Either way, you need to know exactly where NIS2 draws the line on pentest data residency, and whether your current reporting tool can survive the audit.

What NIS2 Article 21 actually says about supply chain security

NIS2 (EU Directive 2022/2555) entered into force on January 16, 2023, with a transposition deadline of October 17, 2024. It covers an estimated 160,000+ organizations across 15 sectors, split into essential entities (energy, health, transport, finance, water, digital infrastructure, public administration, space) and important entities (digital providers, postal services, waste management, food, manufacturing, chemicals, research).

The security requirements live in Article 21, which mandates technical and organizational measures proportionate to risk. Two provisions are directly relevant to pentest tooling:

Article 21(2)(d): "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."

Article 21(2)(e): "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure."

Article 21(3) adds the specificity that makes this operational: entities must "take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures."

Read together, these provisions create a clear obligation. If you are an essential entity in healthcare or energy and you commission a penetration test, the project will contain critical infrastructure vulnerability data: open ports, network topology, authentication bypasses, unpatched CVEs. Under Article 21(2)(d) and 21(3), you must be able to demonstrate that the tools processing and storing that data meet appropriate security standards. If those findings route through a vendor-controlled cloud, that vendor becomes a supplier whose risk you must assess, document, and defend.

Why pentest tooling is now in the supply chain audit scope

Pentest findings are not generic business data. A penetration test report for an essential entity contains a map of exactly how to compromise that organization's infrastructure: the vulnerabilities, the attack paths, the evidence. This is the most sensitive operational security data an organization produces.

Under NIS2's supply chain requirements, any tool that processes this data becomes a link in the supply chain that auditors can examine. The question is not abstract. It is: "Where are your pentest findings stored? Who has access to the infrastructure? What is your data processing agreement? What happens if that vendor is breached?"

For consultancies serving EU clients, the pressure arrives from both sides. Your client, an essential or important entity, must assess their suppliers under Article 21(2)(d). You are that supplier. And the tools you use to store and process their findings are your suppliers. The chain extends: if your pentest reporting platform routes findings to a third-party cloud, your client's auditor can reasonably ask whether you have assessed that platform's security practices, data processing location, and incident response procedures.

Sophisticated EU buyers in regulated sectors are starting to reject "exceptions" in security questionnaires. "We use a cloud platform but here's the DPA" is a defensible answer for many tools. For a platform holding the detailed map of how to break into a hospital network or energy grid, the bar is higher.

The honest answer: NIS2 does not mandate self-hosting

NIS2 does not contain a list of approved tools. It does not mandate on-premise deployment. It requires organizations to take "appropriate and proportionate" measures and to assess supplier security.

A cloud SaaS vendor with SOC 2 Type II, ISO 27001, and a data processing agreement that specifies EU data residency might pass some organizations' supply chain assessments. For a team where the risk tolerance allows it and the auditor accepts it, cloud-hosted pentest tooling can be NIS2-compliant. Anyone who tells you otherwise is selling something.

The question is whether that answer holds for your specific risk profile. For teams at entities designated as essential (government contractors, healthcare providers, energy companies, organizations operating under Germany's KRITIS regulations), the risk calculus is different. These organizations face:

• Fines up to EUR 10 million or 2% of global annual revenue (whichever is higher)
• Management liability: executives can be temporarily banned from management roles for persistent non-compliance (this is new under NIS2, and it is personal, not corporate)
• Auditors who are specifically trained to examine supply chain security under Article 21

For important entities, fines reach EUR 7 million or 1.4% of global revenue. The management liability provisions apply to both categories.

When the fine structure is that severe and the liability is personal, "we assessed the risk and accepted it" requires significantly more documentation and justification than "the data never leaves infrastructure we control." One answer closes the question. The other opens a file.

What closes the question vs. what leaves it open

There are two architectural approaches to NIS2 compliance for pentest data:

	Contractual compliance (cloud SaaS)	Architectural compliance (self-hosted)
Data location	Vendor-controlled cloud; DPA specifies region	Your servers, your datacenter, your access controls
Supply chain surface	Vendor is a supplier under Art. 21(2)(d); must be assessed, documented, defended	No third-party data processor; no supply chain link to assess
Audit answer	"We assessed the vendor and accepted the residual risk"	"The data never leaves infrastructure we control"
Continuous compliance	Requires ongoing vendor assessment; SOC 2 is point-in-time	Infrastructure controls are your responsibility regardless, but no vendor variable
Breach exposure	Vendor breach exposes your findings	No vendor breach vector for pentest data
Air-gapped support	Not possible	Full offline operation, no external dependencies

Contractual compliance works for teams whose risk tolerance and auditor accept it. The honest risk: a SOC 2 report is a point-in-time attestation. The vendor's security posture can change between audits. A breach at the vendor exposes your findings. The auditor can ask "what is your continuous assessment process for this supplier?" and the honest answer is often "we check annually."

Architectural compliance eliminates the most contested surface in the NIS2 supply chain audit. It does not replace the need for proper access controls, encryption, and incident response within your own infrastructure (NIS2 requires those regardless). But it removes the supplier risk variable from the equation for pentest data specifically.

For air-gapped environments (classified facilities, defense contractors, secure government networks), the calculus is simpler. Cloud is not an option. The platform must function fully offline, with no external dependencies and no phone-home telemetry. Offline license activation, local user management, and zero internet connectivity requirements are not features. They are prerequisites.

The open-source auditability angle auditors actually care about

Article 21(3) requires entities to evaluate the "secure development procedures" of their suppliers. For a proprietary, closed-source pentest platform, this evaluation is indirect: you rely on the vendor's SOC 2 report, their security page, their attestations. You cannot inspect the code that handles your findings. You cannot verify that the encryption implementation matches the documentation. You cannot audit how session tokens are generated or how access controls are enforced.

With an open-source platform, the evaluation is direct. The code is inspectable. Your security team can (and regulated teams do) audit the source, verify the claims, and confirm the implementation matches the documentation. When an auditor asks "how do you assess your supplier's secure development procedures?" the answer is "we read the code."

This is not a theoretical advantage. Regulated buyers in government and defense procurement routinely require source code access as a condition of tooling approval. Open-source satisfies this requirement by default.

This applies if / skip this if

This piece is for you if:

• Your organization is designated as an essential or important entity under NIS2, or you serve clients who are
• You have an upcoming vendor risk assessment or procurement review that now includes NIS2 Article 21 supply chain questions
• Your pentest findings contain critical infrastructure vulnerability data that would cause material harm if exposed
• Your risk tolerance for pentest data residency is zero: you need the question closed, not managed
• You operate in a member state that has already transposed NIS2 (Germany, Netherlands, and others as of April 2026)

This piece is less relevant if:

• Your organization is outside the EU and none of your clients are EU essential or important entities
• Your pentest scope is limited to non-critical systems where finding exposure would not trigger regulatory consequences
• Your existing cloud vendor's data processing agreement and security certifications already satisfy your auditors
• You are looking for a general NIS2 overview rather than the specific intersection with pentest tooling

What to do next

1. Check your entity classification. NIS2 applies to essential and important entities across 15 sectors. If you are unsure whether your organization qualifies, start with your legal or compliance team. The classification determines your fine exposure and reporting obligations.
2. Audit your current pentest data flow. Map where findings are created, stored, processed, and transmitted. Identify every third-party service in that chain. Each one is a supplier under Article 21(2)(d).
3. Review your vendor's Article 21(3) documentation. For cloud-hosted tools, request specific evidence of secure development procedures, data residency controls, and incident response. A SOC 2 report alone may not satisfy an auditor asking specifically about NIS2 supply chain requirements.
4. Evaluate self-hosted alternatives for pentest data. If your risk profile demands it, the architectural answer is a platform that runs entirely on your infrastructure, with no third-party processing, no data residency negotiation, and no contractual exceptions.
5. Prepare your Article 21 supply chain response now. Auditors are coming. Having a documented answer for "where is your pentest data and who can access it?" before the audit is significantly less expensive than assembling one during it.

Related content

• Self-Hosted vs. Cloud SaaS for Pentest Reporting: A Data Sovereignty Comparison — the broader data sovereignty argument for pentest tooling, covering GDPR, client requirements, and vendor independence
• Dradis Echo: AI-Assisted Pentest Reporting Without Sending Data to the Cloud — how local AI via Echo keeps finding data on your infrastructure, including the architecture that makes it possible
• Best Pentest Report Generators Compared — honest comparison of reporting platforms including data residency architecture for each
• Enterprise Pentest Management with Dradis — deployment options, compliance certifications, and infrastructure control for enterprise teams
• Dradis Deployment Options — air-gapped deployment, private cloud, offline license activation, and infrastructure requirements

Frequently asked questions