ASD Cloud Security Guidelines: A Practical Playbook for Australian Organisations

Summary

Cloud can harden security and resilience when you implement it the ASD way. The Australian Signals Directorate sets out a practical path: assess the provider and its services, assess your own systems, make shared responsibilities explicit, then monitor continuously and reassess at least every 24 months. The result is a defensible decision for where your data lives and how it is protected, aligned to the PSPF and ISM control set. 

Key Findings

• Cloud improves security only when tenant responsibilities are fulfilled. You remain accountable for your data and risk outcomes. 
• ASD’s blueprint centers on two assessments: Phase 1 for CSP fundamentals and services, then Phase 2 for your own cloud systems, with a documented authorisation package. 
• Shared Responsibility is not optional. Executives must evidence how responsibilities are met, and prefer Secure by Default services that minimise tenant burden. 
• Reassess at least every 24 months, keep abreast of addendums, and maintain continuous monitoring. 

What ASD Expects

ASD guidance integrates the Protective Security Policy Framework and the Information Security Manual. For cloud, ASD standardises terminology on the NIST definition, then provides artifacts that assessors and consumers actually use: a Cloud Controls Matrix (CCM) and a Cloud Security Assessment Report template. Together, they let you scope, evidence, and decide whether a CSP and a specific service can handle your data at the required classification and business impact level. 

Why this matters for non-Commonwealth organisations: even if you are not subject to PSPF, the ISM control library and ASD’s assessment method give you a defensible framework for supplier due diligence, data locality, personnel vetting, and continuity planning. For executives, ASD also publishes a succinct orientation to cloud models, risks, and the role of IRAP. 

Phase 1: Assess the CSP and Its Cloud Services

1A. Security fundamentals of the CSP. Look beyond shiny service names. Validate governance, change and vulnerability management, incident response, secure development life cycle, support model, administration networks, cryptography and key management, data transfers, IAM processes, automation, and continuity. ASD lists these criteria explicitly. Require evidence, not policy statements, and prefer control testing over paperwork. 

Locality and ownership. Analyse where offices, data centres, support staff and control planes reside, and the risk of foreign interference or extrajudicial access. ASD recommends Australian-based services for classified data, but the broader point applies to sensitive commercial data as well. Document the risk and compensating controls. 

1A. Services in scope. For each service, capture an architecture diagram, dependencies, interfaces, tenant isolation, security baseline, deviations, and what you, the tenant, must configure. This becomes the definitive reference for shared responsibility on that service. 

Reassessments and addendums. Insist on assessment age and read addendums. A CSP should push advisories for material changes or control weaknesses and expose these programmatically so you can integrate to your SIEM. 

Phase 2: Assess your cloud systems

Most cloud incidents are tenant misconfigurations. Treat Phase 2 as your own system-level IRAP-style assessment. Identify which controls you inherit from the CSP and which you must implement, then validate effectiveness iteratively through your SDLC and DevSecOps cadence. Bundle results into an Authorisation Package for the approving officer. 

Practical Actions:

• Build and maintain a shared responsibility register per service.
• Validate control inheritance claims. Inheritance does not absolve you of risk, especially when you introduce custom code or data flows. 
• Rely on Secure by Default features where possible to reduce the tenant’s burden. 

Shared Responsibility, Clarified

Executives: You cannot outsource your risk. The CSP has obligations for design, operation and underlying infrastructure, but you will always carry governance accountability for your data’s confidentiality, integrity and availability. Prefer services that reduce your responsibilities and enforce phishing-resistant MFA, logging by default, and managed short-lived credentials. 

SMBs: Choose trustworthy providers with documented SRM, and confirm backups, alerting and help-desk response are available without expensive add-ons. Ask for the provider’s IRAP assessment and read the residual risks. 

Governance Artifacts and Procurement Clauses That Matter

Embed security requirements into contracts and SLAs, not marketing claims. Use ASD’s executive checklist to brief legal and procurement on cyber obligations, break clauses, data locality, and the provider’s willingness to assist during incidents. Capture SRM items, logging retention, access approval workflows, and advisory notifications as contractual requirements. 

Technical Controls That Win (by Cloud Model)

All models, tenant responsibilities

• Use ASD-approved cryptography for data in transit, implement phishing-resistant MFA, and obtain time-synchronised logs and real-time alerts for admin activity. 
• Maintain encrypted, portable backups, test restoration annually, and manage cost/DoS exposure with limits and alerts. 

IaaS

• Harden VM templates, patch promptly, enforce segmentation and host-based firewalls, and administer only from trusted devices and IPs using key-pairs protected with strong passphrases. Architect across zones for availability. 

PaaS

• Securely configure OS and platform components you control; limit network flows to required ports and patch fast. 

SaaS

• Leverage service-specific protections such as tokenisation or encryption at rest where processing is not required, and ensure web security controls and prompt log analysis exist. 

For CSPs and due diligence: mirror the tenant list with provider-side expectations, including privileged access controls, background checks, secure data centre operations, separation of duties, and secure administration. Ask the provider how these are evidenced. 

Continuous Monitoring and Cadence

Build a continuous monitoring plan that processes CSP security advisories, tracks configuration drift, and feeds into time-driven and event-driven authorisation. ASD expects reassessment at least every 24 months, with addendums used to keep assessments current between cycles. 

A Pragmatic Decision Framework

1. Classify and locate your data: map sensitivity, residency, and support-staff locations. 
2. Choose service model to minimise tenant responsibilities where suitable, favouring Secure by Default designs. 
3. Assess CSP fundamentals and target services: use the CCM and report template, demand strong evidence. 
4. Assess your build: map inherited vs implemented controls; capture deviations and compensating measures. 
5. Operate, monitor, reassess: integrate advisories and change events into authorisation decisions; plan for Phase 1b when services change. 

About CyberPulse

CyberPulse is a security-first compliance partner helping organisations reduce cyber risk, build resilience and achieve certification with confidence. Founded by former CISOs and security leaders, we align technical depth with real-world context to deliver measurable outcomes across advisory, managed services, compliance and threat defence.

Let’s Talk

Follow us on LinkedIn for practical insights, or contact us to speak with a CyberPulse expert.

Useful Links

• Cybersecurity Companies in Australia: How ASD Guidance Defines Modern Best Practice
• Cybersecurity Roadmap: A Practical Framework for Australian Organisations
• Navigating the Complexities of Cloud Security
• Cybersecurity Priorities for Australian Boards | ASD Guidance (2025–26)
• NIST Changes Approach To Passwords

Related Services

• Managed Cybersecurity Services that include Cloud Security

External Resources

• Protecting Cloud Computing – ASD Guidance