CIS Benchmarks explained: what they are and how to use them

What are CIS Benchmarks, and do you need to pay for them?

When a customer, contract or regulator asks for a secure configuration standard, the short answer is this: CIS Benchmarks are prescriptive hardening recommendations for specific products and platforms, and the PDFs are free to download. You pay only when you need formats that are easier to load into tooling, or tailoring support, which requires a SecureSuite membership. Before you buy anything, confirm which Benchmark, version and profile the requesting party actually cites, because the free PDF and a membership-only format carry the same recommendations. The organization owns its configuration decisions. Choosing which Benchmark applies, which profile to adopt, which recommendations to accept, and which to document as deviations is your job, and so is the evidence that the settings are in place and stay that way. A Benchmark is not a certification and does not make a system compliant with anything by itself. Only an independent auditor, assessor or certification body issues a report or attestation on your configuration. DeployOpen can help prepare hardened systems and the supporting evidence, but it does not issue those reports. The practical next step is to inventory the technologies in scope, map each one to the Benchmark family that covers it, and check the Benchmark's own terms and version history on the CIS site before you start. Ask your assessor early which Benchmark version and profile they will accept, since that answer determines whether you need tailoring, membership or only the free PDFs.

How the consensus process produces a CIS Benchmark

The consensus sequence turns secure configuration recommendations for one technology into a published Benchmark that any organization can download and check its systems against. Each phase has a defined output, and the published version reflects the community's work on the platform it covers.

Gather volunteers, experts and vendors
Volunteers, subject matter experts, vendors and community members take part in developing a Benchmark for a specific technology. They work through CIS WorkBench, where the discussion for that technology is kept. The output is a working group with a shared scope: the product, version and configuration areas the Benchmark will cover. Before moving on, confirm with CIS which participants are contributing to the Benchmark you plan to use, since membership and roles are set by CIS and the community.
Share vendor and community input
Vendors and community members propose settings, explain how the product is deployed and flag configurations that break common workloads. This input comes from people who run the technology, so it shapes what the recommendations assume about real environments. The output is a set of documented proposals and questions attached to the working discussion, ready for drafting. A proposal is only usable once it is written down with its rationale, so the group can review and challenge it later.
Draft prescriptive configuration recommendations
Subject matter experts turn the agreed scope and proposals into a first draft of prescriptive recommendations. Each recommendation states a configuration to apply, how to check it and, where it applies, the reason it matters. The Benchmark is written to be tested, so every recommendation should be verifiable on a live system. The output is a complete working draft that the group can read, comment on and revise on WorkBench.
Discuss the draft on WorkBench
The draft is opened for discussion on CIS WorkBench, where participants comment on individual recommendations, question their wording and propose changes. Disagreements about a setting are resolved in the thread rather than by a single author. The output is a revised draft, along with a visible record of each comment and how it was handled. Expect several rounds, because each revision can raise new questions about how a setting behaves in other configurations.
Reach consensus on each recommendation
Drafting and discussion continue until the participants reach consensus. Consensus is the test that decides whether a recommendation goes into the Benchmark, and no single contributor can override it. The output is a consensus version of the Benchmark, with its recommendations and their checks agreed by the working group. Recommendations that stay contested are not published as agreed, so a reader should expect that the final text reflects the group's position rather than one vendor's preference.
Publish through the CIS Benchmark Development team
The CIS Benchmark Development team takes the consensus version and publishes it under the Benchmark's name and version. The PDF is free to download from the CIS Benchmarks site. SecureSuite Members can also get machine-readable and office formats such as XCCDF, Word, Excel and XML through WorkBench. The output is a released Benchmark version that scanning tools and hardening scripts can reference. Confirm the version number and release date on the Benchmark itself before you record it in your secure configuration process.
Track releases and archived versions
Benchmark release timing depends on the community and on the release schedule of the technology covered. CIS states that Windows Benchmarks cover the latest Windows build within 90 days of its release. Older and unsupported versions are archived on CIS WorkBench rather than removed. The output for you is a clear record of which Benchmark version matches each system's build. Review that record whenever a platform is upgraded, because a Benchmark for a superseded version may not match the settings you have deployed.

Which CIS Benchmark formats are free and which need SecureSuite?

This table compares what a free user receives from CIS Benchmarks with what a SecureSuite Member receives through CIS WorkBench. Read each row as a question to answer before budgeting: the format you need depends on the tool that will consume the Benchmark, not only on whether the Benchmark is free.

Item	Free access (PDF)	SecureSuite Member access
Benchmark PDF download	true	true
XCCDF, Word, Excel and XML formats via CIS WorkBench	false	true
Tailoring recommendations for your environment	false	true
Who pays	Nothing for the PDF, so the cost is internal staff time to read and apply it	Recurring SecureSuite membership fee paid by the organization
Fit for manual hardening reviews and documented baselines	PDF is usually sufficient for reading and approving settings	Member formats suit teams that want to import settings into tooling
Fit for automated scanning or policy import	Confirm with the scanning tool vendor whether it needs XCCDF or another machine-readable format	Member formats can feed automation, but confirm the tool accepts them
Archived and older versions	Available on CIS WorkBench only where CIS allows access, so confirm your version access	Access to archived and older versions on CIS WorkBench, as CIS describes
Questions to ask CIS before budgeting	Which Benchmark version and PDF applies to our platform and release date	Which formats and tailoring features the membership tier includes, and whether they match our scanner

Which technologies the CIS Benchmarks cover

CIS lists Benchmarks for roughly 100 technology families, grouped into categories that map to different parts of an estate. Each card below names one category, the part of the environment it touches, and what to confirm before applying a Benchmark, because Benchmark versions change with each product's release schedule.

Cloud providers

Benchmarks for cloud platform accounts and services cover identity, logging, networking and storage settings that are configured in the provider console or through infrastructure code rather than on a host. Check which cloud service and version your account uses, since service-level Benchmarks are versioned separately from the foundations Benchmark. Confirm the current version on the Benchmarks page before you write a baseline for a production account.

Operating systems

Operating system Benchmarks give the configuration baseline for desktops and servers, covering settings such as password policy, service state, audit policy and firewall rules. They are the most common starting point for a secure configuration process because most enterprise assets run an operating system. For Windows, CIS states that Benchmarks cover the latest build within 90 days of its release, so confirm the build your fleet actually runs before you test a profile.

Server software

Server software Benchmarks cover applications such as web servers, database engines and directory services that run on top of an operating system. Because application settings often sit in separate configuration files and databases, a host-level scan may miss them. Confirm which server software version and deployment mode (standalone, clustered or containerized) your Benchmark targets, and record any setting you deviate from.

Desktop software

Desktop software Benchmarks cover client applications installed on user devices, such as browsers and office suites. These settings often change with user preferences and auto-update behavior, so they drift faster than operating system settings. Confirm whether your deployment uses a managed policy mechanism that can enforce the Benchmark, and plan for users who hold local administrator rights.

Network devices

Network device Benchmarks cover routers, switches and firewalls, including management plane settings such as administrative access, logging, and secure protocols. Changes to these devices can interrupt connectivity across a site, so test in a lab or maintenance window before rollout. Confirm the firmware version your device runs against the Benchmark version, since vendor firmware changes can alter which settings exist.

DISA STIG and mobile devices

The DISA STIG profile and mobile device Benchmarks are covered separately because their applicability differs. The STIG profile inside CIS Benchmarks applies to organizations that must meet federal hardening requirements, while mobile device Benchmarks address phones and tablets managed by the enterprise. Confirm which profile your contract, authorization or policy names before you choose one, and confirm the mobile management platform can enforce the settings.

How often CIS Benchmarks change and what that means for your process

CIS does not publish Benchmarks on a fixed calendar. Release timing depends on the volunteer and expert community that drafts each Benchmark and on the release schedule of the technology it covers, so a Benchmark for a product with frequent major releases will move more often than one for a stable platform. The one firm commitment in CIS's published guidance is for Windows: Benchmarks cover the latest Windows build within 90 days of its release. For every other technology, confirm the current release status on the CIS Benchmarks page before you plan work around it, and do not assume a Benchmark exists for the exact version you run. Older and unsupported versions are archived on CIS WorkBench rather than removed, which helps when you must audit a legacy system but also means a search can return a superseded document first.

Treat Benchmark version tracking as an input to your own configuration review cycle, not as a separate project. Under Safeguard 4.1, your written secure configuration process must be reviewed at least once a year or after significant enterprise changes, so use the same review to check whether any Benchmark you rely on has been superseded. Assign one owner to watch the Benchmarks for each platform in your inventory, and record the change in your standard build documentation before the next hardening cycle. Confirm with CIS, through the CIS Benchmarks FAQ, how it handles updates for the versions you run.

For audit and incident work, record which Benchmark version and profile each system was assessed against, along with the date of the assessment and any deviations approved for it. An assessor testing Safeguard 4.1 will ask whether you can show what a system was configured to and when that baseline was set. Without that record, a host that passed last year may have been measured against a retired document, and you cannot reconstruct why it was accepted. Keep the version identifier in the scan output or asset record so the evidence stays tied to the baseline it was checked against.

Which standards recognize CIS Benchmarks, and where each applies

CIS states that the Benchmarks are recognized as a secure configuration standard by several frameworks and programs, and that this recognition extends to CIS Hardened Images. Recognition establishes that a Benchmark is an accepted baseline, not that a system passes an audit, so each card below explains what the recognition covers and what the assessor still decides.

DoD Cloud Computing SRG

CIS states that the Benchmarks are recognized as a secure configuration standard by the DoD Cloud Computing Security Requirements Guide. For cloud workloads that serve US defense customers, this means a CIS Benchmark can be a documented baseline for hardening cloud-hosted systems. The assessing body still decides whether each configuration setting meets the impact level you are authorized for, and whether your tailoring and deviations are acceptable. Confirm the current recognition wording with the DoD before you rely on it.

PCI DSS

CIS states that the Benchmarks are recognized as a secure configuration standard under PCI DSS. Assessors reviewing payment environments usually ask whether system configuration follows a documented, approved baseline and whether deviations are justified. A CIS Benchmark profile can supply that baseline, but the Qualified Security Assessor or internal assessor decides whether your implementation satisfies the relevant requirement in your cardholder data environment. Confirm the current recognition position with the PCI Security Standards Council and your assessor.

FISMA

CIS states that the Benchmarks are recognized under FISMA for federal information systems. Federal agencies and their contractors use secure configuration baselines to document how systems are hardened against their security control requirements. Recognition of the Benchmark does not transfer authorization to your system. Your authorizing official and assessors decide whether the chosen profile, its tailoring and your recorded exceptions meet the control baseline for each system.

FFIEC

CIS states that the Benchmarks are recognized as a secure configuration standard by the FFIEC, the body whose IT examination handbooks bank examiners use. Banks and their service providers can use a Benchmark as the configuration baseline behind their examination evidence. Examiners still judge whether the institution's risk assessment, approvals and monitoring justify each configuration decision. Confirm the current FFIEC position with the examiner or your regulator relationship owner.

FedRAMP

CIS states that the Benchmarks are recognized as a secure configuration standard by FedRAMP, the US program for cloud services used by federal agencies. Cloud providers and their components can document Benchmark-based hardening in their security packages. The authorizing agency and the third-party assessment organization decide whether the baseline, tailoring and continuous monitoring evidence meet the applicable FedRAMP baseline. Check the current FedRAMP guidance before you cite the recognition in a package.

NIST and the National Checklist Program

CIS states that the Benchmarks are recognized by NIST and listed in the National Checklist Program Repository. The repository is a public index of secure configuration checklists, so a listed Benchmark gives you a recognized reference for configuration decisions. Listing does not mean a checklist is mandatory for your environment. Verify the current repository entry and the NIST wording for the specific Benchmark version you deploy.

Who does what when you adopt CIS Benchmarks

Your organization owns the secure configuration decisions. Before any build changes, your security and platform leads choose which CIS Benchmarks apply to each technology in scope, which profile (Level 1, Level 2 or the STIG profile) fits each system's risk and operational tolerance, and what the approved baseline looks like. Those decisions belong to you because they carry operational and business risk that an outside party cannot accept on your behalf. Your team also keeps the secure configuration process current, since CIS describes the Benchmarks as prescriptive recommendations that you must test against your own environment.

Benchmark and profile selection: Record which Benchmark version and profile applies to each asset class, and the reason for the choice.
Baseline ownership: Approve the target configuration, track its version and decide when it changes.
Deviation records: Document every setting you cannot apply, the compensating control and the business owner who accepted the risk.
Exception approval: Set who may approve exceptions and how often they are reviewed, which Safeguard 4.1 expects to occur at least once a year or after significant enterprise changes.
Licensing decisions: Decide whether SecureSuite membership is needed for tailored content, formats or CIS-CAT Pro, and who signs the agreement.

Check that every deviation has a named owner, a date for review and a link to the approved baseline version.

How Safeguard 4.1 turns Benchmarks into an auditable process

Safeguard 4.1 asks for a written process for configuring enterprise assets securely, and a CIS Benchmark on its own does not meet it. The Safeguard covers end-user devices, including mobile devices, IoT devices, servers, operating systems and applications. The process must be reviewed once a year or after a significant enterprise change. A Benchmark supplies the prescriptive settings for one technology. The process decides which Benchmark applies to which asset, who owns the configuration, which profile (Level 1, Level 2 or STIG) the organization adopts, how the settings are tested before rollout, how deviations are approved and recorded, and when the whole set is reviewed. An assessor looking for Safeguard 4.1 evidence will ask for that process first, then check whether the Benchmarks and deviation records behind it are actually in use.

The practical test is whether a reviewer can trace one server from its asset record to its approved Benchmark version, its applied settings, any documented exceptions and its most recent scan result. Confirm with your own team who signs off on a deviation, how long an exception may stay open and where the review minutes are kept. Those answers are usually missing from a team that has downloaded a Benchmark PDF but has no written process around it. Note also that the Benchmarks are updated as technology families change, so the process should name who watches for new versions and how they are scheduled into rollout.

Safeguard 4.1 carries weight beyond the audit. In its CDM v3.0 analysis, CIS identified Safeguard 4.1, establishing and maintaining a secure configuration process, as the most effective individual safeguard across all five attack categories it studied (CIS press release, September 21, 2026). That finding gives a security leader a clear reason to fund ownership and review time for the process, not only the tooling that scans against the Benchmarks.

What usually delays Benchmark projects, and how to avoid each

Most slow or expensive Benchmark projects trace back to a small set of decisions made late or not at all. The cards below cover those decisions, and each one names a step to take before configuration or scanning work begins.

Adopting Level 2 without testing

Level 2 profiles add restrictions that are stricter than Level 1 and can break business applications, logins or integrations. Teams that push Level 2 settings straight to production often spend weeks rolling back changes and rebuilding trust with application owners. Before rollout, run the profile in a staging group that mirrors production and record which settings each application needs. Agree on that test scope with the owners before the change window is set.

Scanning without an agreed version

A scan result only means something when the team knows which Benchmark version and profile produced it. Benchmarks are revised as technologies change, so a finding against one version can disappear or appear under another, and reports from different teams stop being comparable. Before scanning starts, write down the Benchmark name, version and profile for each asset group in the secure configuration process, and keep the same baseline until a deliberate upgrade is approved.

No written deviation record

Every setting an organization does not apply needs a reason that an assessor can read. When a failed check is quietly waived in a scanner or a ticket, auditors see an unexplained gap, and the next team reopens the same debate. Before the first scan, create a deviation template that names the asset, the failed check, the compensating control, the approver and the review date, and make an entry mandatory for every exception.

SecureSuite decisions found late

Some capabilities, including tailored Benchmark content and certain Benchmark formats, depend on a CIS SecureSuite membership. Teams that start tailoring or planning Pro-based scanning without checking this often stop mid-project to request budget and approval. Before work starts, confirm with the buyer which SecureSuite features the plan needs and whose budget covers them, and include that cost line in the written scope.

Unsupported systems that fail the baseline

Benchmarks are written for supported versions, and CIS archives older versions on CIS WorkBench. A legacy server or appliance that cannot run the required settings may produce findings that no configuration change can close, which turns a hardening project into a replacement project. Before committing a timeline, inventory operating system and application versions and mark which assets cannot meet the baseline, then plan upgrades, isolation or documented risk acceptance for them.

No owner for the annual review

Safeguard 4.1 expects the secure configuration process to be reviewed once a year or after significant enterprise changes. Without a named owner, the process goes stale, Benchmark updates go unnoticed and evidence for the next assessment is rebuilt from memory. Before the project closes, assign one accountable owner, a calendar date for the annual review and a trigger list for early reviews, such as a major platform upgrade or a new asset class.

Common questions about CIS Benchmarks

Are CIS Benchmark PDFs free to use?

Yes, CIS Benchmark PDFs are free to download, and you can use them to configure your own systems. The paid layer is the machine-readable and tailoring material. CIS SecureSuite Members can get formats such as XCCDF, Word, Excel and XML through CIS WorkBench, and tailoring recommendations require a SecureSuite membership. Read the terms on each document before you republish it or sell a modified copy. CIS Controls content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, and commercial use needs CIS's prior approval. Check the CIS Benchmarks FAQ for the current terms before you build a product or service around a Benchmark.

Do we need SecureSuite membership to tailor a CIS Benchmark?

Yes, CIS states that tailoring recommendations require a SecureSuite membership. You can still apply a Benchmark as published, test its settings and deploy them through your existing configuration management tools. What membership adds is CIS's tailoring guidance and the structured formats that make it easier to build and maintain your own profile. Without membership, record every change you make to the default recommendations, along with the reason and an approver, so the deviation stays visible to an assessor. Confirm current membership fees and categories with CIS, since they depend on your organization and the membership tier you choose.

Does applying a CIS Benchmark make us compliant?

No, applying a Benchmark does not by itself make an organization compliant with any framework. A Benchmark sets configuration recommendations for a technology, and an assessor decides whether your environment meets a given requirement. CIS recognizes the Benchmarks as a secure configuration standard for frameworks including PCI DSS, FISMA, FFIEC, FedRAMP and NIST, but that recognition does not replace the assessment. Ask your assessor which requirement the Benchmark supports and what evidence they will accept, such as scan reports, approved deviations, change records and a record of who approved each setting. Only an independent auditor or assessor issues findings or reports.

How often are CIS Benchmarks updated, and how often should we review them?

CIS does not publish a fixed update cycle. It says release timing depends on the community and on the release schedule of the technology covered. For Windows, CIS states that Benchmarks cover the latest build within 90 days of its release. Older and unsupported versions are archived on CIS WorkBench, so confirm that you are using the version that matches your running systems. Your own review cadence matters more. Safeguard 4.1 of CIS Controls v8.1 expects a secure configuration process that is reviewed once a year or after significant enterprise changes, such as an operating system upgrade or a new platform. Build those triggers into your change calendar.

Can our own team apply CIS Benchmarks without outside help?

Yes, many internal teams apply Benchmarks on their own, starting with the free PDFs, a test environment and a scanner. Most of the effort is internal: choosing the profile that fits each system, testing each setting for side effects, rolling changes out through configuration management and recording each deviation. Outside help becomes worth considering when staff time is limited, when a large or multi-cloud estate needs one consistent build pipeline, or when evidence has to be ready for a specific assessment. An illustrative example: a team with a few Linux servers and a working deployment pipeline may need only a short internal project, while a mixed estate across several clouds usually needs more planning.

What does applying CIS Benchmarks require from our internal staff?

Plan for four roles: a system owner for each platform, an engineer who writes and tests the configuration, a change approver who signs off on settings that affect production, and a compliance contact who keeps the deviation register and evidence current. Effort depends on the number of platforms, how much of the build is already automated, whether you have a test environment that mirrors production, and how many profiles you run. Ask any partner to show how they will split the work between your staff and their team in the written scope. Staff also need access to the systems being hardened and a documented way to roll back a change that breaks a service.

How do we choose a partner to implement CIS Benchmarks?

Start with the outcome you need: hardening a set of systems, setting up scanning, building a documented secure configuration process, or preparing evidence for an assessment. Ask for a written, fixed scope with deliverables, the list of platforms covered, how deviations are handled and who keeps the evidence after handover. If you need tailoring or CIS-CAT Pro, confirm the partner's SecureSuite status. If a provider offers CIS Controls implementation or assessment services, check its accreditation status, since CIS lists an application fee for CIS Controls Accreditation of $1,500 for CREST members and $2,500 for non-members. DeployOpen plans, hardens and documents systems inside your own infrastructure and prepares evidence. It does not issue audit reports or certifications, and an independent assessor does that.

How DeployOpen works on this

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For CIS Benchmarks, that means choosing the right Benchmark and profile for each system, applying it through the client's own configuration process, and leaving behind evidence an assessor can review. DeployOpen prepares systems and evidence only; the organization owns its controls and an independent auditor issues any report.

How we scope

Engagements are fixed-scope, with systems, Benchmarks, profiles and deliverables agreed in writing before work starts.
Scope lists which technology families are in play, such as operating systems, server software or cloud accounts, and which Benchmark version applies to each.
The written scope states who decides profile levels and documents deviations, so the client keeps ownership of its secure configuration decisions.

How we build

Benchmark settings are applied to the in-scope platforms through the client's own infrastructure-as-code or configuration tooling where it exists.
Each profile is tested in a non-production environment to confirm that services, integrations and backups still work before any rollout.
Scans are run against the agreed Benchmarks using the scanning tools in scope, with results kept so that failed checks can be traced to a decision.

How we hand over

Deliverables include the documented secure configuration process, the hardening baselines applied and the scan reports produced during the engagement.
A deviation register records each Benchmark recommendation not applied, the reason, the compensating control and the approver.
Handover includes a walkthrough so the client's team can rerun scans, update baselines and explain the evidence to its own auditor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the initial engagement is complete.
Retainers can cover reviewing new Benchmark releases, retesting baselines after platform upgrades and refreshing scan evidence on a schedule the client sets.
Before any support arrangement starts, confirm in writing which Benchmark versions, SecureSuite membership needs and tooling costs are the client's responsibility.