Cloud infrastructure due diligence is the pre-acquisition review of a target's AWS, Azure or GCP estate, operating evidence and cloud governance. It helps investors test whether the platform is resilient, secure, cost-efficient and scalable enough to support the deal thesis without hidden post-close spend or avoidable operational risk.
For many software businesses, cloud infrastructure is no longer a background IT cost. It is part of cost of goods sold, customer trust, gross margin, uptime, security posture and delivery velocity. A weak cloud estate can turn growth into fragile operations, while a well-managed estate can support faster integration and a cleaner first 100 days.
FoundationState's technical due diligence service reviews cloud infrastructure as commercial risk, not as a preference for one provider or architecture style. In our diligence engagements we typically move from scoping, to data room review, to evidence evaluation, to leadership and engineering interviews, to findings calibration and readout.
What should cloud infrastructure due diligence cover?
Cloud infrastructure due diligence should cover the structure, controls and operating reality of the target's cloud estate. The core areas are account and subscription design, identity and access, production and non-production separation, backup and recovery evidence, resilience, monitoring, deployment approach, security configuration, cost management, vendor dependency and scalability headroom.
The review should also test whether the estate matches the company being bought. A single-product SaaS company may have a simple cloud footprint that is perfectly appropriate for its stage. A regulated, multi-entity or enterprise-facing platform needs stronger evidence: documented ownership, tested recovery, repeatable provisioning, clear segregation and a reliable view of cloud spend.
The technical due diligence checklist gives deal teams a broader evidence structure across architecture, engineering, security and operations. Cloud diligence is the part of that review that asks whether the target can keep the product running, scaling and recovering under the conditions assumed in the investment model.
How should AWS, Azure and GCP estates be reviewed?
AWS, Azure and GCP estates should be reviewed through the same commercial questions, even though the services and terminology differ. Investors need to know who controls the estate, how workloads are separated, whether privileged access is limited, how changes are made, what is monitored, where data sits and which services are critical to revenue.
The AWS Well-Architected Framework is a useful benchmark because it frames cloud architecture around operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. In diligence, those pillars translate into deal questions: is the estate operated deliberately, can it fail safely, and does management know the cost and risk trade-offs?
For Azure, the same review may focus on subscriptions, management groups, Entra ID, role assignments, policy, landing zones and backup configuration. For GCP, it may focus on organisations, folders, projects, IAM, networking, logging and service account controls. The provider-specific detail matters, but the investor view should remain consistent.
The highest-risk estates are often not technically exotic. They are estates where nobody can explain why accounts are structured as they are, which environments are production, who has administrator access, which workloads are customer-critical, or whether the recovery process has ever been tested.
How do you test resilience and disaster recovery?
Resilience should be tested through evidence, not architecture diagrams alone. A diagram may show multiple zones, managed services and backup paths. The diligence question is whether the business has proved that the system can continue operating, degrade safely or recover within the tolerance that customers and the investment case require.
Disaster recovery due diligence should distinguish between configured and tested controls. A backup job that appears green in a console is useful, but it is not the same as a documented restore test. A second region in an architecture diagram is not the same as a working failover plan. A runbook that only one engineer understands is not a reliable control.
Useful evidence includes recent restore tests, incident post-mortems, recovery objectives, monitoring alerts, on-call ownership, dependency maps, database replication settings, infrastructure change history and the target's explanation of what would happen if a cloud region, database, queue, identity service or payment integration became unavailable.
In our diligence engagements we normally ask leadership to describe the most serious plausible outage, then compare that narrative with artefacts from the data room and cloud evidence. The gap between story and proof is often where deal-relevant risk sits.
Why do cloud costs matter to deal value?
Cloud spend matters because it can directly affect gross margin, cash burn, customer profitability and the buyer's post-close value creation plan. A growing revenue line can hide inefficient workloads, over-provisioned databases, unused environments, expensive logging, high data egress or customer-specific deployments that become more costly as the business scales.
Investors should avoid treating cloud cost assessment as a narrow procurement exercise. The aim is not simply to negotiate a cheaper bill. It is to understand whether cloud economics support the product model. If usage grows faster than revenue, if spend cannot be allocated to products or customers, or if the team relies on manual cost clean-up, the margin profile may be less attractive than the headline SaaS story suggests.
The review should look for cost ownership, tagging, budgets, alerts, reserved capacity or savings plans where appropriate, right-sizing discipline, environment lifecycle management and visibility of high-cost services. It should also test whether known optimisation work would compete with roadmap delivery after completion.
Is vendor lock-in a risk?
Vendor lock-in is a due diligence risk when it limits strategic options, increases switching cost or creates dependency that the buyer has not priced. Lock-in is not automatically bad. Using managed cloud services can reduce operating burden and improve reliability. The issue is whether the dependency is understood, deliberate and proportionate to the business.
Cloud migration risk becomes more serious when the target has hard-coded provider assumptions, proprietary data services, customer contracts requiring specific hosting regions, undocumented deployment scripts, limited portability of data, or a roadmap that assumes a future multi-cloud model without funding the work.
Multi-cloud can also be a risk if it exists for accidental reasons. A company may use AWS, Azure and GCP because of acquisitions, historic experiments, customer-specific demands or unmanaged team autonomy. That can increase security, monitoring, cost and skills burden without improving resilience.
Good diligence does not demand cloud neutrality. It asks whether the chosen provider model supports the investment thesis, whether concentration risk is acceptable, and what would need to change if the buyer's integration or enterprise customer strategy requires a different hosting posture.
What cloud evidence should be in the data room?
The data room should let investors test cloud maturity without needing unrestricted production access on day one. The strongest evidence combines diagrams, policies, exports, screenshots, logs and interview explanations that tell the same story.
| Evidence area | What stronger evidence shows | Deal risk if weak |
|---|---|---|
| Account and environment structure | Production, staging, development and shared services are clearly separated, owned and documented. | Accidental access, change or data exposure may be more likely. |
| Identity and privileged access | Administrators are named, MFA is enforced and permissions follow least privilege. | Day-1 control may be fragile after completion. |
| Backup and recovery | Backups are monitored and restore tests are recent, documented and owned. | Recovery may fail when customer revenue is at risk. |
| Infrastructure as code | Core resources are provisioned repeatably, reviewed and version-controlled. | The estate may contain snowflake infrastructure that is hard to reproduce. |
| Monitoring and incidents | Alerts, runbooks, incident records and post-mortems are visible. | Management may lack early warning of reliability issues. |
| Cloud cost management | Spend is tagged, allocated, reviewed and linked to products or workloads. | Gross margin and post-close optimisation may be uncertain. |
| Security configuration | Network exposure, key management, logging and data access are reviewed. | Cloud weaknesses may compound broader security exposure. |
The cyber security due diligence workstream should align with this evidence because cloud configuration, privileged access and logging are central to inherited security risk.
How should findings shape Day-1 remediation?
Cloud findings should be translated into a practical Day-1 and 100-day plan. The buyer does not need every cloud maturity gap fixed before completion, but it does need control of the risks most likely to affect revenue, security, recovery and margin.
Day-1 priorities often include privileged access review, removal of stale accounts, confirmation of backup ownership, cloud billing access, critical alert routing, preservation of incident evidence, and a named owner for production operations. These actions reduce control risk quickly without requiring a platform rebuild.
The first 100 days usually focus on tested recovery, infrastructure as code coverage, cost allocation, environment clean-up, logging and monitoring improvements, vulnerability and patch governance, and a clearer cloud risk register. The strongest remediation plans connect each action to commercial outcomes: lower outage risk, better margin visibility, reduced key-person dependency or more predictable scaling.
FoundationState's work with myHappymind reflects the value of connecting technology decisions to growth readiness and operational confidence. A useful cloud diligence readout should do the same: separate acceptable stage-appropriate gaps from risks that need pricing, protection or immediate remediation.
Get an independent view before cloud infrastructure becomes a post-close value leak. Contact FoundationState to scope a cloud infrastructure due diligence review around your target, provider estate, timeline and investment decision.
Frequently Asked Questions
What does cloud due diligence cover?
Cloud due diligence covers a target's AWS, Azure or GCP estate, including account structure, access control, environment separation, resilience, backups, disaster recovery, monitoring, security configuration, infrastructure as code, cloud costs, scalability and provider dependency. The purpose is to understand operating risk and post-close investment needs before signing.
How do you assess disaster recovery in due diligence?
Assess disaster recovery by testing evidence, not just intent. Review backup configuration, recent restore tests, recovery objectives, runbooks, incident history, ownership, monitoring alerts and dependency maps. A credible target should explain what happens during a serious outage and show that recovery has been rehearsed, not merely documented.
Is vendor lock-in a due diligence risk?
Vendor lock-in is a risk when cloud dependency limits the buyer's options, raises switching cost or conflicts with the integration plan. It is not automatically negative. Managed services can be sensible, but investors should understand whether provider choices are deliberate, documented, affordable and aligned with future customer and architecture needs.
