What NIS2 Actually Requires From Your Infrastructure Platform When You Move Regulated Workloads to the Cloud

NIS2 does not prohibit regulated workloads from running on hyperscalers such as AWS, Azure, or Google Cloud; instead, it requires covered entities to manage and demonstrate cybersecurity controls for the systems they configure and operate above the provider’s infrastructure. Articles 20 and 21 emphasize management accountability and risk-management measures including access controls, MFA, encryption, logging, incident response, backups, recovery testing, secure development, vulnerability management, environment segmentation, and supply-chain oversight, while Article 23 requires early warning of significant incidents within 24 hours, notification within 72 hours, and a final report within one month. The article argues that a cloud provider’s shared-responsibility model leaves customers responsible for identities, network configuration, keys, deployment processes, audit evidence, and much of Kubernetes security. It distinguishes NIS2 from GDPR, DORA, and national sovereignty schemes, noting that data-localization or sovereign-cloud obligations generally arise from other rules rather than NIS2 itself. It also presents bring-your-own-cloud platforms as a model that can retain data, keys, logs, and cloud-account control within the regulated entity while requiring assessment of the platform vendor as part of the supply chain, and promotes Qovery’s BYOC deployment approach as supporting these objectives.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.