The CIS Benchmarks are free, consensus-developed configuration guides from the Center for Internet Security that tell you how to lock down operating systems, cloud platforms, network devices and applications. Hardening with them follows a repeatable pattern. Pick the right benchmark and profile, build it into your images, apply it through automation, test before broad rollout, document the settings you can't adopt, and keep watching for drift.

Default configurations are built for compatibility and easy setup, not for security. Hardening closes that gap, and the benchmarks save you from working out hundreds of settings on your own.

What are the CIS Benchmarks?

CIS publishes more than 100 benchmarks across more than 25 vendor product families. They cover Windows and Linux distributions, macOS, the major cloud platforms, databases, web servers, browsers, network devices and mobile platforms. Volunteers from industry, government and technology vendors develop each one through a consensus process, and CIS makes the PDFs available free of charge.

Each recommendation follows the same structure:

  • A title describing the desired setting
  • The profile or profiles it applies to
  • A description and rationale explaining why it matters
  • The impact of applying it, including anything that may break
  • Audit steps to check the current state
  • Remediation steps to apply the setting
  • The default value and references, including mappings to the CIS Critical Security Controls

That mapping ties the benchmarks to CIS Control 4, "Secure Configuration of Enterprise Assets and Software." In CIS Controls v8.1, released in June 2024, Safeguard 4.1 asks organizations to establish and maintain a documented secure configuration process. The benchmarks give you ready-made content for that process.

What's the difference between Level 1 and Level 2?

Every benchmark groups its recommendations into profiles. The two you'll use most are Level 1 and Level 2.

Level 1 Level 2
Purpose Base recommendations to reduce attack surface Defense in depth for environments where security is paramount
Operational impact Designed to have limited impact on performance and functionality May reduce functionality or disrupt operations if not planned carefully
Rollout effort Can usually be implemented fairly quickly Needs more testing and business sign-off
Typical scope All systems of that type High-value or high-exposure systems

Level 2 includes everything in Level 1 plus additional settings. Many benchmarks also split profiles by role. The Windows Server benchmarks, for example, have separate variants for domain controllers and member servers, and some benchmarks offer additional profiles, such as one aligned to DISA STIG requirements.

Which profile should you choose?

For most small and mid-sized organizations, Level 1 is the right baseline for every system. Apply Level 2 selectively to systems where the extra restriction is worth the operational cost, such as domain controllers, internet-facing servers, privileged access workstations and systems holding sensitive data.

Mixing is normal. You can adopt Level 1 in full and cherry-pick individual Level 2 settings that fit your environment.

How do you choose the right benchmark?

Match the benchmark to the exact product and version you run. Settings change between releases, and a benchmark written for an older version can include recommendations that no longer apply or miss new ones.

A few practical points:

  • Check the benchmark version. Benchmarks are revised as products change, so note which version your baseline is built on.
  • Cover the full stack. A web server needs the operating system benchmark and the web server benchmark, and possibly a database benchmark too.
  • Fill the gaps. Where no CIS Benchmark exists, fall back to the vendor's own hardening guidance or a DISA STIG.

What are hardened images, and should you use them?

A hardened image, often called a golden image, is a pre-configured operating system template with your baseline already applied. Every new server or workstation starts in a known-good state instead of being hardened after deployment.

Building your own gives you full control. The usual approach is an automated image pipeline that starts from the vendor's base image, applies patches and your hardening settings, runs a compliance scan, and publishes the result only if it passes. CIS also offers pre-hardened images through the major cloud marketplaces, which can be a shortcut when you don't have a pipeline yet.

Either way, treat images as short-lived. Rebuild them on a regular schedule, such as monthly, so new deployments don't start out behind on patches and benchmark updates.

How do you apply CIS Benchmark settings at scale?

Hardening by hand doesn't survive contact with a real environment. Settings get missed, servers drift apart, and nobody can prove what was applied. Automation fixes all three.

Group Policy and device management for Windows

For domain-joined Windows systems, Group Policy remains the standard tool. Build separate GPOs for each benchmark and role, such as workstation, member server and domain controller, rather than one large policy. That makes exceptions and troubleshooting much easier. CIS provides Group Policy-based build kits to its members, but you can also build GPOs yourself from the benchmark's remediation steps.

For cloud-managed or non-domain devices, apply the same settings through your device management platform's configuration profiles. Keep the mapping between each setting and its benchmark recommendation number so you can trace it later.

Configuration management for servers

On Linux and mixed estates, configuration management tools such as Ansible, Puppet or Chef can apply and continuously enforce settings. Open-source projects give you a head start. Ansible Lockdown publishes roles aligned to CIS Benchmarks for common Linux distributions, and OpenSCAP can both scan against CIS profiles and generate remediation content for supported platforms.

Treat community content as a starting point. Review what each task does before running it in production.

Infrastructure as code and image pipelines

In cloud environments, put hardening into the templates that create resources. Apply operating system settings in the image pipeline, and use infrastructure-as-code templates and policy-as-code guardrails to enforce cloud-level settings such as encryption, logging and network restrictions. When the template is hardened, every deployment is hardened by default.

How do you test hardening before rollout?

Hardening breaks things. That's not a reason to skip it, but it is a reason to test.

  1. Start in a lab. Apply the baseline to test systems that mirror production roles and applications.
  2. Test the business workflows. Have application owners confirm logins, integrations, printing, file shares, remote management and backups still work.
  3. Roll out in rings. Move from IT's own machines to a pilot group, then to broader groups, with a pause at each stage.
  4. Watch for the usual suspects. Restrictions on legacy authentication protocols, SMB signing requirements, user rights assignments for service accounts, disabled services, TLS changes and removable media controls are frequent culprits.
  5. Keep a rollback path. Know how to revert each GPO or configuration change quickly, and test that you can.

Read the impact statement in each recommendation before testing. It often tells you exactly what's likely to break.

How should you document exceptions?

Very few organizations can apply every recommendation. A legacy application may need an older protocol, or a vendor may not support a setting on their appliance. Exceptions are fine. Undocumented exceptions aren't.

Record each exception in a register with:

  • The benchmark, version and recommendation number
  • The affected systems
  • The business reason
  • Any compensating controls, such as network segmentation or extra monitoring
  • The risk owner who approved it
  • A review or expiry date

Set the same exceptions in your scanning tools so they stop reappearing as failures. Otherwise real regressions get lost among known, accepted deviations.

How do you monitor for configuration drift?

A system that passes on deployment day won't necessarily pass six months later. Admins make one-off changes, software installers change settings, and policies stop applying when systems move between groups.

Build drift monitoring into routine operations:

  • Scan on a schedule. Assess systems against your baseline at least monthly, and more often for critical servers. CIS offers its own assessment tool, CIS-CAT, in a free Lite edition and a fuller Pro edition for members; OpenSCAP and many vulnerability scanners can also run CIS checks.
  • Enforce, don't just report. Group Policy reapplies settings periodically, and configuration management tools can correct drift automatically.
  • Alert on critical changes. Changes to audit policy, local administrator membership or security services deserve an alert, not just a line in a monthly report.
  • Track the trend. Report compliance percentage per system role over time, and investigate sudden drops.
  • Update the baseline. When CIS releases a new benchmark version, review the changes and plan them in, just as you would a software update.

Frequently asked questions

Are CIS Benchmarks free to use?

The benchmark PDFs are available free of charge from CIS. Additional resources, such as full assessment tooling, build kits and tailored benchmark content, come with a paid CIS SecureSuite membership.

Do we have to implement every recommendation?

No. The benchmarks are guidance, not a pass-or-fail certification. Adopt what fits your environment, document why you've skipped anything, and apply compensating controls where the risk warrants it.

What's the difference between CIS Benchmarks and DISA STIGs?

Both are configuration hardening standards. DISA STIGs are produced for the US Department of Defense and are mandatory in that environment. CIS Benchmarks are developed by a broader community and are widely used well beyond government. Some CIS Benchmarks include a STIG-aligned profile for organizations that need to meet both.

How long does a first hardening project take?

It depends on how many system types you run and how much legacy software you have. A focused effort on one platform, such as Windows workstations at Level 1, is a sensible first project before moving on to servers and cloud.

Next steps

  1. List the operating systems, platforms and applications you run, and download the matching benchmarks.
  2. Adopt Level 1 as your baseline, and identify the systems that justify Level 2 settings.
  3. Build the baseline into images, Group Policy and configuration management instead of applying it by hand.
  4. Test in a lab and pilot group before broad rollout, with a tested rollback plan.
  5. Keep an exception register with owners and review dates.
  6. Scan for drift on a schedule and update your baseline when new benchmark versions arrive.

A hardened system is only as good as its last check. Keep the checks running.