CADA and NIS2: review cloud vendors and evidence

A customer asks about cloud vendors

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, who can access the data at those vendors, 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 does not have complete information about support access and subprocessors. 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 support access 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.

This is an illustrative scenario, not a customer case. Answering the questions requires a vendor list, contracts and technical evidence. The company also needs to distinguish applicable law, customer contract requirements and proposed assessment frameworks.

Separate proposals from applicable requirements

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.

CADA is a legislative proposal

The Commission published its CADA proposal on 3 June 2026. It proposes an EU-wide framework for assessing cloud and AI sovereignty. This does not establish a general duty for SMEs to classify or replace vendors today. An internal estimate must not be presented as official recognition.

You can already collect concrete information for procurement: processing locations, access arrangements, subprocessors and contractual export options. These help you assess customer requirements while a proposed framework may still change.

NIS2 deadlines depend on applicable national law

Germany’s implementation took effect on 6 December 2025; Austria’s NISG 2026 on 1 October 2026. Neither establishes a general NIS2 audit deadline of 30 June 2026. Scope, registration and evidence deadlines must be checked against the relevant national rules.

A supplier questionnaire may also reflect a contractual requirement. Record who needs which evidence and by when. A customer deadline alone does not establish that your company falls directly within statutory scope.

What procurement should check before renewal

Procurement knows contract dates and contacts. IT knows data flows and technical dependencies. Before renewal, they need to establish which requirements were actually agreed and which ones the provider can substantiate.

Compare requirements with the contract

A server location or a sovereign-region label is insufficient for that review. Request evidence relevant to the actual requirement: processing locations, support access, contracting entities or technical export options. Record which statements are confirmed and which need a follow-up.

Switching charges within the Data Act’s scope are due to be removed on 12 January 2027. Your own migration work and parallel operations can still incur costs. Ask the provider to explain which services and charges apply to the particular switch.

Assess missing evidence

Missing evidence may complicate renewal, but it does not automatically establish a legal breach. Identify the affected obligation, whether alternative evidence is sufficient and whether a transitional arrangement is possible. Record the decision, its owner, the rationale and a review date.

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: nobody can locate the contractual requirements and their supporting evidence. The second: every customer questionnaire is assembled afresh from emails and screenshots. A maintained vendor list should link to each source and its date so outdated information remains visible.

The third sign is an untested export or recovery path. Containers are not a prerequisite; the question is whether data and applications work at the destination. The fourth is unclear responsibility for evidence and exceptions. Legal classification remains a separate task, supported by technical information from operations.

Review vendors during ongoing operations

A vendor list needs maintenance. Who updates it after a contract change, a new integration or a changed support account? Assign the work so it can continue when the usual contact is unavailable.

Map vendors to requirements

Start with a vendor list organised by data class, access and affected workflows. In the example, Markus checks technical evidence, Petra records customer requirements, Danilo clarifies contracts and Andrea decides on exceptions. If a customer requires a particular assessment, record its source and scope. An internal estimate is not a certification.

Keep, adjust or switch

The company can then keep a service, request changes or prepare a switch. Base that decision on actual requirements, the service’s value and acceptable risks. A DACH location may support an agreed residency requirement, but access and contractual conditions still need review.

Keep evidence retrievable

Link each vendor register entry to its evidence and review date. A shared folder can be enough initially, provided the responsible people have access and changes remain traceable. Record who requests missing information and when it will be reviewed again. Reminders can come from a calendar or an n8n workflow. Automate once responsibilities and procedures are agreed. Expired evidence should not silently appear current: mark it, request an updated version and document how the unresolved question will be handled in the meantime.

Technical requirements for switching providers

Documented configurations, available access and rehearsed export procedures make an approved switch executable. Review these operational requirements for the chosen destination.

DACH hosting and Kubernetes portability

Containers and Kubernetes can make parts of an application easier to move. Databases, storage, identity and networking still need separate review. A trial at the intended destination reveals the necessary changes. CKA and CKAD certificates demonstrate individual technical qualifications, not the legal compliance of an entire environment.

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
├── requirements: source, scope, evidence, open questions
├── 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

Portable components can make a switch easier. The work also depends on data volumes, integrations, licences and the destination environment. Compare a trial migration with the cost of staying before deciding to replace a service. Containers alone do not establish that the whole system is portable.

Observability and audit trails as evidence

Change records can show when a configuration was changed and who was responsible. Incident records should also document reporting procedures, contacts and actions taken. Git and deployment logs supply technical parts of that evidence; they do not replace legal assessment or cover every required record. Assign a concrete source to each item of evidence. Check whether it covers the relevant period and whether the responsible people can retrieve it. Access and retention need separate consideration wherever records contain personal data.

Agree on technical support

A technical review can bring together vendors, access arrangements, data flows and available evidence. The project agreement defines which checks Planfold handles and which remain with your team or legal advisers.

Depending on the agreed scope, a project may produce documented configurations, a rehearsed recovery procedure or reminders for recurring vendor reviews. Ongoing operations also need an owner for maintaining that information and assessing changes. A new vendor, processing location or support access arrangement should prompt a review of the affected records. The service agreement should define the scope and frequency of this work.

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 — CADA remains a proposal. 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 vendors with customer data, privileged access or critical tasks. In week 2, map the statutory and contractual requirements that actually apply. Record missing information as specific questions and assign a responsible person.

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.

For the next customer question, keep the requirement, source, evidence and responsible person together. Agree which changes trigger a new review, such as a new subprocessor or a different processing location.