Cloud due diligence is the process of evaluating a provider’s security posture, service commitments, and operational responsibilities before or after adoption. It includes reviewing controls, validating compliance, checking service level agreements, and understanding which risks remain with the customer versus the provider.
What cloud due diligence actually evaluates
Cloud due diligence is not a single checklist, but an evidence-based review of whether a provider can safely carry the parts of the workload the customer intends to outsource. The core question is what the provider is responsible for, what the customer still owns, and whether the stated controls are real, current, and auditable.
That scope usually spans architecture, security controls, operational processes, legal commitments, resilience posture, and the boundaries of shared responsibility. A strong review should make it clear whether the service model matches the organization’s risk appetite, data sensitivity, and regulatory obligations.
Security controls and commitments to verify
Due diligence should test the provider’s security claims against concrete artifacts, not marketing language. That means reviewing access control, encryption, logging, vulnerability management, backup and recovery, segregation of duties, and the operational processes behind them. For a service that handles regulated data or identity-related workflows, the question is whether the provider’s commitments are consistent with the actual NIST SP 800-53 Rev 5 Security and Privacy Controls stance the provider can demonstrate.
Contracts and attestations matter only when they are specific enough to anchor accountability. Service level agreements, shared responsibility matrices, audit reports, and incident notification terms should all be checked for internal consistency, because a gap between the written commitment and the operating model is a common source of downstream exposure.
Provider risk, dependency, and exit considerations
Cloud due diligence also asks how much organizational risk concentrates in a provider relationship. A provider outage, control failure, compliance lapse, or acquisition event can become a business continuity issue if the customer has not reviewed portability, reversibility, and exit support. The review should therefore cover data return, deletion assurances, backup portability, and dependency on proprietary services.
This is especially important when the cloud service is part of a larger control chain. If the provider becomes the only practical path for authentication, logging, monitoring, or recovery, the customer inherits a dependency risk that cannot be reduced later without migration effort.
Why cloud due diligence is a governance exercise, not just a procurement step
Good due diligence turns cloud adoption into an owned decision rather than an assumed one. It helps teams decide whether a provider’s controls are sufficient for the use case, whether compensating controls are needed, and which risks remain explicitly accepted by the customer. In practice, that makes due diligence a governance control as much as a technical review.
For cloud services that store or process sensitive information, the most useful outcome is not a perfect provider score. It is a clear statement of residual risk, control gaps, and accountability so security, legal, procurement, and operations can act on the same facts.
Risk and Threat Considerations
Cloud due diligence fails when organisations treat provider claims as proof instead of verifying the controls that actually protect data, availability, and access. The resulting risk is not only weak assurance, but also hidden dependency on controls the customer cannot see or operationally influence.
Failure mechanism: Misaligned shared responsibility, incomplete evidence, weak contractual control language, or poor visibility into provider operations can leave material security and resilience gaps undiscovered until an incident occurs.
Impact: Breaches, service disruption, compliance findings, or recovery delays can propagate into the customer environment even when the provider was assumed to be “covered.”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Cloud due diligence must verify how provider accounts and admin access are controlled. |
| CP-9 — System Backup | Backup and recovery evidence is central to cloud resilience and customer exit readiness. | |
| CA-3 — System Interconnections | Due diligence evaluates the trust boundaries and obligations created by cloud interconnections. | |
| Recommendation — Review provider account governance to confirm access is provisioned, monitored, and revoked appropriately. Verify backup controls and recovery objectives before relying on the cloud service for critical data. Assess interconnection agreements and shared responsibilities before approving provider integration. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Cloud due diligence is fundamentally supplier security assessment and oversight. |
| A.5.20 — Addressing information security within supplier agreements | The term depends on contractual clarity about responsibilities, protections, and accountability. | |
| Recommendation — Assess supplier security obligations and evidence before outsourcing critical services. Put security responsibilities and assurance requirements into supplier contracts. | ||
Practitioner Guidance
What to watch for: The most important signal is a gap between the provider’s promises and the artifacts that support them. If the supplier cannot show current control evidence, clarify ownership for incident response, or explain how customer data is isolated and recovered, the due diligence work is not complete.
Governance implication: Treat the result as a risk acceptance decision, not a pass/fail label. The output should identify which controls are inherited, which remain customer-owned, and which residual risks require mitigation, contract changes, or a different provider choice.
Related resources from NHI Mgmt Group
- Who is accountable when wallet-based customer due diligence fails?
- What is the difference between customer due diligence and strong customer authentication here?
- How should security teams assess a vendor’s ownership claims during due diligence?
- What should compliance and security teams do when fraud risk affects investor due diligence?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
