CIS Benchmarks vs DISA STIGs: Choosing a Hardening Baseline

Most organisations pick a hardening baseline by habit or by whatever their scanner ships with, and only find out it was the wrong one when a contract, an assessor or a broken application forces a rebuild. CIS Benchmarks and DISA Security Technical Implementation Guides (STIGs) both turn "configure securely" into thousands of testable settings, but they come from different places, answer to different authorities and break systems at different rates. This guide is the decision page: which baseline your obligations actually require, how strict each one is in practice, how they map onto each other, and how to run a single tooling and exception pipeline when you must evidence both. It assumes you know what each standard is; for the anatomy of a benchmark recommendation or a STIG rule, see the CIS Benchmarks Guide and the DISA STIG Guide. It is written for platform engineers, compliance leads and security architects choosing or defending a baseline.

Key takeaways

• Obligation decides first, preference second. DoD systems must follow applicable STIGs; FedRAMP Rev. 5 tells cloud providers to use DoD STIGs, then CIS up to Level 2 where no STIG exists; almost everyone else is free to choose.
• Strictness is not the same as security value. STIGs and CIS Level 2 cover much of the same ground, but STIGs add DoD specific requirements such as PKI authentication, FIPS mode and banner text that cost effort without always reducing risk outside defence.
• The two are mapped, not identical. CIS publishes STIG profiles that carry DISA Vulnerability IDs, Rule IDs and severity, but a CIS STIG profile is CIS content, not the DISA artefact, so contract evidence may still need DISA checklists.
• One pipeline can serve both. SCAP content such as the SCAP Security Guide ships CIS and STIG profiles over a shared rule set, so you can build once, tailor per profile and report against either.
• Exceptions are where the real cost sits. A STIG deviation in DoD goes to the authorising official and the POA&M; a CIS deviation goes to your own risk process. Design one register keyed to both identifiers.

The short answer

If a contract, authorisation or regulator names STIGs, use STIGs for every product that has one, and fall back to the matching Security Requirements Guide (SRG) where it does not. If you are a cloud service provider pursuing FedRAMP, the FedRAMP Rev. 5 baseline makes the order explicit: DoD STIGs first, CIS guidelines up to Level 2 where STIGs are not available, then a documented custom baseline. If nothing names either, use CIS Level 1 as the estate default and CIS Level 2 for defined high value asset classes, because CIS covers far more products, is written for commercial operating models and is what most customer questionnaires and cyber insurers recognise.

Side by side

Obligations by sector

Start with the documents that bind you, not with the baselines. The table summarises the usual positions; the contract or authorisation package always wins.

Threat model and design intent

CIS Benchmarks

CIS writes for a general enterprise adversary: commodity malware, credential theft, lateral movement and misuse of default services. Level 1 targets settings that reduce attack surface with little operational impact, so it can be applied broadly and quickly. Level 2 assumes a higher value target and accepts more breakage for defence in depth. The architecture is a product benchmark per version, profiles split by role (domain controller, member server, workstation), and a consensus process that tracks vendor releases. The design intent is adoption at scale across heterogeneous estates, which is why coverage reaches SaaS tenants and DevSecOps tooling.

DISA STIGs

STIGs are written for a nation-state adversary against systems on DoD networks, inside an operating model that already includes DoD PKI, approved cryptography, centralised audit and an authorising official who signs off risk. The architecture is layered: SRGs state technology-class requirements traced to NIST SP 800-53 through CCIs, and product STIGs translate them into checks and fixes. The design intent is assurance and accountability: every rule produces a recorded status that feeds the Risk Management Framework package.

That difference explains most of the friction. A STIG rule that assumes smart card logon or a DoD consent banner is cheap inside DoD and expensive outside it. A CIS Level 1 setting that leaves a legacy protocol available for compatibility is reasonable for a retailer and unacceptable on a classified network.

Strictness and breakage risk

For a typical server operating system, CIS Level 1 and the STIG overlap heavily on account policy, audit settings, service minimisation and file permissions. The difference concentrates in a few areas, and these are where applications break.

As a planning rule, treat Level 1 as a change, Level 2 as a project, and a full STIG as a programme with application owner sign-off per system class. The strict areas are also mostly identity and cryptography rules, so involve service account and certificate owners first.

How the two map onto each other

• CIS STIG profiles: CIS publishes STIG benchmarks for selected operating systems and a STIG profile that replaced the former Level 3. CIS describes the profile as including the STIG-specific recommendations plus overlapping Level 1, Level 2 and Next Generation recommendations, with CAT I, II and III variants in its hardened images. Each STIG-derived recommendation lists the STIG release, version and date, the Vulnerability ID, Rule ID, STIG ID and severity, and CIS marks where a STIG requirement contradicts a CIS recommendation.
• Shared SCAP rule sets: the SCAP Security Guide (ComplianceAsCode) ships, for example, a "CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Server" profile aligned to CIS benchmark v2.0.0 and a "DISA STIG for Red Hat Enterprise Linux 9" profile aligned to V2R10. Both select from the same rule library, so a rule such as an SSH or audit setting is one implementation reported under two baselines.
• Framework identifiers: STIG rules carry CCIs that trace to NIST SP 800-53; CIS recommendations map to CIS Controls safeguards. To answer "which STIG rules does our CIS baseline already satisfy", join on the shared technical setting, not on the framework identifiers.
• What mapping cannot do: a CIS STIG profile is not the DISA STIG artefact. If your contract or authorising official requires DISA checklists, a CIS-CAT report against the CIS STIG profile is supporting evidence, not a substitute. Ask before you build on it.

Tooling: one pipeline for both

Organisations that must evidence STIGs for one customer and CIS for everyone else should not run two hardening programmes. The workable architecture is a single build and assessment pipeline with per-profile reporting.

1. Choose a rule library as the source of truth. For Linux, the SCAP Security Guide profiles shipped with the distribution; for Windows, DISA GPO packages or CIS build kits as the starting point, managed in Group Policy, Intune or Desired State Configuration. Record which source owns each setting.
2. Build to the stricter profile where you share images. If one image serves both commercial and government tenants, build to the STIG or CIS Level 2 and tailor down for commercial workloads only where a documented application need exists. Image pipelines are covered in the Server Build and Golden Image Hardening Guide.
3. Tailor in files, not by hand. Use XCCDF tailoring files for SCAP tools and WorkBench tailoring for CIS-CAT, kept in version control alongside the image code, so every deviation is reviewable and reproducible.
4. Assess with the tool the evidence consumer trusts. DISA SCAP benchmarks in SCAP Compliance Checker plus STIG Viewer checklists for DoD evidence; CIS-CAT Pro for CIS reports mapped to the CIS Controls; OpenSCAP for pipeline gates. FedRAMP requires checklists that are SCAP validated or SCAP compatible. See the SCAP and Security Content Automation Guide and the OpenSCAP and Linux Compliance Scanning Guide.
5. Pin versions to the platform. Red Hat maps each RHEL minor release to a specific STIG release (for example V2R9 for several RHEL 9 minor releases) and advises using only the profiles shipped with that minor release.
6. Normalise results. Feed SCC, CIS-CAT and OpenSCAP output into one store keyed by asset, rule and profile, so a dashboard can show CIS score and open CAT I findings from the same data.
7. Gate and roll back. Fail the image build on regression against the tailored profile; apply to running systems in rings; keep separate GPOs per baseline on Windows and version-controlled remediation on Linux so rollback is an unlink or a revert. Drift handling is in the Configuration Drift and Baseline Enforcement Guide.

Treat the scanner credential as a privileged non-human identity: credentialed SCAP and CIS-CAT scans need administrative or sudo access to every target, so use a dedicated account, vault its secret and restrict where it can log on from.

Update cadence and version control

CIS versions each benchmark (for example v2.0.0) and new versions can renumber recommendations; DISA numbers STIGs by Version and Release (for example V2R10), with releases incremental and new versions restructuring. Key exceptions to stable identifiers (the STIG Vulnerability ID, the CIS recommendation title plus benchmark version), record the version in the configuration standard and every report, and on each release re-assess and diff results rather than re-reviewing every rule.

Exception handling across both

Exceptions are inevitable with either baseline and are what assessors scrutinise. Run one register rather than one per standard.

• Key: asset class, setting, CIS recommendation reference and STIG Vulnerability ID where both apply.
• Disposition: not applicable (with reason), deviation with compensating control, or risk accepted with expiry.
• Approver: internal risk owner for CIS; for STIG systems in DoD, the authorising official, with open items carried on the POA&M (NIST SP 800-53 CA-5). Under FedRAMP, compliance check findings are analysed by the 3PAO at assessment and may be grouped into a single CM-6 POA&M item during monthly continuous monitoring.
• Encoding: the exception is also expressed in the tailoring file so it does not reappear as a failure, but the tailoring file never replaces the register.

The Hardening Exceptions and Compensating Controls Template gives a ready structure.

Decision guidance and worked scenarios

• Choose STIGs when: a contract, DoD authorisation or FedRAMP baseline requires them; you operate in a DoD-like model with PKI and FIPS already in place; or customers will audit you against DISA checklists.
• Choose CIS when: no obligation names STIGs; you need coverage of SaaS, cloud accounts or tools that have no STIG; or you want a graded path (Level 1 now, Level 2 for crown jewels).
• Choose CIS STIG profiles when: you need STIG alignment on public cloud images quickly and your customer has confirmed CIS content is acceptable evidence.
• Small organisations: one baseline, Level 1, through images or build kits; running both adds cost without benefit.
• Large or mixed organisations: one pipeline, profiles per enclave, and a shared exception register, as above.

Scenario 1, SaaS provider entering FedRAMP Moderate. The commercial estate runs CIS Level 1. For the FedRAMP boundary, the provider builds RHEL and Windows images to the STIG profiles, uses CIS Level 2 for the managed database and container platform where no STIG fits, and documents a custom baseline for an in-house component. SCAP-validated scanning runs monthly; findings feed one CM-6 POA&M item. Commercial images move to Level 2 for internet-facing services so the two estates share most of their code.

Scenario 2, engineering firm handling CUI under CMMC Level 2. No contract names STIGs. The firm adopts CIS Level 1 for workstations and Level 2 for servers in the CUI enclave, maps the tailored profiles to 03.04.01 and 03.04.02, and keeps STIG checklists only for the one programme whose prime requires them. See the CMMC Scoping Guide.

Scenario 3, commercial bank wanting "STIG grade" servers. Applying the full STIG introduces DoD banners and PKI dependencies with no regulatory benefit. The bank adopts CIS Level 2 and selectively adds STIG rules for audit and cryptography, recording the source of each added rule.

Detection and measurement

• Baseline coverage: percentage of in-scope assets with an assigned baseline and profile (target 100 percent).
• Conformance by profile: CIS score against the tailored profile and count of open CAT I findings on STIG systems (target zero CAT I).
• Version currency: share of assets assessed against the current benchmark version or STIG release.
• Exception health: exceptions past expiry or missing a POA&M or risk reference (target zero).
• Drift rate: new failures between scheduled assessments on assets that previously passed.

Log the build pipeline gate results, configuration management changes to hardening settings, and changes to tailoring files, so a sudden score change can be tied to a commit.

Common failure patterns

• Assuming CIS STIG equals DISA STIG. Teams buy CIS STIG hardened images for a DoD contract, then learn the authorising official wants DISA checklists.
• Applying a full STIG to a commercial estate. FIPS mode and PKI rules break integrations; exceptions pile up until the baseline is abandoned.
• Running two unconnected programmes. Separate CIS and STIG teams remediate the same setting twice and keep conflicting exception records.
• Unpinned versions. Scanner content updates silently to a new release, scores drop, and nobody can tell drift from content change.
• Exceptions only in the scanner. Rules disabled in a tailoring file with no reason, approver or expiry fail at audit.
• Ignoring manual rules. Automated scores look healthy while the manual checks that SCAP cannot test remain Not Reviewed.

Framework mapping

Practitioner checklist

• List every contract, authorisation and framework that binds each system and record whether it names STIGs, CIS or neither.
• Assign a baseline and profile per asset class and enclave, and write it into the configuration standard with the version.
• Confirm with the customer or authorising official whether CIS STIG content is acceptable evidence before relying on it.
• Pick one rule library per platform and build images to the strictest profile you must evidence.
• Keep tailoring files in version control next to image and configuration code.
• Run one exception register keyed to both CIS references and STIG Vulnerability IDs, with approver and expiry.
• Pin benchmark and STIG versions to platform releases and re-assess on every new release.
• Normalise SCC, CIS-CAT and OpenSCAP results into one store and report both CIS score and open CAT I findings.
• Treat scanner and configuration management accounts as privileged non-human identities.

Standards and references

• FedRAMP: Rev. 5 Moderate Baseline Profile (OSCAL)
• NIST: SP 800-70 Rev. 5, National Checklist Program for IT Products
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: SP 800-171 Rev. 3, Protecting Controlled Unclassified Information
• CIS: How to Meet STIG Compliance and Achieve OS Security with CIS
• CIS: Hardened Images Glossary (Level 1, Level 2 and STIG profiles)
• Red Hat: DISA STIG for Red Hat Enterprise Linux
• ComplianceAsCode: SCAP Security Guide content

Related NHI Mgmt Group resources: CIS Benchmarks Guide, DISA STIG Guide, Microsoft Security Baselines and Security Compliance Toolkit Guide, NIST SP 800-53B Control Baselines and Tailoring Guide.