The strategy exists. The execution does not.
Most Australian organisations we assess have a cloud security strategy of some kind. Many have spent significant money on it. The strategy typically includes the shared responsibility diagram, a set of security controls mapped to a framework, and a collection of tool recommendations. On paper, it looks comprehensive.
In practice, the strategy often fails at three points. First, the responsibility boundaries are defined but not operationalised. Someone drew the line between what the cloud provider secures and what you secure, but nobody mapped those responsibilities to specific teams, runbooks, and monitoring. Second, the security tooling is deployed but not tuned. Defender for Cloud is enabled but generating thousands of unactioned alerts. GuardDuty is running but nobody triages the findings. Third, the strategy was designed for the initial deployment and never updated as the environment grew, new services were adopted, and shadow IT expanded the attack surface beyond what the original architecture anticipated.
The result is a gap between documented security posture and actual security posture. That gap is where breaches happen. Gartner's widely cited prediction that 99% of cloud security failures will be the customer's fault is not about technology failure. It is about governance failure -- and specifically, about the failure to translate strategic intent into operational reality.
These are not edge cases. They appear in the majority of assessments.
Cloud security incidents are overwhelmingly caused by a small number of recurring misconfigurations. These are not sophisticated attacks. They are preventable governance failures that persist because configuration management in cloud environments is harder than most organisations anticipate. Research consistently shows an average of 43 misconfigurations per cloud account, with 82% caused by human error.
The pattern across all five is the same: the control exists in the platform, but it was either never enabled, was disabled for convenience, or drifted from its intended state over time. Cloud security is not primarily a technology problem. It is a configuration governance problem.
In cloud, identity and access management is your most critical control.
On-premises security was built around network perimeters: firewalls, VPNs, and network segmentation. In cloud environments, the network perimeter is largely irrelevant. Your identities -- user accounts, service principals, API keys, managed identities -- are the control plane. If an attacker compromises an identity with sufficient permissions, network controls are bypassed entirely.
This is why identity and access management appears in every row of the shared responsibility table as the customer's responsibility. And it is why identity-based attacks are the most common initial access vector in cloud breaches. Stolen credentials, phished tokens, and compromised service accounts provide the access that misconfigurations then amplify.
A functional cloud identity strategy requires several things that most organisations implement incompletely. MFA on all human identities, including conditional access policies that enforce it consistently. Least-privilege access enforced through just-in-time elevation rather than standing permissions. Regular access reviews that identify and remove stale accounts and excessive permissions. Monitoring of identity-based events -- sign-in anomalies, privilege escalation, cross-tenant access -- with alerting that someone actually responds to.
For Microsoft environments, Entra ID (formerly Azure AD) provides the tools to implement all of this. The tools exist. The gap is usually in governance: someone needs to define the policies, enforce them, monitor compliance, and handle exceptions without creating friction that drives workarounds.
Australian regulations follow your data, not your infrastructure.
A common misconception is that moving workloads to a major cloud provider somehow simplifies or transfers compliance obligations. It does not. Australian regulatory requirements apply to the data and the outcomes, regardless of where the infrastructure sits.
APRA CPS 234 is explicit: regulated entities must manage information security risks associated with outsourced activities, which includes cloud services. Paragraph 21 requires that information security controls are maintained whether the entity manages the information assets or a related or third party manages them. Moving to Azure does not reduce your CPS 234 obligations -- it changes the control set you need to evidence.
ISO 27001:2022 introduced Annex A control 5.23, specifically addressing information security for use of cloud services. This requires organisations to define processes for cloud service acquisition, use, management, and exit -- including clearly documented shared responsibilities and assurance mechanisms. Organisations pursuing or maintaining ISO 27001 certification must include cloud environments in their ISMS scope.
The Essential Eight strategies apply to cloud workloads. Application control, patching, restricting administrative privileges, and multi-factor authentication all have cloud-specific implementation requirements. Achieving Maturity Level 3 in a hybrid environment means applying these strategies consistently across on-premises and cloud infrastructure.
The Privacy Act 1988 governs personal information wherever it is stored. Using an Australian data centre region does not change your obligations under the Australian Privacy Principles. And the Notifiable Data Breaches scheme applies equally to breaches involving cloud-hosted data.
The compliance advantage of cloud: Done well, cloud environments are actually easier to audit and evidence than on-premises. Centralised logging, policy-as-code, and automated compliance dashboards provide continuous evidence that most legacy environments cannot match. The challenge is building that evidence pipeline intentionally, not assuming it exists by default.
The build-vs-buy decision depends on your team, not your budget.
Organisations approach cloud security through one of three models: build internal capability, outsource to a managed provider, or adopt a hybrid approach. The right choice depends less on budget and more on whether you have the people and operational maturity to sustain cloud security operations day after day.
Building internally makes sense when you have a mature security team with cloud-specific expertise, when your environment is large and complex enough to justify dedicated headcount, and when you need tight integration between security operations and development workflows. The challenge is that cloud security moves fast -- new services, new attack techniques, new provider capabilities -- and keeping internal skills current requires continuous investment.
Managed cloud security makes sense when your team lacks cloud-specific security expertise, when you cannot attract or retain the specialist talent required, or when your environment is standard enough that a provider's existing playbooks and tooling provide adequate coverage. A Managed SOC that covers cloud workloads provides continuous monitoring, threat detection, and incident response that most mid-market teams cannot sustain internally.
The hybrid model is the most common among the organisations we work with. Internal teams own governance, risk decisions, and architecture standards. External specialists provide operational monitoring, periodic assessments, and specialist expertise for complex configurations. A Virtual CISO often sits at the top of this model, providing the strategic oversight that ties internal and external capabilities together.
The decision should be informed by an honest assessment of your internal capability, not by the assumption that you can build what you need. As our outsourcing guide documents, the Australian cybersecurity skills shortage makes internal capability impractical for many organisations -- and that constraint applies to cloud security specialists even more acutely.
Strategy that survives contact with operational reality.
A cloud security strategy that works has specific characteristics that distinguish it from the documented-but-not-operationalised strategies we typically encounter.
Configuration governance is automated, not manual. Infrastructure-as-code templates enforce security baselines at deployment. Policy-as-code (Azure Policy, AWS Config Rules, or equivalent) detects and remediates configuration drift continuously. Manual configuration reviews are too slow for cloud environments where changes happen hourly.
Identity is treated as critical infrastructure. Privileged access uses just-in-time elevation with approval workflows. Conditional access policies enforce MFA contextually. Service account permissions are scoped to the minimum required and reviewed quarterly. Identity-based events are monitored with the same urgency as network intrusion detection.
Logging feeds a response pipeline, not a data lake. Cloud logs flow to a SIEM or equivalent with detection rules tuned to your environment. Alerts are triaged by someone with the context and authority to act. Logging for the sake of logging is storage cost without security value.
The strategy is tested, not just documented. Regular cloud security assessments verify that controls are operating effectively. Penetration testing covers cloud workloads. Incident response plans include cloud-specific scenarios -- compromised service accounts, data exfiltration through storage APIs, cryptomining on compute resources.
Cloud security is governed, not just operated. Someone owns the strategy, tracks its effectiveness, reports to leadership, and adjusts it as the environment evolves. Without governance, even well-designed controls degrade over time as exceptions accumulate, configurations drift, and new services are adopted without security review.
Assess your current state before designing your future state.
If you do not know where your cloud security stands today, you cannot build a strategy that addresses your actual gaps. The most common mistake is purchasing tools or services based on vendor recommendations rather than evidence-based assessment of your specific environment.
Start with a cloud security assessment that covers configuration review, identity and access audit, logging and monitoring validation, and compliance gap analysis against the frameworks that apply to your organisation. Use the findings to prioritise -- not everything needs fixing at once, and the order matters more than the speed.
If your cloud environment is relatively new or you are planning a migration, invest in the security architecture before the migration, not after. Retrofitting security into a cloud environment that was built for speed is significantly more expensive and disruptive than designing it in from the start. Our cloud migration security guide covers this in detail.
Cliffside's Lighthouse Assessment includes cloud security posture as a standard component. We review your cloud configuration, identity practices, logging coverage, and compliance alignment, and give you a prioritised view of what needs attention. As a Microsoft Partner with Azure and AWS certified staff, we assess your environment against both security best practices and the specific compliance requirements that apply to your industry.