Cloud Consultants near you

Before personal information goes to an overseas recipient, APP 8.1 requires reasonable steps to ensure the recipient does not breach the Australian Privacy Principles, and the OAIC's guidance says this will generally involve enforceable contractual arrangements over how the information is handled. What counts as reasonable moves with the sensitivity of the information, the maturity of the relationship and the harm a failure would cause. Inconvenience is not an excuse.

Section 16C is the sharp end. Where APP 8.1 applies and no exception is available, an act of the overseas recipient that would have breached the APPs is treated as having been done by the Australian entity, and as a breach by that entity, even where reasonable contractual steps were taken. The individual's remedy stays in Australia, against you.

That makes a few design questions non-optional. Which region will the data live in, and does the provider replicate it elsewhere for resilience or for support access. Can support staff outside Australia view production data, and under what controls. Does your privacy policy already name the countries where recipients are likely to be located, which is one of the things an APP privacy policy is expected to cover. Write the answers down before the migration, not after a complaint.

Where the line falls between the provider and you depends on the service. With infrastructure as a service you keep the operating system, the patching and nearly all of the configuration. With platform services the provider takes the runtime but you keep the data, the identities and the permissions. With software as a service you keep little more than identity, configuration and data, but those three are where most incidents start.

ASD's guidance is direct about the consequence: the majority of cloud compromises come from consumers failing to implement the controls they were responsible for under the shared responsibility model, and consumers remain accountable for their own data regardless of the model, including for compromises, losses or damage that occur to it.

A useful test for any proposal is to ask for the responsibility split as a written table covering identity, network, encryption keys, logging, backup and patching, with a name against each row. Anything left blank is yours by default, and you will discover that at the worst possible time.

Cloud spending is consumption-based, which means the finance model changes from a purchase every five years to a variable monthly operating expense that engineers can increase without a purchase order. The first surprise is usually that a lift and shift of oversized virtual machines costs more than the hardware it replaced, because the old servers were bought for peak load and paid for once.

The second surprise is data transfer. Moving data into a provider is generally cheap or free; moving it out, or between regions and availability zones, is metered. Chatty architectures, cross-region replication and large analytics exports are the usual culprits, and they only become visible on a bill.

Ask a consultant for a run-rate estimate broken into compute, storage, data transfer, licensing and support, with the assumptions written down, and ask what the estimate looks like if usage doubles. Then ask which levers exist afterwards: rightsizing, reserved or committed-use discounts, storage tiering, and turning off non-production environments outside business hours.

Lock-in is not a reason to avoid managed services, but it is a reason to know what you are signing up for. Plain virtual machines and object storage are portable. Proprietary databases, serverless frameworks and platform-specific messaging are not, and the more of the platform an application uses, the more a future move costs.

The practical protections are unglamorous. Keep the billing account and the tenant in your company's name rather than the consultant's. Make sure at least one person inside your business holds root or owner access. Require infrastructure to be defined as code and stored in a repository you control, so the environment can be rebuilt by someone else.

Ask, in writing, how you would extract every dataset: in what format, over what period, at what transfer charge, and whether the provider commits to deleting its copies afterwards. That question is easy to answer at the start of a relationship and remarkably hard once it has soured.

If you supply government or handle government data in the cloud, the assessment path is ASD's cloud assessment and authorisation process, supported by IRAP assessments of the provider and its services against the Information security manual. ASD's guidance indicates cloud service providers and their services should be assessed at least every 24 months, or sooner where an event makes revalidation necessary.

An assessment of the provider does not cover what you build on top of it. Inheritance is partial: the assessment of the underlying service tells you which controls you can rely on, and the rest of the system still needs its own assessment and its own authorisation by the responsible government entity.

For commercial buyers with no government exposure, none of this is mandatory, but the same questions are useful. Ask whether the provider has been assessed, when, against which version of the ISM, and whether the report is available under a confidentiality agreement.