A public-safety support team's 911-adjacent SaaS tools live in a third-party cloud but never appear on BIA dependency maps. What mapping correction is required?
Select an answer to reveal the explanation.
Short Explanation
If your flashlight only works when the neighbor's porch light is on, that neighbor is part of your plan. Cloud SaaS behind 911 support is still a dependency. Put those external providers on the map so outages are not a surprise.
Full Explanation
Critical public-safety support functions often depend on external cloud and SaaS providers whose failure produces the same operational impact as internal outages. 911-adjacent tools that never appear on BIA dependency maps leave recovery planners blind to third-party concentration and outage paths. Adding external provider services that critical functions rely on to the dependency maps is the required correction for municipal continuity analysis.
Mapping only on-premises servers so cloud providers stay outside continuity analysis is an outdated boundary that ignores where the work actually runs. Assuming SaaS vendors need no BIA attention because contracts guarantee perpetual uptime confuses marketing and contract language with impact reality. Deleting external services from dependency lists to simplify executive summaries hides material risk for readability.
Exam caveat: external SaaS dependencies belong in BIA maps when functions depend on them. “Cloud” does not mean “out of scope.”
Operational check: inventory SaaS and cloud services behind public-safety support workflows; add provider names, criticality, and known RTO/RPO commitments to the BIA; include provider outage scenarios in the next continuity discussion with leadership.