Skip to content
steelabs

Insights

EU regulation

The European regulatory surface a software product actually sits on — GDPR, the European Accessibility Act, the Cyber Resilience Act and NIS2 — read for what they require of an engineering team, with the dates and the primary sources.

Where we stand

European software regulation arrives as a sequence of dates rather than as a single event, and the useful question is never "are we compliant" but "which of these actually binds this company, and by when". Scope depends on sector, size and where the entity is established, and a great deal of published advice skips all three.

Most of what these regulations ask of an engineering team is unglamorous and familiar: know what is in your product, know where personal data goes, be able to say what changed and when, and have a route to report an incident inside a fixed window. Teams already doing those things well are closer to compliant than they expect.

The places it gets genuinely hard are the seams. A production restore into a staging environment is processing personal data. A dependency you did not write is part of the product you place on the market. An integration partner’s breach is your incident to report. None of those are edge cases and all of them cross a boundary somebody assumed was somebody else’s.

We write about this because the gap between the text and the engineering consequence is where teams get caught, and because we cannot give legal advice — only an accurate account of what the requirement asks a delivery team to do.

Articles on EU regulation

Contact

Have a project in mind?

Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.