Cloud Security Procurement Guide for Australian Organisations

Cloud security products are sold under a crowded set of acronyms: CSPM for posture management, CWPP for workload protection, CASB for SaaS access control, CIEM for cloud identity entitlements, and CNAPP for platforms that combine several of these. The labels overlap and vendors use them differently. An Australian organisation buying cloud security gets better results by starting from the risks in its own cloud estate than by starting from the category names.

CYBORIUM helps Australian organisations compare cloud security platforms and providers through a structured vendor-neutral sourcing process. The selected provider pays CYBORIUM a capped fee. The client contracts directly with that provider, and CYBORIUM does not sell, deliver, operate or invoice the technology.

Map the estate and the shared responsibility line

List the cloud platforms in use, the number of accounts or subscriptions, the main workload types (virtual machines, containers, serverless, managed databases) and the SaaS applications that hold sensitive data. For each, note which security tasks the cloud provider performs and which remain with the organisation. Misconfiguration, excessive permissions and exposed storage sit on the customer side of that line, and they are what most cloud security tools are built to find.

Then check what is already available. Native tools from the major cloud providers include posture checks and threat detection. A third-party platform needs to show what it adds: coverage across several clouds, better prioritisation, or one view for a small team.

Who does what, by service model

The shared responsibility line moves with the service model. Microsoft publishes its version of the split. Other providers publish theirs, and the details differ, so ask each provider for its own.

Source: Microsoft Learn, “Shared responsibility in the cloud”. The same page says that for all deployment types you own your data and identities.

Read the first three rows twice. Whatever you buy, the data, the settings and the accounts stay with you, and those are the areas where misconfiguration, excessive permissions and exposed storage appear. A cloud security tool earns its fee in those rows.

Five areas that decide cloud security value

1. Coverage of your environment

Ask each vendor to confirm support for your specific services, not just your cloud providers. Check whether coverage is agentless, agent-based or both, and what each approach can and cannot see. Agentless scanning is quick to deploy but may miss runtime behaviour inside a workload.

2. Prioritisation

A new cloud security tool often reports thousands of findings in its first week. Ask how the product decides what matters: whether it combines exposure to the internet, identity permissions, known exploited vulnerabilities and data sensitivity into one risk view. Request a sample of the top ten findings from a real trial, not a slide.

3. Identity and entitlements

Excessive cloud permissions are a common route to serious incidents. Test whether the product can show effective permissions for human and machine identities and recommend reductions that will not break production.

4. Compliance mapping and reporting

If the organisation reports against the ASD Information Security Manual, the Essential Eight, ISO/IEC 27001 or APRA CPS 234, check that the product maps findings to those frameworks and that reports can be filtered by business unit or account. For government work, ask whether the provider holds an IRAP assessment and at what classification level, and read the scope of that assessment rather than relying on the badge.

5. Operating model and cost

Pricing is often based on workloads, resources, accounts or cloud spend. Model cost at current scale and at expected growth. Identify who will triage findings, raise remediation tickets and chase fixes with engineering teams, because a tool that finds problems no one fixes does not reduce risk.

A comparable evaluation

Connect each shortlisted product to the same non-production accounts for the same period, using read-only access where possible. Seed a few known issues, such as a public storage bucket, an over-privileged role and an unpatched internet-facing workload. Record which products find each issue, how they rank it, and how clear the remediation guidance is. Score alongside written responses on data handling, data location, access to your environment and support.

A worked trial scorecard with numbers

The figures below are illustrative. They are not drawn from a client engagement.

Three products connect to the same non-production accounts for the same two weeks. The test team seeds three known issues. Each product is scored on every issue: 2 points if it found the issue, 1 point if it ranked the issue in its top ten findings, and 0 to 2 points for how clear the fix guidance was. That gives a maximum of 5 per issue and 15 in total.

P and R tie on 12. The scores tell them apart where it matters: R found the over-privileged role but ranked it low and gave weak guidance, so a small team might never get to it. Q found the identity issue best and missed the workload entirely, because it is agentless and the test workload needed a runtime view. If the organisation had set a rule before the trial that any missed seeded issue disqualifies a product, Q would be out whatever its total. Set that rule before the trial, not after the results.

Contract points to settle

The contract should state what access the product needs to your cloud accounts, where collected configuration and security data is stored, how long it is kept and how it is deleted at exit. It should define how billable units are counted and what happens when usage grows mid-term. If a managed service provider will operate the tool, separate the platform licence from the service obligations, including triage times and reporting.

Logging questions from ASD’s cloud guidance

ASD’s Australian Cyber Security Centre and its international partners advise that logging priorities depend on the cloud service model, because with IaaS the tenant carries a significant amount of the logging responsibility and with SaaS the provider carries more. For cloud environments they single out logging all control plane operations, including API calls and user logins, with read and write activity, administrative changes and authentication events captured.

Put these questions to every vendor.

1. Does the product collect control plane logs from each of our cloud accounts, and which events does it miss?
2. Where are those logs stored, for how long, and can we keep our own copy?
3. Does it record changes to permissions and the creation or deletion of accounts and roles?
4. Which of our log sources does it depend on us turning on?
5. If we exit, how do we take the history of findings and the underlying logs with us?

A product that finds issues but cannot show who changed what, and when, leaves the investigation half done.

CYBORIUM’s role in the decision

CYBORIUM can map the estate and responsibilities, define the evaluation scenarios, coordinate trials, evaluate evidence, model cost and support negotiation. The organisation keeps the decision and contracts directly with the selected provider. Related guides cover identity and access management and secure access service edge, which often touch the same architecture.

Updated 24 October 2026. This guide explains CYBORIUM’s procurement evaluation method. It does not provide legal or regulatory advice.

Standards and further reading

Cloud security decisions turn on who is responsible for what, and that boundary is where most procurement disputes begin.

• ASD cloud security guidance. Australian government guidance on assessing cloud services, including the questions that separate a provider control from a customer control.
• ISO/IEC 27017:2015. The cloud-specific control set. Ask a provider which of these controls it operates and which it expects you to operate, in writing.
• APRA CPS 234. For regulated entities, the information security obligations that follow your data into a third party regardless of where it is hosted.
• Microsoft Learn: Shared responsibility in the cloud. One provider’s published split of duties by service model.
• ASD’s ACSC and partners: Best practices for event logging and threat detection (August 2024). Includes logging priorities for cloud services.

Also relevant: where backups sit with a hyperscaler.

Last updated: 24 October 2026