Deadline Before Firewall: What CADA and the NIS2 Audit Cutoff Mean for SMEs

The questionnaire that arrives before the firewall

Andrea opens the email at 8:47 a.m. The mid-sized DACH logistics service provider has about 45 employees, runs freight across the DACH region, and supplies several large industrial and retail customers. IT and processes sit on a mix of cloud infrastructure, a CRM, a telematics platform, an accounting tool, roughly a dozen SaaS products, and a handful of n8n automations for shipment and status updates. Until that email, the setup felt distributed but manageable. Now, ahead of a contract renewal, a major customer wants to know: which cloud and software vendors process customer data, into which EU sovereignty level those vendors fall, what evidence exists for data residency, and what happens if a vendor has to be replaced.

No one on the team has these answers ready. Markus, the IT lead, knows the technical systems but cannot tell which level the vendors could attain. Petra, who owns compliance and quality management, maintains the customer questionnaires but rebuilds them each time from emails and old answers. Danilo in procurement knows the contract and renewal dates but has never asked about sovereignty levels or switching terms. Andrea ultimately has to decide which answer is defensible with the customer and whether a vendor must be replaced before the next renewal.

The scenario is illustrative, but the mechanism is realistic for SMEs with 10 to 100 employees. Two developments converge in June 2026: a fresh EU cloud sovereignty framework that tiers providers in new ways, and rising NIS2 audit pressure that pushes customers, insurers, and auditors to ask exactly these questions. The questionnaire is not the real problem. It only reveals that no one has yet asked about the sovereignty level of the company's own vendors — and that a one-off answer goes stale within a quarter unless it becomes part of operations.

What actually changes in June 2026

Two signals are reshaping how cloud and software services are procured, even though only one of them is binding law today. Telling the difference between law in force and a framework in progress matters, because it determines what must be built now and what should simply be watched.

The proposed EU Cloud and AI Development Act (CADA) and its levels

On 3 June 2026 the European Commission published the proposed Cloud and AI Development Act (CADA), the centrepiece of the EU Tech Sovereignty Package. CADA is a proposed regulation, not law in force. It now enters ordinary legislative procedure between the European Parliament and the Council. Legal analysis (Jones Day, June 2026) targets final adoption around late 2027, with procurement obligations taking effect roughly one year after adoption.

At its core, CADA introduces a four-level sovereignty assurance framework for providers serving EU public-sector workloads:

• Level 1: data is processed and stored in infrastructure located in the Union.
• Level 2: providers demonstrate independence from third countries and transparency over their software supply chain.
• Level 3: providers are owned and controlled from the EU and meet additional criteria such as personnel citizenship; the Commission may recognise third-country providers.
• Level 4: providers have full transparency and control over their software supply chain with no interference from a third country.

These four levels are a distinct CADA structure. They cannot be equated with the ENISA EUCS certification levels (Basic, Substantial, High) — the Commission's page does not draw that mapping. The scope also matters: the framework addresses public-sector procurement. An extension to NIS2-regulated private providers would be possible only through delegated acts that still have to be adopted. So CADA does not obligate any SME to anything today — but the trajectory of the framework is already changing how vendors position themselves and how customers ask questions.

NIS2 audit pressure and an industry-tracked cutoff

At the same time, supervisory intensity under NIS2 is rising. Germany transposed the directive through the BSI Act in December 2025; Austria did so with NISG 2026 (BGBl. I No. 94/2025) of 23 December 2025. The European Commission's NIS2 page confirms the directive entered into force in January 2023, sets the Member-State transposition deadline at 17 October 2024, and records simplifying amendment proposals from 20 January 2026.

An important boundary follows from this: a universally applicable audit cutoff of 30 June 2026 appears neither in the NIS2 directive text nor on the Commission's NIS2 page. Supervisory and audit cycles are national and are set by competent authorities and CSIRTs. The 30 June 2026 date comes from industry and GRC commentary (Optro, March 2026; Cloud Security Alliance, June 2026). The article may use that date as industry-tracked readiness pressure — but it must be attributed, and readers should be sent to their national authority, in the DACH region to the BSI in Germany or the relevant Austrian authority. The penalty ceilings, by contrast, are anchored in the directive text: under Article 34 of Directive (EU) 2022/2555, essential entities can face fines of up to EUR 10 million or 2 percent of total worldwide annual turnover, whichever is higher; for important entities up to EUR 7 million or 1.4 percent. Which classification and which cycle apply to a given company remains its own legal determination.

Why this deadline hits procurement, not just IT

CADA is built around public-sector procurement, but the question of which sovereignty level a vendor can attain reaches SMEs through customers, insurers, and supply chains — that is, through procurement, not the server room. That is exactly why the cutoff is a procurement and contract question before it is an IT question.

Vendor tiers decide contracts

Levels 3 and 4 require EU ownership and control, respectively full supply-chain transparency with no third-country interference. For providers domiciled outside the EU and exposed to the US CLOUD Act, these levels are structurally hard to reach — according to Jones Day, EU tech chief Henna Virkkunen explicitly flagged the CLOUD Act tension. This leads to a simple but often overlooked fact: a "sovereign region" label or a certificate is not the same as an attainable Level 3 or 4. When a major customer asks for the level, a region is not an answer.

The Data Act sharpens this. The switching and portability provisions of the Data Act have been in force since 12 September 2025, and charges for data egress and format conversion are meant to fall to zero by 12 September 2027. Lock-in thus becomes a reversible decision rather than a fixed state. Ignoring that today bakes a vendor tier into every renewal that you can no longer choose later.

Lock-in becomes compliance debt

The combination of new tiers, the Data Act, and NIS2 pressure turns vendor lock-in into latent compliance debt. A vendor that cannot attain the level a customer needs is hard to swap quickly under pressure — but staying with it writes non-compliant procurement into every renewal. The penalty ceilings of up to EUR 10 million or 2 percent of turnover for essential entities set the frame; more often relevant for an SME is the indirect pressure: a larger customer must explain its own supply chain and passes the question down to the smaller supplier. Even a company below the NIS2 threshold of generally 50 employees or EUR 10 million in turnover feels the question through its customers.

Warning signs your SME is not ready

Most SMEs discover they are unprepared not at an audit but at a customer email. There are clear signals that show up early if they are taken seriously.

The first sign: no one can estimate which CADA level the company's cloud vendors could plausibly attain. The levels are tied to public procurement and are not yet in force — the customer question still arrives, because the customer's own risk management asks it. If you cannot even estimate the attainable level, you have no basis for a renewal decision. The second sign: questionnaires are rebuilt from scratch every time. If Petra assembles a fresh table from emails and screenshots for each customer, that is not an efficiency problem but an operating-model problem. The answers are not repeatable and go stale within a quarter.

The third sign: there is no portability plan. Anyone running workloads without containers and without knowing the data-export and migration paths treats lock-in as fate rather than a decision. The fourth sign: no one owns the evidence pipeline. If it is unclear who collects evidence, who approves reviews, and who decides on a vendor switch, the next audit is a cold start. The fifth sign: legal and operational work are conflated. The legal classification — essential, important, reportable — stays with qualified legal counsel and the national authority. But the operational work that produces evidence for that classification has to be owned by someone.

From deadline to operating model

A cutoff answered once goes stale. Inventory, ownership, review gates, and an audit trail are what turn it into an operating model that outlasts the next cycle. The concrete shape for an SME is lean, but it needs clear ownership boundaries.

Vendor classification against the new levels

The first step is a classified vendor list — not by spend, but by data class, access type, critical workflow, and attainable CADA level. The level estimate is explicitly a plausibility estimate, not a recognition: formal level recognition under CADA happens through Member States after an audit and is not yet in place. For every vendor with customer data or privileged access, a commercial owner is not enough; Markus reviews the technical evidence, Petra keeps the questionnaire archive, Danilo negotiates renewals against the new tier picture, and Andrea decides on critical exceptions.

The keep, replace, repatriate decision

Classification produces the strategic decision: keep, replace, or repatriate. A vendor that plausibly attains the required level stays, with review and evidence obligations attached to its contract. A vendor that cannot attain it is replaced, ideally with switching terms under the Data Act. Workloads with high data or compliance requirements can be repatriated to DACH-hosted infrastructure. This decision is only executable when workloads are portable — which leads straight to the architecture question.

The evidence pipeline that outlasts the next audit

The pipeline is the difference between a one-off snapshot and a recurring capability. Its elements are simple: a central vendor register as the source of truth, an evidence folder or Git repository for proofs, an n8n workflow for deadlines, reminders, and escalations, a runbook for vendor incidents, and a review gate for management decisions. Every critical exception has a documented decision, every missing piece of evidence has a date, every vendor incident has a contact path. n8n orchestrates the recurring work — review reminders, overdue evidence, status lists for the quarterly review — while the decision itself stays human. That is exactly what makes the answer to the next questionnaire reproducible instead of invented.

Technical deep-dive: sovereign infrastructure as the compliance substrate

The operating layer on which a tier decision becomes executable at all is sovereign infrastructure: DACH hosting, portable workloads, and traceable audit trails. Without that substrate, every keep-replace-repatriate decision stays theoretical, because a switch is not technically feasible.

DACH hosting and Kubernetes portability

Portability is the technical core of the answer to lock-in. Running workloads to the Kubernetes standard in containers lets you move them between DACH-hosted environments, sovereign regions, and private infrastructure without rewriting them. That makes a tier downgrade survivable instead of catastrophic: if a vendor loses its attainable level, the workload can be migrated instead of the whole renewal depending on it. This only works with discipline — clear Helm charts or manifests, no vendor-specific lock-in in storage or identity services, planned data exports, and defined migration paths. CKA- and CKAD-certified Kubernetes operations are a capability proof for this critical operational work, not a compliance badge.

A lean register structure that makes this work traceable could look like this:

cada-vendor-register
├── vendor: name, service, contract owner, technical owner
├── exposure: data class, privileged access, critical workflow
├── tier: attainable CADA level (estimate), rationale, gaps
├── portability: workload form, migration path, export format, Data Act status
├── evidence: SLA, security contact, data residency proof, restore proof
├── review: due date, reviewer, decision, exception, next action
└── audit trail: timestamp, change, reviewer, accepted risk

The tradeoff is obvious: full portability costs discipline and standardization up front, but it sharply lowers migration and lock-in cost later. Skipping that effort means paying it at every renewal, in the form of a vendor tier you can no longer choose.

Observability and audit trails as evidence

The second technical pillar is observability and versioned audit trails. NIS2 Article 21 requires risk-driven measures, Article 20 management-body accountability, Article 23 incident reporting. Operationally, that translates to: changes to systems must be traceable, incidents must have a documented path, and reviews must leave a trail. Infrastructure that changes through Git-governed, repeatable paths — GitLab, configuration management, standardized deployments — produces exactly this evidence as a by-product of operations rather than a one-off audit effort. A supervisory cycle, run nationally, does not ask for a slide deck; it asks for evidence that was valid at a given date. The audit trail delivers it.

How Planfold turns the deadline into an operating model

Planfold treats the cutoff not as a one-off audit task but as the occasion to build an operating model. The methodology is defined technically, not used decoratively. Plan means auditing technical debt, vendor tiers (as plausibility, not recognition), data residency, access paths, and existing questionnaire answers. The output is a prioritized vendor map — what is critical, what is unclear, who decides, where evidence is missing.

Unfold means building and integrating systems. That covers the sovereign infrastructure substrate — DACH hosting and portable Kubernetes workloads — plus the evidence workflows: n8n-driven register and review routines, access reviews, restore proofs, and incident runbooks. Resonate means stable operations with recurring audit-readiness. Quarterly reviews, overdue evidence, vendor switches, new automations, and incident learnings flow back into the register, so the next question is not reconstructed from memory.

The boundary stays clear: Planfold gives no legal advice, certifies no NIS2 compliance, performs no formal penetration tests as a compliance substitute, does not decide whether a company is an essential or important entity, and guarantees no specific CADA level for a vendor — level recognition is a Member-State decision after audit under CADA. Planfold builds the architecture, process, and evidence layer that feeds qualified legal, data-protection, and management decisions with reliable facts.

A 30-day starter plan for SMEs

A workable start has to be small enough to actually happen. The first month is not a full compliance claim; it is a prioritized basis for decisions.

In week 1, inventory your cloud and software vendors: cloud, hosting, SaaS, MSP, automation, backup, payment, telematics, support. Do not flag all of them equally, only those with customer data, privileged access, a critical workflow, or incident relevance. In week 2, estimate the attainable CADA level for the top vendors — clearly labelled as an estimate, not a recognition — and add data class, access type, and affected workflows. Where something is missing, there is no green checkmark, only an open action.

In week 3, collect evidence and contacts: SLA, security contact, data residency proof, restore proof, switching and export terms under the Data Act. Accept that not everything is there at once — what matters is that the gap becomes visible. In week 4, set the review rhythm: who checks what when, who decides critical exceptions, how the incident path runs, and at what point legal counsel or the national authority takes over. Petra owns the register, Markus the technical evidence, Danilo the renewal negotiations, Andrea the exception decisions. n8n reminds the team of due reviews and escalates overdue evidence.

The next cutoff does not reward a one-off questionnaire answer. It rewards a reproducible operating capability: a known critical-vendor list, plausible level estimates, named evidence owners, and a workflow that keeps answers from disappearing again in three months.

A deadline does not get easier by being left until later. It gets easier when it becomes part of operations: visible, owned, portable, and honest about open gaps.