Three Regulators, One Deadline: The EU Compliance Crunch Hitting IT Providers in Late 2026

A Nottingham manufacturer that sells sensors into Germany recently asked us a simple question: "Do any of these EU rules actually apply to us? We left the EU." The short answer is yes, and probably more than they expected. The longer answer is that three separate pieces of European law are about to demand attention at almost the same moment, and treating each as its own project is the fastest way to burn a year of budget for no good reason.

Here is the pile-up. NIS2, the updated network and information security directive, is already being written into national law across the bloc and enforcement is ramping through 2026. The EU AI Act's obligations for high-risk systems begin biting in August 2026. And the Cyber Resilience Act (CRA) brings its reporting duties for products with digital elements into force in the second half of 2026, with the full weight of the regime following. For a UK SME that sells software, connected products, or managed services into the EU — or supplies a firm that does — autumn 2026 is when the theoretical becomes the invoiced.

Why UK firms aren't off the hook

Brexit changed who writes the rules, not whether they reach you. These frameworks apply based on where you do business, not where you're headquartered. If you place a connected product on the EU market, the CRA is your problem. If your AI-driven tool is used to screen job candidates or assess creditworthiness for an EU customer, the AI Act's high-risk provisions can attach to you as a provider. If you're an important supplier to an EU entity that falls under NIS2, you'll feel the pressure through their contracts even if you're never named directly.

We've already seen this play out with GDPR. Plenty of Midlands businesses that assumed it was "an EU thing" ended up rewriting their data practices because a customer's procurement team insisted. The same contractual gravity is building around all three of these new regimes.

The trap: three projects, three teams, three spreadsheets

The instinctive response is to spin up a compliance workstream for each. One team reads NIS2 and produces a set of security controls and incident procedures. Another team reads the AI Act and starts cataloguing models and risk classifications. A third reads the CRA and worries about vulnerability handling and product reporting. Each hires a consultant. Each buys a tool. Each writes its own policies.

That approach is expensive, slow, and — critically — produces conflicting evidence. When an auditor or a customer asks how you handle a serious incident, you do not want three different answers depending on which framework they're asking about. The overlap between these rules is substantial, and the smart move is to build once and map many.

Use the strictest incident clock as your standard

Start with incident notification, because that's where the frameworks argue with each other most visibly. NIS2 expects an early warning within 24 hours of becoming aware of a significant incident, followed by a fuller notification within 72 hours. The CRA has its own reporting timelines for actively exploited vulnerabilities and severe incidents. And for financial-sector firms, DORA — the Digital Operational Resilience Act — imposes an even tighter, more prescriptive regime with defined windows and standardised report templates.

Rather than build a separate process to satisfy each clock, build one process that satisfies the strictest. DORA's incident-notification discipline is the most demanding of the group: it forces you to detect fast, classify against clear criteria, and report through a structured template on a firm schedule. If your detection and notification machinery can hit DORA's bar, it clears the NIS2 windows comfortably and gives you the raw material the CRA needs.

You don't have to be a bank to borrow the model. Treating DORA as your de facto internal standard means one runbook, one classification matrix, one on-call escalation path, and one set of report templates that you adapt at the edges for each regulator's submission portal. When an incident hits, your team runs one process rather than pausing to ask which law is watching.

For most SMEs the practical work is unglamorous: agree what "significant" and "severe" mean in your context, write those thresholds down, and rehearse the notification chain so that the 24-hour warning isn't a scramble. Tabletop exercises are worth more here than any policy document.

Build one AI inventory and let three frameworks read from it

The second piece of shared infrastructure is a clean inventory of every AI system you build, buy, or embed. The AI Act obviously needs this — you cannot classify systems as high-risk, limited-risk, or minimal-risk if you don't know what you're running. But a proper inventory pays off across all three regimes.

A connected product with a machine-learning component sits inside the CRA's scope as a product with digital elements, so its AI features need to appear in your vulnerability-handling and security-update planning. NIS2's risk-management obligations expect you to understand the systems in your environment and their exposure, and an AI system that makes or influences operational decisions is exactly the kind of thing a security assessment should cover.

A useful inventory records, for each system: what it does, whether it's yours or a third party's, what data it touches, where it's deployed, its intended purpose, and its risk classification. Add the supplier, the model version, and who owns it internally. That single table becomes the reference point for AI Act conformity work, CRA product documentation, and NIS2 supply-chain risk reviews. Build it once, keep it current, and three separate audit requests draw from the same source of truth.

The payoff: three workstreams collapse into one

When you approach late 2026 this way, the shape of the work changes. Instead of three compliance projects with three budgets, you have one shared evidence base with three views onto it. Your incident process satisfies NIS2 and feeds the CRA, built to a DORA-grade standard. Your AI inventory anchors the AI Act and informs both the CRA and NIS2. Your governance, access controls, and supplier-management practices — the boring foundations — count towards all three at once.

This isn't a loophole; it's how mature compliance actually works. Regulators aren't trying to catch you three times for the same failing. They want to know that you understand your systems, spot problems quickly, tell the right people, and fix them. Answer that once, thoroughly, and you've answered it everywhere.

Where to start before autumn 2026

Three steps, in order. First, scope your exposure honestly — which of your products, services, or customer relationships actually reach the EU, and under which framework. Second, stand up the AI inventory now, because it takes longer to build accurately than anyone expects. Third, adopt the strictest incident-notification standard as your house rule and rehearse it.

The firms that struggle in late 2026 will be the ones who left it to three panicked projects in the final quarter. The ones who cope will have spent 2025 and early 2026 building a single, well-documented picture of their systems and their incident response. If you'd like a straight assessment of which of these rules touch your business — and how to build the shared evidence base rather than three redundant ones — that's exactly the kind of planning we help Midlands SMEs get right before the deadline, not after.