Start with the service model and draw ownership lines for identities, configurations, data, logging, and recovery. The provider secures the underlying platform, but customer teams still control what runs, who can access it, and how it is monitored. If those boundaries are unclear, governance fails before the first control is enforced.
Clarify the shared responsibility model before you buy controls
Cloud security works best when the team treats the provider relationship as a boundary to map, not a blanket to trust. The practical question is which parts of the stack are delegated and which remain yours, because the answer changes how you design access, logging, backup, hardening, and recovery. NHIMG’s Cloud Security Guide is useful here because it frames that boundary across service models, landing zones, identity, and exit planning.
Teams should draw ownership lines for the control plane, identities, configurations, data, telemetry, and restoration workflows. That prevents a common failure mode where the provider’s assurances are treated as proof that customer-side permissions, misconfigurations, and monitoring are already covered.
Which cloud controls must remain under customer ownership?
Even in highly managed cloud services, customers still own the way workloads are configured, who can administer them, what data is exposed, and how alerts are investigated. That means you need explicit decisions for access governance, key and secret handling, log retention, backup integrity, and incident response authority, rather than assuming the platform default is secure enough.
Identity is usually the clearest example of this split. The provider may secure the infrastructure, but the customer still has to protect administrative access, federation trust, session handling, and any workload or service identities that can change resources or exfiltrate data. NHIMG’s Identity Provider and SSO Security Guide and Cloud Workload Identity Guide both reinforce that those identity paths remain customer decisions even when the cloud platform is managed.
What does a healthy cloud operating model look like?
A mature operating model makes provider reliance measurable. You should know which logs you can actually obtain, which alerts are actionable, which recovery steps are customer-controlled, and which exceptions require provider support. If those points are not documented, teams often discover too late that they cannot verify an incident, restore a system quickly, or prove what happened after a change.
This is also where cloud and managed-service boundaries can collapse if they are not tested. For example, outsourced monitoring only helps if the customer still defines scope, response authority, escalation paths, and exit conditions. NHIMG’s MDR Guide is a strong reference for that operating-model discipline, even though the same logic applies to cloud providers and cloud-native security services.
Risk and Threat Considerations
The main risk is over-delegation: teams assume the provider has secured everything that matters, then leave customer-side identities, policies, and telemetry undergoverned. That creates a blind spot where misconfiguration, privilege abuse, or delayed detection can persist even though the underlying platform is healthy.
Failure mechanism: Security responsibility is unclear, so nobody owns the critical control points where cloud compromise usually happens, especially admin access, workload permissions, logging gaps, and recovery validation.
Impact: Misconfigurations go uncorrected, incidents become harder to detect and investigate, and recovery depends on assumptions that were never tested. At scale, the result is systemic exposure across every account, subscription, or project that inherited the same flawed operating model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud shared responsibility hinges on who governs identities and access in the cloud. |
| SEF — Security Incident Management, E-Discovery, and Forensics | Cloud logging and investigation depend on incident handling and evidence availability. | |
| DSP — Data Security and Privacy Lifecycle Management | The question centers on who controls data protection and recovery in cloud services. | |
| Recommendation — Define customer-owned identity and access controls for each cloud service and verify provider boundaries. Ensure telemetry, investigation access, and incident escalation are contractually and operationally defined. Map data protection, retention, backup, and recovery responsibilities to the correct owner. | ||
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | Cloud use requires explicit security responsibility boundaries and service oversight. |
| A.5.15 — Access control | Over-trusting the provider often leaves access ownership and enforcement ambiguous. | |
| A.8.15 — Logging | The answer depends on retaining and using cloud telemetry for detection and investigation. | |
| Recommendation — Document cloud security responsibilities and verify them before adopting each service. Enforce explicit access boundaries for customer-managed identities and privileged actions. Confirm cloud logging is enabled, retained, and reviewable by the customer. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Cloud security ownership must include access governance for customer-controlled identities. |
| CIS-8 — Audit Log Management | The answer emphasizes monitoring and evidence collection as customer responsibilities. | |
| Recommendation — Manage cloud access explicitly rather than assuming provider defaults are sufficient. Centralize and retain cloud audit logs for detection and response. | ||
Practitioner Guidance
What to verify: Confirm that each cloud service has an explicit owner for identity, configuration, logging, data protection, and recovery, and that the provider’s responsibilities are written down in operational terms rather than marketing terms. If you cannot name the control owner, you do not yet have a control.
Decision rule: If a control can materially affect confidentiality, integrity, or recovery, treat it as customer-owned unless the contract and operating model say otherwise. If the provider is responsible for the platform, that does not automatically make the provider responsible for safe configuration or safe access use.
Practitioner takeaway: The safest cloud programmes are the ones that trust the provider for infrastructure but distrust ambiguity around ownership, because unclear responsibility is how strong technology turns into weak governance.
Related resources from NHI Mgmt Group
- How should security teams implement AI agents in cloud and application security workflows without losing control over context and risk?
- How should security teams implement Kubernetes compliance across cloud-managed clusters without relying on a single provider's controls?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org