Why Most Cloud Security Checklists Miss What Matters

The standard cloud security audit checklist follows a predictable pattern: data protection, access controls, compliance, incident response. These categories are not wrong. But they are so broad that an organisation can tick every box and still have a cloud environment full of exploitable gaps.

The problem is that cloud environments fail differently from traditional infrastructure. On premises, the most common audit findings involve unpatched servers, weak passwords, and flat networks. In the cloud, the failures are more subtle. Misconfigured identity policies that grant broad access to every developer. Storage services exposed to the internet because a default setting was never changed. Logging enabled but never connected to detection logic. Security groups that were temporarily opened for troubleshooting and never locked down.

Research consistently shows that customer misconfigurations, not provider vulnerabilities, cause the vast majority of cloud security incidents. Your cloud provider's infrastructure is almost certainly more secure than what you could build internally. The risk sits in how your organisation configures, governs, and operates within that infrastructure. A useful audit checklist needs to target that risk directly.

Identity and Access Management

Identity is the control plane of cloud security. If your cloud environment has weak identity controls, nothing else you do matters much. This is where most cloud breaches start, and it is where most audits should spend the most time.

Your audit should verify these controls are in place and functioning:

  • Privileged access is tightly scoped. Review every account with administrative or elevated permissions. In most cloud environments, privileged access has expanded well beyond what is operationally justified. Service accounts, break-glass accounts, and developer roles with production access all need scrutiny.
  • Multi-factor authentication covers all human access. MFA should be enforced on every account, not just privileged ones. For organisations targeting Essential Eight maturity, phishing-resistant MFA is required from ML2 onwards for online services and workstations.
  • Service accounts and API keys are inventoried and rotated. Service accounts proliferate in cloud environments because they are easy to create and easy to forget. Audit for dormant service accounts, overly broad permissions, and keys that have never been rotated.
  • Federation and SSO are properly configured. If you use identity federation between your on-premises directory and your cloud provider, verify the trust configuration, the claims mapping, and what happens when the federation fails.
  • Access reviews are happening, not just scheduled. Scheduled quarterly access reviews are a common policy. Actually completing them, with evidence, is far less common. Check for evidence, not just calendar entries.

Configuration and Posture Management

Cloud environments change faster than traditional infrastructure. A storage bucket that was private at deployment can be made public with a single API call. A security group that was correctly restrictive can be widened by a developer troubleshooting a connectivity issue and never narrowed again. This is why configuration governance matters more in cloud than in any other environment.

The audit should assess:

  • Cloud Security Posture Management (CSPM) is active. Whether you use a dedicated CSPM tool or your provider's native configuration monitoring, something should be continuously scanning your environment for configuration drift against a defined security baseline.
  • Default settings have been reviewed and hardened. Cloud services often ship with permissive defaults designed for ease of use, not security. Storage services, databases, compute instances, and networking all have defaults that need deliberate hardening.
  • Infrastructure as Code (IaC) is used and scanned. If your cloud infrastructure is defined as code, the audit should check that security scanning is integrated into the deployment pipeline. If it is not defined as code, that is itself a finding, because manual configuration through the console is inherently harder to audit and easier to misconfigure.
  • Network segmentation exists and is enforced. Cloud-native networking provides powerful segmentation capabilities. Verify that workloads are segmented by sensitivity, that security groups follow least-privilege principles, and that east-west traffic within your cloud environment is controlled, not just north-south traffic at the perimeter.

Shared Responsibility Boundaries

Every major cloud provider operates a shared responsibility model. The provider secures the infrastructure. Your organisation secures the workloads, data, and configurations. In practice, the boundary between these responsibilities is less clear than the diagrams suggest, and it shifts depending on whether you are using IaaS, PaaS, or SaaS.

This is one of the most important areas for a cloud security audit to examine, and one of the most commonly skipped.

  • Shared responsibility is documented, not assumed. Your organisation should have a clear, written mapping of which security controls belong to the provider and which belong to you, for every cloud service in use. If this does not exist, the audit has already found a critical gap.
  • The mapping matches the actual service model. Organisations frequently assume they are getting SaaS-level coverage when they are operating at IaaS level. If your team believes the provider handles patch management but you are running IaaS workloads, those systems are going unpatched.
  • Operational teams understand their responsibilities. A shared responsibility mapping that lives in a governance document but is unknown to the operations team is functionally useless. Verify that the people managing cloud workloads understand what they are responsible for securing.

Logging, Monitoring, and Detection

Logging in cloud environments is powerful, often more comprehensive than what most organisations can achieve on premises. But logging without detection logic is just storage. And in many cloud environments we audit, that is exactly what we find: terabytes of logs, no alerts, no baselines, no one watching.

  • Cloud-native logging is enabled across all services. Verify that logging is active on compute, storage, identity, and networking services. Check that log retention meets your compliance and operational requirements.
  • Detection rules exist for high-risk events. At a minimum, you should have alerts for privilege escalation, configuration changes to security groups, access from unexpected locations, root or global admin usage, and API calls from service accounts outside normal patterns.
  • Logs feed into a central detection capability. Whether that is an internal SIEM, a cloud-native security hub, or a managed SOC service, logs need to be correlated and analysed, not just collected.
  • Incident response procedures cover cloud-specific scenarios. Your incident response plan should include cloud-specific playbooks: compromised access keys, exposed storage, lateral movement through cloud APIs, and provider-side incidents that affect your tenancy.

Data Protection and Sovereignty

For Australian organisations, data protection in the cloud involves more than encryption. It involves understanding where your data resides, who can access it under which legal framework, and whether your cloud architecture meets Australian regulatory expectations.

  • Data is classified and the classification drives controls. Not all data needs the same level of protection. Your audit should verify that data classification exists, that it is applied to cloud-hosted data, and that the technical controls, encryption, access restrictions, retention policies, match the classification.
  • Encryption is applied at rest and in transit. Most cloud providers offer encryption by default, but the audit should verify that customer-managed keys are used where required, that key management practices are sound, and that encryption is not silently disabled on any services.
  • Data residency requirements are met. Australian organisations handling sensitive data should verify that their cloud workloads are hosted in Australian regions. The ASD recommends prioritising cloud providers located in Australia and operated under Australian jurisdiction. This matters for legal frameworks, incident response cooperation, and protection from foreign disclosure orders.
  • Backup and recovery controls are tested. Verify that backups exist, that they are stored in a separate account or region, that they are immutable where possible, and that recovery has been tested. For Essential Eight alignment, backup controls are one of the eight strategies and the audit should assess maturity accordingly.

Australian Regulatory Alignment

A cloud security audit for an Australian organisation that does not address the local regulatory landscape is incomplete. Generic global checklists miss the specific requirements that Australian regulators expect.

ASD Information Security Manual and cloud guidance

The Australian Signals Directorate publishes comprehensive cloud security guidance covering provider assessment, service evaluation, and ongoing monitoring. The ISM includes specific controls for cloud environments that your audit should assess against. For organisations using Microsoft 365 or Azure, the ASD Blueprint for Secure Cloud provides practical configuration baselines aligned with the ISM.

Essential Eight in cloud environments

The Essential Eight applies to cloud workloads, and some strategies behave differently in cloud than on premises. Application control on cloud servers, patching of cloud-hosted operating systems, restricting administrative privileges across cloud management consoles, and MFA for cloud services all need specific assessment. Your cloud security audit should assess Essential Eight maturity for cloud-hosted assets, not just on-premises ones.

APRA CPS 234 for regulated entities

Financial services organisations operating under APRA CPS 234 must ensure their cloud arrangements meet information security capability requirements. This includes assessing the information security capability of material service providers (your cloud provider), classifying information assets in the cloud, testing controls that protect cloud-hosted information assets, and maintaining incident response capabilities that cover cloud-specific scenarios. CPS 234 does not prescribe specific cloud controls, but it requires you to demonstrate that your controls are commensurate with the threat environment.

Privacy Act and data handling

The Australian Privacy Act requires organisations handling personal information to take reasonable steps to protect it. In a cloud context, this means understanding how your provider handles personal information, where it is stored, who can access it, and what happens in the event of a breach. The audit should verify that your cloud data handling practices align with your Privacy Act obligations, including the Notifiable Data Breaches scheme.

What Good Looks Like

The organisations that consistently perform well in cloud security audits share a set of common characteristics. They are not necessarily the ones with the largest security budgets. They are the ones that treat cloud security as a continuous governance discipline rather than a periodic compliance exercise.

They have documented shared responsibility boundaries that operational teams understand and reference. They run continuous configuration monitoring and remediate drift within defined SLAs. Their identity controls are tight by default and exceptions are documented and time-limited. They test their cloud incident response through tabletop exercises and simulations, not just by reviewing the plan document. And they commission independent audits that test whether controls work in practice, not just whether policies exist.

The organisations that struggle are the ones running cloud environments that grew organically without security architecture input. Multiple accounts with inconsistent policies. Developer-configured security groups with no governance. Logging enabled but never monitored. Shared responsibility documented once in a slide deck that no one has looked at since onboarding.

Getting Started

If your organisation has not conducted a structured cloud security audit, or if your last audit used a generic checklist that did not address the areas above, the most valuable step is an honest assessment of your current posture. Not a vendor demo. Not a compliance checkbox exercise. A genuine evaluation of whether your cloud security controls are working.

Start by mapping your cloud estate: which providers, which services, which workloads, which data classifications. Understand your shared responsibility boundaries for each service model. Review your identity controls with a critical eye. Check whether your logging is connected to actual detection capability. And assess your posture against the Essential Eight and any other frameworks your organisation is measured against.

Cliffside's cloud security and cybersecurity audit teams work with Australian organisations to assess cloud environments against the controls that matter, not just the ones that are easy to check. If you want an honest view of where your cloud security stands, start with a Lighthouse Assessment.