Who is accountable for cloud native security when responsibilities are split between the cloud provider and the customer?

Why This Matters for Security Teams

Cloud native environments compress infrastructure, platform, application, and identity decisions into a single operating model, but accountability does not compress with them. The organisation still owns risk acceptance, control design, and evidence of compliance, even when a provider supplies secure defaults or managed services. That distinction is central to NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects controls to be assigned, implemented, and monitored by the responsible party.

Practitioners often get this wrong by treating the cloud contract as a control boundary. It is not. The provider may handle physical security, base platform hardening, or service availability, but the customer still has to decide who approves access, who configures segmentation, who reviews logs, and who responds when identity is abused. That is where cloud native security becomes a governance problem as much as a technical one.

In practice, many security teams encounter the accountability gap only after a misconfiguration, access abuse, or incident has already exposed where ownership was never actually defined.

How It Works in Practice

Shared responsibility should be translated into a control matrix, not a slide deck. The matrix should map each control area to the party that implements it, the party that monitors it, and the party that can evidence it. In cloud native security, this often spans identity and access management, container and workload hardening, secrets handling, logging, network policy, backup recovery, and incident triage. NIST guidance on control ownership and continuous monitoring helps make those assignments auditable rather than implied.

For cloud native services, the practical question is not simply “who secures the stack?” It is “who owns the security outcome at each layer?” For example, a provider may secure the managed Kubernetes control plane, while the customer still owns cluster role design, workload service accounts, secret rotation, and policy enforcement. The same logic applies to storage, databases, and serverless services. The customer remains responsible for data classification, encryption choices, alert routing, and response playbooks, even if the service provides built-in capabilities.

• Define shared responsibility by service type, not by generic cloud category.
• Assign each control to an accountable owner, then validate that ownership in operational runbooks.
• Separate platform hardening from workload hardening, because the same team rarely owns both cleanly.
• Review identity boundaries first, since mis-scoped access is one of the fastest paths to cloud compromise.

For detection and response, log access, audit trail retention, and escalation paths must be agreed in advance. CISA guidance on logging and monitoring cloud environments is useful here because it reinforces that visibility is a shared operational requirement, not a passive provider feature. The most mature teams also align cloud responsibility mapping to NIST CSF outcomes so that governance, protection, detection, response, and recovery all have named owners. These controls tend to break down when responsibility is spread across multiple cloud subscriptions and teams because each group assumes another has already enabled logging, policy enforcement, or incident escalation.

Common Variations and Edge Cases

Tighter cloud governance often increases operational overhead, requiring organisations to balance speed of delivery against clarity of accountability. That tradeoff becomes sharper in multi-cloud, platform engineering, and heavily outsourced operating models, where the provider, central security team, and application squad may all touch the same control.

Best practice is evolving for managed services and higher-level abstractions because the line between provider-managed and customer-managed control is not always obvious. There is no universal standard for this yet, so the safest approach is to document the boundary at the service feature level. For example, one service may include native key management, but the customer still decides key rotation policy, access approval, and exception handling. Likewise, a provider can supply immutable infrastructure primitives, but the customer still owns what gets deployed and whether it is continuously scanned.

Identity is the most common hidden edge case. When cloud native workloads use human and Non-Human Identity, accountability must extend to token issuance, workload identity, API keys, and service account lifecycle. If agentic automation is present, the organisation should also define who authorises the agent, who limits its tool access, and who can revoke it quickly. In cloud native environments, that accountability is usually weakest where teams assume the platform will enforce policy for them.

Related resources from NHI Mgmt Group

• How should security teams split responsibilities between AD recovery, ITDR, and access governance platforms?
• Who remains accountable when a managed cloud security provider misses an incident?
• How should security teams split responsibilities between an IdP and an upstream authenticator?
• How should security teams split responsibilities between API gateways and service meshes?