A misconfigured server does not announce itself. It just sits there, quietly accepting the default settings a vendor shipped it with, until someone finds the gap. The Verizon 2026 Data Breach Investigations Report found that software vulnerability exploitation has overtaken stolen credentials as the top initial access vector in confirmed breaches, appearing in roughly 31% of cases compared to 13% for credential abuse. A large share of those exploitable weaknesses trace back to systems that were never hardened past their factory defaults. CIS Benchmarks exist to close that gap, and this tutorial walks through applying them on real Linux and Windows servers in 2026, using the free and paid tools that make the process repeatable instead of a one-time checklist exercise.
By the end of this guide you will have scanned a server against a current CIS Benchmark profile, read a hardening index score, automated remediation with Ansible, and built a pipeline that keeps configuration drift from creeping back in. This is a hands-on, command-line tutorial. Expect to spend 90 to 120 minutes working through it on a test system before you touch anything in production.
Why CIS Benchmarks Matter More in 2026 Than They Did Two Years Ago
CIS Benchmarks are consensus-built configuration standards maintained by the Center for Internet Security, covering operating systems, cloud platforms, container runtimes, and now a growing set of AI infrastructure targets. They are not a single document. Each benchmark is a PDF and a machine-readable profile that lists specific, testable settings, things like disabling unused filesystem modules, enforcing password complexity, or restricting SSH root login, each mapped to a scoring status of Level 1 or Level 2.
The urgency behind this topic in 2026 is not theoretical. Beyond the DBIR’s vulnerability-exploitation numbers, cloud misconfiguration keeps showing up as a recurring theme in breach post-mortems, and one widely cited 2026 analysis built on IBM’s Cost of a Data Breach data put the global average breach cost at $4.44 million, with U.S. incidents running far higher at roughly $10.22 million. Hardening does not stop every attack, but it shrinks the attack surface that a vulnerability scanner or an attacker’s reconnaissance script has to work with in the first place. If you already run a vulnerability scan on your infrastructure, CIS hardening is the step that happens before the scan finds fewer things to report.
CIS also keeps expanding its scope to match how infrastructure actually looks today. The CIS Docker Benchmark is up to version 1.8.0 and the CIS Kubernetes Benchmark has reached v1.12.0, reflecting how much container and orchestration hardening has matured as its own discipline separate from classic OS-level work. If you manage clusters, this tutorial pairs well with a dedicated pass through Kubernetes security hardening, since the two benchmark families overlap but are not interchangeable.
What a CIS Benchmark Actually Contains
Every CIS Benchmark document is organized around two profile levels. Level 1 recommendations are meant to be practical and unlikely to break normal operation, things like disabling core dumps for unprivileged users or setting a minimum password length. Level 2 recommendations go further, covering settings that improve security meaningfully but can affect functionality or performance, such as disabling IPv6 entirely or enforcing full disk encryption at the kernel level. Most organizations start with Level 1 across the fleet and apply Level 2 selectively to systems that hold sensitive data.
Each individual recommendation inside a benchmark follows the same format: a description of the setting, the rationale for changing it, the audit procedure to check current state, the remediation steps to fix it, and any default value. This structure is what makes CIS content automatable. Tools like OpenSCAP and CIS-CAT do not need to interpret prose, they read a machine-readable version of that same content (an XCCDF or OVAL file) and run the audit procedure directly against the target system.
As of September 2026, the current benchmark versions worth knowing include CIS Ubuntu Linux 24.04 LTS Benchmark v2.0.0, published in June 2026, and a CIS RHEL 9 Benchmark at version 2.0.0. Amazon Linux 2023 has its own CIS benchmark at v1.0.0. On the Windows side, Chef’s compliance profile catalog lists a current CIS Windows Server 2022 audit profile at v4.0.0, and CIS confirmed Windows Server 2025 installation support inside its SecureSuite tooling, though a dedicated numbered benchmark release for Server 2025 was not yet publicly confirmed at the time of writing. Always check the CIS Benchmarks page directly before you start a project, since these version numbers move.
Prerequisites: What You Need Before You Start
- A test or staging server you can break without consequence. Do not run your first CIS pass against production.
- Linux target: Ubuntu 24.04 LTS, RHEL 9, or Amazon Linux 2023, with root or sudo access.
- Windows target: Windows Server 2022 or 2025, with local administrator rights and PowerShell 7.4 or later.
- Java Runtime Environment 11 or later, required to run CIS-CAT Lite and CIS-CAT Pro Assessor.
- OpenSCAP scanner and the SCAP Security Guide package (
openscap-scannerandscap-security-guideon RHEL/Ubuntu repos). - Lynis, the open-source auditing tool, version installed via your package manager or the official GitHub repository.
- Ansible 2.16 or later on a control node, if you plan to automate remediation across multiple hosts.
- Optional: a free CIS-CAT Lite account (no cost) or a CIS SecureSuite membership for CIS-CAT Pro Assessor, which unlocks the full benchmark catalog and Level 2 automated remediation content.
- A snapshot or backup of the target system taken immediately before you begin remediation.
CIS SecureSuite membership, which unlocks CIS-CAT Pro and the full remediation content library, is priced by organization size on an annual basis. Published tiers run from roughly $2,400 a year for organizations with up to 99 employees up to $20,000 a year for enterprises with 100,000 or more employees, with a 5% discount for two-year commitments and 10% off three-year terms. If that is outside your budget, this tutorial deliberately leans on the free stack, CIS-CAT Lite, OpenSCAP, and Lynis, which together cover the vast majority of what a small or mid-size team actually needs.
Step 1: Pick the Right Benchmark and Profile Level
Go to the CIS Benchmarks catalog and download the PDF and XCCDF files for your exact OS and version. Do not grab a benchmark for a nearby version and assume it applies, a benchmark written for Ubuntu 22.04 references package names and paths that changed by 24.04. Decide upfront whether you are scoring against Level 1 or Level 2 for this system class. A public-facing web server handling no regulated data is a reasonable Level 1 target. A database holding payment card data under PCI DSS 4.0 scope should be evaluated against Level 2.
Step 2: Install OpenSCAP and the SCAP Security Guide
OpenSCAP is the free, open-source scanning engine that most Linux hardening workflows are built around. The SCAP Security Guide project (packaged as scap-security-guide, and increasingly developed under the ComplianceAsCode project on GitHub) ships pre-built CIS profiles you can run immediately, without hand-converting the CIS PDF into XCCDF yourself. The underlying scan engine itself is maintained as part of the OpenSCAP project, which has been the de facto standard SCAP implementation on Linux for over a decade.
# Ubuntu 24.04 LTS
sudo apt update
sudo apt install -y openscap-scanner scap-security-guide
# RHEL 9 / Amazon Linux 2023
sudo dnf install -y openscap-scanner scap-security-guide
# Confirm the CIS profile is available for your platform
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml | grep -i cisThe profile ID you are looking for typically follows the pattern xccdf_org.ssgproject.content_profile_cis_level1_server or _level2_server. List all profiles in the datastream before you run a scan so you pick the correct one for your target level.
Step 3: Run Your First OpenSCAP Compliance Scan
Run an evaluation-only pass first. Do not enable remediation on the first run, you want to see the current state of the machine before anything changes.
sudo oscap xccdf eval
--profile xccdf_org.ssgproject.content_profile_cis_level1_server
--results scan-results.xml
--report scan-report.html
/usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xmlOpen scan-report.html in a browser. You will see a pass/fail count per rule, a severity rating, and the exact remediation script or command for each failed check. A typical first scan on a stock Ubuntu 24.04 install will show output resembling this:
Title Pass Fail Other
CIS Ubuntu 24.04 LTS Benchmark - Level 1 - Server
Rule Result Breakdown:
pass 142
fail 38
notchecked 6
notapplicable 9
Severity of failed rules:
high 9
medium 21
low 8Roughly 20-25% failure rate on a fresh install is normal. Distributions ship for compatibility first, not maximum hardening, so an unmodified OS never scores 100%.
Step 4: Install and Run CIS-CAT Lite for a Second Opinion
CIS-CAT Lite is CIS’s own free assessment tool, distributed at no cost through the CIS website after a free account registration. It scores against a limited set of CIS benchmarks with full functionality reserved for CIS-CAT Pro Assessor, which requires SecureSuite membership. Running both OpenSCAP and CIS-CAT Lite against the same host is a useful sanity check, since the two tools sometimes interpret an ambiguous audit step differently.
# Extract the CIS-CAT Lite archive downloaded from CIS's site
unzip CIS-CAT-Lite.zip -d ~/cis-cat-lite
cd ~/cis-cat-lite
# Run against the bundled Ubuntu 24.04 benchmark
./Assessor-CLI.sh -b benchmarks/CIS_Ubuntu_Linux_24.04_LTS_Benchmark_v2.0.0-xccdf.xml
-p "Level 1 - Server" -aCIS-CAT writes an HTML and a CSV report to the reports/ directory. Cross-reference any rule that fails in one tool but passes in the other, that discrepancy is usually a sign the audit script needs a distro-specific tweak, not that one tool is wrong.
Step 5: Audit with Lynis for a Broader Hardening Index
Lynis, maintained by CISOfy, takes a different approach than a strict CIS profile scan. It runs hundreds of checks across the entire system, not just the items in one benchmark, and produces a single 0-100 hardening index score you can track over time. That single number is useful for showing leadership a trend line without walking them through a 180-line XCCDF report.
sudo apt install -y lynis
sudo lynis audit system
# Read the hardening index at the end of the run
grep "Hardening index" /var/log/lynis-report.dat
# Example output:
# hardening_index=64A freshly installed, unhardened server typically scores in the 55-65 range. After applying Level 1 CIS remediation, most teams see that climb into the 75-85 range. Getting past 90 usually means Level 2 controls and application-specific hardening that goes beyond what any generic benchmark covers.
Step 6: Remediate Manually for High-Severity Findings First
Before you automate anything, fix the highest-severity findings by hand on your test box so you understand what each change actually does. Common Level 1 fixes on a fresh Ubuntu or RHEL install include disabling unused filesystem kernel modules, setting SSH PermitRootLogin to no, enforcing password aging via /etc/login.defs, and removing legacy services like rsh or telnet if they were installed by a base image.
# Example: disable root SSH login and set password aging, a common Level 1 pair of fixes
sudo sed -i 's/^#?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd
sudo sed -i 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS 365/' /etc/login.defs
sudo sed -i 's/^PASS_MIN_DAYS.*/PASS_MIN_DAYS 1/' /etc/login.defsRe-run your OpenSCAP scan after each batch of five or six fixes, not after every single one. Scanning after every micro-change wastes time, and scanning only once at the end makes it hard to tell which fix caused a service to break if something does.
Step 7: Automate Remediation at Scale with OpenSCAP
Once you have validated the manual fixes on one machine, use OpenSCAP’s built-in remediation mode to apply the same fixes automatically, either as a dry run first or directly against a fleet through your configuration management tool.
# Generate a remediation shell script without applying it
oscap xccdf generate fix
--profile xccdf_org.ssgproject.content_profile_cis_level1_server
--output remediate.sh
/usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml
# Review remediate.sh line by line before running it
less remediate.sh
# Apply remediation directly (only after review, and only on a test host first)
sudo oscap xccdf eval
--profile xccdf_org.ssgproject.content_profile_cis_level1_server
--remediate
--results remediated-results.xml
/usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xmlNever run --remediate on a fleet without first testing the generated script on an identical staging image. Some remediation actions, such as disabling a kernel module a monitoring agent depends on, can take a service down.
Step 8: Scale Linux Hardening Across a Fleet with Ansible
Running OpenSCAP by hand works for one server. For a fleet, pull in a maintained Ansible role built around CIS content, or wrap the OpenSCAP remediation script in your own playbook so it runs consistently across every host in inventory.
---
- name: Apply CIS Level 1 hardening baseline
hosts: linux_servers
become: true
vars:
ssg_datastream: /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml
cis_profile: xccdf_org.ssgproject.content_profile_cis_level1_server
tasks:
- name: Ensure OpenSCAP and SSG content are installed
apt:
name:
- openscap-scanner
- scap-security-guide
state: present
update_cache: true
- name: Run baseline scan before remediation
command: >
oscap xccdf eval --profile {{ cis_profile }}
--results /tmp/pre-scan-{{ inventory_hostname }}.xml
{{ ssg_datastream }}
ignore_errors: true
- name: Apply CIS remediation
command: >
oscap xccdf eval --profile {{ cis_profile }}
--remediate --results /tmp/post-scan-{{ inventory_hostname }}.xml
{{ ssg_datastream }}
ignore_errors: true
- name: Fetch post-remediation report for the audit trail
fetch:
src: /tmp/post-scan-{{ inventory_hostname }}.xml
dest: ./reports/{{ inventory_hostname }}/
flat: trueChef’s InSpec compliance profile catalog offers a parallel path if your shop already standardizes on Chef, with maintained audit profiles including CIS Amazon Linux 2023 v1.0.0, CIS Red Hat Enterprise Linux 10 v1.0.0, and CIS Windows Server 2022 v4.0.0. Pick whichever automation stack your team already operates rather than introducing a second one just for compliance.
Step 9: Assess a Windows Server Against Its CIS Benchmark
Windows hardening follows the same audit-then-remediate pattern, but the tooling differs. CIS-CAT Lite and Pro both support Windows Server assessment, reading Group Policy state, registry keys, and local security policy settings directly.
# Run CIS-CAT against Windows Server from an elevated PowerShell prompt
cd C:CIS-CAT-Lite
.Assessor-CLI.bat -b benchmarksCIS_Microsoft_Windows_Server_2022_Benchmark_v4.0.0-xccdf.xml -p "Level 1 - Member Server" -aCIS confirms that Windows Server 2025 installation is supported inside current SecureSuite tooling, so if you are already on 2025 you can run the same assessor against it, using whichever benchmark profile CIS has published as current for that release at the time you run the scan.
Step 10: Remediate Windows Findings with Group Policy or PowerSTIG
For a handful of servers, apply fixes through a dedicated Group Policy Object scoped to a hardening OU, rather than editing local policy on each box by hand. For larger Windows estates, the open-source PowerSTIG module (built for DISA STIG compliance but overlapping heavily with CIS Level 1/2 controls) lets you apply and verify settings declaratively through PowerShell Desired State Configuration.
# Install PowerSTIG from the PowerShell Gallery
Install-Module -Name PowerSTIG -Scope AllUsers -Force
# Example: apply a Windows Server security policy configuration
Configuration HardenedServer {
Import-DscResource -ModuleName PowerSTIG
Node 'localhost' {
WindowsServer BaselineHardening {
OsVersion = '2022'
OsRole = 'MS'
StigVersion = '2.5'
}
}
}
HardenedServer -OutputPath .HardeningConfig
Start-DscConfiguration -Path .HardeningConfig -Wait -VerboseReboot the server after applying a batch of Windows security policy changes, several settings, including some account lockout and Kerberos policies, do not take effect until the next reboot even though the console reports success immediately.
Step 11: Re-Scan, Score, and Document the Baseline
Run your full scan suite again, OpenSCAP or CIS-CAT for the Linux boxes, CIS-CAT for Windows, and Lynis for a cross-check on Linux. Save every report with a timestamp and hostname in a version-controlled repository, not a shared drive folder that gets overwritten. This is the artifact an auditor will ask for six months from now when someone asks how you know the fleet is hardened.
Step 12: Extend Coverage to Containers and Cloud Workloads
CIS Benchmarks are no longer just an OS story. The CIS Docker Benchmark has reached v1.8.0 and the CIS Kubernetes Benchmark is at v1.12.0, both reflecting how much container-specific hardening guidance has grown, covering things like daemon socket exposure, image provenance, and pod security admission settings that a generic Linux benchmark never touches. Run docker-bench-security (the open-source implementation of the Docker benchmark) against your container hosts the same way you ran OpenSCAP against your VMs, and treat it as a separate scan, not a substitute for OS-level hardening on the underlying host, or the container image scanning you may already run with Trivy.
git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo sh docker-bench-security.shStep 13: Wire Scans into CI/CD So Drift Gets Caught Early
A one-time hardening pass decays. Configuration drift creeps back in through patches, new packages, and well-meaning admins loosening a setting to fix an unrelated problem. Schedule your OpenSCAP or Lynis scan as a recurring job, either a cron entry that emails a report or, better, a pipeline stage that fails a build if the hardening index or CIS pass rate drops below a threshold you define.
# Cron entry: nightly scan with a Slack-friendly summary
0 2 * * * root oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level1_server
--results /var/log/cis-scans/scan-$(date +%F).xml
/usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml
|| echo "CIS scan flagged new failures on $(hostname)" | mail -s "Hardening drift alert" secops@example.comComparing the Core Tools: CIS-CAT Pro vs Lite vs OpenSCAP vs Lynis
Each tool in this stack fills a different role, and most mature teams end up running more than one. The table below breaks down the practical differences you will run into once you move past a single test server.
| Tool | Cost | Coverage | Best For | Output |
|---|---|---|---|---|
| CIS-CAT Pro Assessor | SecureSuite membership, $2,400-$20,000/year by org size | Full CIS benchmark catalog, Level 1 and 2 | Enterprises needing full remediation content and support | HTML, CSV, ARF reports |
| CIS-CAT Lite | Free (registration required) | Limited set of benchmarks, assessment only | Small teams validating a single benchmark quickly | HTML, CSV reports |
| OpenSCAP + SCAP Security Guide | Free, open source | Wide Linux distro coverage via community content | Automating scan-and-remediate at scale on Linux | XCCDF results, HTML report, remediation scripts |
| Lynis | Free (open source), paid Enterprise tier for centralized reporting | System-wide audit beyond a single benchmark | Ongoing hardening index tracking and quick triage | 0-100 hardening index, text report log |
| PowerSTIG | Free, open source | Windows Server, IIS, SQL Server, .NET Framework | Declarative Windows hardening via DSC | DSC compliance reports |
Mapping CIS Benchmarks to NIST 800-53, DISA STIG, and PCI DSS 4.0
None of these frameworks are identical, but they overlap heavily enough that hardening work for one satisfies most of another. NIST Special Publication 800-53 Revision 5 defines control families like access control and configuration management at a policy level, while a CIS Benchmark tells you the exact registry key or config line that implements that policy on a specific OS. DISA STIGs serve a similar technical role to CIS Benchmarks but are written for U.S. Department of Defense systems and tend to be stricter by default, which is why PowerSTIG can apply both STIG and CIS-adjacent settings from the same underlying DSC resource. Reviewing the control language side by side is useful the first time you build a mapping spreadsheet, since NIST’s phrasing is deliberately abstract while a CIS rule reads more like a line from a runbook, and a team that only ever reads one of the two documents tends to either over-engineer the policy layer or under-specify the technical layer.
PCI DSS 4.0 does not mandate CIS Benchmarks by name, but its requirement to maintain configuration standards for all system components is commonly satisfied in practice by adopting CIS Benchmarks as that standard and documenting the scan evidence as your audit trail. If your compliance program touches cardholder data, treat the CIS scan reports from Step 11 as the artifact your QSA will want to see, not just an internal checklist. Keep a change log next to each scan report noting who approved a given remediation batch, since PCI assessors increasingly ask for approval records alongside the raw pass/fail output, not just the numbers themselves.
| Framework | Type | Relationship to CIS Benchmarks |
|---|---|---|
| NIST SP 800-53 Rev. 5 | Policy-level control catalog | CIS Benchmarks provide technical implementation for configuration-management controls |
| DISA STIG | DoD technical hardening standard | Similar structure to CIS, often stricter, some tools apply both together |
| PCI DSS 4.0 | Payment card industry requirement | Requires configuration standards, CIS Benchmarks commonly used to satisfy that requirement |
| CIS Controls v8 | CIS’s own higher-level control framework | CIS Benchmarks are the technical implementation layer beneath CIS Controls |
Common Pitfalls When Applying CIS Benchmarks
- Applying Level 2 everywhere by default. Level 2 controls can break monitoring agents, backup software, or legacy applications. Reserve Level 2 for systems that actually need it, and test thoroughly first.
- Skipping the pre-remediation snapshot. Some fixes, especially kernel module and network stack changes, are hard to reverse without a snapshot or backup taken before you started.
- Treating a benchmark for the wrong OS version as close enough. A CIS Ubuntu 22.04 profile run against 24.04 will report false failures and miss real ones, because package names, default configs, and even init behavior differ between releases.
- Chasing 100% compliance as the goal. Some rules will never apply to your environment or will legitimately conflict with a business requirement. Document exceptions with a justification instead of forcing every checkbox green.
- Running remediation directly in production on the first pass. Always validate on a staging clone first. A remediation script that disables an unused protocol can also disable a protocol a legacy integration quietly depends on.
- Never re-scanning after the initial project. Hardening without a recurring scan schedule guarantees silent drift within a few patch cycles.
- Ignoring the audit trail. Scan reports that get deleted after the project wraps up leave nothing to show an auditor or incident responder six months later.
Troubleshooting Common CIS Hardening Issues
- OpenSCAP reports “notchecked” for many rules. This usually means the OVAL check requires a package or capability not installed on the base image. Install the missing dependency (often
auditoraide) and re-scan. - SSH access breaks immediately after remediation. A remediation script may have disabled password authentication before key-based access was confirmed working. Always test key-based SSH login in a second terminal session before closing your first one.
- CIS-CAT Lite fails to launch with a Java version error. Confirm you are running JRE 11 or later with
java -version, older Java runtimes are a frequent cause of silent CIS-CAT crashes. - Lynis hardening index does not change after remediation. Lynis caches some results per session, so run
sudo lynis audit system --forcedto force a completely fresh audit rather than reusing cached findings. - A service stops after applying a Level 1 kernel module rule. Some monitoring or storage agents dynamically load kernel modules that a benchmark rule disables by default. Check the agent vendor’s documentation for a CIS-compatible configuration flag before assuming the rule is wrong.
- Windows Group Policy changes do not appear to apply. Run
gpupdate /forceand confirm withgpresult /rthat the policy is actually linked to the correct OU, misapplied policy links are the most common cause of “nothing changed.” - Ansible playbook reports success but the scan still shows failures. Confirm the datastream file path and profile ID in your playbook match the exact SCAP content version installed, a stale cached datastream from an old package version is a common mismatch.
- PCI QSA rejects your CIS scan report as insufficient evidence. Auditors typically want scan reports paired with a documented exceptions list and a remediation timeline for any outstanding findings, not just a raw pass/fail report.
- PowerSTIG configuration fails with a module version conflict. Run
Update-Module -Name PowerSTIG -Forceand confirm your target OsVersion and StigVersion parameters match a combination the module actually supports.
Advanced Tips: Keeping a Fleet Hardened Long-Term
Once the initial project is done, the real work is maintaining the baseline without it becoming a full-time job. Bake your hardened configuration into the golden image or base container layer your team already uses, so new instances launch compliant instead of needing a post-boot remediation pass. Track your CIS pass rate and Lynis hardening index as a metric in whatever dashboard your team already watches, next to patch compliance and vulnerability counts from a tool like the ones compared in our Tenable vs Qualys vs Rapid7 breakdown, so hardening drift gets the same visibility as an unpatched CVE.
Build an exceptions register for every rule you deliberately do not apply, with a short justification and an owner. When a new hire or an auditor asks why a specific control shows red, that register answers the question in seconds instead of triggering a research project. Finally, re-download the current benchmark version at least once a year, since CIS periodically retires older major versions, and a June 2026 profile like the Ubuntu 24.04 v2.0.0 release will eventually be superseded the same way it replaced v1.x content.
Building a Complete CIS Hardening Pipeline: A Working Project
Put the pieces from this tutorial together into a single repeatable pipeline you can hand to a new team member. The project below assumes a small Linux fleet managed through Ansible, with results collected centrally for audit purposes.
- Inventory: An Ansible inventory file grouping hosts by OS and sensitivity tier (public, internal, regulated).
- Baseline playbook: The Ansible playbook from Step 8, parameterized so
cis_profileswitches between Level 1 and Level 2 based on the host group. - Scan storage: A dedicated Git repository (or object storage bucket) that receives a timestamped scan report from every run, giving you a queryable history.
- Scheduled execution: A CI pipeline job (GitLab CI, GitHub Actions, or a simple cron-triggered Ansible run) that executes the baseline playbook weekly and fails loudly if the pass rate on any host drops more than 5 percentage points from the prior run.
- Alerting: An email or Slack webhook fired on scan failure, routed to the team that owns the affected host group.
- Quarterly review: A recurring calendar item to re-check the CIS Benchmarks catalog for new versions of every benchmark in use, and to review the exceptions register for entries that no longer need an exception.
# Simplified GitHub Actions workflow: scheduled CIS scan across the fleet
name: cis-hardening-check
on:
schedule:
- cron: '0 3 * * 1'
jobs:
scan:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
- name: Run CIS baseline playbook
run: ansible-playbook -i inventory/production cis-baseline.yml
- name: Archive scan reports
uses: actions/upload-artifact@v4
with:
name: cis-scan-reports
path: reports/This is intentionally a small, boring pipeline. The value is not in the tooling being clever, it is in the scan running on a schedule nobody has to remember, with a paper trail nobody has to reconstruct after the fact.
CIS Benchmarks for Cloud and AI Infrastructure in 2026
CIS’s benchmark catalog has grown well beyond classic server operating systems. Container-focused benchmarks for Docker and Kubernetes are now mature enough to be their own scanning category, distinct from OS-level hardening, and CIS continues to expand coverage into cloud provider configuration baselines. If your infrastructure includes managed Kubernetes or heavy container use, run the Docker and Kubernetes benchmarks as a separate workstream from this tutorial’s OS-focused steps, since the audit tooling, remediation patterns, and even the personnel who own the fix are usually different between a platform team and a systems team. Treat this tutorial’s Linux and Windows steps as the foundation layer underneath whatever container or cloud-specific hardening your platform team runs on top, and pair it with an identity-focused control layer such as zero trust network access if your fleet spans multiple clouds or a hybrid on-prem footprint.
Frequently Asked Questions
What is the difference between a CIS Benchmark and a CIS Control?
CIS Controls v8 are a higher-level set of prioritized security actions, like “inventory and control of enterprise assets.” CIS Benchmarks are the detailed, OS-specific technical settings that implement those higher-level controls on a given platform. You use the Controls to plan a program and the Benchmarks to execute the technical work.
Is CIS-CAT Lite good enough for a small business, or do I need Pro?
CIS-CAT Lite covers a limited set of benchmarks with assessment-only functionality, which is enough for most small teams to get an accurate picture of their current state. CIS-CAT Pro Assessor, available through a paid SecureSuite membership, adds the full benchmark catalog, automated remediation content, and dashboard reporting that larger organizations typically need to manage compliance across hundreds of hosts.
How often should I re-scan a server against its CIS Benchmark?
Weekly automated scans catch drift fast enough for most environments without generating alert fatigue. Regulated environments under PCI DSS 4.0 or similar frameworks often scan daily on in-scope systems, since the cost of undetected drift is higher when cardholder data is involved.
Will applying CIS Level 1 hardening break my applications?
Level 1 controls are specifically designed to be low-impact and broadly safe for production servers, but “low-impact” is not “zero-impact.” Always test on a staging clone first, and pay particular attention to monitoring agents, backup software, and any legacy service that depends on a protocol a benchmark disables by default.
Do CIS Benchmarks satisfy PCI DSS 4.0 requirements on their own?
CIS Benchmarks are commonly used to satisfy PCI DSS 4.0’s requirement for documented configuration standards, but the standard itself does not mandate CIS by name. Your QSA will want to see the scan reports, a documented exceptions process, and evidence that the standard is actually enforced, not just that a benchmark exists somewhere in a shared drive.
What is the difference between OpenSCAP and Lynis?
OpenSCAP scans strictly against a specific machine-readable benchmark profile (like a named CIS Level 1 profile) and can generate and apply remediation scripts automatically. Lynis runs a broader set of system checks that go beyond any single benchmark and produces a single hardening index score, making it better suited for a quick health check or trend tracking than for strict compliance evidence against a named standard.
Can I apply CIS Benchmarks to a Kubernetes cluster the same way as a Linux server?
No. The CIS Kubernetes Benchmark, currently at v1.12.0, covers control-plane and node-level settings specific to Kubernetes, like API server flags and pod security admission configuration, that a generic Linux OS benchmark does not address. Run it as a separate scan using a tool built for Kubernetes, such as kube-bench, in addition to hardening the underlying node OS with the Linux steps in this tutorial.
What score should I aim for on my first hardening pass?
Do not chase 100%. A realistic first-pass target for Level 1 controls is 85-90% compliance, with the remaining findings documented as exceptions with a business justification. Forcing every single rule to pass, including ones that conflict with a real operational need, tends to create more risk than it removes.
