Cloud Workload Security: What It Is and How to Get It Right

A common and dangerous misconception among Australian businesses is that moving to the cloud means moving to something inherently secure. It doesn’t. In fact, Gartner projects that through 2025, 99% of cloud security failures will be the customer’s fault – primarily because of misconfigurations, excessive permissions, and improperly secured workloads. The cloud provider secured their infrastructure. The workloads running on it? That’s on you.

This is not a theoretical risk. In 2024, 45% of data breaches globally occurred in the cloud – up from 27% just three years prior. Tenable’s 2025 Cloud Security Risk Report found that 29% of organisations have what it calls a ‘toxic cloud trilogy’: publicly exposed workloads that are critically vulnerable and highly privileged. Any one of those three conditions is a problem. All three together is a breach waiting to be discovered.

Cloud workload security is the discipline that closes this gap – the set of practices, controls, and tools that protect everything running inside your cloud environment, from virtual machines and containers to serverless functions and SaaS data. For Australian businesses operating on Microsoft Azure, AWS, or hybrid environments, it is one of the most consequential security decisions you make – and one of the most frequently under-resourced.

This guide covers what cloud workload security is, why the shared responsibility model is the starting point for understanding it, the types of workloads that need protection, the most common threats and how they manifest, the tools and frameworks available, and what Australian businesses should prioritise in 2026. For implementation support, explore our managed cybersecurity services or our cloud security assessment service.

The Shared Responsibility Model: Where Cloud Provider Security Ends and Yours Begins

The shared responsibility model is the foundational concept for understanding cloud workload security – and the source of most cloud security failures when it is misunderstood. Every major cloud provider operates under this model, which divides security responsibilities between the provider and the customer.

The model is not complicated. It is, however, precisely defined – and the line between provider responsibility and customer responsibility shifts depending on the type of cloud service you are using.

The practical implication: in most cloud configurations, the security of your actual workloads – the applications, data, and services your business depends on – is entirely your responsibility. Microsoft or AWS securing their datacentres and hypervisors does not make your misconfigured Azure storage account secure. It does not patch your virtual machine’s operating system. It does not prevent your developers from deploying an overly permissive IAM role. Those are all customer-side failures, and they are the dominant cause of cloud breaches.

This is why many Australian businesses that moved to the cloud for security improvements found themselves no more secure – sometimes less so. They secured the perimeter but left the workloads inside exposed. Understanding the shared responsibility boundary is the prerequisite for meaningful cloud workload security. See our overview of what the cloud actually is for a broader introduction to cloud service models.

What Are Cloud Workloads? The Five Types You Need to Protect

The term ‘cloud workload’ covers a wide range of compute resources. Understanding what each type is – and why each presents different security challenges – is essential for designing a workload security strategy that covers your actual environment.

1. Virtual Machines (VMs)

Virtual machines are the most common cloud workload for Australian SMBs – virtual servers running Windows Server or Linux, hosting applications, databases, file services, and domain controllers. Azure Virtual Machines and AWS EC2 instances are the primary examples.

Security challenge: VMs require OS-level security just like physical servers. Guest OS patching, antimalware, firewall configuration, and hardening are all customer responsibilities. A VM running an unpatched Windows Server 2019 is as vulnerable as an unpatched on-premises server – the fact that it is in Azure changes nothing. Many Australian businesses that migrated via lift and shift without hardening their workloads brought their on-premises vulnerabilities directly into the cloud.

2. Containers

Containers – particularly Docker containers orchestrated by Kubernetes – package applications and their dependencies into portable, isolated units. They are increasingly common in modern application architectures and development environments.

Security challenge: Containers are ephemeral and highly dynamic – they spin up and disappear in seconds, making traditional security scanning approaches ineffective. A container might be deployed, run for five minutes, and be gone before any security tool has had a chance to assess it. Container image vulnerabilities – malicious or vulnerable packages baked into the container image – can persist invisibly across thousands of container instances. Container security requires scanning at the image registry level, before deployment.

3. Serverless Functions

Serverless computing – Azure Functions, AWS Lambda – allows code to execute in response to events without managing the underlying server infrastructure. The provider manages the computer; you write the function code.

Security challenge: Serverless functions are invisible to most traditional security tools – they have no persistent host to scan, no OS to monitor, and no agent to deploy. They are also frequently over-permissioned: developers assign broad IAM roles to functions for convenience, creating accounts that can access far more cloud resources than the function actually needs. A compromised serverless function with excessive permissions is a lateral movement vector into your wider cloud environment.

4. Databases and Data Services

Cloud databases – Azure SQL Database, Azure Cosmos DB, AWS RDS, AWS DynamoDB – store your business’s most sensitive data and are a primary target for attackers. They also represent the workload type where misconfigurations have the most immediate and severe consequences.

Security challenge: Public accessibility is the most common and catastrophic misconfiguration – a database with a public endpoint and no network restriction is an internet-accessible data store. Azure and AWS both allow databases to be made publicly accessible with a single configuration option. Credential stuffing, brute force attacks, and direct exploitation of unpatched database engines are all active threat vectors against cloud databases that lack proper network controls and access management.

5. SaaS Applications and Data

Microsoft 365, Salesforce, Xero, and other SaaS platforms are cloud workloads in the sense that your business data resides in them and is processed by them – even though you have no control over the underlying infrastructure.

Security challenge: SaaS data is widely assumed to be backed up and protected by the vendor – it is not. Microsoft’s shared responsibility model for Microsoft 365 explicitly states that data protection is the customer’s responsibility. Email, SharePoint, OneDrive, and Teams data can be permanently deleted, ransomware-encrypted via compromised accounts, or exfiltrated – and Microsoft’s native retention policies are not a substitute for backup. Our dedicated guide on Microsoft 365 backup explains what you are and are not protected against in the default Microsoft 365 configuration.

The 6 Biggest Threats to Cloud Workloads in 2026

Understanding the threat landscape is prerequisite to building effective defences. These six threat categories account for the vast majority of cloud workload security incidents in Australian environments.

Threat 1: Misconfiguration – The #1 Cloud Killer

Misconfiguration remains the dominant cause of cloud security incidents. A misconfigured Azure storage account with public blob access can expose terabytes of business data to anyone with a URL. A misconfigured security group that allows inbound access on port 22 (SSH) from 0.0.0.0/0 exposes a server to the entire internet. An IAM role with AdministratorAccess assigned to a Lambda function gives any attacker who compromises that function full control of your AWS account.

What makes misconfigurations particularly insidious is their invisibility in normal operations. A misconfigured storage account does not generate errors – it functions normally while simultaneously being accessible to unauthorised parties. Without proactive misconfiguration scanning, businesses often discover breaches months after the initial exposure – exactly as occurred in the Medibank breach, where misconfigurations in access controls allowed an attacker to move laterally through the environment undetected.

Threat 2: Identity and Access Management (IAM) Failures

CrowdStrike’s 2025 Global Threat Report found that 75% of cloud-conscious attackers targeted identity and access controls rather than technical vulnerabilities. Identity is the new perimeter in cloud environments – and the most exploited one. Over-permissioned roles, unused service accounts with high privileges, and credentials exposed in code repositories are among the most common entry vectors into cloud environments.

The ‘toxic cloud trilogy’ identified by Tenable – publicly exposed workloads that are critically vulnerable and highly privileged – is largely an IAM problem. When a workload is reachable from the internet and its service account has excessive permissions, a single compromise of that workload gives an attacker wide access to the broader cloud environment.

Threat 3: Unpatched Vulnerabilities in Cloud Workloads

Cloud providers patch their underlying infrastructure. They do not patch your virtual machines, container images, or application dependencies. An Azure VM running an unpatched OS is vulnerable to every public CVE affecting that OS. A container image built from a base image six months ago likely contains dozens of known vulnerabilities that have been patched in subsequent releases.

The ASD Essential Eight mandates patching within defined timelines for exactly this reason – unpatched vulnerabilities are among the most reliably exploited attack vectors in both on-premises and cloud environments.

Threat 4: Data Exfiltration via Unsecured Storage and APIs

Cloud environments expose data through multiple channels that have no equivalent in on-premises infrastructure: publicly accessible object storage (Azure Blob Storage, AWS S3), APIs without authentication or rate limiting, and data pipelines that move information between services without encryption. Any of these, misconfigured, becomes a data exfiltration path.

API security is particularly challenging because APIs are intentionally designed to be accessible – the line between legitimate access and malicious access is defined entirely by authentication, authorisation, and rate limiting controls that developers must implement correctly. Email security gateway controls prevent one class of data exfiltration; cloud storage and API controls prevent another class that is increasingly exploited.

Threat 5: Lateral Movement Through Cloud Environments

Once an attacker gains initial access to one cloud workload, their objective is to move laterally – using the permissions and network access of that initial foothold to reach more valuable targets. Cloud environments frequently have flat internal network structures and over-permissioned service accounts that make lateral movement straightforward.

The absence of network segmentation between cloud workloads – treating all workloads as if they are on the same trusted network – is one of the most common architectural security failures in cloud environments. A compromised front-end web application should not be able to reach a production database directly; proper network controls create a mandatory inspection point between them.

Threat 6: Supply Chain and Third-Party Component Risks

Modern cloud workloads depend on dozens of third-party libraries, open-source components, and vendor services. Each dependency is a potential attack vector – as demonstrated by the SolarWinds and Log4j incidents, where widely used legitimate software components contained vulnerabilities that gave attackers access to thousands of cloud environments simultaneously.

Container images pulled from public registries without verification, npm packages with malicious dependencies, and misconfigured third-party integrations all represent cloud workload supply chain risks that grow as cloud deployments become more sophisticated.

CWPP, CSPM, and CNAPP: Understanding the Cloud Security Toolset

The cloud security tooling landscape has its own alphabet soup of acronyms. Understanding what each category does – and when each is appropriate – is essential for making informed tool decisions without over-investing in redundant capabilities.

For most Australian SMBs operating on Microsoft Azure, Microsoft Defender for Cloud provides CNAPP-equivalent capability – combining cloud security posture management (identifying misconfigurations, compliance gaps, and over-exposed resources) with cloud workload protection (runtime protection for VMs, containers, and serverless) in a single, integrated platform. It is included at varying capability levels in Microsoft 365 Business Premium and Azure subscriptions.

8 Cloud Workload Security Best Practices for Australian Businesses

1. Enforce the Principle of Least Privilege Across All Cloud Identities

Every service account, application identity, virtual machine managed identity, and human user account in your cloud environment should have only the permissions they need to perform their specific function – nothing more. This principle is universally understood but universally under-implemented. Over-permissioned identities are the highest-frequency contributing factor to lateral movement after initial cloud compromise.

Specific actions:

• Audit IAM roles quarterly: identify roles and accounts that have not used assigned permissions in 90 days – these permissions are candidates for removal
• Use managed identities instead of service account credentials: Azure Managed Identities provide automatically-rotated credentials for workloads without storing secrets in code or configuration
• Implement just-in-time privileged access: use Entra ID Privileged Identity Management (PIM) to require approval for elevated permissions rather than permanently assigning them
• Separate development, test, and production environments: use separate Azure subscriptions or AWS accounts with no cross-environment permissions between development and production workloads

2. Eliminate Misconfigurations Before They Become Breaches

Misconfiguration detection must be continuous and automated – not periodic. Cloud environments change constantly: developers deploy new resources, configurations drift as teams make adjustments, and new services are enabled without security review. A storage account that was correctly configured on Monday may be publicly accessible by Thursday due to a developer change made without security review.

• Enable Microsoft Defender for Cloud: provides continuous misconfiguration assessment with remediation guidance, maps findings to compliance frameworks, and prioritises risks based on exploitability and exposure
• Configure Azure Policy: define and enforce configuration standards – prevent deployment of resources that don’t meet your security baseline before they are created, not after
• Conduct a structured cloud security assessment: a periodic deep-dive assessment goes beyond automated tooling to identify architectural weaknesses and configuration patterns that automated tools miss. Our cloud security assessment provides this for Australian businesses

3. Patch Cloud Workloads as Aggressively as On-Premises Systems

Cloud VMs are not self-patching. Without a centralised, automated patch management programme, cloud virtual machines will fall behind on OS and application patches exactly as on-premises servers do. The ASD Essential Eight’s patching controls apply equally to cloud workloads – critically exploited vulnerabilities require patching within 48 hours, and all critical patches within 14 days at Maturity Level 2.

• Use Azure Update Manager: centralised patch management for Azure VMs – schedule maintenance windows, enforce compliance policies, and report patch status across all managed VMs
• Scan container images before deployment: use Microsoft Defender for Container Registries or equivalent to scan container images for known vulnerabilities before they reach production. Block images with critical unpatched vulnerabilities from being deployed
• Retire end-of-life operating systems immediately: cloud VMs running EOL operating systems (including Windows 10 past October 2025) are permanently unresolvably vulnerable

4. Encrypt Data At Rest and In Transit – Without Exceptions

Encryption is the last line of defence when other controls fail. If an attacker gains access to cloud storage or a database, encryption determines whether they can read the data or not. In 2026, encryption should be a non-negotiable baseline – not an advanced security feature.

• Enable Azure Storage encryption: Azure encrypts storage data at rest by default – but verify that customer-managed keys (CMK) are used for sensitive data rather than Microsoft-managed keys, which Microsoft can technically access
• Enforce HTTPS/TLS for all data in transit: reject HTTP connections to all endpoints; use TLS 1.2 or higher; enforce this via Azure Policy or security group rules that block unencrypted traffic
• Encrypt database transparent data encryption (TDE): ensure Azure SQL Database TDE is enabled with customer-managed keys for sensitive data – TDE is enabled by default but the key management model matters for compliance with the Privacy Act

5. Segment Cloud Workloads – Eliminate Flat Network Architecture

A flat cloud network – where every workload can reach every other workload – is as dangerous as a flat on-premises network. Proper network segmentation in the cloud uses Virtual Networks (VNets in Azure, VPCs in AWS), network security groups (NSGs), and private endpoints to enforce controlled boundaries between workloads.

• Use Azure Private Endpoints for PaaS services: connect to Azure SQL Database, Storage Accounts, and App Services via private IP addresses rather than public endpoints – completely removing them from the public internet
• Configure NSG rules to restrict east-west traffic: Azure VMs should only be able to communicate with the specific other resources they legitimately need to reach – not with the entire VNet
• Separate internet-facing workloads from internal ones: use Azure Application Gateway or Azure Front Door with WAF as the internet-facing layer; keep backend services – databases, APIs, internal applications – on private subnets with no public endpoints

6. Enable Runtime Threat Detection Across All Workloads

Configuration-based security (CSPM) tells you your workloads are configured correctly. Runtime detection tells you when something unexpected is happening inside a running workload – even if the configuration is correct. These are complementary, not interchangeable.

• Microsoft Defender for Servers: deploys Microsoft Defender for Endpoint onto Azure VMs, providing behavioural EDR detection – identifying suspicious processes, lateral movement attempts, and privilege escalation inside running VMs
• Microsoft Defender for Containers: provides runtime threat detection for containerised workloads – detecting abnormal container behaviour, privilege escalation, and crypto-mining activity
• Enable Microsoft Defender for App Service: detects common web application attacks and unusual activity in Azure-hosted web applications and APIs
• Feed alerts into Microsoft Sentinel: aggregate Defender alerts from across your cloud workloads into Sentinel for correlation, investigation, and automated response – a misconfigured VM generating suspicious network traffic is a much higher-priority alert when correlated with a concurrent credential anomaly

7. Secure the Software Supply Chain and Container Images

Modern cloud workloads depend on third-party code and container base images that may contain vulnerabilities or malicious components. Shift-left security – building security into the development and deployment pipeline, not just monitoring production – is the only approach that keeps pace with the speed of cloud deployments.

• Scan container images in CI/CD pipelines: integrate container vulnerability scanning into your deployment pipeline so that images with critical vulnerabilities are blocked before they reach production
• Use trusted base images from verified sources: build containers from Microsoft-verified base images rather than arbitrary public Docker Hub images; maintain an approved image registry
• Pin dependency versions: avoid using floating version references (latest, *) for package dependencies – pin to specific, verified versions and update deliberately through a review process
• Scan infrastructure-as-code (IaC) templates: use tools like Checkov or Microsoft Defender for DevOps to scan Terraform, Bicep, and ARM templates for misconfigurations before they are deployed

8. Implement Continuous Logging, Monitoring, and Incident Response

Security controls that generate no alerts provide no security value. Cloud workload security requires comprehensive logging of security-relevant events – authentication events, configuration changes, network connections, privileged operations – and active monitoring and response to the alerts those logs generate.

• Enable Azure Activity Log and Diagnostic Logs: ensure all cloud resources are configured to send logs to a central Log Analytics workspace – this is the raw data that all monitoring and detection depends on
• Configure Microsoft Sentinel alert rules: implement detection rules that flag specific high-risk behaviours: impossible travel logins, mass storage access, privileged role assignment changes, security group modifications
• Define and test cloud incident response procedures: your incident response plan must include cloud-specific playbooks – how to isolate a compromised Azure VM, revoke a compromised managed identity, and rotate compromised credentials across all affected services
• Set resource locks on critical infrastructure: Azure Resource Locks prevent deletion or modification of critical resources – preventing an attacker (or a mistaken administrator) from destroying your security monitoring infrastructure

Cloud Workload Security and Australian Compliance Requirements

For Australian businesses, cloud workload security is not only a technical discipline – it has direct compliance implications across multiple frameworks that carry legal or regulatory weight.

For businesses pursuing ISO 27001 certification, cloud workload security controls map directly to multiple Annex A controls in the Technological theme – A.8.7 (Protection Against Malware), A.8.8 (Management of Technical Vulnerabilities), A.8.9 (Configuration Management), A.8.22 (Segregation of Networks), and A.8.24 (Use of Cryptography). Implementing cloud workload security systematically simultaneously progresses ISO 27001 Annex A compliance.

�� Case Study: How a Brisbane Technology Company Closed 14 Critical Cloud Security Gaps in 6 Weeks

The Situation

A 42-person Brisbane software company providing managed applications to healthcare and legal clients had operated on Microsoft Azure for three years. Their IT infrastructure was managed by a part-time contractor who handled day-to-day support. When their cyber insurer requested an independent cloud security assessment as a condition of renewal, they engaged CodeHyper.

The assessment covered their Azure environment – 8 virtual machines, 3 Azure SQL databases, 2 Azure Storage accounts, multiple Azure App Service instances, and their Microsoft 365 tenant. What it found was not unusual for an SMB that had moved to the cloud without specific security expertise: 14 critical or high-severity security gaps, three of which had direct potential for significant data breach if discovered by an attacker.

The 3 Critical Misconfigurations Found

• Critical Gap 1 – Publicly accessible storage account: One Azure Storage account containing client document templates and configuration files had anonymous blob access enabled – meaning anyone on the internet could list and download all files without authentication. The account had been in this state for approximately 11 months. The storage included files with client names, contact details, and legal case references – directly relevant to the Privacy Act
• Critical Gap 2 – Azure SQL Database with public endpoint and weak firewall: One production database hosting client application data had a public endpoint enabled with a firewall rule of 0.0.0.0 to 255.255.255.255 – effectively permitting all internet traffic to attempt authentication against the database. The database used SQL authentication (username/password) rather than Azure Active Directory authentication, and the SA account password had not been rotated in two years
• Critical Gap 3 – Service principal with Owner-level permissions: An Azure service principal – created during an initial setup several years earlier and apparently forgotten – had Owner-level permissions on the main Azure subscription. Owner permission is the highest possible level – equivalent to Global Admin for the entire Azure environment. The service principal had no expiry date, no usage logs, and no documented owner. Its client secret was never rotated

The Additional High-Severity Findings

• Microsoft Defender for Cloud not enabled – no misconfiguration monitoring or workload threat detection in place
• No Azure Monitor alerts configured – zero visibility into configuration changes, authentication failures, or unusual activity
• 7 of 8 VMs had not received OS patches in over 60 days
• Azure Activity Logs not retained beyond 90 days – insufficient for incident investigation under most regulatory frameworks
• No Azure Resource Locks on any critical resource – production databases and storage accounts were deletable by any subscription contributor
• Microsoft 365 data not covered by any third-party backup – client data in Teams and SharePoint had no recovery protection beyond Microsoft’s limited native retention
• Multiple legacy app registrations with unused API permissions accumulating in Entra ID
• MFA not enabled for two contractor Microsoft 365 accounts

The 6-Week Remediation Programme

8. Week 1 – Critical issues: Storage account anonymous access disabled immediately. Azure SQL public endpoint changed to private endpoint using Azure Private Link. Service principal secret rotated, permissions reduced to minimum required, expiry date set. These three actions eliminated the highest-risk exposure within 48 hours
9. Week 2 – Identity hardening: Audit of all service principals and app registrations – 4 legacy registrations decommissioned, 6 had permissions reduced. MFA enabled for all user and contractor accounts. Entra ID PIM configured for subscription Owner and Contributor roles
10. Week 3 – Workload protection: Microsoft Defender for Cloud enabled with Standard tier. Defender for Servers enabled across all 8 VMs. Azure Update Manager configured with automated patching on a 14-day maximum window for critical patches. Patch compliance baseline established
11. Week 4 – Network segmentation: All remaining PaaS services migrated to private endpoints. NSG rules reviewed and tightened – 23 overly permissive rules identified and replaced with least-privilege equivalents. Azure Application Gateway with WAF deployed for internet-facing App Service instances
12. Week 5 – Monitoring and logging: Azure Monitor alerts configured for 18 high-priority events (subscription role changes, storage access policy changes, SQL firewall modifications, etc.). Activity Log retention extended to 1 year via Log Analytics workspace. Resource Locks applied to all production resources
13. Week 6 – Backup and documentation: Datto SaaS Protection deployed for Microsoft 365 data. Azure Backup configured for VM-level backup with geo-redundant retention. Assessment findings documented and submitted to insurer. Defender for Cloud Secure Score improved from 34% to 78%

The Results

“We thought we were reasonably secure because we were using Microsoft Azure. The assessment was a genuine wake-up call. Three things we didn’t even know existed were the kind of things that make the news. The insurer got their report. We got security we should have had from day one.”  – CTO, Brisbane Technology & Software Company

Your Cloud Workloads Are Running. Are They Secure?

The shared responsibility model is unambiguous: once you move workloads to the cloud, their security is your responsibility. The cloud provider secures the infrastructure. You secure everything running on it. And based on industry data, most organisations are not doing this well – 99% of cloud security failures trace back to the customer side.

The good news is that the gap between ‘cloud workloads running’ and ‘cloud workloads running securely’ is measurable and closeable. A structured cloud security assessment identifies your specific exposure. A systematic remediation programme closes it. And ongoing monitoring through tools like Microsoft Defender for Cloud maintains the posture as your environment evolves.

At CodeHyper, we design, assess, and manage cloud workload security for Australian businesses across Microsoft Azure and hybrid environments. Whether you are starting a cloud migration and want to build security into the architecture from the start, or you are already in the cloud and unsure how exposed your workloads are – our team brings the technical depth and Australian compliance context to do it properly.

Start with our cloud security assessment to understand exactly where your workloads are exposed and what it would take to close the gaps. Or contact us today for a no-obligation conversation about your cloud security posture.

Frequently Asked Questions: Cloud Workload Security

What is cloud workload security?

Cloud workload security is the practice of protecting the applications, services, virtual machines, containers, serverless functions, and data that run inside cloud environments. It is the customer’s responsibility under the cloud shared responsibility model – cloud providers secure the underlying infrastructure, but everything running on top of it (workloads, configurations, access controls, data) is secured by the customer.

Why is cloud workload security different from traditional security?

Cloud environments are dynamic, distributed, and ephemeral in ways traditional on-premises environments are not. Containers spin up and disappear in seconds. Infrastructure is defined and deployed through code rather than physical configuration. Resources can be made publicly accessible with a single API call. Traditional security tools and approaches – designed for stable, physical infrastructure – often cannot keep pace with the velocity of cloud change. Cloud-native security tools (CWPP, CSPM, CNAPP) are designed specifically for these dynamic characteristics.

What is the shared responsibility model in cloud security?

The shared responsibility model is the framework that defines which security obligations belong to the cloud provider and which belong to the customer. Cloud providers (Azure, AWS, Google Cloud) are responsible for the physical security of their datacentres, the underlying hardware, and the hypervisor layer. Customers are responsible for the guest operating systems on VMs, application code, data encryption, identity and access management, network configurations, and workload security. The boundary shifts depending on whether you use IaaS, PaaS, or SaaS services.

What is the difference between CWPP, CSPM, and CNAPP?

CWPP (Cloud Workload Protection Platform) secures what runs inside the cloud – virtual machines, containers, and serverless functions – with runtime protection, vulnerability scanning, and threat detection at the workload level. CSPM (Cloud Security Posture Management) secures the cloud infrastructure itself by continuously monitoring for misconfigurations, compliance violations, and exposed resources in the cloud control plane. CNAPP (Cloud-Native Application Protection Platform) combines both, plus identity management (CIEM), into a unified platform – the most comprehensive approach and increasingly the standard for organisations wanting consolidated cloud security tooling.

What is the most common cause of cloud security breaches?

Misconfiguration is the dominant cause of cloud security incidents – Gartner projects that 99% of cloud security failures through 2025 will be the customer’s fault, primarily due to misconfigurations. Common misconfigurations include publicly accessible storage accounts, overly permissive IAM roles, databases with public endpoints, and network security groups that allow inbound access from the entire internet. The cloud security assessment we conduct for Australian businesses almost always finds at least one critical misconfiguration that the organisation was unaware of.

Does Microsoft Azure secure my workloads for me?

No. Microsoft Azure secures the underlying infrastructure – the physical datacentres, hardware, networking, and hypervisor layer. Everything you deploy on Azure – virtual machines, databases, storage accounts, applications, and their configurations – is your responsibility. Azure provides security tools (Microsoft Defender for Cloud, Azure Policy, NSGs) that help you secure your workloads, but using those tools is your responsibility. Moving to Azure does not make your workloads secure by default.

Is Microsoft 365 data backed up and protected by Microsoft?

Not comprehensively. Microsoft’s shared responsibility model for Microsoft 365 explicitly places data protection responsibility on the customer. While Microsoft provides some native retention policies and version history, these are not a substitute for backup – they do not protect against ransomware encryption via compromised accounts, deliberate deletion, or retention policy gaps. A dedicated Microsoft 365 backup solution is required to properly protect Exchange Online, SharePoint, OneDrive, and Teams data.

How does cloud workload security relate to the ASD Essential Eight?

The ASD Essential Eight applies to cloud workloads as directly as to on-premises environments. Essential Eight Control 2 (Patch Applications) and Control 6 (Patch Operating Systems) apply to cloud VMs – the cloud provider does not patch your guest OS. Control 5 (Restrict Administrative Privileges) applies to cloud IAM – over-permissioned service accounts and IAM roles are an Essential Eight compliance failure. Control 8 (Regular Backups) applies to cloud data – cloud-native retention is not a substitute. Implementing the Essential Eight to Maturity Level 2 provides the governance framework for cloud workload security compliance.

What tools does CodeHyper use for cloud workload security in Azure?

For Microsoft Azure environments, our primary toolset includes: Microsoft Defender for Cloud (CNAPP capability – CSPM + CWPP in one platform), Microsoft Defender for Servers (EDR for Azure VMs), Microsoft Defender for Containers (runtime protection for containerised workloads), Azure Policy (misconfiguration prevention and compliance enforcement), Microsoft Sentinel (SIEM for aggregating and correlating cloud security alerts), Azure Update Manager (centralised VM patch management), and Azure Private Link/Private Endpoints (network-level workload isolation). For Microsoft 365, we add a dedicated third-party backup solution and email security controls.

How do I get started with cloud workload security for my Australian business?

The most effective starting point is a structured cloud security assessment – a review of your current cloud environment against security best practices and the shared responsibility model’s customer obligations. This identifies your specific misconfigurations, IAM gaps, unpatched workloads, and network exposure, and produces a prioritised remediation plan. CodeHyper conducts these assessments for Australian businesses on Microsoft Azure and hybrid environments. Contact us today to discuss your environment and what a cloud security assessment would involve – or explore our cloud security assessment page for more detail.