The EU compliance surface for a software product

The General Data Protection Regulation has applied since 2018, has no size threshold worth relying on, and reaches any organisation processing the personal data of people in the European Union. For most software teams this is settled ground, and the interesting parts are no longer the policy documents but the engineering seams where personal data ends up somewhere nobody accounted for.

Where teams actually get caught

• The staging environment. Restoring a production database into a lower environment is processing, and the copy inherits none of the access controls that made production defensible.
• Logs and error reporting. A stack trace with a request body in it is a personal data store nobody designed, retained for as long as the log retention policy says, which is often forever.
• Analytics and third-party tags, which frequently fire before consent is obtained because the tag manager loads on first paint.
• Deletion that marks a row rather than removing it, and leaves the data in backups, search indexes and the data warehouse.

The test data problem is the one we meet most often and the one with the most workable answers. We have written it up separately in testing with production-like data without breaking GDPR, including why anonymised and pseudonymised are not interchangeable words.

Pseudonymised data is still personal data. Anonymised data is not. Getting that distinction wrong is what turns a reasonable-sounding test-data plan into unlawful processing.

Obligations under the European Accessibility Act became applicable on 28 June 2025. The Act covers a defined list of products and services rather than the whole economy: e-commerce, consumer banking, e-books, electronic communications, and elements of passenger transport are the ones software teams meet most often. If you sell to businesses only, read the scope carefully before assuming it binds you.

There is a real exemption. Microenterprises providing services — fewer than ten people and no more than two million euro turnover — are outside the service obligations. It is a genuine relief and a fragile one, because a company can grow out of it considerably faster than it can rebuild an interface.

Which version of WCAG actually binds

Separate technical guidance from the legal reference. W3C identifies WCAG 2.2 in the 2026 EN 301 549 edition. Use WCAG 2.2 AA for web engineering, then confirm the applicable national law, Official Journal citation and additional EN clauses with the responsible specialists. Record the exact assessment version and scope. We explain that distinction in the European Accessibility Act piece.

The cost profile here is unusual: conformance is cheap when it is designed in and expensive when it is retrofitted, and the gap between those two is larger than for almost any other requirement in this guide. That asymmetry is why we treat it as implementation work rather than as an audit finding to remediate later.

The Cyber Resilience Act covers products with digital elements placed on the European Union market. It entered into force on 10 December 2024, the reporting obligations have applied since 11 September 2026, and full application follows on 11 December 2027. Those three dates do different things and are routinely collapsed into one in summaries.

The scope test that matters most

Pure software-as-a-service is generally outside the Act. It covers products — including software placed on the market as a product, and hardware with software in it — rather than services delivered over a network, unless remote data processing is integral to a product someone buys. A great many SaaS companies currently preparing for the CRA are not in scope, and a number of manufacturers who have not started are.

1. 01Do you place a product on the EU market, as opposed to operating a service? If no, the Act probably does not reach you.
2. 02Does that product have digital elements, including firmware and bundled software? Almost certainly yes if the answer to the first question was yes.
3. 03Is remote data processing integral to how the product functions? If so, that processing is pulled into scope with it.

Where it does apply, the obligations are recognisably engineering work: security by design, a vulnerability handling process for the support period, a software bill of materials, and reporting of actively exploited vulnerabilities on a defined clock. The reporting timings and the mechanics are covered in our piece on the September 2026 deadline.

Nobody can make you "CRA compliant" with a security test. Conformity assessment is a regulatory process; an assessment is engineering evidence that supports it. Anyone selling the first while performing the second is selling you the wrong document.

NIS2 sets cybersecurity risk-management and incident-reporting duties on entities in listed sectors above a size threshold. Annex I lists essential entities — energy, transport, banking, health, digital infrastructure and others. Annex II lists important entities, including certain manufacturing, postal services, chemicals, food, and digital providers. Below the size threshold, and outside the sectors, it generally does not apply directly.

The transposition deadline for member states was 17 October 2024, but implementation has moved at different speeds across the Union, so the date that binds a given company is the one in the member state where the entity is established rather than a single European date.

Why suppliers feel it anyway

NIS2 places supply-chain security obligations on the entities it covers. Those entities discharge them through their contracts, which means a supplier who is comfortably out of scope receives the obligations second-hand: notification windows, evidence of security practice, a named contact. In practice it arrives as a security questionnaire long before it arrives as law, which is one reason we treat OWASP-based assessment as commercial groundwork rather than as a compliance exercise.

If all four are potentially in play, the order that wastes least effort is the one that resolves scope before it builds anything.

1. 01

   Establish scope in writing

   For each instrument, record whether it applies, on what basis, and who decided. A written scope decision helps avoid spending effort on irrelevant obligations and provides a basis for revisiting applicability when the product changes.

2. 02

   Fix the data seams

   Test environments, logs and deletion. These are cheap to fix early, they are the most common source of a genuine breach, and the work is useful regardless of which instrument turns out to apply.

3. 03

   Build accessibility in, now

   The only item on this list whose cost multiplies with delay. Even if the Act does not reach you, the work is the same work that makes an interface usable.

4. 04

   Get an assessment before you need one

   A security assessment done ahead of a deal is a project. The same assessment during a deal, with a procurement deadline attached, is a fire — and the findings are identical.

None of this is legal advice, and the scope questions in particular are exactly where a lawyer earns their fee. What we can tell you is what each requirement asks a delivery team to do, and how much of it you are already doing. If you want that assessed against a specific product, describe what you are shipping and we will tell you which of these actually applies.