Compliance Convergence 2026-2027: A Single Control Fabric for AI Act, CRA, NIS2 and the Data Act

Four EU regimes with heavily overlapping controls are landing inside the same eighteen months, and the default response — a programme, a workstream and a spreadsheet for each — is the expensive way to do it and the way that leaves gaps.

The AI Act, the Cyber Resilience Act, NIS2 and the Data Act were drafted by different directorates for different purposes, but they ask a firm to do many of the same things: keep tamper-evident logs, detect and report incidents on a clock, handle vulnerabilities, document your architecture, and be able to show a supervisor the evidence on demand. If you stand up a separate team for each, you will pay for the same control four times, and you will still find holes where nobody was sure which team owned what. The way through is not four programmes. It is one control catalogue with a mapping from each regulation to the controls that satisfy it. I have argued this before for AI Act, DORA and NIS2; adding the CRA and the Data Act only makes the case sharper.

The dates that force the decision

The timetable is the reason this is urgent rather than tidy. NIS2 (Directive (EU) 2022/2555) had a transposition deadline of 17 October 2024, and in mid-2026 a number of member states are still finishing their national laws — so the obligation is live but the detail varies by jurisdiction. The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024; its incident and vulnerability reporting duties apply from 11 September 2026, and the bulk of the manufacturer obligations from 11 December 2027. The Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025, with cloud switching charges due to be fully abolished on 12 January 2027. The AI Act’s high-risk obligations were originally due on 2 August 2026; a Digital Omnibus reached political agreement to defer Annex III standalone systems to 2 December 2027 and Annex I embedded systems to 2 August 2028, but as I write it has not been published in the Official Journal — so the original dates remain the binding law until it is. Treat the deferral as room to get ahead, not permission to wait; I have written separately on why the Annex III reprieve is a trap.

Stacked like that, the dates make the siloed model untenable. You cannot run four independent design cycles when their controls overlap and their deadlines interleave. You end up rebuilding the same logging standard three times because three teams reached it in three different months.

Where the four actually overlap

The overlap is not marketing. It is concrete and it is at the control layer, which is exactly where you want convergence to happen. Incident detection and time-bound notification appears in NIS2’s reporting duties and in the CRA’s reporting obligations, on comparable clocks. Tamper-evident logging and retention is demanded by the AI Act’s record-keeping requirement for high-risk systems, by NIS2’s risk-management measures, and by the CRA’s essential requirements. Coordinated vulnerability handling and a maintained software bill of materials sit in the CRA and lean on the same asset inventory NIS2 expects. The Data Act is the outlier — its centre of gravity is portability and switching rather than security — but it still draws on the same architecture documentation and the same interoperability metadata, and for an AI-enabled product the CRA and AI Act conformity work collides on a single design file.

Once you see the controls as shared, the unit of work changes. You are not satisfying four regulations. You are operating a set of controls, each of which happens to discharge obligations under several of them. One piece of evidence — a logging standard with proof it is enforced — can answer three supervisors.

The control fabric, concretely

A control fabric is three things: a single catalogue of controls, each with a named owner and a pointer to its evidence; a mapping from every obligation in each regime to the control or controls that discharge it; and a report that inverts the mapping to show, per regulation, which obligations are covered, which have no control, and which have a control but no evidence. The mapping is the artefact that matters. It is what lets you answer the two questions a board and a regulator both ask: are we covered, and can we prove it.

Keep the mapping machine-readable rather than trapped in a slide. If it is data, you can generate the coverage report on every change, diff it when a national transposition lands, and fail a build when a control loses its evidence. A minimal shape looks like this — a catalogue that declares, per control, which regime and articles it satisfies, with a coverage summary a tool produces from it.

# control-crosswalk.yaml
# One catalogue, mapped to every regime that relies on each control.
# A coverage tool reads this, inverts it per regulation, and flags
# any obligation with no control (a gap) or no evidence (a hole).

controls:
  - id: CTL-INC-01
    name: Incident detection & time-bound notification workflow
    owner: Head of Security Operations
    evidence:
      - runbook/incident-notification.md
      - siem/alert-rules/
    satisfies:
      - regime: NIS2          # Directive (EU) 2022/2555
        articles: ["23"]
      - regime: CRA           # Regulation (EU) 2024/2847
        articles: ["14"]      # reporting applies from 11 Sep 2026

  - id: CTL-LOG-02
    name: Tamper-evident logging & retention
    owner: Platform Engineering
    evidence:
      - architecture/logging-standard.md
    satisfies:
      - regime: AIAct         # Regulation (EU) 2024/1689
        articles: ["12"]      # automatic record-keeping, high-risk
      - regime: NIS2
        articles: ["21"]
      - regime: CRA
        articles: ["annex-I"]

  - id: CTL-VULN-03
    name: Coordinated vulnerability handling & SBOM
    owner: Product Security
    evidence:
      - security/vuln-policy.md
      - sbom/latest.spdx.json
    satisfies:
      - regime: CRA
        articles: ["annex-I"]
      - regime: NIS2
        articles: ["21"]

# coverage report (generated, not hand-written):
#   obligations_total:        41
#   mapped:                   38
#   unmapped:                  3   # e.g. AI Act Art 27 FRIA, Data Act switching
#   mapped_without_evidence:   5   # control claimed, artefact missing

The point of the file is not elegance. It is that the two failure modes — an obligation nobody mapped, and a control nobody can evidence — become numbers you watch, not surprises a supervisor finds for you.

Where the model has limits

A shared catalogue is not a claim that the four regimes are the same. They are not. The AI Act cares about fundamental-rights impact and human oversight in ways the CRA does not touch. The Data Act’s switching and egress obligations are a commercial and architectural matter with no analogue in NIS2. NIS2 reaches into governance and management accountability the CRA leaves to product conformity. The mapping must therefore be honest about the obligations that are unique — they get their own controls, owned once, not folded into a generic bucket to make the coverage number look better. A crosswalk that maps everything to something is worse than useless; it hides the gaps it was built to expose.

The other limit is ownership. A control with two regimes pointing at it still needs one accountable owner, or it becomes everyone’s job and therefore no one’s. The fabric shares controls; it does not share accountability. Each control has a single name against it, and that name is answerable when the evidence is asked for.

Build four programmes and you will pay four times to arrive at controls that were always the same controls. Build one fabric and the regulations become what they should have been from the start: different views onto a single, evidenced estate. The firms that treat the 2026-2027 cluster as one engineering problem will spend the deferral getting ahead. The ones that treat it as four will spend it rebuilding the same logging standard in three different quarters.