In Part 1, SELL! shipped a reference landing zone without mapping the workload. This field note picks up after the cutover scars: the deny policies meant to protect the platform become the reason teams stop using it.
SELL! is a fictional company. Any resemblance to a real platform team’s war story is the point.
Setting the Scene
Week nine at SELL!. The lending workload is mostly in Azure. The CEO still wants “cloud first” on the board slide. Security has one ask after the migration near miss:
“Lock it down. No more surprises.”
The platform team does what fearful teams do under a compliance mandate. Every default Azure Policy that can deny, denies. Public IPs: deny. Unapproved SKUs: deny. Missing tags: deny. Subscription requests need the security architect, the network lead, and, if the form looks interesting, the CISO.
Deny first. Exceptions later. The board wants proof of control.
- Root deny initiatives from the accelerator are left on.
- Three person approval for every subscription request.
- No exception register. Escalate if blocked.
- SaaS purchases stay outside the platform team's remit.
The Pilot: The Guardrails Work Perfectly
On paper, governance has arrived. In a market the size of New Zealand’s, there are fewer people, fewer central teams, and far less tolerance for process friction.
For six weeks the dashboard stays green. No public IPs. No unapproved SKUs. No exception tickets. Security reports “lockdown complete” to the CEO.
What nobody says: no workload team has asked for anything new. The lending app is still living on the exemptions from cutover. The guardrails have not met a request. They have only met silence.
The denies are live. Nobody has asked for a new environment yet.
- Policy compliance reports are clean.
- The subscription request queue is empty.
- Cutover exemptions are still carrying the lending app.
- The bureau rewrite has not been filed.
The Path Nobody Designed
Then the product team needs a sandbox for the bureau integration rewrite. They fill in the form. A release date does not wait with them.
So they do what NZ teams are famous for: they get pragmatic.
| Symptom | What to do instead |
|---|---|
| Workload teams route around you. Shadow subscriptions via the enterprise agreement, resources deployed through personal accounts, or SaaS bought because it was faster than IT. Classic shadow IT . | Start with audit mode , not deny. Ship golden paths so the compliant route is the easiest. Measure time to
deploy a compliant workload, not policy count. References: Why Landing Zones Fail · CAF: Governance design area · WAF: Security |
Post-Hardening: The Cracks Widen
Once the sandbox is stuck, the workarounds become how work gets done.
Workaround Issues
Developers share credentials, test in production adjacent sandboxes nobody tagged, or click Deploy in the portal with a personal account because the pipeline path takes too long.
SaaS Issues
Marketing buys a CRM. Ops buys a monitoring tool. Personal and credit adjacent data now sits in services never assessed under the Privacy Act 2020 or the Credit Reporting Privacy Code. Governance that only covers Azure is incomplete.
Escalation Day: The Agency Questionnaire
An NZISM questionnaire arrives with the agency pilot. The cracks are already wide. Tui, the compliance lead, asks for the exception register. There is not one.
The Mandate Nobody Questioned
The landing zone at SELL! was commissioned under pressure: board deadline, migration scars, a security mandate that said “lock it down.” The team that received that mandate inherited its fear. Fearful teams build deny first governance.
There is also a skills gap. Writing an effective Azure Policy is hard. Writing a hard deny is trivial. Under time pressure, teams ship deny policies they cannot reverse and do not fully understand, then spend months unpicking the ones that blocked legitimate work.
Audit first is the default. It is not a religion. A small set of denies belong on day one: public network access to storage that holds personal or credit information, controls that disable logging, and anything else that is a data exfiltration vector rather than a convenience rule. Those are hard stops. Everything else earns its deny after you have watched it in audit.
| Symptom | What to do instead |
|---|---|
| Policies arrive as deny on day one. Legitimate work fails. Exceptions pile up through escalation. Nobody measured what the denies would have blocked in the real estate. | Deploy every new control as Audit for one or two sprints. Learn which denies would block real work,
which controls nobody needed, and what the baseline actually looks like before you harden. References: Azure Policy effects · CAF: Governance design area · WAF: Security |
Operations: The Missing Exception Register
Exceptions already happen. They just happen as favours. Someone’s manager escalates to your manager. There is no SLA, no documented assessment, and no named risk acceptor: the person accountable for accepting residual risk. When Tui needs evidence, the answer is a Slack thread and a hallway conversation.
The Lessons We Can Learn
Nothing about having policies was wrong. What was wrong was treating governance as a tollbooth instead of a product with users: the workload teams.
Measure the Right Metric
The metric that matters:
Time from “team needs an environment” to “team has a compliant, deployable environment.”
Target it in days. Publish it. Improve it. That single number is the health indicator of your governance product.
Build Golden Paths, Not Gatekeepers
For a NZ organisation, the highest leverage move is subscription vending with pre approved patterns. Start with the CAF landing zone reference implementation, or a thin Terraform or Bicep wrapper around it, rather than inventing vending from a blank subscription.
- A team requests an environment through a form or pipeline
- They receive a subscription configured with correct management group placement, baseline policies (NZISM informed where relevant), budget alerts, mandatory tags, network integration, and logging wired to the central workspace
- Total time: hours, not weeks
Now the fastest path is also the compliant path. The deny policies that remain are few, well understood, and defensible.
| Symptom | What to do instead |
|---|---|
| Environment requests take weeks. The compliant path is slower than a personal subscription or a SaaS credit card. | Automate subscription vending. Pre bake the guardrails. Publish time to compliant environment as a
product metric and treat every week of delay as a defect. References: CAF: Subscription vending · CAF: Platform automation and DevOps · WAF: Operational Excellence |
Make Exceptions a Risk Decision, Not a Favour
Establish a formal exception register with:
- A defined SLA (for example, five business days) for review
- Documented risk assessment against the applicable framework (NZISM profile, Privacy Act impact, Credit Reporting Privacy Code where credit information is in play)
- Expiry dates. Exceptions that live forever are policies that do not exist
- Named risk acceptors, each one a person who can own residual risk in writing
When Tui’s agency questionnaire arrives, the register is evidence of a functioning control environment. That is worth real money in an NZ market where enterprise deals routinely hinge on security questionnaires.
Remember the SaaS Blind Spot
Governance that only covers Azure is incomplete. Privacy Act obligations cover personal information in every SaaS tool the business has bought. A lightweight approval path, faster than buying rogue, looks like this:
- Run shadow IT discovery first so you have an inventory before you write a form
- One named approver, with an SLA of 48 hours, for anything that will hold personal or credit information
That path is part of the landing zone story whether the platform team likes it or not.
Nothing about needing guardrails was wrong. What was wrong was the order and the product design: deny first, exceptions by escalation, no published path that made compliance the easy choice.
| What they did | Should have done |
|---|---|
| Turned accelerator defaults into root denies after the migration scare. | Run new controls in audit mode for one or two sprints before any deny. |
| Measured success by number of policies enforced. | Published time to a compliant, deployable environment and improved that number. |
| Made subscription requests a three person approval queue. | Stood up subscription vending with pre approved patterns so hours beat weeks. |
| Granted exceptions only through manager escalation. | Ran an exception register with SLA, named risk acceptor, expiry, and framework mapping. |
| Left SaaS purchases outside governance until the questionnaire arrived. | Offered a SaaS approval path faster than buying rogue, covering Privacy Act scope beyond Azure. |
The Moral
A landing zone’s policies are not the product. The product is a path workload teams will actually take. SELL! built a wall, then discovered that New Zealand teams walk around walls.
In a market this size, your platform team’s reputation is a real asset or a real liability. The organisation will talk, in stand ups, at meetups, across the corridor. Be the team that made the right thing easy.
The test: can a two person team inside your organisation get a fully compliant production environment in under a week? If not, you do not have governance. You have a tollbooth.
Before you add another deny, publish your time to compliant environment and your exception SLA. If either number is blank, product design is the work, not more policy. If you want that work structured as an engagement, see Fractional Cloud Architecture and Advisory.
One Block · build from here