SaaS configuration in a cloud recovery plan

Which SaaS settings does a cloud environment depend on?

• Identity: users, groups, applications and sign-in policies in an identity provider such as Okta or Microsoft Entra ID.
• Edge: DNS zones, CDN and firewall rules in a service such as Cloudflare or Akamai.
• Operations: monitors and alert rules in an observability tool, and escalation policies in a paging tool.
• Code and secrets: repositories, pipelines and secret stores.

None of these live in a cloud account, so a cloud backup does not hold them.

What can go wrong with them?

The same incidents that hit cloud infrastructure: an administrator deletes an application in the identity provider, an automation script overwrites DNS records, an attacker changes sign-in policies. The result is an outage even though every server is healthy.

Because these services sit outside the cloud account, the cloud provider's own logs and backups do not show the change, so the gap is often found only when users report it.

What do vendors document?

Firefly's docs list SaaS data sources including Okta, Entra ID, Datadog, GitHub, Cloudflare, New Relic, PagerDuty, MongoDB Atlas, Databricks, Akamai, NS1 and HashiCorp Vault, and its disaster recovery page names SaaS alongside Kubernetes. On 23 July 2026 Firefly announced that it codifies Okta and Microsoft Entra ID configuration as infrastructure as code with versioned, immutable snapshots, so the identity setup can be restored to a known-good state.

ControlMonkey describes SaaS configuration capture for Okta, Entra ID, Cloudflare, Cisco Meraki and Zscaler.

The other tools scored here do not describe SaaS configuration recovery on the pages we reviewed.

In what order does SaaS configuration come back?

Identity first, because people need to sign in to run the recovery. Then DNS and edge rules, because users need to reach the rebuilt service. Observability and paging can follow, but restore them before the incident is closed, or the next problem goes unnoticed.

Who owns SaaS recovery?

SaaS settings often sit with different teams: identity with IT, DNS with networking, monitoring with platform engineering. A cloud DR plan that covers only cloud accounts leaves each of these to its owner, with no shared order or test. Name one owner per service in the plan, and include at least the identity provider and the DNS service in the same rehearsal as the cloud rebuild.

What should you take from this lesson?

List the SaaS services your production environment cannot run without. For each, write down where its configuration is backed up today. A blank in that list is a gap in your cloud DR plan.