In the cloud shared responsibility model, which controls are actually ours?

Practitioners must understand that "security in the cloud" translates to direct control over critical aspects of their cloud environment. This includes classifying and encrypting data, configuring network security groups and virtual private clouds, managing user identities and access permissions, and securing applications deployed within the cloud. For Infrastructure as a Service (IaaS), the customer retains significant control over operating systems, middleware, and applications. In Platform as a Service (PaaS), the customer manages applications and data, while the provider handles the underlying platform. With Software as a Service (SaaS), customer responsibility primarily focuses on data input, user access management, and ensuring appropriate configuration settings within the application.

A common misconception is that a cloud service provider's (CSP) FedRAMP authorisation or SOC 2 report fully satisfies an organisation's security and compliance requirements. These attestations primarily validate the CSP's "security of the cloud" controls. Customers remain responsible for implementing and auditing their own controls to meet their specific compliance obligations, which often extend beyond the CSP's scope. For instance, a FedRAMP-authorised CSP ensures the underlying infrastructure meets government standards, but the agency using that CSP must still implement controls for their data, applications, and user access in accordance with NIST SP 800-53 and agency-specific policies. Similarly, while a SOC 2 report provides assurance about a CSP's controls over the Trust Services Criteria, the customer must ensure their own operational processes and configurations align with their internal controls and regulatory mandates. Organisations should meticulously review the CSP's Customer Responsibility Matrix (CRM) or similar documentation to delineate precise control boundaries.