CIS Benchmark drift
The CIS Foundations Benchmarks are the security community's consensus definition of a well-configured cloud account, published separately for AWS, Azure, and Google Cloud and revised on a regular cadence. Each benchmark is organized into sections — identity, logging, monitoring, networking, and storage — and each recommendation carries a profile level (Level 1 for a practical baseline, Level 2 for defense-in-depth that may trade some functionality) and an assessment status (Automated recommendations a tool can score, and Manual ones that require human verification). Drift against this baseline happens two ways: a real regression, where a setting that once passed is changed by hand and no longer conforms, and version drift, where the account is unchanged but a newer benchmark release adds, renumbers, or tightens controls the estate is no longer being measured against. This page is about measuring both — scoring every account, subscription, and project against the current benchmark at the right profile, and turning the pass/fail output into a ranked plan rather than a flat report. The assessment reads configuration through each provider's own APIs; it never changes a setting, so the output is a measurement of posture, not an action against production.
Overview
What this check looks like in practice
The CIS Foundations Benchmarks are the industry's consensus baseline for a securely configured cloud account, and every estate drifts away from them over time as teams ship. We measure each account, subscription, and project against the relevant benchmark and separate the deviations that create real exposure from the ones that are noise. The goal is not a perfect score — it is knowing exactly where you stand and which gaps to close first.
Why it matters
A CIS benchmark score is one of the first artifacts an auditor or cyber-insurer asks for, because it is a recognized external yardstick that shows security is measured rather than asserted — and a stale or partial score is worse than none, since it signals conformance the environment no longer has. The most dangerous gaps are the quiet ones: Manual recommendations that automated tooling silently skips, so a control shows neither pass nor fail and is assumed satisfied, and accounts still measured against a superseded benchmark version, so controls added in the current release are never evaluated at all. A single failed control usually looks minor, but the same failure repeating across dozens of accounts is the real signal — it points to a missing organization-level guardrail, and it means every new account starts life already off-baseline. Left unranked, benchmark output becomes a hundreds-of-line list nobody acts on, which is how consensus-baseline gaps accumulate into the small footholds an attacker chains into an incident. Closing them maps directly to CIS Benchmarks, and the same evidence supports NIST CSF, ISO 27001, SOC 2, and the change- and configuration-management controls in PCI-DSS.
What we assess
What we look for
- Every account, subscription, and project scored against the current CIS Foundations Benchmark version for its provider, at a profile level (Level 1 baseline, Level 2 for sensitive workloads) chosen deliberately rather than by default
- Failed Automated recommendations ranked by the exposure they create — internet-facing, identity, and logging foundations first — instead of reported as a flat pass/fail count
- Manual (non-automated) recommendations actually verified and recorded, not assumed passing because no tool evaluates them
- Accounts still measured against a superseded benchmark version, so controls added or tightened in the current release go unscored — version drift separated from genuine configuration regressions
- Account-level foundational settings CIS calls out explicitly: root/owner MFA and access-key posture, an enforced password policy, default encryption, default audit logging, and the default network/VPC and security-group state
- Recurring failed controls across many accounts that point to a missing org-level guardrail rather than a one-off mistake
- Suppressed, muted, or exception-flagged CIS controls reviewed to confirm each was risk-accepted deliberately, with a named owner and a stated rationale
- Native CIS mappings (Security Hub's CIS standard, Defender for Cloud's CIS compliance view, Security Command Center's health analytics) enabled where available, and their coverage gaps — accounts, regions, or resource types not evaluated — made explicit
Across your clouds
AWS, Azure & Google Cloud
AWS
The CIS AWS Foundations Benchmark is measured per account, and AWS Security Hub ships it as a named standard (releases such as v1.2.0, v1.4.0, v3.0.0, and v5.0.0) whose automated checks are backed by AWS Config rules. The recurring foundational items are root-account MFA and key usage, the IAM password policy, CloudTrail multi-region logging and log-file validation, default EBS/S3 encryption, and the default security group — and we flag accounts scored against an older standard version.
Azure
The CIS Microsoft Azure Foundations Benchmark is measured per subscription, and Microsoft Defender for Cloud maps it directly in the regulatory-compliance dashboard, with the automated portion reflected in secure score. Controls span Entra ID (MFA, guest and administrator posture), Storage account public access and secure transfer, SQL auditing and Transparent Data Encryption, Monitor/Activity-log configuration, and Network Security Group rules for management ports.
Google Cloud
The CIS Google Cloud Platform Foundation Benchmark is measured per project and organization, and Security Command Center's Security Health Analytics maps its detectors to CIS recommendations. Coverage centers on Cloud IAM (service-account keys, primitive roles, separation of duties), audit-logging configuration, default VPC and firewall rules exposing SSH/RDP, Cloud Storage public access prevention, and Cloud SQL public IP and TLS settings.
Example finding
Production accounts still scored against a superseded CIS AWS Foundations Benchmark version
Risk: The score reads healthy, but controls added or tightened in the current benchmark release — around default encryption, block-public-access, and instance metadata posture — are never evaluated, so real gaps show as not-applicable or simply go unmeasured while leadership treats the old score as current conformance.
Fix: Re-baseline every account to the current benchmark version and chosen profile level, re-score through the provider's native CIS standard, and reconcile the delta so newly-introduced controls are triaged instead of silently skipped.
Remediation
How to close it
- 1 Decide the target: which CIS Foundations Benchmark version and profile level (Level 1 as the baseline, Level 2 for sensitive accounts) each account, subscription, and project will be held to, standardized across the organization.
- 2 Score the whole estate against that current version — through the provider's native CIS mapping (Security Hub, Defender for Cloud, Security Command Center) where available — rather than accepting a stale or partial run.
- 3 Triage failed controls by real exposure: remediate internet-facing, identity, and audit-logging foundations first; queue low-impact deviations as backlog rather than treating every line equally.
- 4 Verify the Manual recommendations the automated tooling cannot check, and record the outcome so they are not assumed passing.
- 5 Push the systemic, recurring failures up to preventative org-level guardrails (SCPs, Azure Policy, Organization Policy constraints) so new accounts and regions inherit the baseline instead of drifting into it.
- 6 Re-score on a defined cadence and whenever the benchmark version changes, reconciling added and removed controls and re-confirming every exception so the score stays meaningful over time.
Questions
Which CIS Benchmark version and profile do you measure against?
The current CIS Foundations Benchmark for each provider — AWS, Azure, and Google Cloud — at the profile level that matches the account's sensitivity: Level 1 as a practical baseline and Level 2 where defense-in-depth is warranted. Because CIS revises these benchmarks, we also flag accounts being scored against a superseded version, which is one of the most common hidden sources of drift.
Is a 100% CIS score the goal?
No. Some recommendations are Level 2 hardening that does not fit every workload, and some deviations are risk-accepted for good reasons. The goal is a known, justified posture — every deviation either fixed or captured as an owned, documented exception — not a vanity number that hides accepted risk or unverified Manual controls.
Security Hub, Defender, and Security Command Center already score CIS. How is this different?
Those tools run the Automated checks, and we use their output directly. What we add is the part they leave out: verifying the Manual recommendations they skip, deduplicating findings across accounts, ranking each by the real exposure it creates, and separating benchmark-version drift from genuine regressions — so a flat compliance list becomes a remediation plan your team can actually run. The review is read-only; it produces the plan, your team makes the changes.
More in configuration & posture
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
