Level 1, 2, 3: building a governance baseline you can actually reach

The first time an organization runs a full security benchmark against its Azure estate, the result is almost always the same: a wall of red. Hundreds of failed controls, spread across every subscription, sorted by severity, all apparently urgent.

It’s accurate, and it’s nearly useless as a plan. Nobody can work on four hundred things. So teams pick a few at random, make some progress that doesn’t show up in the total, and the report gets opened less each quarter.

Start with the checks that matter most

The alternative is to stop treating governance as one pass/fail exam and build it as a ladder.

Level 1 is a short list of checks every environment should pass, chosen because they’re high-impact and usually cheap to fix:

• No storage accounts open to the public internet without a reason.

• No management ports such as SSH or RDP exposed to the world.

• Key Vaults protected against accidental deletion.

• No standing privileged access that nobody actually uses.

• No orphaned disks, IPs and network interfaces quietly costing money.

Level 1 should be small enough that a team can finish it in weeks, not quarters. Finishing matters. It’s the first time the report has said “done” about anything.

Level 2 adds the next tier, such as backup coverage, diagnostic settings, end-of-life runtimes and TLS versions. Level 3 goes further toward a full benchmark. Each level includes everything below it, so moving up never means losing what you’ve already achieved.

Why levels beat one big score

A single estate-wide score is a fine headline. As a working target it has a flaw: it moves with everything at once. Fix twenty important things while forty new test resources arrive, and the score drops. The team did the right work and the number punished them for it.

A level asks a narrower question: of the checks we agreed matter, how many are clear? That number is stable and comparable, and it belongs to the team. It’s also something you can report upward without a page of caveats: “Level 1 is at 94%, up from 61% at the start of the quarter.”

Your history shouldn’t start the day you define a level

The usual problem with defining a new target is that it has no past. You create a level today, and the chart starts today with a single dot.

It doesn’t have to work that way. A level is only a set of checks. If the scan history keeps a record of which checks were failing on each day, a new level can be applied to that history straight away. Define Level 2 this afternoon and see how the estate would have scored against it over the past months.

The same applies when you edit a level. The whole line is redrawn under the new definition, so the trend always compares like with like. Days with no scan data are left as gaps, not drawn as zero, because a day nobody measured isn’t a day everything failed.

Building the ladder in Praefic

In Praefic, levels are presets you define yourself. Each one is a named set of checks drawn from the rule catalog, and each can build on the one below. The catalog covers 19 areas of Azure:

• Network, identity and privileged access (RBAC and PIM)

• Key Vault, Defender for Cloud, backup and storage

• Virtual machines, App Services, databases and containers (AKS, Container Registry, Container Apps)

• Cost and budgets, the activity log and AI model lifecycle

Every level shows how many of its checks are clear today, how many are clear only through an approved exception, and how that has changed over time, replayed across your full scan history.

You can’t fix four hundred things this quarter. You can finish Level 1.

Praefic is built by Just Software.