Somebody asked me last week who owned a specific Azure tenancy in their organisation.

Three people in the room looked at each other.

Nobody answered.

That's not a horror story. That's Tuesday in most New Zealand health and utilities organisations I walk into.

The Pattern

It always starts the same way.

A project team needs cloud infrastructure. They need it fast. The procurement process is going to take three months and the deadline is in six weeks. So someone — a well-meaning someone, a "just get it done" someone — spins up an Azure tenancy on a corporate card. The project delivers. Everyone celebrates. The tenancy stays.

Six months later, a different team has the same problem. Different project. Same outcome. Another tenancy.

Two years in, the organisation has four tenancies. Maybe six. The person who set up the first one left eighteen months ago. The person who set up the third one doesn't remember which email address they used. Nobody's sure there isn't a fourth one floating around somewhere.

This is the pattern. I've seen it in DHBs, in energy retailers, in local councils. It's not a technology problem. It's an accountability gap wearing a technology disguise.

What It Actually Costs

There's the obvious cost: the Azure invoice nobody's actively watching. Underutilised VMs still running. Storage that was "temporary" and is now in its third year. Reserved instances bought for a project that ended.

The less obvious cost is security exposure.

An unmanaged Azure tenancy is not a neutral thing sitting quietly in the corner. It has credentials. It has service accounts. It probably has connections to internal systems that were configured during the original project and never reviewed. It may have compliance obligations attached to it — particularly in health, where the data sensitivity is genuine and the regulatory requirements are not optional.

I've seen tenancies connected to patient data systems with zero MFA configured. Not because anyone made a bad decision. Because no decision was made at all. The tenancy just kept running. Because nobody turned it off. Because nobody knew they should.

The even less obvious cost is your team's time. Your cloud engineers spend real hours every quarter trying to work out what a tenancy is for, who to talk to, whether they can decommission anything without breaking something else. That's not infrastructure work. That's archaeology. And it adds up fast.

Why It Keeps Happening

The immediate answer is "poor governance." That's true, but it's also useless.

The real answer is that your organisation has never clearly assigned accountability for cloud infrastructure at the tenancy level. You have someone responsible for the IT budget. You have someone responsible for specific applications. You might even have a cloud platform team. But nobody's job is "know what Azure tenancies exist and own the governance of each one."

In health and utilities, this gets compounded by organisational complexity. Mergers, restructures, shared services arrangements — each one can create new tenancies and orphan old ones simultaneously. The people who knew the history leave. The documentation, if it ever existed, doesn't follow them.

You don't find out how bad it is until someone asks the question in a room and three people look at each other.

What Good Actually Looks Like

I'm not going to tell you to buy a Cloud Security Posture Management tool and call it solved. That's a half-answer. It treats the symptom.

The actual fix is ownership. Not tooling.

Assign a named owner to every Azure tenancy. Not a team. A person. With their name on it, their manager aware of it, and a quarterly review in someone's actual calendar.

Create a tenancy register. It can be a spreadsheet. I'm not precious about the technology. What matters is that you can answer three questions for every tenancy in your estate: What is it for? Who owns it? When was it last reviewed? If you can't answer those three questions, you don't have a cloud strategy — you have a catalogue of things you've forgotten about.

Build decommissioning criteria into every tenancy approval. Every tenancy created for a project should have an end date or a sunset review baked into the sign-off. If the project ends, the tenancy gets 30 days to wind down unless someone makes an active case to keep it. Default to off.

Run a discovery exercise this week. Not next quarter. This week. Microsoft has tooling. So does every decent managed service provider in this country. Pull the list of subscriptions associated with your billing accounts. You might find three you forgot about. You might find eight. Either way, you need to know before someone else finds out for you.

A Note on Health

I want to be direct here because I work with a lot of health-adjacent clients.

The Health Information Security Framework is explicit about cloud governance obligations. If you're holding health information in an Azure tenancy that isn't in your information asset register, isn't covered by a data processing agreement, and isn't subject to access reviews — you have a compliance gap. Not a theoretical one. A real one.

The New Zealand health sector is mid-transformation. Health New Zealand is still consolidating accountability structures that were fragmented across the old DHB model. In that environment, ungoverned cloud infrastructure is a liability that compounds every quarter it sits there unaddressed.

The tenancy audit that takes your team a week to run is significantly cheaper than the incident it prevents. That's not a close call.

A Note on Utilities

The exposure is different but the pattern is identical.

In energy and water, the concern is operational technology. Legacy SCADA systems increasingly have cloud connectivity — often added incrementally, often by operational teams rather than IT, often completely undocumented. An Azure tenancy stood up to manage remote monitoring for one substation becomes the bridge between your corporate network and your operational network. That is a very interesting attack surface.

The Stryker incident from March 2026 — where a single compromised global admin account was used via Microsoft Intune to remotely wipe 80,000 devices across 79 countries — is worth sitting with. The attackers didn't need a sophisticated exploit chain. They needed one unguarded management plane and a single set of privileged credentials.

Ungoverned tenancies are unguarded management planes. That's not a metaphor.

One Action You Can Take Today

Log into the Azure portal. Go to Cost Management. Pull the list of subscriptions and tenancies associated with your billing accounts. Cross-reference that list against your configuration management database.

The gap between those two lists is your immediate risk.

If the gap is zero, you're in better shape than most NZ organisations I've seen. If it's not zero, you know exactly what to do next. And you know it can't wait.

Featured Profile