Reading your audit report

Sort findings by euro impact. Read effort and risk before you commit to any of them.

The report is a prioritised list of savings opportunities, each one specific enough to act on or to reject with a reason.

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).
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.
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.

When the report arrives

Candidates generate during your first week, and the architect sizes and prioritises them. The report reaches the in-app Audits page after the working session, in week one of connecting.

How to prioritise

1. 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.
2. Confirm owners in the working session. A finding without an accepted owner stalls regardless of its number.
3. Take one or two low-risk, high-confidence findings first. Early verified savings build the trust the larger findings need.

The report sequences that order for you as a 90-day plan: reversible actions first, renewal-timed moves last.

NovaPulse is a real Azure estate with its identifiers replaced. The plan above is that estate’s, at that estate’s scale.

Tip

Parking a finding costs you nothing. The underlying data keeps flowing, so you can pick it up months later against fresh numbers, and nobody has to re-audit the estate to get them.

Disagreeing with a finding

Tell us when a finding is wrong. Infralign may not know that a resource is oversized deliberately ahead of a launch, or kept for a contractual reason. Context you add during review sharpens attribution for everything that follows.

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.

Validated fixes follows one approved finding all the way to a verified saving.