Cloud vendor due diligence

Cloud vendor due diligence asks whether a defined supplier arrangement can support your workload under terms your organisation can operate and exit. Review the proposed services, configuration, parties and agreements before approving the purchase. Record every gap with an owner and a decision date.

Define the arrangement

Name the business action the workload supports, its technical owner, the data involved, and the proposed services and regions. Identify any reseller, migration partner or managed service provider. Where several parties are involved, record which agreement governs each task and who receives an incident call.

Collect the proposed order, service terms, service level agreements (SLAs), support entitlement, security and data-processing terms, and documentation for required features. Note document versions and negotiated exceptions. Product marketing can raise a question; the applicable terms and current product documentation must answer it.

Where the agreement authorises resale or supply of Google Cloud Platform under a Google Cloud Partner or reseller program, the Cloud Run SLA treats the Partner or Reseller (as applicable) as the Customer. Financial credits apply only to impacted Partner or Reseller orders under that agreement.

Check commitments against the workload

An SLA covers a defined provider service under stated conditions. It does not promise that a customer can complete an application action. For example, the Amazon EC2 SLA separates region-level and individual-instance commitments, while Cloud Run sets commitments for its covered service. Neither SLA establishes availability for an entire application.

Keep support separate from the SLA. Check which case severities the team may raise, when an initial response is available, how escalation works and who must remain available on your side. An initial response target is not a restoration target.

Collect the applicable service commitments, support plan, service credits, customer-conduct conditions (such as any retry or back-off requirement) and stated remedies as evidence. Record the outcome of your review.

Cloud Provider SLA Commitments: Availability and Remedies

Assign security and privacy duties

Responsibilities vary by service. AWS assigns EC2 customers responsibility for the guest operating system, application software and security-group configuration. More managed services shift the division of infrastructure work, but customers still must manage their data and access choices. Assign an operator for identity, configuration, logging, updates, backup and incident response under the actual arrangement.

For an Australian organisation handling personal information, examine storage, copies, overseas support access and subcontracting. OAIC guidance says the Australian Privacy Principles that apply when sending personal information overseas partly depend on whether the handling is a 'use' or a 'disclosure'.

Where it is a disclosure, the entity must take reasonable steps to ensure the overseas recipient complies with the APPs and remains accountable if the recipient breaches them, subject to exceptions. Where it is a use, the entity may still be considered to hold the information, must comply with applicable APPs, and is accountable for a breach.

It may be unclear whether the information is being used or disclosed. In that case, the OAIC recommends taking reasonable steps to ensure the APPs are complied with.

APP 11.3 applies to personal information held after 11 December 2024. Reasonable steps to secure personal information under it include technical and organisational measures.

Records outside your jurisdiction

State Records NSW General Authority GA50 allows a NSW public office to take or send State records out of NSW for storage or maintenance by an external provider only on conditions. These conditions include a risk assessment and provider facilities and systems meeting State Records NSW standards.

Contractual arrangements must also cover security, safekeeping and ongoing accessibility, exportability and return of records, retained ownership and lawful deletion. Regular monitoring is required under the State Records Act 1998.

Australian Privacy and Records Management Requirements for Cloud Use

Check exit and feature readiness

List the data and configuration needed to use the workload elsewhere, including records, metadata, application settings and relevant recovery copies. Establish who can export them, in which formats, before access ends, and how remaining copies will be handled. A download function alone does not establish a usable exit.

Treat a future feature as an unresolved dependency until its status and availability are documented for the intended service, region, plan and account. Preview access carries different terms from general availability.

Microsoft says Azure public-preview features typically have no SLA, and service level agreements and production support commitments are not guaranteed. If the feature is essential, make approval conditional on evidence that it is available and suitable, or use a design that works without it.

For Azure infrastructure products and features, verify the current lifecycle stage and availability for the intended use. Consult Microsoft's lifecycle guidance for the detailed implications.

Record the purchase decision

Mark each requirement met with evidence, conditional with an owner and deadline, or unmet. For a conditional item, name the document or proposed check that would close it and the decision if it fails. A proposed demonstration is not a performed result.

Identify the approvals required before purchase from relevant business, technical, procurement, privacy, security, records-management and legal functions, as applicable. Retain documented sign-off in the purchase record. Keep the agreed configuration, applicable documents, operating owners, material exceptions and exit route together, and revisit the record when terms, service status or workload needs change.