What it is
NIS2 and DORA are usually named in one breath, and for a software vendor they do land the same way — as questions from customers — but they are different instruments aimed at different people.
NIS2 — Directive (EU) 2022/2555 — is the EU’s network-and-information- security directive, the successor to the original NIS Directive. It obliges “essential” and “important” entities in listed sectors (energy, transport, banking, health, digital infrastructure, public administration, managed service providers and more) to take appropriate and proportionate cybersecurity risk-management measures, to have management accountable for them, and to report significant incidents on a fixed timeline. Among those measures are supply-chain security and security in the acquisition, development and maintenance of network and information systems.
DORA — Regulation (EU) 2022/2554, the Digital Operational Resilience Act — does a similar job for the financial sector, in much more detail: ICT risk-management frameworks, incident classification and reporting, resilience testing, and a dedicated regime for managing ICT third-party risk, including contractual requirements towards ICT providers and direct EU oversight of providers designated as critical.
Neither was written about software vendors as such. What both do is push documentation demands down the chain: a regulated customer that must demonstrate control over its suppliers and its systems’ development will ask its vendors to demonstrate the same — in questionnaires, in contracts, in audits. That is where most readers of this guide will meet NIS2 and DORA: not as a regulator at their own door, but as a customer’s procurement or risk team asking “show us how your software is developed and changed”.
A necessary honesty, up front: NIS2 is governance and security regulation for essential and important entities, and DORA is ICT risk management for finance. The development-evidence slice this guide describes is a small part of either. Saying so plainly protects the credibility of the rest.
Who it applies to and when
NIS2 applies to entities in the sectors listed in its annexes that meet the size thresholds (medium-sized and above, with sector-specific exceptions), split into essential and important entities with different supervision intensity. Member states had to transpose it by 17 October 2024; national enforcement is ongoing and uneven, and the concrete obligations a vendor’s customer faces come from the national law and the supervising authority, not from the directive’s text alone. A software vendor is directly in scope only if it is itself such an entity — for example a managed service provider, a cloud provider or a data-centre operator.
DORA applies to financial entities — banks, insurers, investment firms, payment and crypto-asset service providers, and others — and to the ICT third-party service providers that serve them. It has applied since 17 January 2025. Most ICT providers meet DORA through the contractual arrangements their financial customers are obliged to put in place; a small number of providers designated as critical come under direct oversight by the European supervisory authorities.
The neighbouring instrument on the vendor side is the Cyber Resilience Act: where NIS2 and DORA make your customers ask about your development process, the CRA makes it your own documentation duty from 11 December 2027, with reporting clocks from 11 September 2026. The three converge on the same record from three directions.
What it asks of your development process
Read from the vendor’s chair, the asks are concrete and repetitive across customers:
- Evidence of a controlled development lifecycle. NIS2’s risk-management measures expressly include security in the acquisition, development and maintenance of systems (Article 21(2)(e)); DORA’s ICT risk framework expects change management and secure development practices, and its third-party provisions expect the customer to be able to assess and monitor them. The practical question is always the same: can you show, for a given change or release, what changed, who or what authored it, what was reviewed and tested?
- Supply-chain security and provenance (NIS2 Article 21(2)(d)). Customers want to know where changes come from — from suppliers, from components, and increasingly from AI tools. “What share of your code is AI-generated, and how is it reviewed?” is now a standard vendor-assessment question, and it cannot be answered from a policy document.
- Vulnerability-handling and incident support. Both regimes run incident-reporting clocks on the customer’s side (NIS2’s early warning within 24 hours and notification within 72 hours; DORA’s classification and reporting timelines). When a customer’s incident traces to your software, what they need from you within those hours is the timeline: which versions contain the affected component, when the fix was authored, reviewed, tested and released.
- Answers that survive an audit. A questionnaire response is a promise. Customers’ auditors and supervisors increasingly want the promise backed by records they could, in principle, inspect — and a record whose integrity a third party can check without trusting the vendor is worth more than one that cannot be.
What the regimes do not ask of a vendor’s development process — and where a vendor should not be sold otherwise — are the governance duties that sit squarely with the regulated entity: board accountability, organisational risk management, the entity’s own incident reporting to its authority, DORA’s resilience testing programme and register of information. Those are your customer’s, and a development record does not discharge them.
What OLOBOLO evidence supports
OLOBOLO records the development-process slice that regulated customers ask vendors about: per-change provenance (human or agent authorship, tool and model), review decisions, test evidence and sealed releases with external time anchors — exportable, and verifiable by anyone with the open-source verifier. Our regulatory mapping v1 covers NIS2; the table mirrors it, line for line, including its deliberately limited claim.
| Requirement | What you need to show | Chain evidence | Support |
|---|---|---|---|
| NIS2 Art. 21(2)(d)-(e) — supply-chain security and security in development/maintenance of systems | Evidence of a controlled development process and of the provenance of changes from suppliers and tools (incl. AI tools) | Per-change provenance (human/agent authorship), review + test evidence, release seals with anchors | Partially supports |
| NIS2 governance, risk management, incident reporting (Art. 20, 21, 23) | Organisational measures, board accountability, 24/72-hour incident reporting | — | Out of scope |
The mapping says it outright: NIS2 has limited relevance for the chain. It supports the development- and supply-chain evidence slice of an entity’s NIS2 measures — nothing more — and the organisational and operational duties are out of scope.
DORA is not (yet) a regulatory mapping. We have not published mapping lines for DORA, and this guide does not invent them. What we can say with the same vocabulary: for the ICT third-party documentation a financial customer asks of a software vendor — secure development practices, change control, provenance of changes and components, remediation timelines — the chain supports the evidence part in the same way as the NIS2 line above, and the financial entity’s own framework, testing, register and reporting duties are out of scope. If and when DORA enters the mapping, this section will follow it, not lead it.
Evidence, not a legal opinion: this maps what the chain supports as documentation — your counsel, and your customer’s, decide what compliance requires.
How to start
- Answer the next vendor questionnaire from the record. Install the recorder on the repositories your regulated customers depend on; from then on “how are changes authored, reviewed and tested?” has a verifiable answer rather than a promise.
- Make AI provenance explicit. If agents write code, let the recorder capture it — tool, model, session — and pair each agent change with a human review. That is the supply-chain question customers are now asking first.
- Keep release seals and reports. A sealed release with its evidence report is what you hand a customer’s risk team, and what lets you answer an incident’s “which versions, since when, fixed how” inside their reporting clock.
- Be honest about the boundary. Tell customers what the record is — evidence of your development process — and what it is not. A vendor that overclaims on NIS2 or DORA loses the credibility of everything else it says.