The Map Is the Missing Control: GIS in Risk and Resilience

Category: Operational Resilience Author: Cody Swidler Tags: GIS, geospatial risk, concentration risk, business continuity, cloud regions, BIA, third-party risk

A firm I worked with had a beautiful continuity program. Every critical process had a documented recovery site. Every recovery site had been tested. The BIA named a primary and an alternate for all of it, the alternates were all in different buildings, and the whole thing had sailed through two external audits without a finding. Then somebody put the addresses on a map for an unrelated reason — a facilities project, not a risk one — and it turned out that eleven of the "geographically separated" recovery pairs were inside the same twelve-mile radius. Same power utility. Same flood plain. Same three highways. The register had been telling the truth the entire time. Primary in one building, alternate in another. Both fields correctly populated, both distinct, and the distinction meaningless.

Nothing in that program was dishonest and nothing was lazy. The failure was structural. Geography had been stored as text, and text does not compare. "1200 Riverside Drive" and "45 Commerce Way" are two different strings, so any system holding them will report two different locations, and any auditor reading them will see separation. Only a coordinate knows they are four miles apart. This is the whole argument for treating geospatial data as a first-class citizen in a risk program, and it is why I have come to think of the map less as a reporting artifact and more as a control in its own right — the one that catches the correlation your registers are structurally incapable of seeing.

Your Register Cannot Detect Correlation

Risk registers are built as lists of independent rows. That framing is useful for accountability — one risk, one owner, one rating — and it is precisely wrong for the thing that actually hurts you. Real losses cluster. The flood does not take out one facility; it takes out everything downstream of the same river within a day. The regional power event does not degrade one vendor; it degrades every vendor whose data center sits on that grid, plus your own office, plus the call center you outsourced to keep costs down. A register scores each of those as a separate row with a separate likelihood, and the arithmetic quietly assumes independence that does not exist.

I have written before about fourth-party risk and concentration, and geography is the same problem wearing different clothes. When four of your critical SaaS vendors all run in us-east-1, you do not have four vendor risks — you have one region risk with four names on it. When your payroll processor, your document signing platform, and your identity provider all failed over to the same secondary region, your carefully diversified vendor portfolio has a single point of failure that appears nowhere in the vendor register, because no single row is wrong. The concentration lives in the relationships between rows, and a list is the one data structure that cannot represent relationships between rows.

A coordinate system can. The moment every site, vendor, hosting region, and recovery target carries a latitude and longitude, "how many of our critical processes recover into the same metro" becomes a query rather than a research project. So does "which of our tier-one vendors sit inside the flood zone that is on the news this morning," which is the question every executive asks during an event and almost no program can answer inside an hour.

What Actually Goes on the Map

The instinct when people hear "GIS" is to reach for a mapping platform and a consultant, and that is usually the point at which the project dies of ambition. The useful version is smaller than that. You need four layers, and three of them are data you already have, stored badly.

The first layer is your own footprint — offices, data centers, operations hubs, call centers, and anywhere staff physically are during a business day. Most firms have this in a facilities spreadsheet that nobody in risk has ever opened. The second is your recovery targets, which live in the continuity plans and, as the story above illustrates, are the layer most likely to contain an unpleasant surprise. The third is your third parties, and specifically not their headquarters address, which is what vendor registers usually capture and which is close to meaningless. What matters is where the service is actually delivered and hosted — the cloud regions, the processing centers, the offshore delivery sites. That distinction between the legal address and the operational location is the single most common data-quality gap I see, and it is worth the effort to close before anything else.

The fourth layer is the outside world: hazard exposure, seismic and flood zones, and the live event feeds that tell you what is happening today. That is the layer everyone wants to start with because it is the visually exciting one, and it is the one that delivers the least value on its own. A map of global earthquakes is a news product. A map of global earthquakes with your facilities on it is a risk product. The external data is only worth anything once the internal layers are underneath it, which is the reverse of how these projects usually get sequenced.

Precision matters less than people fear here. You do not need survey-grade coordinates, and for cloud regions you cannot have them anyway — hyperscalers publish a metro, not a building, and a region is several availability zones spread across that metro regardless. Metro-level accuracy answers nearly every question a resilience program actually asks. It will tell you that your primary and alternate are in the same city. It will not tell you they are on the same substation, and if you need that answer you are in a different and much more expensive conversation.

The Questions That Only a Map Will Answer

Once the layers exist, a specific set of questions becomes cheap that were previously impossible, and each one tends to change a decision rather than just produce a slide.

The first is separation distance between every primary and its recovery target, computed rather than asserted. Almost every continuity program claims geographic diversity somewhere in its documentation. Very few have ever calculated it, and the number of pairs that turn out to sit inside a common hazard radius is reliably higher than the team expects. This is a two-hour exercise once the coordinates exist, and it has ended more comfortable assumptions in my experience than any tabletop I have run — though the tabletop is still where you find out whether anyone can act on the finding.

The second is vendor concentration by region rather than by name. Sorting your third-party inventory by hosting region instead of alphabetically produces a chart that most executives have never seen and immediately understand. It reframes vendor diversification from a procurement metric into a resilience one, and it makes the DORA and operational-resilience conversation about substitutability concrete rather than theoretical — which is the same point I make in DORA is not an IT problem.

The third is exposure overlay: which parts of the estate sit inside a hazard zone that matters. This one has to be handled with discipline, because it is where geospatial work most easily slides into decoration. A heat map of global cyclone frequency is not a finding. "Our transaction processing recovers into a metro that has had two named storms make landfall within fifty miles in the last decade, and our RTO assumes staff can reach the building" is a finding, and it belongs in the risk register as a row with an owner.

The fourth is the live one — during an actual event, the ability to filter your own footprint by proximity to what is happening. The value here is almost entirely about speed. The information usually exists somewhere; the problem is that assembling it takes four hours and six people, and the incident commander needed it in the first fifteen minutes. Pre-built geography is what converts that from an investigation into a lookup, which is exactly the argument for treating it as incident command infrastructure rather than as analysis.

Where the Cloud Changes the Shape of the Problem

There is a version of this that is specific to how software actually runs now, and it deserves separating out because it breaks a lot of received continuity wisdom. When your estate was buildings, geographic risk was intuitive — you could drive to it. When your estate is regions, the geography is real but invisible, and almost nobody in the risk function can tell you where eu-west-1 physically is or which of your systems depend on it.

That invisibility produces a specific failure. Teams architect for availability-zone redundancy, document it as resilience, and never notice that zone redundancy protects against a rack or a building and does nothing whatsoever about a regional event. Multi-AZ is a very good answer to a hardware question and a non-answer to a geography one. Multi-region is the answer to the geography question, and it is meaningfully more expensive, which is why the decision gets made by an architect on cost grounds and never surfaces to anyone accountable for the recovery objective. Putting the regions on a map is a blunt but effective way of dragging that decision into the light, because it makes the single-region dependency visually obvious to people who will never read the architecture diagram.

The other cloud-specific gap is between what a provider tells you and what you can verify. Every hyperscaler publishes a status page, and those pages are the authoritative source for whether a region is healthy. But they are all built for a human reading one provider at a time, and the concentration question spans providers. Nothing in AWS's dashboard knows that your identity provider runs on Azure. Assembling the cross-provider view is unglamorous integration work, and it is the difference between knowing that a region is degraded and knowing what that means for you.

It is also where I would offer a warning about data honesty, because it applies well beyond mapping. Some of these feeds are readable by a browser and some are not, for ordinary technical reasons. When you build a dashboard that mixes live data with stale data with data you inferred, the discipline that matters is labelling which is which — every panel saying where it came from and when it was last true. A dashboard that shows a green light because the feed failed silently is worse than no dashboard, because it converts an absence of information into a false assurance. I built the PivotRisk risk intelligence map partly to demonstrate that principle: every signal on it names its publisher, and the two providers whose feeds cannot legitimately be read from a browser are shown as link-outs rather than dressed up as live.

Keeping It From Becoming a Wall Display

The failure mode for geospatial risk work is not technical. It is that you build something genuinely beautiful, it gets shown at a steering committee, everyone agrees it is impressive, and then it is never opened again. I have watched this happen more than once, and the pattern is consistent: the map was built as a visualization rather than as an input to a decision that someone was already required to make.

The fix is to attach it to an existing obligation rather than creating a new ritual around it. Separation distance belongs in the business impact analysis as a computed field, so that it gets refreshed on the BIA cycle whether anyone finds it interesting or not. Region concentration belongs in the vendor review, as a standing question with a threshold attached, which makes it a risk appetite conversation rather than an observation. Live hazard proximity belongs in the incident runbook as a step, not as a tool someone might remember exists. Each of those has an owner and a cadence already; the geography just becomes a column in something that was going to happen anyway.

That is also the honest test of whether this work was worth doing. Not whether the map looks good in a board pack, but whether a coordinate has ever changed a decision — a recovery site relocated, a vendor's hosting region renegotiated, a multi-region spend approved that would otherwise have been deferred. If a year in you cannot name one, you did not build a control. You built a wall display, and the eleven recovery pairs in the same flood plain are still sitting there, correctly documented in two different fields, waiting.