CIS Benchmarks vs DISA STIGs: which one a buyer needs
When a contract, federal authorization or commercial customer names a hardening standard, the first step is to find out whether it names a CIS Benchmark profile or a DISA STIG. The two are related but not interchangeable. CIS Benchmarks include a STIG profile, which contains the STIG-specific recommendations plus overlapping Level 1 and Level 2 recommendations where applicable, while DISA STIGs are a separate catalog published by DISA. The required standard depends on the exact wording of the requirement, so ask the customer or assessor which document, version and profile they will test against before choosing a configuration baseline.
Responsibility splits three ways. The organization owns its configuration decisions, including which profile applies, which deviations it accepts and who signs off on them. An implementation partner such as DeployOpen can prepare and document the hardened systems, including the settings, the deviation records and the scan output that supports them. Only an independent assessor or the authorizing body can judge whether the configuration meets the named requirement and issue any assessment result. Confirm that split in the statement of work so no one assumes the hardening work itself is the attestation.
Before scoping, check three points with the customer: whether they name a CIS Benchmark, a STIG profile or a DISA STIG by title; whether they accept CIS STIG Benchmarks or CIS STIG Hardened Images as equivalent; and which Benchmark version and operating system release they will test. Recognition also differs by buyer. CIS states that its Benchmarks are recognized by standards bodies and programs such as the DoD Cloud Computing SRG, FedRAMP and PCI DSS, and that this recognition extends to CIS Hardened Images. Federal buyers often name DISA STIGs directly, so confirm with the contracting officer or authorizing official whether a CIS-based baseline is accepted in place of the DISA document.
How the STIG profile, CIS STIG Benchmarks and DISA STIGs relate
The STIG profile is a profile within a CIS Benchmark, not a separate document. It replaced the former Level 3 profile and combines the recommendations that are specific to STIG alignment with the Level 1 and Level 2 recommendations that overlap with them where applicable. Every recommendation in a Benchmark belongs to at least one profile, so the STIG profile is one way of selecting items from the same Benchmark rather than a different set of technical content.
- Replacement of Level 3: Organizations that previously referenced Level 3 in a Benchmark should read the STIG profile in its place when their requirement names STIG alignment.
- Composition: The profile includes STIG-specific recommendations plus overlapping Level 1 and Level 2 recommendations, which means it is not simply Level 2 with extra items.
- Profile membership: Each recommendation belongs to at least one profile, so a single setting can appear under Level 1, Level 2 and STIG at the same time.
- Scanning: A scan must be run against the STIG profile specifically to report results for it; a Level 2 scan does not establish STIG profile results.
- Deviations: Any STIG profile item the organization does not implement should be recorded as a documented deviation with a reason and a compensating measure.
Before committing, confirm with the assessor whether the STIG profile in a Benchmark satisfies the requirement or whether a DISA STIG itself is expected.
CIS STIG Benchmarks are standalone Benchmarks in the CIS Benchmarks catalog, held in a separate DISA STIG category. Each is built to map to a corresponding DISA STIG so that the CIS recommendations can be traced to the STIG requirements they cover. The catalog lists dozens of these, for example the Ubuntu Linux 22.04 LTS STIG Benchmark. They are distinct from the STIG profile inside a general Benchmark, so a team that has applied an Ubuntu 22.04 Benchmark at Level 1 has not necessarily applied the Ubuntu 22.04 LTS STIG Benchmark.
- Example: The Ubuntu Linux 22.04 LTS STIG Benchmark is the CIS artifact to name when a contract refers to the Ubuntu 22.04 configuration built on the DISA STIG.
- Mapping: The Benchmark is based on DISA STIG standards, so each recommendation is intended to correspond to a STIG requirement.
- Access: Confirm the licensing and download terms for each STIG Benchmark in the catalog, since free use terms differ from those that require SecureSuite membership.
- Scanning: Use a tool that reports against the STIG Benchmark version specifically, and retain the version in the scan report.
- Version tracking: Record the Benchmark version in the secure configuration baseline so the mapping can be checked against the DISA STIG version an assessor references.
Confirm the exact Benchmark title and version a contract names, and ask the assessor whether a mapping table between the Benchmark and the DISA STIG is acceptable evidence.
CIS STIG Hardened Images are machine images built on the CIS STIG Benchmarks that are mapped to DISA STIG standards. They are a delivery form for the configuration rather than a separate standard. The image carries the configuration in its build, which can shorten the time to a baseline on new systems, but the owner still needs to show that the running instances keep the configuration over time.
- Source: The image is based on the mapped CIS STIG Benchmark, so the Benchmark version is the reference point for assessing it.
- Recognition: CIS states that recognition of the CIS Benchmarks as a secure configuration standard extends to CIS Hardened Images, but the buyer should confirm which recognition applies to the specific STIG variant named in a contract.
- Drift: Image configuration can change after launch through updates, package changes or administrator actions, so periodic scanning of running instances is still required.
- Customization: Local changes made after the image is built become deviations that need documentation.
- Sourcing: Confirm where the image is obtained and how it is updated, since availability and terms vary by cloud platform and by image.
Identify which CIS STIG Benchmark version an image was built from, and ask the assessor whether that image, plus scans of its running instances, is sufficient evidence for the requirement.
Which standards recognize CIS Benchmarks, and what that means for federal and commercial buyers
CIS states that its Benchmarks are recognized as a secure configuration standard by several federal and commercial frameworks, and that this recognition extends to CIS Hardened Images. Recognition is a starting point for the assessment, not a finding in itself, so each card below points to the question to settle with the assessor or contracting office.
Federal cloud and authorization recognition
CIS states that the CIS Benchmarks are recognized by the DoD Cloud Computing Security Requirements Guide, FedRAMP and FISMA. For a cloud service provider or federal contractor, this recognition matters when a secure configuration baseline must be documented for an authorization package. Ask the authorizing official or assessor which Benchmark version and profile they accept, and whether the same baseline applies to every system boundary in scope.
Commercial payment and banking recognition
CIS states that the CIS Benchmarks are recognized under PCI DSS and FFIEC. Commercial buyers in card payments and financial services often check these two recognitions first, because the baseline supports the configuration evidence an assessor requests. Confirm with the Qualified Security Assessor or examiner whether the recognition covers your specific operating system, cloud image and profile, since a general statement of recognition does not settle that question.
NIST and National Checklist Program references
CIS states that the Benchmarks are recognized by NIST and the National Checklist Program Repository. These references matter when a buyer asks for a checklist that maps to published federal guidance, and they are often cited in risk assessments and vendor questionnaires. Ask the buyer whether a checklist reference satisfies the requirement or whether a specific named checklist version must be supplied as evidence.
Recognition extends to CIS Hardened Images
CIS states that its recognition extends to CIS Hardened Images, which are built from CIS STIG Benchmarks mapped to DISA STIG standards. A buyer who accepts the Benchmark recognition may still ask for proof that the image in use is the one covered. Record the exact image name, version and build date in the configuration evidence, and confirm with the assessor that the image and the underlying Benchmark version are both in scope.
Federal buyers and DISA STIG requirements
Federal buyers usually start by asking whether DISA STIG content is required for the system, not whether a CIS Benchmark is acceptable. Where a DISA STIG is mandated, the STIG profile inside a CIS Benchmark or a CIS STIG Benchmark may be offered as the matching baseline, but the contracting office must accept it in writing. Ask which STIG release and checklist format the authorization requires before selecting a profile.
Commercial buyers and the evidence request
Commercial buyers usually ask whether a configuration baseline is recognized under a framework they already must meet, such as PCI DSS or FFIEC, and then request the scan output. The evidence that answers this is a dated scan report against a named Benchmark version and profile, plus recorded deviations. Confirm with the assessor which scanner output and report format they will accept before the scan begins.
Which hardening artifact to pick when a contract names STIG
If a contract, task order or authorization names a DISA STIG explicitly, start with the STIG itself. The named STIG decides the artifact: either the STIG profile inside a CIS Benchmark, which CIS offers as the successor to the former Level 3 profile, or a separate DISA STIG Benchmark from CIS's catalog, such as the Ubuntu Linux 22.04 LTS STIG. Ask the contracting officer or assessor which of these they will accept, and whether a CIS STIG Hardened Image is acceptable in place of a configuration you build yourself. Do not assume that a Level 1 or Level 2 profile satisfies a clause that names a STIG, because the profile names are different products with different scopes.
If the contract instead accepts a secure configuration standard without naming DISA, a CIS Benchmark with an appropriate profile may satisfy it, provided the buyer recognizes CIS Benchmarks for that engagement. The profile choice is where operational risk sits. The Level 1 profile is designed as a base that can be implemented fairly quickly with minimal performance impact, so it is the sensible first target for production estates. The Level 2 profile is defense in depth for environments where security is paramount, and CIS warns that it can harm operations if applied without care. Before selecting Level 2 for any system, test it in a non-production copy, confirm which services and integrations depend on the affected settings, and record each deviation you accept through your secure configuration process, with an owner and a review date.
The practical check is to compare the contract's named standard with the profile you plan to deploy, then document the mapping in your system security plan or equivalent record. Ask the buyer to confirm the exact benchmark version and profile they will assess against, and keep the scan output from a tool such as CIS-CAT or an open-source checker as evidence. The organization owns the decision and the deviations. An implementation partner can prepare the hardened builds and evidence, but only the buyer's assessor or authorizing official can accept that the configuration meets the named requirement.
How the team moves from the chosen Benchmark to assessed configuration
The sequence turns a chosen CIS Benchmark or DISA STIG profile into a tested, documented and applied configuration, with evidence that an independent assessor can review. The organization owns each decision, and the implementation partner prepares the systems and records.
Confirm the required standard and version
Before any hardening starts, the organization confirms with its assessor or contracting customer which standard applies, whether that is a CIS Benchmark, a DISA STIG profile, or a CIS STIG Benchmark, and which version is in scope. Ask the assessor to state in writing whether a CIS Benchmark profile is accepted for the requirement or whether the STIG itself is expected. The output is a short written scope note naming the Benchmark, version, platforms and the assessor's acceptance. The step is done when that note is signed off by the control owner.
Select the profile for each asset class
The team maps each in-scope platform to a profile. Level 1 is the base profile intended to be implemented with minimal performance impact, while Level 2 adds defense in depth and can disrupt operations if applied without care. Where a STIG profile is required, it includes the STIG-specific recommendations plus overlapping Level 1 and Level 2 recommendations where applicable. The output is a profile register listing each system, Benchmark, version and chosen profile, reviewed by the platform owner and security lead.
Test the configuration in a non-production environment
The implementation partner builds a non-production copy of each platform image or template and applies the selected profile. The team checks that applications, services, logging, authentication and backups still work, and records any recommendation that breaks a required function. A scan of the test build, run with the chosen tool, shows the baseline result. The step is complete when the platform owner accepts the test results in writing and the tested configuration is stored as code or a versioned image.
Document deviations in the secure configuration process
Every recommendation that the team does not apply, or applies differently, goes into a deviation record. Each record names the Benchmark recommendation, the system, the reason, the compensating control, the risk owner and a review date set by the organization. The deviation register sits inside the secure configuration process that the organization documents under CIS Control 4. The output is an approved deviation log that the assessor can trace back to the decision and the person who accepted the risk.
Apply the configuration to production systems
The team deploys the approved configuration through the organization's normal change process, using the tested image, template or configuration management code rather than manual edits. Changes are tied to change tickets and the deviation register is attached. The implementation partner keeps a record of which systems received which build. The step is done when a sample of production systems shows the approved configuration and each change has an authorized ticket.
Scan production and keep the output as evidence
After deployment, the team runs the chosen scanning tool against production systems and stores the reports with dates, Benchmark version, profile and host identifiers. Failed checks are either remediated or matched to an approved deviation. The organization retains scan output on a schedule it sets, so the assessor can compare configuration over time. Scan results alone do not prove the process works, so the output is paired with the scope note, profile register and deviation log.
Repeat the cycle when the Benchmark or standard changes
When CIS or DISA publishes a new Benchmark version or STIG release, or the assessor's requirement changes, the team reruns the sequence from the scope note. The impact on existing deviations is reviewed, and the profile register and test records are updated. The output is a revised scope note and change record that shows which systems moved to the new version and which deviations were retired or renewed.
Who owns the configuration, who prepares it and who assesses it
A CIS Benchmark or DISA STIG setting does not become compliant by being copied onto a server. Four parties each carry a different part of the work: the organization decides and accepts risk, a partner prepares systems and evidence, an independent assessor tests and reports, and the publishers maintain the content itself.
The organization owns decisions
The organization chooses which Benchmark or STIG profile applies, approves each deviation and accepts the residual risk. Those decisions belong in its secure configuration process, signed by a named owner, with a reason for every recommendation that is not applied. Check that your policy names who may approve a deviation and how long an accepted exception stays valid before it is reviewed again.
The partner prepares hardened systems
An implementation partner such as DeployOpen can build baselines, apply the chosen profile in your cloud accounts or data centers, run scans and assemble evidence packs for the assessor. The partner works inside the scope and the decisions the organization has already made. It does not set the risk position or sign off on compliance. Ask for the scan configuration, the deviation register and the change log in the handover.
The assessor tests and reports
An independent auditor, assessor or certification body tests the configuration and issues any report or certificate. Assessors look at the actual running state, the documented process and the approvals behind each deviation. DeployOpen prepares systems, controls and evidence for these assessments but does not issue audit reports, attestations or certifications. Confirm early which assessor your customer or regulator accepts.
CIS and DISA publish the content
CIS publishes the CIS Benchmarks, including the STIG profile inside them and the separate CIS STIG Benchmarks. DISA publishes the STIGs that federal systems follow. Both publishers maintain the recommendations and versions, so your team must track which release each host was checked against. Confirm which version your assessor expects before you start hardening.
Questions buyers ask about CIS Benchmarks and DISA STIGs
Is a CIS Benchmark the same as a DISA STIG?
No. A CIS Benchmark is a consensus configuration guide published by the Center for Internet Security, while a DISA STIG is a configuration standard published by the Defense Information Systems Agency for Department of Defense systems. They overlap heavily, and CIS Benchmarks include a separate DISA STIG category with dozens of STIG Benchmarks, such as the Ubuntu Linux 22.04 LTS STIG. The buyer's question is which document their assessor or contract names. Check the requirement text first, then confirm with the assessor which version and profile they will accept. Start from the CIS Benchmarks catalog to see which STIG Benchmarks are available for your platform.
Does the STIG profile replace Level 3 in CIS Benchmarks?
Yes. The STIG profile replaced the former Level 3 profile. It includes all STIG-specific recommendations plus overlapping Level 1 and Level 2 recommendations where they apply. Every recommendation in a CIS Benchmark belongs to at least one profile, so a team moving from Level 3 should map its existing settings to the STIG profile and check that nothing it relied on has changed. Confirm the exact profile definitions in the current Benchmark version before you plan the change, because a STIG profile can require settings that Level 1 or Level 2 deployments do not yet have. Record any deviations in your secure configuration process so an assessor can see why a setting differs.
Can CIS Hardened Images satisfy a STIG requirement?
CIS Hardened Images can support a STIG requirement, but they do not satisfy it automatically. CIS offers STIG Hardened Images based on CIS STIG Benchmarks that are mapped to DISA STIG standards, and CIS states that recognition of the CIS Benchmarks extends to CIS Hardened Images. The system owner still decides whether the image matches the authorizing body's required STIG version, what is applied after launch, and how drift is detected. Ask the authorizing official or assessor which STIG version and checklist they accept, then compare that against the image's documented configuration. Evidence of the image build and of ongoing scans is what the assessor will review.
What does the organization have to do itself?
The organization owns its controls and its authorization decision. Key tasks it must keep in-house include:
- Deciding which Benchmark, profile and version applies to each system type and documenting that choice.
- Approving deviations and accepting the residual risk they create.
- Running the configuration process, change control and scanning on its own systems.
- Keeping the evidence current for the assessor.
An implementation partner can prepare hardened builds, scanning pipelines and evidence packs, but it does not own those decisions or issue assessment results. An independent assessor or the authorizing body reviews the outcome.
How long does it take to implement a STIG or Benchmark profile?
The duration depends on the number of systems, how many platforms they run, how much custom software depends on the current settings, and how much testing the change board requires. Level 1 is designed as a base profile that can usually be implemented fairly quickly with minimal performance impact, while Level 2 and STIG-level changes need more testing because CIS warns Level 2 can harm operations if applied without care. Ask any partner for a written scope that lists platforms, Benchmark versions, the number of hosts and the test environments, then compare the timeline against those items. DeployOpen does not publish a fixed timeline; a timeline follows from the written scope agreed before work starts.
What does hiring a partner cost, and what drives the price?
Cost has several parts: the work to build hardened configurations, the scanning and reporting setup, the testing of changes against applications, the documentation of deviations, and any ongoing support. Some of these are one-time, such as the initial build and documentation, while scanning, patching of baselines and re-testing recur with each Benchmark release. Costs rise with the number of platforms, the depth of custom software and the number of environments. Ask for a quote that separates one-time and recurring items and states which Benchmark versions and profiles are in scope. DeployOpen does not publish a price list; a quote follows from the written scope.
Where STIG and CIS projects stall and how to avoid it
Most stalled hardening projects trace back to one of four decisions made early: treating the two hardening standards as interchangeable, switching on the strictest profile without testing, leaving deviations undocumented, or presenting a hardened image as the whole evidence set. Each card names the risk, what it does to the project and the check that prevents it.
Assuming the names are interchangeable
A CIS Benchmark and a DISA STIG are different documents from different publishers, even though CIS Benchmarks include a STIG profile and a separate DISA STIG category. Teams that cite a "CIS-hardened" or "STIG-compliant" build without naming the exact Benchmark, version and profile cannot show an assessor which recommendations were applied. Before work starts, write down the single baseline each system must meet and the recognition your contract or authorization expects.
Applying Level 2 without testing
Level 2 is defense in depth for environments where security is paramount, and CIS warns that it can harm operations if applied without care. Enabling it across a fleet in one change window is the most common cause of outages in hardening projects. Start with Level 1 on a representative test group, record every service or workflow that breaks, and roll Level 2 items out in stages with a documented rollback for each.
Missing deviation records
Some recommendations will not fit a system, for example a legacy application that needs a service the Benchmark disables. An assessor will not accept an unexplained gap. Each deviation needs the affected system, the recommendation, the business reason, the compensating control, an approver and a review date. Ask your team to confirm where these records live and who reviews them before the first assessment.
Treating a hardened image as all evidence
A CIS Hardened Image gives a known starting configuration, but it does not show that the running system stayed in that state. Patches, configuration drift, added packages and emergency changes all move a host away from its baseline. Keep scan results from a tool such as CIS-CAT or an open-source checker for each host over time, along with build records and change tickets, so the image is one input to the evidence set rather than the whole of it.
How DeployOpen scopes and documents Benchmark hardening
DeployOpen starts every Benchmark or STIG hardening engagement by agreeing the artifact in writing. That means naming the exact CIS Benchmark or DISA STIG Benchmark version, the profile (Level 1, Level 2 or the STIG profile where it applies), the systems in scope and the deliverables before any configuration changes are made. The reader should expect the scope document to record which recommendations are being implemented, which are excluded and why, and who approves each deviation. Where a client is deciding between a STIG-profile build and a CIS STIG Hardened Image, that choice belongs in the scope document too, because it determines the source of the baseline and the scan evidence that follows.
Inside the client's own cloud accounts, data centers or air-gapped networks, DeployOpen implements the agreed configuration, documents each change against the Benchmark recommendation it addresses, and records the exceptions with their operational reason. Scan evidence is prepared by running the scanner the client has agreed to use, such as CIS-CAT or an open-source tool, against the hardened systems and retaining the raw output alongside a summary. The handover package typically includes the scope document, change records, exception register and scan reports. DeployOpen does not issue assessment results, attestations or certifications. An independent assessor or certification body decides whether the evidence meets the relevant recognition or requirement.
Before engaging, ask any provider to confirm four things in writing: which Benchmark and profile version the work targets, who holds the scanner licenses and any SecureSuite membership required for the scanning tool, how exceptions are approved and retained, and who owns the ongoing configuration drift checks after handover. Those answers determine both the quote and whether the evidence will hold up when a federal customer, a PCI assessor or a FedRAMP reviewer asks for it. Scope, deliverables and timelines are fixed in writing before work starts, and any change to scope is recorded the same way.
