What We Found
- Azure SQL Databases across multiple subscriptions — none protected by Azure Backup
- Managed Instances — not protected
- SQL Server VMs across the tenant — none protected by Azure Backup
- Every SQL asset in the tenant was unprotected
- The majority of assets were mapped to a named owner via subscription billing data
- An Arc-connected SQL Server that standard inventory tooling couldn't see at all — discovered via a separate Resource Graph query against
microsoft.azurearcdata/sqlserverinstances
How We Did It
The inventory came from Azure's standard resource APIs — SQL Databases, Managed Instances, and SQL IaaS VMs. Cross-referencing Azure Backup vault contents against that inventory is where most engagements stop: protected count vs. total count, gap identified, done.
The harder part was making the gap actionable. A list of unprotected assets isn't useful unless someone can act on it. That meant joining the asset inventory to ownership data to identify who was responsible for each subscription.
What Azure Can and Can't Tell You About Ownership
Azure RBAC Role Assignments surface who has technical access to a subscription — the individuals and groups with Owner, Contributor, or Reader roles. This is useful for identifying who can execute a remediation. But RBAC access and billing accountability are not the same thing.
In large tenants — especially those on Microsoft Customer Agreement — the person financially responsible for a subscription may not hold an RBAC Owner role at all. That accountability is tracked outside Azure: in a CMDB, a designated ownership register, or a billing portal export that doesn't flow back into the resource APIs.
In this engagement, billing accountability data came from an export the customer provided. When we tested whether the same names were surfaceable from RBAC alone, about half matched — the rest were either managed by security groups with no individually visible members, or the billing owner simply held no RBAC role on the subscription they were financially responsible for.
The takeaway: RBAC tells you who has access. Billing tells you who is accountable. For stakeholder routing in a remediation conversation, you usually want billing. We document both in the deliverable and are explicit about which assets couldn't be owner-attributed from Azure alone.
The Bonus Finding
Standard Azure sizing scripts query a specific set of resource providers. Arc-connected SQL resources live under a different one: microsoft.azurearcdata/sqlserverinstances. That resource type doesn't appear in standard VM or SQL inventory tooling.
A separate Resource Graph query against that provider surfaced an Arc-connected SQL Server that had been completely invisible to the customer's own tooling — operationally significant and completely absent from their internal asset inventory. A blind spot they didn't know existed.
That finding was included in the deliverable as a distinct section with the Resource Graph query attached, so the customer could run it on a schedule going forward.
What They Got
A single CSV — one row per SQL asset across the entire tenant. Protection status. Subscription name. Named owner where attributable, explicit notation where it wasn't. Ready to be forwarded to each owner as a remediation task with no additional triage required.
The value isn't the spreadsheet. The value is that it took one session to produce something the customer's internal teams hadn't produced in years of running the environment — and it came with ownership attached so it could actually go somewhere.
Tech Stack
This engagement was conducted as part of a broader data protection assessment. Client details have been generalized. The methodology and tooling are identical to the open-source Azure SQL Protection Audit available on GitHub.