Tackling Natural Disaster and Climate Risk at Enterprise Scale

This customer story has been adapted from a fireside chat with IAG (Insurance Australia Group) at “Mapped for Impact”, a geospatial breakfast hosted by CARTO and Google Cloud in Sydney in June 2026.

What is SAM?

Our first project together — our first foray into getting CARTO into IAG — was to deliver on a specific use case: our situational awareness mapping, or SAM. We've been quite public about it, and it's even been on mainstream media; Channel 9 News has done a piece on our command center.

As an insurer, we don't just price risk. Pricing is a key component, but we have to be able to deliver on our promise as well. That means when an event happens, we're able to respond and support our customers through that event and the recovery. Last year alone there was $3.2 billion worth of damages from extreme weather, so this is a real problem for us and for Australia.

We need data to give us the ability to make decisions quickly. Where are we hit hardest? Where should we send our assessors and builders? Should we be worried about this event because it's impacting our portfolio? Should we be giving people temporary accommodation? All of those questions are driven off our data in Google Cloud — and being able to see that visually and interact with it, especially in a command center setting, was really important. It let our executives and our response teams work collaboratively, because they all had access to the same information.

Why CARTO, rather than a standalone app

The reason we brought CARTO in, rather than building a separate standalone app, is that SAM is one use case. There are many use cases for geospatial visualization and geospatial analytics in an insurance setting.

That could be how many buildings on an agricultural property we need to insure when one of our people is out in the field talking to a customer. It could be where our biggest opportunity for portfolio growth is. It could be visually verifying our data in a test setting. It could be asking a question of our data insights agent and seeing what that data actually looks like geospatially.

We knew SAM wasn't going to be a one-time-only map. We needed the ability to quickly deploy mapping applications and extend our geospatial capability on BigQuery, and CARTO was chosen for that.

How SAM is used when an event hits

It's been operational for about a year and a half now, and it's been tried and tested through many events in that time. There are always improvements to be made. Initially SAM was created as an application people go to in order to find information; we want to flip that, so SAM becomes more proactive — alerting, notifying and sending information out, rather than waiting to be visited.

Any mapping or geospatial application is only as good as the data behind it. We've been fortunate to invest in our data products and move them into BigQuery to make them accessible and scalable across the business. I look after all of our physical assets and the data about the world around them: where every single property in Australia is, whether it's agricultural, residential or industrial, what buildings are on that property and where those buildings are, what the property boundary is, what events are hitting that property, and how we've risk-modeled and scored it. All of that information is inherently geospatial.

We make that available in SAM and overlay it with who our customers and policy holders are, and which of them have made claims. We have a command center in our Hurstville office, where the majority of our claims team sit, with a floor-to-ceiling screen showing SAM. It shows the event as it's tracking — a bushfire, a cyclone, a flood, a hailstorm — and who is being impacted: how many of our policy holders are affected, who has claimed, who is yet to make a claim. Those decisions feed back into our insurance and claims platforms to drive where we send assessors, who we call, who we door knock, and how we help people through what could be one of the worst moments of their lives.

Before BigQuery: a siloed geospatial stack

We've had a geospatial team managing geospatial data for a long time — that was one of the teams I led previously. Back then we had a siloed geospatial data store, because our on-premise data lake had no geospatial indexing and we couldn't put geospatial data in it. We had our own setup around a web server serving Postgres data, and it needed specialist geospatial people to manage it.

The concept of SAM isn't new for us; we've been doing this forever. What was different was the manpower it took. An event would happen and we would have to manually go in, create all the data, create the maps and deploy them onto our web server — and only one or two people knew how to do that. It could be a day or two before we could get anything meaningful to the business.

From days to on demand

Once we moved to Google Cloud and had our data in BigQuery, that was the moment to ask how we were going to serve geospatial needs in BigQuery. The use cases were endless: we want to use asset data across the insurance value chain, not just within a specific area like pricing or claims. That's when I started exploring with Google what our best option would be for deploying geospatial capability.

For SAM specifically, we just couldn't have teams waiting days for data. It's not okay in this day and age. We needed something on demand, with data flowing into BigQuery in near real time and the ability to run queries that say this property was impacted by this event and has had this claim. There's no longer a team of one or two people working nights to pull maps together.

It also means we're not only using the technology when a major event hits. It might be a burst water main in Como affecting customers, or a fire at an industrial warehouse — is that one of our policy holders, and do we need to get in touch with them? Because it's on demand and always available, it's now used much more broadly than for major events alone.

How it's built

Number one, you have to have your data organized and available. Get your data into BigQuery and make it available so it can be consumed by anything — whether that's CARTO, an agent, or something else.

We've organized our data into data products. I'm the product manager for our asset data; we also have product managers for claims, for policy and for customer. Being really clear on ownership, and curating accurate, timely, well-governed data within our strategic data platform, is the key. Then we can do the fun stuff, like putting CARTO over the top of it.

When we started thinking about CARTO, our risk appetite at the time was to take a self-hosted approach rather than the SaaS version. That appetite has probably shifted since, as we've become more comfortable working in Google Cloud — but self-hosting also lets us customize. So it's self-hosted for now, running on Google Kubernetes Engine, with the intention that we might move to SaaS one day.

We've set it up so different users have access to different data. If you're in pricing you may have a separate service account with access only to pricing data, not customer data. If you're in claims, you're only allowed to see certain data or create certain types of maps.

The hard part isn't the technology

We had a lot of governance gates to go through when we deployed CARTO. If anyone's using agents for coding and AI-assisted coding now, it's getting really easy to do analysis and data prep pipelines — that's the easy stuff. The hard stuff is the governance gates, organizing funding, alignment with programs, and all the extra work that comes with doing it in a safe and responsible way, so that we're not on the news tomorrow for a breach of some sort. That's still the hard part.