CIS Benchmarks: Level 1 vs Level 2 and How to Apply Them
CIS Benchmarks are free, consensus-built configuration guides published by the Center for Internet Security (CIS). Each one tells you exactly how to harden a specific product: which settings to change, what value to set, and how to check it. CIS describes them as "best practices for the secure configuration of a target system," and it publishes more than 100 of them across 25+ vendor product families.
This guide is for system administrators, cloud and security engineers, compliance leads, and startup founders who have been told to "harden to CIS" and need to know what that means in practice. It is also for anyone answering an auditor, a FedRAMP reviewer, or a PCI assessor who asks which configuration standard you follow.
What CIS Benchmarks Are
A CIS Benchmark is a hardening guide for one product family, such as Windows Server, Ubuntu Linux, Amazon Web Services, Microsoft 365, or Kubernetes. Each recommendation names a setting, explains why it matters, gives the value to apply, and describes how to audit and remediate it.
NIST calls this kind of document a security configuration checklist. In SP 800-70 Rev. 5 (May 2026), NIST describes a checklist as "a document that contains instructions, procedures, or machine-readable and executable content to configure an IT product to a specific risk posture for an operational environment, verify that the product has been configured properly, identify unauthorized configuration changes to the product, and/or produce artifacts that show the security posture of the product." NIST runs the National Checklist Program as a central place to find such checklists, and CIS lists that program among the bodies that recognize its Benchmarks.
The Benchmarks are free to download as PDFs. According to CIS, other formats (XCCDF, Word, Excel, XML) are available to CIS SecureSuite members, along with the tools to tailor and scan against them (CIS Benchmarks FAQ).
CIS Benchmarks vs CIS Controls
The two are easy to confuse because they come from the same organization. The CIS Controls are a program-level list of 18 security practices: inventory your assets, manage access, run vulnerability management, and so on. The Benchmarks sit one level down. They are the per-product settings that make a system match a secure baseline.
A Control states an outcome you must reach; a Benchmark gives the exact values that reach it on one product. CIS Control 4, "Secure Configuration of Enterprise Assets and Software," is the bridge: a Benchmark is a common way teams meet it on a given operating system or cloud account.
CIS Level 1 vs Level 2 vs STIG Profile
Most Benchmarks group their recommendations into profiles. CIS explains that "every recommendation within each CIS Benchmark is associated with at least one profile." The profiles below come from CIS's own definitions.
| Profile | What CIS says it is | Typical use |
|---|---|---|
| Level 1 | A base recommendation that "can be implemented fairly promptly" and is "designed to not have an extensive performance impact" | Default for most servers, workstations, and cloud accounts |
| Level 2 | "Defense in depth," intended "for environments where security is paramount"; can have "an adverse effect" if applied without due care | Regulated workloads, high-value systems, hardened enclaves |
| STIG profile | Replaces the old Level 3; holds the STIG-specific recommendations plus overlapping Level 1 and Level 2 items | Defense contractors and systems expected to meet DISA STIGs |
Level 1: the baseline
The intent of Level 1, in CIS's words, is "to lower the attack surface of your organization while keeping machines usable and not hindering business functionality." Expect items such as password and lockout policy, disabling legacy protocols, turning on audit logging, and removing unneeded services. Because CIS designs it to be implemented "fairly promptly," even a small team can plan a fleet-wide Level 1 rollout after testing rather than a long project.
Level 2: defense in depth
Level 2 includes everything in Level 1 plus settings that restrict functionality further. Some will disable features users or applications rely on. CIS warns that Level 2 recommendations "can have an adverse effect on your organization if not implemented appropriately or without due care." That is why Level 2 is usually applied selectively: to the systems that hold regulated data, not to every developer laptop.
What happened to CIS Level 3?
Searches for "CIS Level 3" still turn up, but the profile no longer exists under that name. CIS states that "the STIG profile replaces the previous Level 3." The STIG profile collects the recommendations needed to align with the Defense Information Systems Agency (DISA) Security Technical Implementation Guides. CIS also publishes separate STIG Benchmarks for some platforms (for example, Windows Server 2022 STIG and Ubuntu 24.04 LTS STIG) and notes which DISA STIG items they do not include (CIS Benchmarks list; CIS Hardened Images).
What the Benchmarks Cover
The catalog spans operating systems, cloud platforms, SaaS suites, databases, browsers, network devices, and container platforms. A snapshot of current versions listed on the CIS Benchmarks page on 22 October 2026:
- Cloud: Amazon Web Services Foundations 7.1.0, Microsoft Azure Foundations 6.0.0, plus service-specific AWS Benchmarks for compute, database, and storage.
- SaaS: Microsoft 365 Foundations 7.0.0 and Google Workspace Foundations 1.4.0.
- Operating systems: Windows 11 Enterprise 5.1.0, Windows Server 2022 5.1.0, Windows Server 2025 2.1.0, Ubuntu Linux 24.04 LTS 2.0.0, and Ubuntu Linux 26.04 LTS 1.0.0.
- Containers: Kubernetes, plus managed variants for EKS, AKS, and GKE.
Version numbers move often. CIS states that its Windows Benchmarks "will always cover the latest Windows build version within 90 days of a new Windows version release." Pin the Benchmark version you adopt in your configuration standard, and review it when CIS publishes a new release.
How the Benchmarks are built
Volunteers write the Benchmarks: practitioners and vendor engineers working with CIS's own development team. Drafts are discussed on the CIS WorkBench site "until a consensus has been reached," then published. After release, tickets and discussion threads feed the next version. Registration on WorkBench is free, and anyone can file a ticket against a recommendation they think is wrong (CIS Benchmarks FAQ).
That consensus process is why CIS fits the "industry-accepted" wording several frameworks use: it is not one vendor's opinion.
Which Regulations Point at CIS Benchmarks
No law says "you must apply CIS Benchmarks." What several frameworks do is require a documented secure configuration baseline, and CIS is a widely used way to meet that requirement outside the federal STIG world. Here is where the requirement sits in each one.
| Framework | Requirement | Where CIS fits |
|---|---|---|
| FedRAMP (Rev. 5) | CM-6(a) Requirement 1 | Named: DoD STIGs first, then "CIS up to Level 2," then custom baselines |
| NIST SP 800-53 Rev. 5 | CM-6 Configuration Settings | Asks for "common secure configurations"; CIS is one |
| NIST SP 800-171 / CMMC Level 2 | 3.4.2 Security configuration settings | Accepted way to define the settings you "establish and enforce" |
| PCI DSS v4.0.1 | Requirement 2.2.1 | CIS lists PCI DSS among the frameworks that recognize its Benchmarks |
FedRAMP: the only one that names CIS outright
The FedRAMP Security Controls Baseline adds a FedRAMP-specific requirement to CM-6: "The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available." A second requirement says checklists must be Security Content Automation Protocol (SCAP) validated, or SCAP compatible if no validated checklist exists. CM-7(b) reuses the same order to decide which ports, protocols, and services to prohibit.
So for a cloud service seeking FedRAMP authorization, CIS is not optional decoration. Where no STIG exists for a component, CIS is the expected source, and the ceiling is Level 2.
NIST SP 800-53 CM-6
NIST SP 800-53 Rev. 5 control CM-6 requires organizations to "establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [organization-defined common secure configurations]." The control's discussion describes common secure configurations as "recognized, standardized, and established benchmarks" and names the US Government Configuration Baseline and STIGs as examples. CIS Benchmarks fill the same role for products those two do not cover. CM-6 also requires you to document and approve deviations, which is where a Benchmark exception register comes from. Our NIST 800-53 controls guide covers the rest of the CM family.
NIST SP 800-171 and CMMC
Requirement 3.4.2 of NIST SP 800-171 Rev. 2 reads: "Establish and enforce security configuration settings for information technology products employed in organizational systems." CMMC Level 2 assesses that same requirement, using the Rev. 2 assessment procedures (SP 800-171A, June 2018). NIST has since published SP 800-171 Rev. 3 (May 2024), where the topic sits under 03.04.02 Configuration Settings and asks you to "establish, document, and implement" settings that "reflect the most restrictive mode consistent with operational requirements." A CIS Benchmark gives the assessor a documented source for each setting, and a scan report shows the "enforce" half. See our NIST 800-171 guide and CMMC guide for the assessment side.
PCI DSS
PCI DSS Requirement 2.2.1 deals with configuration standards for system components. CIS Benchmarks are a common choice here, and CIS itself lists PCI DSS among the frameworks that recognize them (CIS Hardened Images). The requirement is for your configuration standard, informed by CIS, not for CIS itself. An assessor will compare your written standard to the live settings. Read the current text in the PCI SSC Document Library and our PCI DSS 4.0 requirements guide.
SOC 2, ISO 27001, and HIPAA
None of these names CIS. They do require secure configuration in general terms, and a CIS-based baseline with scan evidence is a clean way to show an auditor that the control operates. For Microsoft 365 and Google Workspace specifically, CISA also publishes free SCuBA secure configuration baselines with the ScubaGear and ScubaGoggles assessment tools. CISA notes that although SCuBA's primary goal is federal civilian agencies, "all organizations can use SCuBA to strengthen SaaS security." If you use both, run SCuBA alongside the CIS Microsoft 365 Benchmark and reconcile any differences.
How to Apply CIS Benchmarks Without Breaking Production
Teams that run into trouble usually apply a Benchmark straight to production. The rollout below follows CIS's own advice to test first and the CM-6 requirement to document deviations.
- Inventory first. List every system class you run: operating systems, cloud accounts, SaaS tenants, databases, network gear. You cannot harden what you have not counted. This is CIS Controls 1 and 2.
- Pick the Benchmark and version per class. Record the exact version (for example, Windows Server 2022 5.1.0) in your configuration standard.
- Choose the profile per system tier. Level 1 for the general fleet; Level 2 for systems holding regulated or high-value data; STIG profile where a contract requires DISA alignment.
- Scan before you change anything. A baseline scan shows how far you are from the target and which settings fail.
- Apply in a test environment. Run the application's normal workload and regression tests against the hardened build. Expect Level 2 items to break something.
- Write down every exception. For each recommendation you will not apply, record the reason, the compensating control, the approver, and a review date. This is the "identify, document, and approve any deviations" clause of CM-6.
- Encode the baseline. Put the settings in Group Policy, Ansible, Terraform, or your cloud policy engine, so new systems are born compliant instead of fixed later.
- Scan on a schedule and on change. Drift is normal. Re-scan after patches, major upgrades, and new Benchmark releases.
A useful exception entry is specific enough that someone else could re-check it. A hypothetical example: two legacy file servers skip a recommendation that disables an old file-sharing protocol, because a line-of-business application on them still needs it. The compensating control is network isolation, with host firewall rules that allow inbound traffic only from the application subnet. The IT security lead approved it, and it is reviewed at the vendor's next upgrade or in six months, whichever comes first. An entry that only says "breaks app" gives an assessor nothing to test.
Hardened images
CIS also sells pre-hardened virtual machine images on the AWS, Azure, Google Cloud, and Oracle Cloud marketplaces. CIS says they "are configured to follow the recommendations of the globally-recognized CIS Benchmarks" (CIS Hardened Images). They save the build step for new instances. You still own the exceptions, the application layer, and drift after launch.
Tools That Scan Against CIS Benchmarks
CIS-CAT Lite is CIS's free assessment tool. It gives unlimited scans against "select CIS Benchmarks" and a compliance score. CIS-CAT Pro Assessor is part of the paid SecureSuite membership. It works with tailored Benchmarks and maps results to the CIS Controls and Implementation Groups (CIS-CAT Pro).
Cloud providers ship their own checks. AWS Security Hub supports versions 1.2.0, 1.4.0, 3.0.0, and 5.0.0 of the CIS AWS Foundations Benchmark. Note the gap: CIS's current AWS Foundations release is 7.1.0. A cloud-native check can trail the latest Benchmark by more than one major version. Confirm which version your tool actually tests before you tell an auditor you "meet CIS." Commercial vulnerability scanners and cloud security posture tools also bundle CIS policies; check the same version detail there.
Common Mistakes With CIS Benchmarks
- Applying Level 2 everywhere. It feels safer and generates outages. Tier your systems first.
- No exception register. An undocumented skipped setting looks like a failure to an assessor. A documented one with a compensating control gives the assessor something to evaluate.
- Hardening once. A server hardened at build and never re-scanned drifts as patches and admin changes accumulate.
- Version drift between tool and standard. Your policy says one Benchmark version and your scanner tests another.
- Starting with the Benchmarks before the inventory. You harden the systems you know about and miss the ones attackers find.
Frequently Asked Questions
What is the difference between CIS Level 1 and Level 2?
Level 1 is a baseline CIS designed to apply "fairly promptly" without extensive performance impact while keeping systems usable. Level 2 adds "defense in depth" settings for environments where security is paramount, and CIS warns they can have an adverse effect if applied without due care.
Is there a CIS Level 3?
No. CIS states that "the STIG profile replaces the previous Level 3." The STIG profile holds the recommendations needed to align with DISA STIGs, plus the Level 1 and Level 2 items that overlap.
Are CIS Benchmarks free?
Yes, as PDF downloads. Additional formats, tailoring in CIS WorkBench, and the CIS-CAT Pro scanner come with a paid CIS SecureSuite membership. CIS-CAT Lite is a free scanner for select Benchmarks.
Is CIS compliance mandatory?
Not by law in general. FedRAMP names CIS (up to Level 2) as the configuration source when no DoD STIG exists. NIST 800-53, NIST 800-171, CMMC, and PCI DSS require a secure configuration baseline, and CIS is a widely accepted way to meet it.
What is the difference between CIS Benchmarks and CIS Controls?
The CIS Controls are 18 program-level security practices. The Benchmarks are per-product configuration settings. Control 4, secure configuration, is commonly met by applying Benchmarks.
What is the difference between CIS Benchmarks and DISA STIGs?
Both are configuration hardening guides. STIGs are published by DISA for Department of Defense systems. CIS Benchmarks are consensus-built for general use, and some include a STIG profile. FedRAMP puts STIGs first and CIS second.
Bottom Line
CIS Benchmarks turn "configure systems securely" into a list of specific settings an auditor can check. Apply Level 1 broadly, keep Level 2 for systems that hold sensitive data, and use the STIG profile only where a contract asks for DISA alignment. The work that passes audits is the boring part around the Benchmark: a pinned version, a tested rollout, a written exception register, and scans that run after every change.
Sources used
- CIS Benchmarks FAQ (profiles, development, formats), accessed 2026-10-22
- CIS Benchmarks list and current versions, accessed 2026-10-22
- FedRAMP Security Controls Baseline (Rev. 5), CM-6 and CM-7 requirements, accessed 2026-10-22
- NIST SP 800-53 Rev. 5, Security and Privacy Controls (CM-6), accessed 2026-10-22
- NIST SP 800-70 Rev. 5, National Checklist Program for IT Products, accessed 2026-10-22
- NIST National Checklist Program repository, accessed 2026-10-22
- NIST SP 800-171 Rev. 2 (requirement 3.4.2), accessed 2026-10-22 (Rev. 2 is the revision CMMC Level 2 assesses); NIST SP 800-171 Rev. 3 (03.04.02), accessed 2026-10-22
- CISA, Secure Cloud Business Applications (SCuBA) Project, accessed 2026-10-22
- PCI Security Standards Council, Document Library (PCI DSS v4.0.1), accessed 2026-10-22
- CIS-CAT Pro Assessor and CIS-CAT Lite, accessed 2026-10-22
- CIS Hardened Images, accessed 2026-10-22
- AWS Security Hub, CIS AWS Foundations Benchmark, accessed 2026-10-22
Last reviewed: 2026-10-22. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.
