DevSecOps for regulated EU enterprises

What actually changed in Europe

The shift is not that Europe suddenly cares about secure code. It is that three separate instruments now expect the same thing from different angles: a defensible, repeatable process across the software lifecycle, with an audit trail. The engineering consequence is concrete — findings need owners, gates need policies, and dependencies need inventories.

The second shift is accountability. Under Directive (EU) 2022/2555, management bodies of in-scope entities are expected to approve and oversee cybersecurity risk-management measures. Security stopped being something delegated entirely downward, which is why these conversations now start in the boardroom and arrive at your backlog.

Three regulations, one engineering problem

NIS2 — risk management and supply chain

Directive (EU) 2022/2555 requires essential and important entities to take appropriate technical, operational and organisational measures to manage risks to their network and information systems. Two of the listed measure areas land squarely on software teams: supply chain security, including the security of relationships with direct suppliers; and security in acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure.

NIS2 is a directive, which means it becomes law through each Member State's transposition. Practical consequence: the obligations you face in Estonia, Germany or Spain derive from national law, and the detail differs — but the software controls converge.

DORA — operational resilience for finance

Regulation (EU) 2022/2554 applies directly to financial entities and to the ICT third-party providers that serve them. It requires an ICT risk management framework, incident classification and reporting, digital operational resilience testing, and structured management of ICT third-party risk. For software organizations, the practical reading is: your development and testing practices, vulnerability management and dependency governance are now in scope of financial supervision — either directly, or through your clients.

Cyber Resilience Act — product security and SBOM

Regulation (EU) 2024/2847 takes a product angle: it sets essential cybersecurity requirements for products with digital elements placed on the EU market, covering both the security properties of the product and the manufacturer's vulnerability handling processes across the support period. It is the instrument that puts a software bill of materials — machine-readable, covering at minimum top-level dependencies — into European law, and it introduces obligations to report actively exploited vulnerabilities.

The timeline is staged, and the reporting obligations arrive first. The Regulation entered into force on 10 December 2024; the rules on conformity assessment bodies apply from 11 June 2026; the vulnerability and incident reporting obligations under Article 14 apply from 11 September 2026 — a 24-hour early warning and a 72-hour notification to ENISA and the relevant CSIRT; and the main body of requirements applies from 11 December 2027. For most manufacturers, 11 September 2026 is the first hard deadline, and it is imminent. The CRA briefing has the full timeline.

The controls all three converge on

• ▸Component inventory. A current, machine-readable inventory of what your software is made of — see CycloneDX SBOM standard for the format most European buyers now request. This is the foundation for every other control; you cannot govern what you have not enumerated. How we establish it.
• ▸Early detection in the lifecycle. Static analysis and dependency scanning where developers work, mapped to a recognised taxonomy such as OWASP Top 10 project. SAST and code quality.
• ▸Risk-based prioritization. Regulators expect proportionality, not a flat backlog of every scanner finding. Reachability and business impact are what turn 1,000 findings into a defensible short list.
• ▸Vulnerability handling with ownership. Named owners, target dates, and a documented path from discovery to fix — explicitly referenced in NIS2's measure areas and in the CRA's process requirements.
• ▸Build and pipeline integrity. Protecting the process that produces the artifact, not just the artifact. Supply-chain Levels for Software Artifacts is the most useful public framework for reasoning about provenance levels.
• ▸Evidence. Scope, method, findings, decisions and outcomes, written so someone outside your team can follow them. NIST SP 800-218 remains the clearest public articulation of secure development practices to map your controls against.

Evidence: what an auditor actually asks for

The gap that sinks most programmes is not detection — it is narrative. Teams can produce a dashboard; they cannot produce a defensible account of why the dashboard looks like that. In practice, four artifacts do most of the work:

• ▸Scope and method statement. What was analysed, with what technique, over what period, and what was deliberately out of scope. Auditors trust a documented limitation far more than an unexplained gap.
• ▸Findings register with decisions. Not just the issues, but what you decided about each one and why — including accepted risks with an approver.
• ▸Remediation record. Evidence that the process completed: fixes, dates, verification.
• ▸Control narrative. A plain-language mapping from your engineering practice to the control the regulation expects. What we produce for auditors.

One caution worth stating plainly: no consultancy and no tool can certify your compliance. Certification decisions sit with you, your auditors and, where relevant, your notified body. Anyone promising otherwise is describing something that does not exist.

A 90-day implementation sequence

The order matters more than the speed. This is the sequence we use, and it front-loads the two things that unblock everything else: knowing your estate, and getting developers to trust the signal.

Days 1–30: baseline and inventory

• ▸Enumerate repositories, services and the products they compose — including the legacy nobody wants to open.
• ▸Establish a component inventory and generate a first SBOM.
• ▸Run a baseline analysis across code, dependencies, secrets and infrastructure as code. Measure noise honestly.
• ▸Map your regulatory exposure: which instruments, via which entity, through which contracts.

Days 31–60: signal quality and ownership

• ▸Tune rulesets to your stack until the false-positive rate is defensible to the engineers who receive the findings.
• ▸Introduce analysis in pull requests in observation mode — nothing blocks yet.
• ▸Assign ownership for material findings and agree remediation SLAs with engineering leadership.
• ▸Start the evidence trail from day one; reconstructing it later is the expensive path.

Days 61–90: gates and governance

• ▸Enforce blocking only for the risk classes your teams have agreed to, with a documented exception path.
• ▸Establish dependency governance: approved sources, update policy, review triggers.
• ▸Produce the first control narrative and review it with whoever owns compliance.
• ▸Set the cadence: what gets reviewed monthly, what gets reported quarterly, who signs.

See the gate progression and deliverable structure in detail.

Five mistakes that cost European teams a year

• ▸Buying tools before scoping obligations. Licences get renewed annually; the wrong ones get renewed twice before anyone admits it.
• ▸Enforcing gates on day one. Blocking a release with an untuned ruleset is the fastest way to have security permanently disabled by the people who ship.
• ▸Treating SBOM as a document. An inventory generated once for an audit is a snapshot of a system that changed the following week. It has to be continuous or it is theatre.
• ▸Ignoring the legacy estate. COBOL, RPG and ABAP cores are usually where the material risk and the regulatory exposure actually live — and they are excluded from most modern tooling by default.
• ▸Leaving evidence to the end. Reconstructing twelve months of decisions in the four weeks before an audit costs more than having recorded them.

The legacy problem nobody budgets for

A scanner that supports Java, Python and TypeScript covers the part of your estate that was written recently. It does not cover the transaction core in COBOL, the RPG on the AS/400, or the ABAP customisations in your ERP — which is exactly where a regulator will ask about change control and vulnerability management.

This is why the refactor-versus-remediate decision is a compliance decision as much as an engineering one. If you are weighing it, the technical debt diagnosis exists to make that call on evidence — an operational risk index and a recovery-effort estimate — rather than on instinct.

Frequently asked questions