NIS2 and Cloud Service Providers: Shared Responsibility Under the Directive

The Shared Responsibility Model Under Regulatory Pressure

The traditional shared responsibility model divides security obligations between cloud provider and customer based on the service type. In Infrastructure-as-a-Service, the provider secures physical infrastructure, hypervisors, and network fabric; the customer secures operating systems, applications, data, and access management. In Software-as-a-Service, the provider assumes responsibility for the application layer, leaving the customer responsible for configuration, access controls, and data classification.

This model has always contained ambiguities — the boundaries between provider and customer responsibility are not always clear, particularly in areas such as identity management, encryption key custody, logging, and incident detection. NIS2 does not eliminate these ambiguities, but it does create regulatory stakes for them. Under Article 21, essential and important entities must implement appropriate and proportionate security measures covering, among other things, supply chain security and the security of their relationships with direct suppliers and service providers.

The practical implication is that an organisation cannot discharge its NIS2 obligations by pointing to a cloud provider's certifications or standard terms of service. The entity must demonstrate that it has actively assessed, contractually addressed, and continuously monitored the security of its cloud relationships. The ultimate accountability remains with the entity, regardless of where the workload runs.

Contractual Requirements: Beyond Standard Terms

NIS2 Article 21(2)(d) requires entities to address supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. For cloud relationships, this translates into specific contractual requirements that go well beyond the standard terms most providers offer.

Contracts should explicitly allocate security responsibilities for every layer of the stack, with particular attention to the grey areas: who is responsible for misconfiguration detection, for monitoring anomalous access patterns within the tenant, for encrypting data at rest versus in transit, and for maintaining audit logs at sufficient granularity and retention? Incident notification clauses must align with NIS2's own timelines — the provider must notify the customer of incidents affecting the customer's data or services within timeframes that allow the customer to meet its 24-hour early warning and 72-hour incident notification obligations to competent authorities.

Data processing location and jurisdictional controls require contractual precision under NIS2. Organisations must know where their data is processed and stored, and must be able to demonstrate that processing occurs within jurisdictions that meet the directive's requirements. Sub-processing arrangements — where the cloud provider engages additional service providers — must be transparent and subject to equivalent security requirements.

Audit Rights and Assurance Mechanisms

Audit rights represent one of the most contentious elements of cloud contracts under NIS2. Hyperscale providers resist individual customer audits on operational grounds — they serve millions of customers and cannot accommodate individual audit requests at scale. Yet NIS2 requires entities to verify that their suppliers and service providers maintain adequate security measures, and Article 21 specifically references the ability to assess the effectiveness of cybersecurity risk-management measures.

Pragmatic solutions exist. Third-party attestations such as SOC 2 Type II, ISO 27001^[2], and the forthcoming European Cybersecurity Certification Scheme (EUCS) provide standardised assurance. However, these certifications assess the provider's general security posture, not the specific configuration and controls applied to an individual customer's environment. Organisations must supplement provider certifications with their own assessment of customer-side controls: access management, configuration baselines, logging adequacy, and encryption practices.

Contracts should preserve the right to audit, even if exercised through pooled audit mechanisms, qualified third parties, or enhanced certification requirements. The right to audit upon material incident — allowing the customer to commission an independent assessment of the provider's handling of a breach affecting the customer — is particularly important and should be non-negotiable.

Cloud Provider Obligations Under NIS2

Cloud computing service providers are themselves classified as important entities under NIS2, bringing them directly within the directive's scope. This means providers must implement their own risk-management measures under Article 21, report significant incidents to competent authorities, and cooperate with CSIRTs during incident response. For customers, this dual coverage creates both opportunities and complexities.

The opportunity lies in regulatory alignment: because the provider is itself subject to NIS2, it must maintain security standards that are broadly compatible with its customers' obligations. The complexity arises from potential gaps in incident reporting. When an incident occurs at the provider level, both the provider and its affected customers may have independent notification obligations to potentially different competent authorities. Contractual mechanisms must ensure that information flows between provider and customer with sufficient speed and detail to enable both parties to meet their respective obligations.

Provider exit and portability obligations also take on new significance under NIS2. Organisations must be able to transition away from a provider without unacceptable security risk or operational disruption. This requires contractual commitments on data export formats, transition support timelines, and the secure deletion of data from provider systems after migration. Lock-in that prevents an entity from exercising its responsibility to manage supply chain risk may itself constitute a compliance gap.

Multi-Cloud and Hybrid Environments

Most European organisations operate in multi-cloud or hybrid environments, combining services from multiple providers with on-premises infrastructure. NIS2 does not distinguish between cloud models; the entity's obligation to manage risk and ensure supply chain security applies uniformly. However, multi-cloud environments amplify the governance challenge: responsibility boundaries multiply, incident correlation across providers becomes more difficult, and the risk of configuration inconsistency increases.

Effective governance of multi-cloud environments under NIS2 requires a centralised security operating model that provides consistent policy enforcement, monitoring, and incident response across all cloud platforms. Identity and access management must be unified, with a single source of truth for user identities and access policies regardless of where workloads run. Logging and monitoring must aggregate data from all environments to enable holistic threat detection and the correlation of suspicious activity across providers.

Practical Steps for Compliance

Organisations should begin with a cloud dependency inventory — a comprehensive mapping of which business processes depend on which cloud services, what data each service processes, and what the contractual security provisions are for each relationship. This inventory forms the foundation for assessing whether existing arrangements meet NIS2 requirements or require renegotiation.

Contract review and renegotiation should focus on four priorities: explicit responsibility allocation for all security domains, incident notification timelines aligned with NIS2 obligations, audit rights or equivalent assurance mechanisms, and exit provisions that preserve the organisation's ability to manage its security posture during and after transitions. For existing contracts that cannot be immediately renegotiated, organisations should document compensating measures and establish timelines for bringing agreements into compliance.

Finally, organisations should implement continuous monitoring of their cloud security posture. Cloud Security Posture Management tools can automate the detection of misconfigurations, excessive permissions, and policy violations. Combined with regular provider assurance reviews, this creates a governance framework that meets NIS2's expectation of ongoing, proportionate risk management rather than point-in-time compliance.