Introduction
"The cloud provider handles security" is the most expensive sentence in a vendor review. Cloud adoption changes the due diligence question.
It is no longer "Is the provider secure?" It is "Are the provider, our configuration, our data practices, our integrations, and our contracts collectively fit for the risk we are taking?"
In 2024, Mandiant traced every investigated Snowflake customer incident to compromised customer credentials, not a breach of the platform. Missing MFA was a common thread.
This guide serves security leaders, procurement teams, deal teams, general counsel, and board members. It covers procurement, migration, M&A, renewals, new subprocessors, and incidents. You get a practical framework across scope, evidence, control domains, red flags, reporting, and ongoing oversight.
Key Takeaways
- Review the provider's controls and your own side of the shared responsibility model.
- Treat certifications as a starting point; check scope, dates, exceptions, and customer duties.
- Tie every finding to business impact, an owner, a decision, and a validation deadline.
- Keep reviewing after approval through change triggers, incidents, and renewals.
What Cloud Security Due Diligence Covers and Why It Matters
What cloud security due diligence means
Cloud security due diligence is a structured review of a cloud service's security posture, data handling, resilience, dependencies, contract protections, and customer-side controls. Teams run it before signing and again at key points during the relationship.
It overlaps with, but differs from, three related activities:
- General vendor assessments: broader scope, often generic checklists
- Technical configuration reviews: tests of your actual cloud settings
- M&A cyber due diligence: evaluation of a whole target company
A good review borrows from all three, scaled to the risk.
Shared responsibility across IaaS, PaaS, and SaaS
Responsibility shifts with the service model, not the provider's brand. AWS states that customer responsibilities vary by service.
| Model | Provider typically runs | Customer typically keeps |
|---|---|---|
| IaaS | Underlying infrastructure | Guest OS patching, applications, security groups, identities, data |
| PaaS | Underlying OS and platform | Application code, configuration, identities, data |
| SaaS | Application stack | Tenant settings, access, identities, data |
For the specific service under review, label each control as provider-managed, customer-managed, or shared. Shared responsibility is not shared accountability. You remain accountable for your data and your users.
When to perform the review
Common triggers:
- Initial procurement or migration
- Acquisitions
- Renewals
- Material service or architecture changes
- New data categories, regions, or subprocessors
- Security incidents
- New regulatory obligations
Why executives and boards care
Cloud findings map to board-level outcomes:
- Confidentiality and availability risk
- Regulatory exposure and customer trust
- Deal value and integration cost
IBM's 2026 report puts the US average breach cost at $11.5M, though that figure is not cloud-specific. The Verizon DBIR attributes 48% of breaches in its 2026 dataset to third-party involvement, also not cloud-only.
The Capital One case shows why boards treat this as governance, not only technology. The OCC's 2020 action imposed an $80M penalty and cited ineffective risk assessment before the company migrated significant operations to public cloud.
A Risk-Based Cloud Security Due Diligence Process
Establish scope, criticality, and decision criteria
Document before you ask for anything:
- The service, supplying legal entity, and cloud model
- Data categories, data locations, and users
- Privileged access, integrations, and subprocessors
- Business owner, critical processes, and dependencies
Then set the rules: inherent-risk tier, blocking requirements, reviewers, decision authority, evidence deadline, and when formal risk acceptance or escalation applies.
A tiered approach keeps effort proportionate:
- Tier 1: Focused review call with security and the business owner, ideally within 30 days or before go-live
- Tier 2: Document review within 60 to 90 days
- Tier 3: Short questionnaire, revisited at renewal
Request evidence that matches the service
Skip the generic document bundle. Ask for what validates the real data, access, and resilience risks:
- SOC 2 reports, ISO 27001 evidence, ISO/IEC 27017 material
- CSA CAIQ or Cloud Controls Matrix responses
- Penetration-test summaries and vulnerability remediation records
- Architecture and data-flow diagrams
- Incident-response procedures and recovery-test summaries
- Subprocessor lists
For early-stage vendors without SOC 2, use compensating controls: limited access, no production data, shorter terms, and a dated security roadmap.
Validate evidence instead of accepting claims
Check that each document covers the right legal entity, service, environment, geography, and review period. Record anything expired, partial, or out of scope.
Know the report types. A SOC 2 Type 1 has no operating-effectiveness opinion, while Type 2 reports include tests and results. Read the exceptions. Read the complementary user entity controls (CUECs), which list what you must do yourself. Check whether subservice organizations are carved out.
AWS notes customers are not certified by association. A provider's ISO certificate covers a defined scope, not your workloads.
Assess technical and operational controls
For material or high-risk services, pair documents with architecture discussions, targeted interviews, configuration evidence, incident history, and recovery or tabletop test evidence. External security ratings are a signal, not the decision.
Separate provider weaknesses from customer-side ones: permissive IAM, public storage, unmanaged keys, missing logs, insecure integrations, and access that was never removed.
Produce a decision-ready assessment
Build a risk register with these fields:
- Finding and affected asset or data
- Evidence reference
- Likelihood and impact rationale
- Owner, remediation action, and deadline
- Residual risk and validation method
Then state one outcome: approve, approve with conditions, defer pending evidence, or reject. Route exceptions to the authorized risk owner, with an expiry date, so unresolved findings do not vanish into the report.
Cloud Security Due Diligence Checklist
Identity, access, and privileged administration
Inadequate IAM ranks first in the Cloud Security Alliance's 2026 threat report. Verify:
- Identity federation and MFA coverage, including cloud consoles and admin portals
- Least-privilege roles and short-lived privileged elevation
- Root and break-glass account controls
- Service accounts, secrets management, and key rotation
- Access reviews, admin-action logging, and prompt offboarding
Red flags: shared accounts, dormant identities, unreviewed machine identities, hard-coded credentials, and unclear ownership of access approvals.
Data protection, privacy, and location
Review:
- Data classification and encryption in transit and at rest
- Key ownership, masking, retention, and deletion
- Backups, export paths, and every location where data is stored or accessed
Map the service to your obligations: state privacy laws, HIPAA, GLBA and the FTC Safeguards Rule, PCI DSS (requirement 12.8.3 calls for due diligence on service providers), or contract terms.
HHS says a cloud provider holding encrypted ePHI can still be a business associate, even without the key. No certification replaces legal review.
Network, infrastructure, application, and deployment security
Examine:
- Segmentation, firewall rules, and security-group configuration
- Internet-facing assets, WAF, and API protections
- Container and serverless controls
- Patching, infrastructure-as-code, CI/CD, and secrets scanning
Ask how cloud assets are inventoried, how misconfigurations are detected, how changes are approved, and how high-risk findings are retested. CIS Benchmarks and CISA's SCuBA baselines give you a concrete yardstick.
Logging, detection, incident response, and resilience
Confirm:
- Audit-log coverage, centralization, retention, and protection from alteration
- Alert ownership, threat detection, and forensic access
- Severity definitions and notification commitments
- Provider and customer response coordination
- Recovery objectives, backup isolation, and failover
Ask for at least one full restore test of a critical service, with a dated report and lessons learned. A backup nobody has restored is an assumption.
Third parties, governance, contracts, and exit
Identify subprocessors, hosting dependencies, platform or model providers, and support staff with data access. Confirm how changes are communicated. Focus fourth-party review on critical vendors' key subprocessors, not every dependency.
Contract review should cover:
- Breach notification in hours, not "reasonable time"
- Audit rights, data ownership, return, and deletion
- Portability, liability, and service levels
- Transition help and exit testing
Ask about concentration risk too: reliance on one cloud, one identity provider, or one MSP.
How to Evaluate Findings and Build the DD Report
Classify findings by business impact and evidence quality
Use one severity method across all reviews. Weigh affected data, exploitability, criticality, regulatory exposure, and recovery difficulty. Label each finding as a control failure, evidence gap, customer responsibility, or unknown.
Record "not verified" separately from "failed." Treat it as material when the missing evidence blocks an informed decision. A simple scale works: 0 for unknown or no proof, 1 for partial, 2 for a clear owner and evidence.
Identify cloud-specific red flags
- Expired or out-of-scope assurance reports
- Unresolved critical vulnerabilities and unexplained public exposure
- Weak privileged access and incomplete logging
- Untested backups and unclear data locations
- Undisclosed subprocessors and weak notification terms
- Repeated unresolved findings
- No workable exit path
Behavior counts too. Evasive answers, questionnaires that contradict contracts, and refusal to explain material exceptions signal governance risk, even without a confirmed vulnerability. A challenged claim should produce a real artifact within a week.
When the DD report itself is a red flag
A report earns that label when it is materially incomplete, stale, or leans on vendor assertions. It is also suspect if it omits scope and limitations, stays silent on exceptions, or cannot connect findings to business impact.
A sound report discloses missing evidence, assumptions, testing limits, unresolved disputes, customer-side dependencies, and any provisional conclusions.
Structure the report for technical and executive readers
Include:
- Executive summary
- Scope and methodology
- Architecture and data-flow context
- Control-domain findings
- Evidence limitations
- Prioritized remediation plan
- Residual-risk decisions
- Required contract or integration conditions
Add a one-page, plain-English board summary: current posture, what changed, top risks, trend, decisions needed, escalation thresholds, accountable executives, and next review date. A director should grasp it in two minutes.
Convert findings into decisions and a 90-day plan
Map each material issue to a treatment:
- Remediate before approval
- Approve with a compensating control
- Add a contract condition
- Limit data or access
- Defer deployment
- Accept residual risk through the proper authority
A board advisor or interim CISO can help turn findings into decisions. Tyson Martin's advisory practice, for example, converts technical findings into decision rights, escalation thresholds, and a 90-day plan with named owners and measurable outcomes. The practice advises and validates; it does not run security operations or perform penetration testing.
After the Assessment: Contracts, Remediation, and Ongoing Oversight
Put protections into the contract and operating model
Translate findings into specific contractual obligations:
- Security controls and audit evidence
- Notification windows and subprocessor changes
- Data location, retention, and deletion
- Recovery, liability, and exit assistance
FFIEC guidance, for example, calls for timely, machine-readable data return.
Then assign internal owners for the controls you must run. A contract should never suggest the provider manages the entire risk.
Execute and validate remediation
Prioritize by business impact and dependency. Give each fix an owner (not "the security team"), a due date, and proof of closure such as test results, logs, or access-review evidence.
Structure the 90 days in phases:
- Days 1 to 30: Reduce immediate exposure, such as MFA on admin paths and removing shared accounts
- Days 30 to 60: Foundational work on logging, backups, and restore tests
- Days 60 to 90: Policy, contract changes, and metrics ready for monthly review
- Beyond: Longer-term architecture improvements
Hold weekly working sessions to unblock delivery and monthly executive reviews to approve spend and accept risk.
Maintain continuous oversight
Reassess when conditions change:
- Incidents, major outages, or privilege increases
- Architecture or subprocessor changes
- New data uses, renewals, or regulation
- A shift in business criticality
NIST SP 800-137 ties monitoring to changes in systems, threats, and risk tolerance.
Keep a stable one-page dashboard: open risks, trend, overdue actions, accepted residual risk, evidence freshness, and decisions needing executive attention.
Frequently Asked Questions
What are the top 3 cloud security risks?
Priorities vary by service. Commonly they are excessive or compromised access, misconfiguration or exposed resources, and weak detection, recovery, or third-party controls. CSA's 2026 report ranks inadequate IAM first.
What is a red flag DD report?
It is a due diligence report with material gaps: unsupported claims, stale or out-of-scope evidence, hidden exceptions, unclear customer responsibilities, missing owners, or no actionable decision.
What are the five pillars of cloud security?
No single universal model exists. This guide uses identity and access, data protection, infrastructure and network security, detection and response, and resilience and governance. NIST CSF 2.0 has six functions, so map the pillars to it.
What evidence should be requested during cloud security due diligence?
Request scoped assurance reports, architecture and data-flow diagrams, IAM and encryption details, testing and remediation records, incident and recovery documentation, subprocessor lists, and contract terms. Ask for customer-side control requirements too.
How often should cloud security due diligence be performed?
Refresh the initial review at renewal, at least annually for critical services, and whenever incidents, new data uses, subprocessors, architecture changes, or regulations shift the risk. No single cross-sector interval exists.
