Exceptions are part of governance, not a failure of it

There’s a public storage account behind the company website. There’s a legacy VM that can’t be patched until the vendor ships a new version. There’s a test subscription where the backup policy deliberately doesn’t apply.

None of these is a mistake. All of them will show up in any posture scan, every time, forever. What happens next is where governance usually breaks down.

Muting is not deciding

When a tool can’t record a deliberate deviation, people do the next best thing: they mute it. They dismiss the alert, filter out the rule, or learn to ignore that line in the report.

It works until it doesn’t. A muted finding has no reason attached, no owner and no end date. Six months later nobody remembers why it was muted, and the rule that was switched off for one storage account is now quietly hiding three more. The dashboard turns green, and the green means less every week.

What a proper exception contains

An exception is a decision, so it needs what any decision needs:

• A scope. Exactly which resource, resource group, subscription or tagged set of resources it covers, and nothing beyond that.

• A reason. Written down, readable by the next person.

• An owner. Who approved it.

• An expiry date. Every exception should be reviewed eventually. The best way to make sure that happens is to make it lapse.

When an exception expires, the finding should come back by itself. Then “temporary” stays temporary without anyone setting a reminder.

Declaring exceptions where the infrastructure lives

Many teams manage Azure through infrastructure as code. For them, a portal-based approval flow is a second place to keep in sync with the first. So there’s a second way: declare the exception on the resource itself, as an Azure tag.

praefic.exempt.NET_NSG_OPEN_SSH = until=2026-12-31;ref=CHG-1234;reason=Bastion host, IP-restricted upstream

The exception is created in the same pull request as the resource. The people who review the infrastructure review it too, and it’s deployed and rolled back along with the resource. Remove the tag and the exception goes with it.

Two details matter more than they seem:

• Tags don’t cascade. A tag on a subscription doesn’t silently exempt every resource inside it. Azure itself has no tag inheritance, and inventing one would let a single tag silence findings on resources whose owners never saw it. Broader exceptions are approved explicitly instead.

• A typo is reported, not ignored. If the rule code in a tag is misspelled, someone believes they’ve signed off a finding when they haven’t. That gets flagged rather than quietly ignored.

Being honest about the score

There’s one more thing a good exception model should do: admit what it’s doing to your numbers.

An excepted finding counts as handled, which is correct, because a risk you’ve knowingly accepted is not an open gap. But that means a compliance level can read 100% while resting partly on sign-offs. That’s a fact a manager deserves to see, not one to tuck away. A good governance tool shows both numbers: how much is clear, and how much of that is clear only because of an exception.

How Praefic handles it

Praefic supports both routes in one model:

• Exceptions approved in the app, scoped to a resource, resource group, subscription or tag selector.

• Exceptions declared as praefic.exempt.* tags, picked up on every scan.

Both kinds carry a reason, a reference and an expiry. Expired exceptions lift automatically. Signed-off findings are kept separate from findings muted by hand, so you can always tell a decision from a shortcut.

Exceptions aren’t a failure of governance. Unrecorded exceptions are.

Praefic is built by Just Software.