NIS2 and your Git host: what Article 21 requires

NIS2 (Directive (EU) 2022/2555) requires essential and important entities to assess the security of their supply chain. Your source code host stores your intellectual property, runs your builds, and holds your deployment secrets. It is a supplier in that chain.

Article 21(2)(d) mandates "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Article 21(3) adds that you must consider each supplier's vulnerabilities, the quality of their cybersecurity practices, and their secure development procedures.

24 of 27 EU member states have transposed NIS2 into national law. Enforcement is live: Belgium, Italy, Hungary, and Germany have already issued fines or formal notices. An estimated 160,000 entities across the EU are in scope.

This page lists the questions your supplier assessment needs to answer about your Git host. They apply to any provider, not just Codebahn.

1. Where is the provider incorporated?

Jurisdiction determines which governments can compel access to your data. The US CLOUD Act (H.R. 4943, 2018) allows US law enforcement to compel a US-incorporated company to produce data regardless of where the servers are located. Choosing an "EU region" on a US-owned service changes the datacenter, not the legal entity that controls your data.

What to document: the provider's country of incorporation, any parent or holding company, and whether any entity in the ownership chain is incorporated in a jurisdiction with extraterritorial data access laws.

2. Where is data processed and stored?

NIS2 does not impose a blanket data localization mandate, but your risk assessment must document where data is processed. National transpositions and sector-specific rules (such as DORA for financial entities) may add stricter requirements.

For a Git host, "data" includes repository content, CI build logs, secrets and environment variables, issue and pull request metadata, and backups.

What to document: the provider's data center locations for each data category, including backups. Whether CI jobs execute in the same jurisdiction as the data at rest.

3. Which sub-processors are involved?

Every sub-processor extends your supply chain. Article 21(3) requires you to consider the "overall quality of products and cybersecurity practices" of your suppliers, which includes their suppliers.

What to document: the full sub-processor list, each entity's country of incorporation, what data they process, and whether you are notified before changes. A provider that publishes this list without requiring an NDA makes the assessment faster. One that gates it behind a sales call makes it slower.

4. What is the incident notification timeline?

NIS2 Article 23 requires entities to submit an early warning within 24 hours of becoming aware of a significant incident, and a full notification within 72 hours. Your ability to meet that timeline depends on how quickly your suppliers notify you.

What to document: the provider's contractual notification timeline for security incidents and data breaches. Whether notification is documented in a DPA or terms of service, not just a verbal commitment.

5. What business continuity and exit provisions exist?

Article 21(2)(c) requires "business continuity, such as backup management and disaster recovery, and crisis management." Vendor lock-in is itself a continuity risk: if you cannot leave a provider, your business continuity plan has a single point of failure.

What to document: backup frequency and retention, restore testing, whether the export format is open or proprietary, and what happens to your data after contract termination.

6. What secure development practices are in place?

Article 21(2)(e) covers "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure." For a Git host, this means: how quickly are security patches applied, is the underlying code auditable, and is there a vulnerability disclosure process?

A provider built on open-source software (where the code is publicly auditable) satisfies part of this requirement by construction. A provider whose hosting stack is entirely closed-source requires you to rely on certifications or contractual representations instead.

What to document: the provider's patching cadence, vulnerability disclosure policy, and whether the hosting platform's source code is open or closed.

7. How is continuous oversight documented?

A one-time assessment at contract signing does not satisfy Article 21. The NIS2 Implementing Regulation (EU 2024/2690) requires ongoing oversight: periodic re-assessment, monitoring of supplier security posture, and triggered re-assessment after incidents or material service changes.

What to document: whether the provider publishes security documentation publicly (so your team can monitor it without requesting updates), whether sub-processor changes are notified in advance, and whether a status page and incident history are available.

How Codebahn answers these questions

Our NIS2 supplier assessment page publishes the answers to each of these questions, including what we do not have (no SOC 2, no ISO 27001). We publish it rather than waiting to be asked, because you should be able to assess us before a call.