Key Takeaways<\/p>\n
- \n
- Steering three logics in parallel.<\/strong> Corporate platforms, plant-proximate OT, and regulatory requirements operate simultaneously-digital sovereignty is the ability to definitively control location, processing site, operator, and exit path.<\/li>\n
- Five workload classes.<\/strong> At least five classes-from SaaS and core systems to AI, edge, and regulated processing-replace blanket cloud-first and on-premises mandates.<\/li>\n
- Separate roles and budgets.<\/strong> Corporate IT sets baselines, the region translates compliance, and the plant controls OT proximity-Volkswagen and Siemens separate central platforms from production-near workloads.<\/li>\n
- Decision tree before go-live.<\/strong> Data classification, latency, and integration determine location and operator; the operational proof with RTO and RPO per ISO 22301 closes out the architecture.<\/li>\n<\/ul>\n<\/div>\n
Related<\/span>Digital Sovereignty 2026: Delos Cloud, Gaia-X, EU Data Act<\/a> \/<\/span> Sovereign Cloud: Europe\u2019s Path to Digital Sovereignty<\/a><\/p>\n
The Tension Field: Sovereignty, OT, and Global Platforms<\/h2>\n
Today\u2019s CIOs and CDOs must govern three logics at once. Corporate platforms push for standardization, economies of scale, and global release cycles. Plant and site systems demand availability, deterministic latency, and tight coupling to machines, control systems, and shift handovers. Regulatory and contractual mandates on data residency, commissioned processing, and audit trails add further constraints. Yet none of this alone dictates an architecture.<\/p>\n
The tension arises when any one of the three logics becomes the sole guiding principle. A blanket cloud-first mandate can plunge OT-near workloads into latency, maintenance, and release bottlenecks. A blanket on-premises mandate inflates costs for standard applications and undermines patch and identity discipline. Digital sovereignty, in an IT sense, is not a political statement. It is the ability to definitively control location, processing site, operator, and exit path.<\/p>\n
In practice, this means data classes, processing locations, and operational responsibility must be defined before platform selection. Germany\u2019s BSI C5 criteria catalog requires cloud providers to disclose court jurisdiction, data-processing sites, and statutory disclosure obligations in their system descriptions. The C5:2026 edition further sharpens technical implementation of sovereignty and tenant separation. At the same time, GDPR Chapter V (Articles 44 ff.) regulates third-country transfers of personal data. The EU Data Act (Regulation (EU) 2023\/2854), effective from September 2025, adds cloud-switching rights and safeguards against unauthorized third-country access to non-personal data held in the EU. If these determinations are made only after cloud migration, rework costs and audit risks escalate-especially where production data, HR data, and supplier interfaces coexist in the same stack.<\/p>\n
Workload classes instead of blanket cloud-first rules<\/h2>\n
A robust operating model begins with workload classes, not providers. At least five classes make sense: enterprise-wide SaaS and collaboration services, core systems with high integration requirements, analytical and AI workloads, edge-proximate control and sensor workloads, and regulated or location-bound processing. Each class needs criteria for latency, data classification, change frequency, operator capability, and exit costs.<\/p>\n
Cloud is suitable where elasticity, global identities, and standardized operations processes drive value. Edge and local compute power are appropriate where production cycles, offline capability, or tight OT coupling set the pace. Hybrid means the deliberate assignment of workloads to locations and operating models. Established reference models provide guidance: the functional hierarchy per ISA-95 (IEC 62264) separates physical process, control, manufacturing execution, and enterprise systems. The ISA\/IEC 62443 series adds zones and conduits-security zones with comparable protection requirements and controlled communication paths between them.<\/p>\n
Cleanly separating workload classes prevents two typical mistakes. First, migrating critical shop-floor systems solely because the corporate standard is cloud. Second, blocking straightforward standard workloads behind sovereignty arguments that don\u2019t hold up technically or legally. The decisive question is: which control, which location, and which operator suit this class?<\/p>\n
Roles of plant, region, and corporate IT<\/h2>\n
Without clear roles, hybrid collapses into shadow IT and duplicated effort. Corporate IT sets architectural principles, identity and security baselines, procurement frameworks, and platform standards. Regional IT translates corporate guidelines into country-specific compliance, contract realities, and operational conditions. The plant level owns OT proximity, shift operations, local disruptions, and the interface to maintenance and production.<\/p>\n
The interface must be formalized. Change and release rights, incident ownership, and approval paths for OT-relevant changes belong in an operating model with clear escalation routes. Identities, network zones, and logging must not be reinvented at each site. At the same time, the plant needs decision-making leeway for time-critical systems that cannot follow the corporate release cadence.<\/p>\n
Financially, capex and opex diverge along the same roles. Corporate platforms can often be budgeted as shared services. Site-proximate infrastructure and OT coupling remain largely investment-driven and require multi-year maintenance and modernization planning. Public company examples confirm the separation of control layers: Volkswagen is building a central platform for enterprise applications with the Group Private Cloud 2.0 based on T-Systems\u2019 T Cloud Private, emphasizing, according to CIO Hauke Stars, the combination of partnerships and in-house infrastructure-explicitly ruling out cloud-only. At the same time, Volkswagen runs production-near workloads via the Digital Production Platform with AWS. Siemens describes the convergence of IT and OT at its Bad Neustadt engine plant as a site-proximate operating case with data-driven manufacturing. Without this separation of roles and budgets, shadow budgets and competing priorities arise between plant and headquarters.<\/p>\n
Procurement and Operational Risks in the Germany Setup<\/h2>\n
The Germany setup carries typical procurement risks. Long lead times for servers, networking hardware, and OT equipment clash with tight maintenance windows in production. Master agreements with global hyperscalers and local hosting providers run in parallel, creating inconsistencies in SLAs, audit rights, and exit clauses. Staffing shortages in OT-adjacent operational roles amplify dependency on integrators and vendor support.<\/p>\n
Operational risks mirror the architecture. Separate identities between IT and OT expand attack surfaces and complicate forensic traceability. Unclear data residency in backup, logging, and AI pipelines leads to later corrections. Patch backlogs accumulate at edge-adjacent systems when security updates aren\u2019t aligned with production releases. Germany\u2019s Federal Office for Information Security (BSI), in its ICS and OT recommendations, emphasizes that OT operates longer hours, has rare maintenance windows, and demands real-time performance-making it difficult to apply standard Office-IT protection measures. The BSI\u2019s \u201cPrinciples of OT Cybersecurity\u201d (2024) targets decision-makers and calls for end-to-end control from planning to operations. ISA\/IEC 62443 provides concrete baselines for segmentation and patch management in industrial automation and control systems through zones, conduits, and Technical Report 62443-2-3. The BSI\u2019s IT-Grundschutz module IND.1 complements this with requirements for process control and automation technology.<\/p>\n
Sourcing must therefore follow architecture, not the other way around. Multi-cloud driven solely by negotiation reflex inflates operating costs and governance complexity when workload classes and data flows aren\u2019t predefined. Local colocation or sovereign hosting options only help if operational processes, key management, and recovery procedures are tested and budgeted. The CIO owns residual risks and exit readiness.<\/p>\n
Decision Tree for Hybrid and Edge Cases<\/h2>\n
A practical decision tree starts with data and process classification. First, decision-makers must determine whether the workload processes personal, sensitive, or production-critical data and which residency and audit obligations apply. Next comes latency and availability: is a regional cloud zone sufficient? Is proximity to the plant or offline capability required? Then consider change frequency and integration density with MES (Manufacturing Execution System), SCADA (Supervisory Control and Data Acquisition), ERP, and identity services.<\/p>\n
Only then does the location and operator decision follow. SaaS is permissible if data classification, contract terms, and exit provisions align. Private or virtual private cloud suits integrated core systems with stringent control demands. Edge and on-premises instances serve OT coupling, strict latency limits, or site-bound approvals. Hybrid emerges when local preprocessing and centralized analytics or training run in tandem with standardized interfaces.<\/p>\n
The tree culminates in operational evidence. Who operates, who patches, who escalates, and how recovery is achieved within what timeframe must be answered before go-live. ISO 22301 on Business Continuity Management defines key metrics: RTO (Recovery Time Objective-the maximum tolerable downtime) and RPO (Recovery Point Objective-the maximum tolerable data loss). Without this proof, the architecture remains incomplete, even if the target platform is formally approved.<\/p>\n
For CIOs and CDOs, the takeaway is clear: site IT becomes a control object defined by workload classes, role models, and decision trees. Cloud remains a tool. Sovereignty remains control. OT remains operational reality. Those who align these three layers in the operating model cut capex misallocation and build robust hybrid decisions for the Germany mode.<\/p>\n
Frequently Asked Questions<\/h2>\n
\nWhy do audit risks increase when residency and exit decisions are made retroactively?<\/summary>\n
Data classes, processing locations, and operational responsibilities must be defined before platform selection. C5:2026 requires transparency regarding jurisdiction, data locations, and client separation. Chapter V of the GDPR governs third-country transfers, while the EU Data Act, effective since September 2025, introduces switching rights and protection against unauthorized third-country access. Retroactive corrections drive rework costs and audit risks once production, personnel, and supplier data reside in the same stack.<\/p>\n<\/details>\n
\nWhich procurement risks are particularly shaping the German setup?<\/summary>\n
Extended lead times for servers, networking, and OT hardware clash with tight maintenance windows in production. Concurrent framework agreements with hyperscalers and local hosts create inconsistencies in SLAs, audit rights, and exit clauses. Staff shortages in OT-adjacent operational roles amplify dependency on integrators and vendor support. Sourcing follows architecture once workload classes and data flows are segmented.<\/p>\n<\/details>\n
\nHow do you formalize the interface between corporate IT and plant operations?<\/summary>\n
Change and release rights, incident ownership, and approval paths for OT-relevant modifications belong in an operating model with clear escalation paths. Identities, network zones, and logging remain standardized across the enterprise. At the same time, the plant retains decision-making authority for time-critical systems outside the corporate release cadence. Capex and opex follow the same role logic, separating shared corporate services from investment-driven site infrastructure.<\/p>\n<\/details>\n
\nWhen does the architecture remain incomplete despite an approved target platform?<\/summary>\n
When operational evidence is missing before go-live. Who operates, who patches, who escalates, and how recovery is achieved must be answered definitively. ISO 22301 defines RTO as the maximum tolerable downtime and RPO as the maximum tolerable data loss. Without these targets and clear ownership paths, the architecture remains incomplete.<\/p>\n<\/details>\n
\nMore from the MBF Media Network<\/p>\n
![\"Wenn](\"https:\/\/www.cloudmagazin.com\/wp-content\/uploads\/2026\/07\/wenn-gpus-den-saas-etat-auffressen-cover-hero-250x143.jpg\")
<\/p>\n\n - Five workload classes.<\/strong> At least five classes-from SaaS and core systems to AI, edge, and regulated processing-replace blanket cloud-first and on-premises mandates.<\/li>\n
![\"KI](\"https:\/\/mybusinessfuture.com\/wp-content\/uploads\/2026\/07\/ki-mittelstand-pilot-skalierung-roi-roadmap-cover-hero-250x195.jpg\")
<\/p>\n![\"Der](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/cover-hero-3-250x143.jpg\")
<\/p>\n