CIS Microsoft Azure Benchmarks: Four Benchmarks, 339 Controls, One Scan

Searching for "the CIS Azure benchmark" suggests there is one document. There are four. CIS publishes separate benchmarks for Azure foundations, compute, database and storage services, each with its own version number and control list. If you scope an Azure review against only the Foundations benchmark, you have covered 127 of the 339 recommendations that ConfigCobra assesses for Azure.

This post lays out what the four benchmarks are, how large each one is, how the controls split across Level 1 and Level 2, and what a scan needs in order to read your subscriptions without being able to change them.

The four CIS Microsoft Azure benchmarks

ConfigCobra covers all four benchmarks in a single Azure scan:

Benchmark	Version	Controls	Level 1	Level 2
CIS Microsoft Azure Foundations Benchmark	v6.0.0	127	74	53
CIS Microsoft Azure Compute Services Benchmark	v2.0.0	99	71	28
CIS Microsoft Azure Database Services Benchmark	v2.0.0	49	27	22
CIS Microsoft Azure Storage Services Benchmark	v2.0.0	64	33	31
Total		339	205	134

The version numbers matter because the benchmarks are versioned independently. Foundations is at v6.0.0 while the three service-specific benchmarks are at v2.0.0, so "Azure v2" or "Azure v6" on its own does not identify a document. Name the benchmark and the version together when you scope an audit.

What Foundations covers

The Foundations benchmark is the broadest of the four. Its 127 controls fall under seven numbered sections:

Section	Controls
2 Analytics Services	12
3 Compute Services	1
5 Identity Services	15
6 Management and Governance Services	24
7 Networking Services	16
8 Security Services	38
9 Storage Services	21

Two things stand out. Security Services is the largest section at 38 controls, nearly a third of the benchmark. And Foundations has only one control under Compute Services, because the detail lives in the separate Compute Services benchmark with its 99 controls. The same pattern applies to storage: the 21 Storage Services controls in Foundations sit alongside the 64 in the dedicated Storage Services benchmark.

Why the split between benchmarks affects scoping

Because there are four benchmarks, the practical questions are about scope:

• Which benchmarks are in the audit? A statement such as "we assess against CIS Azure" is ambiguous. Foundations only is 127 controls; all four is 339.
• Which level? Level 1 across the four benchmarks is 205 controls; Level 2 adds 134 more. Level 2 is the stricter, security-focused profile, so it is the one most likely to need a discussion about impact before anything is changed.
• Which subscriptions? Controls evaluate resources, so a benchmark result is only meaningful against a defined set of subscriptions.

Running one scan across all four benchmarks removes the first question as a source of gaps, because nothing needs to be assembled from separate runs.

What a scan needs: read-only access

The Azure connector is read-only by design and never writes to your Azure environment. The access model has four parts:

• An Entra app registration that authenticates with a certificate, not a client secret.
• The Reader role on the target subscriptions, plus Key Vault Reader for the Key Vault checks.
• A read-only Microsoft Graph policy permission (Policy.Read.All), so identity-related policy settings can be read.
• One tenant per scan, covering either every subscription the app can read or a selected list.

Reader is the role to scrutinise in a security review. It permits listing and reading resource configuration but not modifying anything, which is why it suits an assessment tool. If your organisation reviews every service principal that holds a role assignment, the certificate-based registration and the Reader scope are what you will want to show.

From a failing control to the resource behind it

A benchmark result that says "control failed" leaves you to hunt for the cause. Findings from an Azure scan are per resource: each one points at the exact Azure resource it concerns, so the follow-up is a specific storage account, database or virtual machine rather than a subscription-wide search.

Before you change a setting, remediation impact analysis shows the affected resources and identities, the effect, a confidence level and a preparation step, with an impact level of High, Medium, Low or None. That is the information needed to decide whether a Level 2 control is safe to apply on a production workload. For each finding, ConfigCobra also generates a remediation script or admin portal steps for you to run; ConfigCobra itself does not change your environment.

The Azure resource inventory sits alongside the benchmark results. It lists resources across your subscriptions, including compute, storage, networking, databases, Key Vault, identity and monitoring, together with security properties such as public network access and minimum TLS version. Findings link to the inventory objects they concern.

A practical order of work

1. Decide the scope in benchmark terms: which of the four benchmarks, which level, which subscriptions.
2. Connect the Azure environment with the certificate-based app registration and Reader access.
3. Run the scan, then start with Level 1 findings, which make up 205 of the 339 controls.
4. Use remediation impact analysis on each failing control before you apply the fix.
5. Take Level 2 controls separately, with the owners of the affected workloads involved.

See it on your own subscriptions

The 14-day free trial gives full access to every available module and every control, so you can run all four Azure benchmarks against your own environment. Start a free trial. For the benchmark details, see the CIS Microsoft Azure benchmarks page, read how the Azure connector works, or compare with the CIS Microsoft 365 Foundations Benchmark, which uses the same read-only approach for your tenant.