NIS2 and DORA for software suppliers: what reaches you and the evidence to keep

NIS2 lists sectors and entity types, and developing or publishing software is not one of them. A software company comes into scope directly when it provides a listed service and is at least medium-sized: in Annex I, digital infrastructure (point 8) includes cloud computing service providers, whose service models include software as a service under recital 33, data centre service providers and content delivery networks, and ICT service management (point 9) covers managed service providers and managed security service providers; Annex II point 6 adds online marketplaces, search engines and social networking platforms. National transposition laws decide the details, so check each Member State where you have customers or an establishment.

DORA regulates financial entities, not their suppliers. It reaches you through Articles 28 to 30: your financial customers remain fully responsible for their compliance, must assess you before contracting, must write specific terms into the contract and must record the arrangement in their register of information. A provider the European Supervisory Authorities designate as critical is also overseen directly.

Article 21(2) says the measures rest on an all-hazards approach and “shall include at least” ten items. If you're in scope, each needs owned evidence; if you supply an in-scope entity, expect questions on the ones your product touches. For the entity types Article 21(5) names, the annex of Implementing Regulation (EU) 2024/2690 sets the detail in 13 sections, and ENISA's Technical Implementation Guidance (June 2025) gives examples of evidence and mappings to standards.

Section 6 of the annex turns point (e) into ten subsections: security in acquiring ICT services or products, the secure development life cycle, configuration management, change management with repairs and maintenance, security testing, security patch management, network security, network segmentation, protection against malicious and unauthorized software, and vulnerability handling and disclosure. The secure development rules apply whether development is in-house or outsourced and cover all phases, including specification, design, development, implementation and testing. Point 6.10 includes laying down a procedure for disclosing vulnerabilities in line with the national coordinated vulnerability disclosure policy.

Where a requirement applies “where appropriate” or “to the extent feasible”, an entity that doesn't apply it has to document why. An SSDF evidence matrix, release-bound test results, patch timelines measured against your policy and a published disclosure process answer most of section 6, and the same records serve your customers' supplier questionnaires.

Article 21(3) requires in-scope entities to 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”. In practice the questions arrive as a questionnaire or contract schedule. Answer with evidence rather than yes or no:

• Secure development: the framework you follow and evidence from recent releases, such as an SSDF matrix (/frameworks/ssdf-product-lifecycle/).
• Components: an SBOM per release and how you track vulnerabilities in it (/domains/supply-chain/sbom/generate-release-inventory/).
• Vulnerability handling: your disclosure policy, advisory format and fix timelines by severity.
• Incidents: how quickly you'll tell the customer about an incident affecting them, set well inside their 24-hour early warning.
• Access: MFA and SSO for customer administrators, audit logs customers can export.
• Independent assurance: a SOC 2 Type 2 report or ISO/IEC 27001 certificate whose scope names the service you sell.

Article 30(2) lists the terms every contract for ICT services needs, and Article 30(3) adds terms where the service supports a critical or important function. Commission Delegated Regulation (EU) 2024/1773 sets what the financial entity's policy on such contracts must contain, and Delegated Regulation (EU) 2025/532 covers subcontracting of those services. Each term needs something you can show:

Article 28(3) requires each financial entity to keep a register of all its ICT contracts, in the templates of Commission Implementing Regulation (EU) 2024/2956. Customers will ask you for the provider fields every year and whenever something changes, so publish them once as data. The ITS requires a valid legal entity identifier (LEI) or European Unique Identifier (EUID) for providers that are legal persons, your legal name, the country of your headquarters, your ultimate parent's identifier, the countries from which each service is provided, whether it stores data, where data is stored and where it is processed, and the chain of subcontractors that support it, each with a rank.

The field names below are this site's own. They feed ITS columns such as B_05.01.0010 (the provider's identifier), B_05.01.0080 (headquarters country), B_05.01.0110 (ultimate parent), B_02.02.0130 (country of provision), B_02.02.0150 and B_02.02.0160 (where data is stored and processed) and template B_05.02, the ICT service supply chain with each provider's rank. Countries use ISO 3166-1 alpha-2 codes, as the ITS requires.

{
  "provider": {
    "lei": "984500QUILLSTONE0X42",
    "legal_name": "Quillstone Software GmbH",
    "type_of_person": "legal person",
    "headquarters_country": "DE",
    "ultimate_parent_lei": "984500QUILLPARENT056"
  },
  "services": [
    {
      "name": "Quillstone Reconcile (SaaS)",
      "provided_from": [
        "DE",
        "IE"
      ],
      "stores_data": true,
      "data_at_rest": [
        "DE",
        "IE"
      ],
      "data_processing": [
        "DE",
        "IE",
        "PT"
      ],
      "supply_chain": [
        {
          "rank": 1,
          "provider": "Quillstone Software GmbH",
          "role": "service provider"
        },
        {
          "rank": 2,
          "provider": "cloud infrastructure provider (named in the contract annex)",
          "role": "hosting"
        },
        {
          "rank": 2,
          "provider": "support centre in PT (Quillstone Unipessoal Lda)",
          "role": "level 2 support with data access"
        }
      ]
    }
  ],
  "updated": "2026-10-01"
}

Most of what NIS2 and DORA customers ask for is the same evidence seen from different articles, as /frameworks/compliance-evidence-reuse/ shows for other frameworks. Keep one manifest that names each piece of evidence, when it was refreshed and how old it may get, and map every requirement your contracts cite to it. The checker below fails when evidence is stale, a requirement cites evidence that doesn't exist, an LEI fails its ISO 17442 check digits or a country isn't an ISO code. Run it in CI and before each customer review.

{
  "reviewed_on": "2026-10-10",
  "evidence": {
    "SDLC": {
      "what": "SSDF 1.1 evidence matrix for the last two releases",
      "refreshed": "2026-09-30",
      "max_age_days": 120
    },
    "PENTEST": {
      "what": "Independent penetration test report, summary for customers",
      "refreshed": "2026-03-14",
      "max_age_days": 365
    },
    "CVD": {
      "what": "Vulnerability disclosure policy and published advisories (CSAF)",
      "refreshed": "2026-08-02",
      "max_age_days": 365
    },
    "SBOM": {
      "what": "CycloneDX SBOM per release, on request",
      "refreshed": "2026-10-02",
      "max_age_days": 45
    },
    "PATCH": {
      "what": "Patch timelines met, by severity, last two quarters",
      "refreshed": "2026-07-05",
      "max_age_days": 120
    },
    "SOC2": {
      "what": "SOC 2 Type 2 report, 1 July 2025 to 30 June 2026",
      "refreshed": "2026-08-20",
      "max_age_days": 365
    },
    "BCP": {
      "what": "Business continuity test: region failover, measured recovery times",
      "refreshed": "2026-05-28",
      "max_age_days": 365
    },
    "EXIT": {
      "what": "Exit runbook: full export in documented formats, transition support terms",
      "refreshed": "2026-02-11",
      "max_age_days": 365
    },
    "REGISTER": {
      "what": "Register-of-information data sheet (supplier-register-data.json)",
      "refreshed": "2026-10-01",
      "max_age_days": 90
    }
  },
  "requirements": {
    "NIS2 Art. 21(2)(d), 21(3) supply chain security": [
      "SDLC",
      "PENTEST",
      "SBOM"
    ],
    "NIS2 Art. 21(2)(e) development, vulnerability handling and disclosure": [
      "SDLC",
      "CVD",
      "PATCH"
    ],
    "DORA Art. 30(2)(b) locations of service and data": [
      "REGISTER"
    ],
    "DORA Art. 30(2)(c) availability, authenticity, integrity, confidentiality": [
      "SOC2"
    ],
    "DORA Art. 30(2)(d) access, recovery and return of data": [
      "EXIT"
    ],
    "DORA Art. 30(3)(c) contingency plans and their testing": [
      "BCP"
    ],
    "DORA Art. 30(3)(f) exit strategy and transition period": [
      "EXIT"
    ]
  }
}

It needs only the Python standard library. On the files above it prints assurance pack OK; change one LEI character and the check-digit test fails. The ISO 7064 check turns each letter into a number from 10 (A) to 35 (Z), reads the whole identifier as one decimal number and requires a remainder of 1 when divided by 97.

"""Check the assurance pack and register data sent to NIS2 and DORA customers before each review.

Usage: python3 check_pack.py assurance-pack.json supplier-register-data.json
"""

import json
import re
import sys
from datetime import date


def lei_ok(lei):
    """ISO 17442: 20 alphanumeric characters whose ISO 7064 MOD 97-10 check is 1."""
    if not re.fullmatch(r"[0-9A-Z]{18}[0-9]{2}", lei or ""):
        return False
    return int("".join(str(int(c, 36)) for c in lei)) % 97 == 1


def problems(pack, register):
    today = date.fromisoformat(pack["reviewed_on"])
    found = []
    for name, item in pack["evidence"].items():
        age = (today - date.fromisoformat(item["refreshed"])).days
        if age > item["max_age_days"]:
            found.append(f"{name}: {age} days old, refresh after {item['max_age_days']}")
    for requirement, names in pack["requirements"].items():
        for name in names:
            if name not in pack["evidence"]:
                found.append(f"{requirement}: cites missing evidence {name}")
    provider = register["provider"]
    for field in ("lei", "ultimate_parent_lei"):
        if not lei_ok(provider.get(field)):
            found.append(f"register: {field} {provider.get(field)!r} is not a valid LEI")
    for service in register["services"]:
        countries = service["provided_from"] + service["data_processing"]
        if service["stores_data"]:
            countries += service["data_at_rest"]
            if not service["data_at_rest"]:
                found.append(f"{service['name']}: stores data but lists no storage country")
        found += [f"{service['name']}: {c!r} is not an ISO 3166-1 alpha-2 code"
                  for c in countries if not re.fullmatch(r"[A-Z]{2}", c)]
    return found


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f, open(sys.argv[2], encoding="utf-8") as g:
        issues = problems(json.load(f), json.load(g))
    print("\n".join(issues) or "assurance pack OK")
    sys.exit(1 if issues else 0)

NIS2 is a directive, so national law applies to you, not the directive's text. Germany's implementing act entered into force on 6 December 2025. On 8 July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for not notifying full transposition; most other Member States had notified, and the Dutch Cyberbeveiligingswet entered into force on 15 August 2026. Registration duties, supervisors and fines differ by country.

Two proposals were still in the legislative process on 10 October 2026. The Commission's proposal of 20 January 2026, COM(2026) 13, would amend NIS2 to simplify jurisdiction rules and align it with the revised Cybersecurity Act. The Digital Omnibus, COM(2025) 837, would add a single ENISA entry point for incident reports under NIS2, the GDPR, DORA and other laws. Neither changes what you report today. For EU product rules on manufacturers, the Cyber Resilience Act's reporting duties have applied since 11 September 2026; see /frameworks/cra-reporting-runbook/.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Directive (EU) 2022/2555 (NIS2), Article 21: cybersecurity risk-management measures. OJ L 333, 27 December 2022.
2. NIS2, Article 23: reporting obligations. OJ L 333, 27 December 2022.
3. Commission Implementing Regulation (EU) 2024/2690: technical and methodological requirements under NIS2. OJ L 2024/2690, 18 October 2024.
4. ENISA: NIS2 Technical Implementation Guidance. 26 June 2025.
5. European Commission: referral of Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose NIS2. 8 July 2026.
6. European Commission: proposal amending NIS2 for simplification and alignment with the Cybersecurity Act, COM(2026) 13. 20 January 2026.
7. Regulation (EU) 2022/2554 (DORA), Article 30: key contractual provisions. OJ L 333, 27 December 2022.
8. Commission Delegated Regulation (EU) 2024/1773: policy on ICT services supporting critical or important functions. OJ L 2024/1773, 25 June 2024.
9. Commission Implementing Regulation (EU) 2024/2956: register of information templates. OJ L 2024/2956, 2 December 2024.
10. Commission Delegated Regulation (EU) 2025/532: subcontracting ICT services supporting critical or important functions. OJ L 2025/532, 2 July 2025.
11. ESMA: the European Supervisory Authorities designate critical ICT third-party providers under DORA. 18 November 2025.
12. ESAs: list of designated critical ICT third-party service providers (19 providers)
13. European Commission: DORA implementing and delegated acts

Reference information

Tags

Supply chain attacksRegulationSupplier and open source risk

SDLC phase

PlanningSecurity program

Role

Security leaders

Download this guide as Markdown

Continue exploring