What Are CIS Benchmarks? A Defender's Guide

A fresh Ubuntu server boots with SSH allowing root login, password authentication on, no firewall rules, and verbose service banners advertising versions to anyone who scans it. None of that is a vulnerability in the CVE sense. The software is patched and current. It is simply configured the way the vendor ships it, which is built for everything to work out of the box, not for everything to be hard to attack. An attacker does not need a zero-day against that host. They need the default. A CIS Benchmark is the document that tells you, line by line, which of those defaults to change and what to change them to.

A CIS Benchmark is a consensus-built set of secure configuration recommendations for a specific technology: a Linux distribution, a Windows version, an AWS account, a Docker engine, an Apache server. It is published by the Center for Internet Security (CIS), a nonprofit, and it is free to download as a PDF. This guide covers what CIS and its benchmarks are, the Level 1 and Level 2 profiles that decide how hard you lock a system down, how the benchmarks relate to the CIS Critical Security Controls, how they are built, and how a blue team actually uses them to harden and audit systems.

What is a CIS Benchmark?

A CIS Benchmark is a detailed configuration baseline for one technology, broken into individual recommendations. Each recommendation names a specific setting, states the secure value, explains why it matters, and gives the exact steps to audit the current state and to remediate it. "Ensure SSH root login is disabled" is a recommendation. So is "Ensure CloudTrail is enabled in all regions" and "Ensure password length is 14 or more characters." A full benchmark for an operating system runs to hundreds of these.

The Center for Internet Security publishes them. CIS is a US nonprofit, and the benchmarks are distributed free of charge in PDF format, so any defender can download the document for the exact platform they run. CIS maintains secure configuration guidance "for more than 100 CIS Benchmarks across 25+ vendor product families," covering the technologies most organizations actually deploy.

The reason benchmarks exist is the gap between a working configuration and a secure one. Vendors ship defaults tuned for compatibility and ease of setup, not for a minimal attack surface. A benchmark closes that gap with specifics: not "harden SSH" but the precise directives to set, not "restrict permissions" but the exact mode bits. That specificity is what makes a benchmark auditable. You can check a system against it setting by setting and get a pass or fail on each line, which is the foundation of both system hardening and configuration auditing. Tightening those defaults is direct attack surface reduction: every disabled service and closed default is one less thing an attacker can reach.

What does a CIS Benchmark cover?

CIS publishes benchmarks across the full stack a typical organization runs, grouped into categories. The CrowdStrike reference for this topic lists the categories as:

• Cloud providers: AWS, Microsoft Azure, Google Cloud Platform.
• Operating systems: Windows, macOS, Linux distributions.
• Server software: Apache Tomcat, Docker, MongoDB, NGINX.
• Desktop software: Microsoft Office, Zoom.
• Mobile devices: iOS, Android.
• Network devices: Cisco, Juniper.
• DevSecOps tools: GitHub.
• Multi-function print devices.

The cloud benchmarks are the ones most relevant to a modern environment. The CIS AWS Foundations Benchmark, the Azure benchmark, and the GCP benchmark define the account-level configuration baseline (logging, identity, networking, storage defaults) that most cloud security posture tooling checks against. When a cloud security scanner reports your account is "85 percent compliant," there is a good chance the standard behind that number is a CIS Benchmark.

CIS Benchmark profiles: Level 1 vs Level 2

Most CIS Benchmarks split their recommendations into profiles. A profile is a named subset of the recommendations, so you can choose how aggressively to harden a system based on what it does. The two core profiles are Level 1 and Level 2.

Level 1 is the base recommendation. Per CIS, it "can be implemented fairly promptly and is designed to not have an extensive performance impact," with the intent to lower the attack surface while keeping the machine usable. Level 1 is the safe starting point: settings almost any system can adopt without breaking the application it runs.

Level 2 is the defense-in-depth profile. CIS describes it as "intended for environments where security is paramount," and warns that its recommendations "can have an adverse effect on your organization if not implemented appropriately." Level 2 turns off functionality and tightens controls in ways that can break workloads if applied without testing, which is exactly why it is a separate profile rather than the default.

The practical workflow is to apply Level 1 broadly, then add Level 2 on the systems that justify the operational cost and the testing effort: domain controllers, systems holding regulated data, internet-facing infrastructure. Some benchmarks also publish a STIG profile, which maps the CIS recommendations to the US Department of Defense Security Technical Implementation Guides. Per CIS, "the STIG profile provides all recommendations that are STIG specific," and overlapping Level 1 and Level 2 recommendations appear in it as applicable, so an organization with a STIG obligation can meet it from the same benchmark.

CIS Benchmarks and the CIS Controls

CIS publishes two related things, and conflating them is a common mistake. The CIS Benchmarks are configuration baselines for specific products. The CIS Critical Security Controls are a prioritized list of defensive actions for an organization as a whole, independent of any single product.

The current version is CIS Controls v8.1, released June 25, 2024, which contains 18 Controls. (Version 8 reduced the count from the earlier 20 by consolidating around activities rather than who manages the device; v8.1 added governance emphasis and kept the 18.) Each Control is a category of defensive activity, from "Inventory and Control of Enterprise Assets" to "Penetration Testing," broken down into specific Safeguards.

The two fit together. The Controls tell you *what* defensive outcomes to pursue (for example, Control 4, "Secure Configuration of Enterprise Assets and Software"). The Benchmarks tell you *how* to achieve the secure-configuration outcome on a given platform, setting by setting. A benchmark is the concrete, product-level execution of the configuration Controls.

The Controls also define Implementation Groups (IG1, IG2, IG3) that scope which Safeguards an organization should adopt based on its resources and risk. IG1 is the basic-hygiene starting point CIS calls essential for every enterprise; IG2 and IG3 layer on the Safeguards needed by organizations with more sensitive data and a larger attack surface. Benchmarks and Controls together feed an organization's broader vulnerability management program, because a misconfiguration is a weakness whether or not it carries a CVE.

How CIS Benchmarks are built

The credibility of a benchmark comes from how it is made. CIS Benchmarks are developed through what CIS calls "a unique consensus-based process comprised of cybersecurity professionals and subject matter experts around the world." Volunteers (vendors, auditors, practitioners, government participants) propose, debate, and refine each recommendation in CIS WorkBench, where "discussion threads are established to continue dialogue until a consensus has been reached" before a recommendation ships.

That process is the point. A single vendor's hardening guide reflects one party's interests; a consensus benchmark reflects what a community of practitioners agrees is both secure and operationally workable. It is also why benchmarks are versioned and revised: as a product changes and as the community learns, the recommendations are updated, so the document for the version of the software you run is the one to use, not an older edition.

Implementing CIS Benchmarks

Applying a benchmark is a project, not a checkbox, because every disabled feature is a feature some workload might depend on. A workable sequence, aligned with the CrowdStrike reference's implementation steps:

1. Assess the current state. Pull the benchmark for the exact platform and version you run, and audit your systems against it to get a baseline pass/fail per recommendation. Configuration-assessment tools and CIS-CAT (the CIS Configuration Assessment Tool) automate this against the official content.
2. Prioritize. Start with Level 1 on the systems with the most exposure or the most sensitive data. Do not try to reach 100 percent everywhere at once.
3. Plan the changes. Decide which Level 2 recommendations apply, and identify any setting that could break a workload before you touch production.
4. Test before rolling out. Apply changes in a staging environment, confirm the application still works, then promote. This is where Level 2 settings earn their separate profile.
5. Roll out gradually. Use configuration management (Group Policy, Ansible, and the like) so the hardened state is enforced and reproducible rather than hand-applied and forgotten.
6. Monitor for drift. A system hardened once does not stay hardened. Re-audit on a schedule and alert on configuration drift, because an operator change or a new deployment can quietly undo a setting.

The drift point is the one most often missed. Benchmark compliance is a state you maintain, not a milestone you pass. CIS also publishes CIS Hardened Images, prebuilt virtual machine images configured to a benchmark and available on the major cloud marketplaces, which let you start from a hardened baseline instead of hardening a default image after the fact.

CIS Benchmark levels and components at a glance

The pieces of the CIS ecosystem serve different jobs, and knowing which is which keeps an audit conversation straight.

The benchmark is the line-by-line configuration standard; the Controls are the organizational strategy; the profiles decide how hard you lock down; the hardened images and CIS-CAT are how you apply and check it at scale.

Frequently Asked Questions

What is a CIS Benchmark?

A CIS Benchmark is a consensus-built set of secure configuration recommendations for a specific technology, such as a Linux distribution, a Windows version, an AWS account, or a Docker engine. Each recommendation names a setting, its secure value, the reason, and the steps to audit and remediate it. The Center for Internet Security publishes the benchmarks free of charge as PDFs.

Who creates CIS Benchmarks and are they free?

The Center for Internet Security (CIS), a US nonprofit, publishes them. They are developed through a consensus process involving cybersecurity professionals and subject matter experts worldwide, refined in CIS WorkBench until the community agrees. The PDF benchmarks are distributed free of charge; members get additional formats and tooling.

What is the difference between CIS Benchmark Level 1 and Level 2?

Level 1 is the base profile: recommendations that can be applied quickly without an extensive performance impact, meant to reduce attack surface while keeping a system usable. Level 2 is the defense-in-depth profile for environments where security is paramount; its settings tighten controls further and can disrupt workloads if applied without testing, which is why it is a separate, opt-in profile.

How are CIS Benchmarks different from the CIS Controls?

CIS Benchmarks are configuration baselines for specific products, telling you which settings to change on a given platform. The CIS Critical Security Controls are a prioritized list of 18 organization-wide defensive activities (v8.1, released June 25, 2024). The Controls define what defensive outcomes to pursue; the Benchmarks are how you achieve the secure-configuration outcome on a particular technology.

How many CIS Benchmarks are there?

CIS maintains secure configuration guidance for more than 100 CIS Benchmarks across more than 25 vendor product families, spanning cloud providers, operating systems, server and desktop software, mobile devices, network devices, DevSecOps tools, and print devices. Each is versioned and revised as the underlying product changes, so the benchmark for the version you run is the one to use.

How do you implement a CIS Benchmark?

Pull the benchmark for your exact platform and version, audit current systems against it (CIS-CAT automates this), and prioritize Level 1 on the most exposed and sensitive systems first. Plan and test any Level 2 changes before production, roll them out with configuration management so the state is reproducible, and re-audit on a schedule to catch configuration drift.

What are CIS Hardened Images?

CIS Hardened Images are prebuilt virtual machine images configured to a CIS Benchmark and made available on the major cloud provider marketplaces. They let a team launch a workload that is already hardened to the benchmark instead of deploying a vendor-default image and remediating it afterward, which removes a window of exposure and reduces manual hardening work.

The bottom line

A CIS Benchmark is a consensus-built, free configuration baseline that tells you exactly which of a technology's defaults to change to make it hard to attack, recommendation by recommendation. The profiles set the intensity: Level 1 broadly, Level 2 where security outweighs operational cost, a STIG profile where compliance demands it. The benchmarks pair with the CIS Critical Security Controls (v8.1, 18 Controls, scoped by Implementation Groups), which say what defensive outcomes to pursue while the benchmarks say how to configure each product to get there.

The work is not downloading the PDF; it is applying it without breaking production and keeping it applied as systems drift. Audit against the right benchmark version, harden Level 1 first and test Level 2, enforce the state with configuration management, start cloud workloads from CIS Hardened Images where you can, and re-check on a schedule. Defaults favor the attacker. A benchmark is how you take that advantage back, one setting at a time.