The audit
Reading your audit report
How each audit finding is structured — € impact, evidence, owner, effort, risk, next action — and how to prioritise them.
Your audit report lands in a fixed sequence. Candidate findings generate automatically during your first week, and the architect sizes and prioritises them. The working session then reviews them with your team. The report lands on the in-app Audits page after that session — typically still within week one of connecting. It is a prioritised list of savings opportunities, each one specific enough to act on or to reject with a reason.
Click any image to enlarge.
Anatomy of a finding
Section titled “Anatomy of a finding”
Each finding carries the same six fields.
| Field | What it tells you |
|---|---|
| € impact | The estimated monthly saving, in euros, from your actual billing data and Azure pricing (including Reservation and Savings Plan pricing where relevant). Not a percentage of a guess. |
| Evidence | The cost lines, the utilisation signal (30-day p95 CPU, idle-days), and the resource configuration that makes the case. An idle-VM finding shows the p95 CPU under 5% and the idle-day count; a rightsizing finding shows its confidence level. Verify every claim against your own dashboards. |
| Owner | The team or person best placed to approve the change. Where tagging is thin, owners are proposed from resource context and confirmed in the working session. |
| Effort | What implementing the change actually involves, including any application code changes, so you can weigh saving against engineering time. |
| Risk | The blast radius if the change misbehaves, stated plainly. Every finding is reviewed against your architecture and policy constraints, but residual risk remains and the report says what it is. |
| Next action | The concrete step that moves the finding forward: approve it, gather one missing piece of evidence, or park it with a review date. |
How to prioritise
Section titled “How to prioritise”
- Sort by € impact first, but read effort and risk before committing. A €40K/year finding needing one config change beats a €60K/year finding needing an application rewrite.
- Confirm owners in the working session. A finding without an accepted owner stalls regardless of its number.
- Take one or two low-risk, high-confidence findings first. Early verified savings build the trust the larger findings need.
Disagreeing with a finding
Section titled “Disagreeing with a finding”Findings are evidence-based, and evidence can be incomplete — the platform may not know that a resource is oversized deliberately ahead of a launch, or kept for a contractual reason. Say so. Context you add during review sharpens attribution for everything that follows.
From findings to fixes
Section titled “From findings to fixes”Approve or reject each finding in the app. In an engagement, an approved finding becomes a change plan prepared by the senior Azure architect and merged by your team through your own pipeline.
Next: Validated fixes — how an approved finding becomes a verified saving.