What the audit covers

The audit is free: a working session with your team plus a written report identifying savings opportunities in your Azure estate. Every finding carries the same six decision fields, set out in reading your audit report.

The audit lifecycle, free and with no commitment. A single cyan Infralign band — marked read-only and not a rules engine — spans a time axis of nightly, week one, and after the session, and holds three cards. First, a bar-chart card: step 1, read nightly and read-only, step 2, six detection types, tagged automated. Second, a card carrying a person icon: step 3, findings sized and prioritised, step 4, a working session with your team, tagged done by a person — this is the expert-led half of the audit, not a rules engine. Third, in green, a document card: step 5, the prioritised report, tagged what you leave with. A strip beneath lists the six fields every finding carries: euro impact, evidence, owner, effort, risk, next action. — Figure 1 — Detection is automated, but the audit itself is expert-led — a senior architect sizes and prioritises every finding before it reaches your report.

What the audit surfaces

The six detection types in step 2 of figure 1 are set out in full below.

Category	Signal	Threshold	€ basis
Idle VMs	30-day rolling p95 CPU, with an idle-day count	p95 CPU under 5%	The spend the idle VMs carry
Rightsizing	30-day p95 CPU utilisation, with a confidence level per candidate	—	The saving on each shutdown or resize candidate
Reservations and Savings Plans	Commitment coverage per pool	60% coverage target	The € left on the table where coverage is thin
Orphaned disks	Managed disks with no attached VM, still billing	—	What those disks still charge
Log optimisation	Over-provisioned logging and retention that can be trimmed without losing signal	—	The logging spend the trim releases
Azure Hybrid Benefit (AHB) licensing	Eligible Windows and SQL workloads not yet claiming the benefit	—	The licensing saving the benefit delivers

How the evidence is built

A rightsizing recommendation drawn from billing data alone is a guess. The audit enriches Azure Advisor’s recommendations with the platform’s own signals — 30-day p95 CPU from Azure Monitor, idle-day counts, resource inventory from Azure Resource Graph — so every finding is checked against how the resource is actually used before it reaches your report. Advisor is an input, not the output: its recommendations are filtered against your actual spend and context rather than passed through raw.

The senior Azure architect running the engagement then reviews each candidate against your architecture and policy constraints (step 3 in figure 1).

What you need to provide

Azure connected, and the working session. Billing and resource metadata alone support a meaningful audit, and ownership attribution improves progressively as more context is correlated.

What the audit is not

It is not a penetration test, a general architecture review, or a compliance assessment. It is a cost audit with architecture context. If you choose, the next step is an engagement where the approved fixes are prepared and merged.

Next: Reading your audit report — the six fields on every finding, and how to prioritise them.