Cloud contracts often contain reassuring language about security, availability, incident notification, and compliance. Those commitments matter, but they do not prove that controls are operating or that the customer can act when a provider has a problem.
A June 2026 U.S. Government Accountability Office report offers a useful warning. GAO reviewed eight selected federal cloud systems across four agencies and evaluated three practices: continuous monitoring, incident response and recovery, and service-level agreements. The sample was limited and is not statistically generalizable, but the operational gaps are recognizable well beyond government.
The executive takeaway is simple: cloud provider accountability is not established when the contract is signed. It is established when responsibilities are explicit, evidence is reviewed, response is exercised, and service commitments can be enforced.
What GAO found
GAO found that the selected agencies fully performed continuous monitoring for only three of eight systems. Most had monitoring plans, but they did not always review provider monitoring deliverables. Five systems had fully implemented the service-level-agreement practice; the remaining agreements did not consistently define performance metrics, how performance would be measured, or enforcement mechanisms.
GAO also identified incomplete incident-response and recovery practices, including gaps in coordination procedures, response-time measurement, testing, and prompt provider reporting. The report made 12 recommendations to three of the four agencies.
These findings do not show that cloud services are inherently insecure, nor do they justify treating the reviewed systems as representative of every federal or commercial environment. They show something more practical: assigning a requirement to a provider does not complete the customer’s governance obligation.
The shared-responsibility model needs an evidence layer
The phrase shared responsibility is widely understood but often implemented as a diagram produced during procurement. That is insufficient because responsibility changes by service model, specific product, configuration, data use, contract, and operating arrangement.
The Cloud Security Alliance’s 2026 introductory guidance for Cloud Controls Matrix 4.1 distinguishes provider-owned, customer-owned, and shared controls while emphasizing service-specific tailoring. That distinction should become an operating record, not remain a generic model.
For each material control, the organization should know:
- which party performs it;
- which party verifies it;
- what evidence demonstrates performance;
- how frequently that evidence is reviewed;
- what event triggers escalation or reassessment; and
- who can require remediation or accept the remaining risk.
This complements the approach described in treating security plans as operating contracts. A cloud responsibility record should connect the business service, provider dependency, control claim, evidence, accountable decision-maker, and change trigger.
Three capabilities turn contract language into operational assurance
1. Continuous monitoring that informs decisions
Collecting a provider report is not the same as reviewing it. A useful monitoring process defines which provider deliverables matter, who evaluates them, what thresholds require action, and how unresolved issues influence authorization, renewal, architecture, and risk decisions.
Current FedRAMP continuous-monitoring guidance describes the desired outcomes as operational visibility, managed change control, and attention to incident-response duties. Although FedRAMP requirements apply to federal cloud use, the operating principle transfers: monitoring exists to support ongoing confidence, not to accumulate documents.
For a commercial organization, a proportionate evidence set might include security advisories, material configuration changes, vulnerability trends, audit-log availability, significant control exceptions, recovery-test results, and remediation commitments. The exact set should follow service criticality and data risk rather than a universal checklist.
2. Incident coordination that has been exercised
The worst time to negotiate authority, evidence access, or communications is during an incident. NIST SP 800-61 Revision 3 states that responsibilities transferred to third parties should be clearly defined in contracts and that incident responders should understand information flows, coordination, and authority to act.
That means contracts and playbooks should agree on more than notification deadlines. They should define:
- what constitutes a reportable security event;
- who can isolate accounts, integrations, regions, or services;
- which logs and forensic artifacts will be available;
- how legal, privacy, regulatory, and customer communications are coordinated;
- how response and recovery time are measured; and
- how exercises and post-incident improvements are tracked.
If a critical provider has never participated in a scenario or tabletop exercise, the organization has not validated the coordination model it expects to rely on.
3. Service commitments with measurement and consequence
An SLA statement such as “commercially reasonable security” provides little operational leverage. Useful commitments identify a measurable outcome, the measurement source, reporting frequency, threshold, accountable parties, and consequence when performance falls short.
Not every security control belongs in an SLA, and punitive terms alone do not create resilience. The purpose is to make critical expectations observable and actionable. That may include remediation plans, enhanced reporting, escalation rights, service credits, termination assistance, or other remedies appropriate to the business relationship.
A practical accountability model
| Governance element | Minimum useful definition | Evidence leaders should expect |
|---|---|---|
| Business dependency | Service supported, critical data, tolerance for disruption | Service map, criticality decision, recovery requirements |
| Responsibility | Provider-owned, customer-owned, or shared for each material control | Service-specific responsibility record with named owners |
| Monitoring | Evidence received, review frequency, decision thresholds | Dated reviews, findings, trends, remediation status |
| Incident response | Notification, authority, information flow, containment, recovery | Joint playbook, contacts, exercise results, open improvements |
| Service assurance | Metric, measurement method, threshold, consequence | Reports, exceptions, escalation decisions, enforcement record |
| Change | Events that require reassessment | Provider notices, architecture decisions, contract and risk updates |
| Exit resilience | Data return, deletion, transition, and continuity needs | Tested export or transition procedure and accountable owner |
The goal is not to convert every provider relationship into an exhaustive control audit. It is to apply stronger assurance where provider failure could materially affect operations, customers, safety, legal obligations, financial performance, or reputation.
What leaders should do next
- Identify the most consequential cloud dependencies. Start with a small set of services whose prolonged loss, compromise, or data exposure would force an executive decision.
- Reconcile the shared-responsibility model. Compare provider documentation, internal architecture, configuration, contracts, and actual operating practices. Record ambiguity as a risk, not as “shared.”
- Define the evidence cadence. Assign an owner to review provider evidence and specify the thresholds that trigger remediation, escalation, reassessment, or acceptance.
- Exercise one joint incident scenario. Test contacts, notification, log access, containment authority, decision rights, communications, and recovery dependencies.
- Strengthen the next renewal. Convert lessons into measurable commitments and remedies while preserving the flexibility providers need to operate and improve their platforms.
- Prepare for exit before it is urgent. Confirm that data, identities, keys, integrations, logs, and business processes can be transitioned or recovered within an acceptable timeframe.
Organizations using external security services should connect these practices to a broader hybrid security operating model. The provider may perform important work, but the customer still owns the business decision about whether the remaining risk is acceptable.
Questions leaders should ask
- Which cloud services would create a material business event if unavailable or compromised?
- Where does our responsibility model still say “shared” without identifying who acts and who verifies?
- Which provider evidence do we receive but not meaningfully review?
- Can our incident team obtain the required logs and engage the right provider authority at any hour?
- When did we last exercise response and recovery with a critical provider?
- Which security commitments lack a measurement method or consequence?
- Can we exit the service without losing essential data, evidence, or operational capability?
My Perspective
Cloud risk discussions often become polarized between trusting the provider and attempting to audit everything. Neither is a workable operating model.
The better approach is selective, evidence-based accountability. Trust the provider for the capabilities it is designed and contracted to operate. Independently verify the small set of outcomes that matter most to the business. Make joint responsibilities explicit. Exercise the decisions that will become urgent during an incident. Escalate when evidence shows that an accepted assumption is no longer true.
This is also an architecture concern. Provider telemetry, identity, logging, recovery, and exit mechanisms must connect to the customer’s own control environment. If the organization cannot observe or act across that boundary, the contract describes an intention that the architecture may not support.
Conclusion
GAO’s findings are federal, but the management lesson is broader: cloud security accountability must remain active after procurement.
A provider contract should establish the foundation. Continuous evidence, tested coordination, measurable service commitments, and explicit decision rights make that foundation operational. Leaders do not need perfect visibility into every provider control. They need enough reliable evidence to know whether critical business outcomes remain protected—and enough authority to act when they are not.