Security of the cloud refers to the provider protecting the infrastructure layer, including data centers, hardware, networking, and virtualization. Security in the cloud refers to the customer protecting what they deploy and store there, such as applications, identities, configurations, and sensitive data. The distinction matters because the provider can harden the platform, but customers still control how securely their own environments are configured.
Why the distinction matters in cloud security
Cloud responsibility is split at the service boundary, so the question is not just semantic. The provider is responsible for the underlying platform, while the customer is responsible for the way that platform is used. In practice, that means the same cloud service can be hardened at the infrastructure layer and still be exposed by weak identity, permissive access, insecure configuration, or poor data handling.
This is why cloud assessments usually have two lenses: the provider’s control plane and infrastructure assurance, and the customer’s workload, data, and access posture. A strong provider does not compensate for overly broad permissions, exposed secrets, or misconfigured storage. For broader cloud control mapping, the CSA Cloud Controls Matrix is a useful reference because it separates shared-responsibility domains across governance, IAM, infrastructure, and data security.
What “security of the cloud” covers
Security of the cloud is the provider’s job. It includes the physical and virtual foundation that makes the service possible, such as data centers, hardware, networking, hypervisors, managed service infrastructure, and the operational controls that keep that platform available and trustworthy. Customers typically do not control those layers directly, but they depend on them being hardened, monitored, patched, and resilient.
For practitioners, this means evaluating provider attestations, platform segmentation, resilience, and service-specific assurance rather than trying to treat the cloud like self-managed infrastructure. The relevant standard is often organisational assurance rather than device-by-device administration. ISO/IEC 27001:2022 Information Security Management is useful here because its cloud, access, and privileged-access controls frame the provider-side expectations around a managed security programme.
The provider’s responsibility also includes making secure defaults available, but secure defaults are not the same as secure outcomes. If the service offers encryption, logging, network isolation, or identity controls, those capabilities still have to be enabled and operated correctly by the customer in many deployments.
What “security in the cloud” covers
Security in the cloud is the customer’s job. It includes the applications deployed into the cloud, the identities and permissions those applications use, the configuration of storage and networking, and the handling of sensitive data. This is where most real-world cloud failures occur, because the customer controls the workload design and the access paths that attackers can abuse.
The practical focus is on least privilege, secure configuration, secret protection, logging, and data governance. Identity is often the critical control plane because cloud access is usually mediated by roles, tokens, service principals, keys, or similar credential material. NHIMG’s Ultimate Guide to Non-Human Identities is relevant as a navigation point for the customer-managed side of cloud access, especially where machine credentials, lifecycle, rotation, and visibility determine exposure.
This customer-side responsibility is also where overpermission, stale access, and misconfiguration create the most common blast-radius problems. In cloud environments, a small configuration mistake can expose a large amount of data or grant broad control over resources very quickly, especially when privileged identities are reused across environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | Directly addresses security responsibilities when using cloud services. |
| A.5.15 — Access control | Customer-side cloud security depends on controlling access to workloads and data. | |
| A.8.2 — Privileged access rights | Cloud misconfiguration and overpermission often turn on privileged access control. | |
| Recommendation — Apply A.5.23 to define cloud security responsibilities and verify service-specific obligations. Enforce A.5.15 to restrict cloud access to only the identities and roles that need it. Review and limit privileged cloud roles under A.8.2 to reduce blast radius. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Cloud in-use security hinges on customer-controlled identities and access paths. |
| PR.DS — Data Security | Cloud customers must protect the data they store and process in cloud services. | |
| Recommendation — Use PR.AA to govern cloud identities, authentication, and role-based access. Apply PR.DS to classify, protect, and monitor data placed in cloud services. | ||
Practitioner Guidance
What to verify: Separate provider assurances from customer controls in every cloud review. If the question is about underlying infrastructure, focus on the service provider’s shared-responsibility commitments, resilience, and platform assurance. If the question is about workload exposure, focus on the customer’s identity, configuration, and data controls.
What good looks like: The provider secures the platform layer, while the customer can clearly show who can access what, where secrets live, how permissions are constrained, and how sensitive data is protected in the deployed environment.
Common mistake: Treating “cloud-secure” as a vendor property. A service can be robust at the infrastructure layer and still be insecure in practice if customer-managed identities, configurations, or storage are weak.
Practitioner takeaway: The distinction matters because cloud risk usually appears at the boundary between provider-managed infrastructure and customer-managed usage, and the customer side is where access, configuration, and data exposure most often break down.
Related resources from NHI Mgmt Group
- What is the difference between threat intelligence and enforcement in cloud security?
- What is the difference between zero trust and traditional perimeter security in cloud environments?
- What is the difference between strong authentication and least privilege in cloud security?
- What is the difference between IGA and CIEM in cloud identity security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
