How should a change advisory board handle cloud provider incidents?

Make upstream provider incidents a standing CAB agenda item with a clear trigger, one named owner, and a fixed output. Route AWS Health, Azure Service Health, Google Personalized Service Health, and Cloudflare Incident Alerts into your ITSM, review each provider's post-incident report when it lands, and record the decision in your risk register.

Cloud Provider Incidents: A Standing Item for Your CAB Agenda

No affiliate links appear in this article. Provider commitments are quoted from each provider’s own documentation, linked in Sources.

Why this matters
What providers actually promise after an incident
Where each provider falls short
Designing the standing agenda item
Getting the signal into your change process
What to do about it
FAQ
Sources

Why this matters

Most change advisory boards review changes the organization makes. Very few review the changes their providers make, even though those are often the ones that take production down. Cloudflare’s November 18, 2025 outage began at 11:20 UTC and was not fully resolved until 17:06 UTC, and Cloudflare’s own write-up traces it to a change on Cloudflare’s side that pushed a bad Bot Management configuration file across its network. Nobody at the affected customers raised a change ticket, and their services failed anyway.

This is not a one-off. As of this morning, Cloudflare’s status page still lists the Asia-Pacific network degradation that began on September 21, 2026, when multiple subsea cable outages congested traffic between Tokyo and Singapore. A week-long upstream degradation can raise latency or error rates in the middle of your change windows, and without a process to catch it, the CAB approves the next deploy without knowing the ground has moved.

Regulators already expect this. NIST CSF 2.0 asks organizations to make sure “relevant suppliers and other third parties are included in incident planning, response, and recovery activities” (GV.SC-08) and that supplier risks are “monitored over the course of the relationship” (GV.SC-07), per the NIST Cybersecurity Framework 2.0. For EU financial entities, DORA Article 28(3) requires a register of information covering “all contractual arrangements on the use of ICT services provided by ICT third-party service providers.” A standing agenda item is how that register turns into something the change process actually uses.

What providers actually promise after an incident

Before you design the agenda item, you need to know what input it will receive. The four providers most organizations depend on publish very different commitments.

AWS commits to a public Post-Event Summary “when an issue has broad and significant customer impact that results in the failure of a significant percentage of control plane API calls, impacts a significant percentage of a service’s infrastructure, resources or APIs or is the result of total power failure or significant network failure.” Summaries stay available “for a minimum of 5 years.”

Microsoft is the most specific. According to Microsoft Learn’s Azure incident-readiness training, “for every Azure service incident that impacts customers, we provide a Mitigation Statement.” For the largest incidents, a Preliminary Post Incident Review follows “generally within 72 hours of mitigation,” and a Final PIR “generally within 14 days of mitigation.” The Azure status history keeps each PIR for five years.

Google Cloud publishes a public incident report for what it calls “Broad Severe” incidents, defined as “global impact or affecting a significant percentage of customer projects across multiple regions.” Service Health keeps records “for up to five years.”

Cloudflare publishes incidents on its status page and writes detailed blog posts after major outages. Its status documentation describes how to get notified, but we found no published threshold or timeline for post-incident reports.

The matrix below compares these commitments on the four things a change board needs.

Matrix comparing AWS, Microsoft Azure, Google Cloud, and Cloudflare on public review trigger, publication timing, retention, and machine-readable incident feeds

Provider	Public review trigger	Timing	Retention	Feed you can automate
AWS	Broad, significant impact	”Following the closure of the issue”	5+ years	AWS Health via EventBridge
Microsoft Azure	Every customer-impacting incident gets a Mitigation Statement	Prelim PIR ~72h, final ~14 days	5 years	Service Health alerts via action groups
Google Cloud	”Broad Severe” incidents	After resolution	Up to 5 years	Personalized Service Health API, logs, alerts
Cloudflare	Not published	Not published	Not stated	Incident Alerts, Status API feeds

Where each provider falls short

None of the four gives a change board everything it needs, and each has its own gap.

AWS gives you no clock. The Post-Event Summary commitment says “following the closure of the issue” and nothing more, so you cannot schedule the CAB review against a known date. The threshold is also AWS’s judgment of “significant,” which means a regional issue that hurt you badly may not qualify.

Azure’s detail depends on severity. Microsoft is explicit that “different incidents might get different types of PIRs,” per its incident-response guidance. For smaller issues “the mitigation statement is the final summary,” so a short, single-region incident that broke your deploy may never get a full root-cause write-up.

Google Cloud keeps smaller reports private. Its documentation says that “in the case of smaller-scoped incidents, a nonpublic report might be made available to customers.” If you are not the account owner who receives it, your CAB may never see it unless someone forwards it.

Cloudflare publishes the least in advance. Its post-outage blog posts are detailed, but without a published trigger or timeline you cannot plan around them. You find out when the post appears.

The practical result: the agenda item cannot simply wait for a provider report. It has to start from your own impact data and use the provider report as evidence when it arrives.

Designing the standing agenda item

A standing item that runs every week soon gets skipped. A good one has a trigger, an owner, and a fixed output.

Trigger. Put an upstream incident on the next CAB agenda when any of these is true: a provider incident overlapped a change window; a provider incident affected a service your change calendar marks as critical; a provider published a PIR or Post-Event Summary for an incident you logged; or an incident ran longer than your own recovery time objective for the affected service. The Cloudflare APAC degradation qualifies on the third test for any team serving users in that region.

Owner. One person, usually the service owner or platform lead for the affected dependency, prepares a one-page summary. Rotating the job around the CAB means nobody owns it.

Output. The review produces one of four decisions, recorded against the provider’s entry in your risk register or DORA register of information: no action; adjust change windows or freeze rules for that dependency; add or test a failover path; or escalate to vendor management for a contract or architecture review. Our guide to cross-region failover testing covers what the third option looks like in practice.

History. Use the providers’ own archives to spot patterns. Our Azure outage timeline and AWS us-east-1 outage history show how often provider-side changes, not customer changes, set off the biggest events. A dependency with a record of change-triggered failures deserves a stricter freeze rule than one without.

Getting the signal into your change process

The agenda item only works if the signal reaches your ITSM without someone watching four status pages. Each provider now offers a way to automate this.

AWS: “All AWS customers can receive AWS Health events through Amazon EventBridge at no additional cost,” per the AWS Health documentation. Route those events to your ITSM as a linked record.
Azure: Service Health alerts use action groups that support email, SMS, push, and “Webhook, Logic Apps, or Information Technology Service Management (ITSM) integrations,” per Microsoft Learn.
Google Cloud: Personalized Service Health offers a dashboard, an API, alerts, and logs, and you can alert “when new incidents are reported, when existing incidents are updated,” per the Service Health overview.
Cloudflare: Its status documentation describes Incident Alerts that can be filtered by impact level and component and delivered by email, webhook, or PagerDuty. The status page’s own notifications are delivered independently of Cloudflare’s infrastructure, so they still fire when Cloudflare is down.

For a quick cross-provider view during a change window, our cloud status heatmap shows the major providers side by side. For more on tooling that pulls many status pages into one feed, see our status page aggregators comparison.

What to do about it

List your critical upstream dependencies. Start from the DORA register or vendor inventory you already keep, and mark the providers that can stop a critical service. NIST CSF GV.SC-04 asks that suppliers be “known and prioritized by criticality.”
Wire provider feeds into your ITSM. Use EventBridge, Azure action groups, Google Cloud Service Health alerts, and Cloudflare Incident Alerts so every provider incident creates a linked record.
Add the standing item with a written trigger. Put the four trigger conditions in your CAB charter so the item comes up when it should, not every week by default.
Name one owner per dependency. The owner prepares the one-page summary and tracks the provider’s post-incident report.
Record a decision every time. Log no action, a freeze-rule change, a failover task, or a vendor escalation against the provider’s risk-register entry.
Review the pattern quarterly. Count provider incidents that overlapped change windows. If one provider keeps showing up, that is an architecture conversation, not a CAB one.

FAQ

Why should a CAB review changes it did not make?

Because provider-side changes cause many of the largest outages. Cloudflare’s November 18, 2025 outage came from a change on Cloudflare’s own network, and customers had no ticket to review. A standing agenda item turns those events into decisions about freeze rules, failover, and vendor risk.

How long does Azure take to publish a post-incident review?

For its largest incidents, Microsoft says a Preliminary PIR follows generally within 72 hours of mitigation and a Final PIR generally within 14 days. Smaller incidents may only get a Mitigation Statement, which Microsoft treats as the final summary.

Does AWS publish a post-mortem for every outage?

No. AWS commits to a public Post-Event Summary only for issues with broad and significant customer impact, such as widespread control plane API failures or significant network failures. It does not publish a timeline, and summaries stay available for at least five years.

Can I automate provider incident alerts into ServiceNow or Jira?

Yes. AWS Health events flow through Amazon EventBridge at no added cost, Azure Service Health alerts support ITSM integrations through action groups, Google Cloud Personalized Service Health exposes an API and log-based alerts, and Cloudflare Incident Alerts support webhooks and PagerDuty.

What should the CAB record after reviewing a provider incident?

One decision, logged against the provider’s risk-register entry: no action, a change-window or freeze-rule adjustment, a failover task, or an escalation to vendor management. The record is what makes the review count as evidence for NIST CSF or DORA.

How does this relate to DORA?

DORA Article 28(3) requires EU financial entities to keep a register of information on ICT third-party service arrangements. A CAB review of provider incidents gives that register current operational evidence instead of a static list of contracts. This is operational guidance, not legal advice.

More on provider reliability lives on our cloud and SaaS pillar.

Sources

#change advisory board #cloud outages #post-incident review #third-party risk #AWS #Azure #Google Cloud #Cloudflare

Published September 28, 2026.