CIS Benchmarks: what they are and why they matter

What CIS Benchmarks actually are

A CIS Benchmark is a document that tells you, setting by setting, how to configure a specific operating system, cloud platform, piece of software or network device so that it is harder to attack. They are published by the Center for Internet Security (CIS), a US nonprofit, and cover the platforms most organisations actually run: Windows Server and desktop editions, the major Linux distributions, Amazon Web Services, Microsoft Azure, Google Cloud, Kubernetes and Docker, Microsoft 365, Google Workspace, common browsers, and network devices from vendors including Cisco and Palo Alto Networks. There are more than 100 Benchmarks in total, spanning over 25 vendor product families, and CIS updates each one as new platform versions ship.

CIS Benchmark recommendations go through a consensus process before publication. Volunteer subject-matter experts, drawn from industry, government and academia, propose, review and vote on each setting, which is why the guidance reads as practical operator advice rather than a vendor's own hardening documentation. Each recommendation is marked either "Scored", meaning compliance can be measured automatically and rolled into a numeric score, or "Not Scored", meaning it is a good practice worth doing but doesn't lend itself to automated verification.

The Benchmarks themselves are free to download as PDF for every platform CIS covers. What costs money is the tooling built around them: CIS-CAT Pro, an assessment tool that scans a system against a Benchmark and produces a compliance score and remediation report, and CIS Hardened Images, pre-configured virtual machine images that come compliant with a Benchmark out of the box, sold through the AWS, Azure and GCP marketplaces under a CIS SecureSuite membership. A free, limited version called CIS-CAT Lite exists for organisations that want to try automated scoring against a single Benchmark before committing to a paid tier.

Anatomy of a recommendation

A Benchmark isn't a loose list of suggestions. Every recommendation inside one, and a single Benchmark can contain several hundred, follows the same five-part structure, which is what makes the guidance usable by an engineer rather than just readable by one:

• Description: what the setting is and what it controls.
• Rationale: why the change matters and what kind of attack or exposure it closes off.
• Audit procedure: the exact steps or command-line check needed to confirm whether a system currently meets the recommendation.
• Remediation procedure: the exact steps or commands needed to bring the system into compliance if the audit fails.
• Default value: what the setting is left at out of the box, before anyone changes anything.

That structure comes out of CIS WorkBench, the collaborative platform where the consensus process actually happens. Volunteer experts from vendors, government agencies, auditors and industry submit, argue over, test and vote on each recommendation before it is published, and Benchmarks are revised on an ongoing basis as platforms change and new threats emerge. It is a slower process than one vendor writing its own hardening guide, and that is the point: a recommendation that survives review from people with competing incentives is a stronger baseline than one written by whoever built the product.

CIS Benchmarks vs CIS Controls: the distinction that gets lost

CIS also publishes the CIS Controls, and the two are often confused in conversation, including inside IT teams that use both. The Controls are a set of 18 prioritised safeguards, organised into three Implementation Groups by organisational maturity, that describe what a security programme needs to cover: asset inventory, access control, data protection, incident response, and so on. They operate at the level of a strategy document. Benchmarks operate one level down, turning one of those safeguards, secure configuration, into exact, testable settings for a specific platform.

The two are designed to work together rather than substitute for each other. CIS Control 4, Secure Configuration of Enterprise Assets and Software, addresses secure configuration at the programme level, and its Safeguard 4.1 calls for establishing and maintaining a documented secure configuration process. CIS Benchmarks are the platform-specific guidance most organisations use to put that process into practice, not a source the Control itself mandates over an equivalent baseline.

Examples of CIS Benchmarks by platform

"CIS Benchmark" isn't one document, it's a family of them, each scoped to a specific platform. A few of the ones organisations reach for most often:

Each Benchmark is versioned to a specific platform release, and CIS updates or retires guides as vendors ship new ones. Check CIS's own Benchmark catalogue for the current version rather than working from a cached copy someone downloaded a year ago.

Who actually needs to care about this

The conceptual case for secure configuration is easy to agree with and easy to leave unactioned. It becomes concrete once you recognise your own situation in it. A Benchmark is worth implementing when you:

• Run Windows or Linux servers, virtual machines, or manage endpoints at any meaningful scale
• Operate Microsoft 365, Google Workspace or other SaaS platforms holding company data
• Run workloads in AWS, Azure or Google Cloud and want a baseline beyond the provider's own defaults
• Process payment card data, or handle other regulated or sensitive information
• Need documented, auditor-ready evidence of secure configuration for ISO 27001, PCI DSS, NIST CSF or NIS2
• Provision infrastructure through Terraform, Ansible or similar tooling and want compliant systems by default
• Manage enough systems that configuration can no longer depend on whoever happened to build each one

None of that means implementing every recommendation on every system. The right baseline depends on the platform, the business requirement and what a given system can tolerate operationally, which is exactly what the phased rollout in the implementation section below is for.

Why secure configuration is worth this much attention

Default configurations exist to get a system running with the fewest support calls, not to resist an attacker. A freshly installed server, an out-of-the-box cloud storage bucket, a new Microsoft 365 tenant, all ship with settings that favour convenience: broader permissions than most users need, legacy protocols left enabled for compatibility, logging turned down to reduce noise. None of that is a bug. It is simply not the configuration a security team would choose, and most organisations never go back and choose one deliberately.

That gap is exactly where a large share of real-world incidents originate. An exposed storage bucket with default public access, a server still running a legacy protocol nobody remembers enabling, an admin console left reachable from the internet because a firewall rule was never tightened after a migration: these are configuration failures, not zero-day exploits, and they are also the failures that are cheapest to prevent. Misconfiguration keeps showing up as a leading root cause in breach reports across cloud and on-premise infrastructure alike, because the underlying condition behind it, complex platforms shipped with permissive defaults, hasn't gone away.

A Benchmark closes that gap by giving you a specific, tested answer instead of a general principle. "Harden your servers" is advice nobody can act on directly. "Disable SMBv1, enforce a minimum password length of 14 characters, disable the built-in guest account, and restrict anonymous SID and name translation" is something an engineer can implement and an auditor can verify. That specificity, multiplied across every setting a platform exposes, is the actual value of a Benchmark over generic hardening advice.

Level 1 and Level 2: two tiers of hardening

Every CIS Benchmark organises its recommendations into two profile levels. Level 1 covers foundational hardening: settings that meaningfully reduce attack surface with minimal risk of breaking normal operation. It is intended as a baseline suitable for practically any system, including ones running general business applications where uptime matters more than defence-in-depth. Level 2 goes further, covering settings intended for higher-security environments where some reduction in functionality or performance is an acceptable trade for stronger protection. Regulated environments, systems handling sensitive data, and internet-facing infrastructure are the usual candidates for Level 2.

How to implement a Benchmark without breaking production

The most common mistake is applying a Benchmark, especially Level 2, directly to production without testing it first. Some recommendations disable functionality that a specific application quietly depends on, a legacy protocol an old piece of line-of-business software still uses, or a permission a monitoring agent needs to operate correctly. Rolling out every recommendation at once and finding that out in production is how hardening projects earn a reputation for causing outages, which is usually what leads a team to abandon the effort altogether.

A phased rollout avoids that. Pilot the Benchmark against a representative subset of systems first, ideally including at least one system running each critical application, and validate that everything still functions before expanding further. Where a recommendation genuinely conflicts with a business requirement, document the exception, the reason for it and any compensating control, rather than silently skipping it. An exceptions register that an auditor can review is a stronger position than a Benchmark applied unevenly with no record of why.

Two approaches handle the rollout itself at scale better than hardening each machine by hand. The first is a Golden Image: harden one master image against the Benchmark, validate it thoroughly, then clone it for every new system instead of re-applying the same settings one at a time. CIS sells pre-built Hardened Images through the major cloud marketplaces for exactly this reason, though many organisations build and maintain their own master image instead, tailored to their own application stack. The second is Infrastructure as Code. Provisioning scripts written in Terraform or Ansible can encode a Benchmark's settings directly, so every server, container or cloud resource comes into existence already compliant, rather than compliant after someone remembers to run a separate hardening step.

Neither approach removes the need for ongoing checks. A system built from a Golden Image, or provisioned through compliant IaC, drifts away from that baseline within weeks as patches are applied, software is installed, and well-meaning changes are made under time pressure. CIS-CAT scans should run on a recurring schedule, not only once before an audit, so drift is caught and corrected while it is still a small gap rather than discovered as a finding.

Where CIS Benchmarks fit in an audit

Most compliance frameworks require a secure configuration baseline without naming CIS specifically, which is why CIS Benchmarks have become one of the most commonly used sources of evidence for that requirement. ISO 27001 Annex A control 8.9, Configuration Management, requires documented, monitored secure configurations for hardware, software, services and networks. A CIS Benchmark, paired with a CIS-CAT compliance report, provides strong technical evidence for that control, though the configuration standard an auditor reviews still needs to be your own documented standard, not an unmodified copy of the CIS PDF filed as a policy. PCI DSS Requirement 2 requires documented configuration standards for all system components and lists industry-accepted hardening standards, including CIS, as an acceptable basis, with the same catch: the standard has to be tailored to your own environment rather than just referenced. NIST CSF's Protect function expects secure baseline configurations to be established and maintained, and NIS2's Article 21 technical measures cover system security and vulnerability handling in language auditors typically evidence the same way.

Our ISO 27001 guide and NIST CSF and NIS2 mapping guide cover where secure configuration sits inside those broader frameworks.

Common mistakes worth avoiding

• Treating hardening as a project with an end date: a Benchmark applied once and never rescanned degrades into undocumented drift within months.
• Applying Level 2 everywhere by default: the operational cost is rarely worth it on systems that don't need it, and failed rollouts damage appetite for the systems that do.
• Skipping the exceptions process: quietly ignoring recommendations that conflict with a business need leaves no record for an auditor and no visibility for the next engineer who inherits the system.
• Assuming one version's Benchmark still applies to the next: CIS publishes separate Benchmarks tied to specific platform versions, and a guide written for an older release can miss settings introduced since.
• Confusing Benchmarks with Controls when talking to an auditor: the two answer different questions, and conflating them in an audit conversation can send the evidence-gathering down the wrong path entirely.

None of this replaces a documented hardening standard or a wider secure-by-design approach. It is the specific, implementable layer that sits underneath one, and it is usually the fastest gap to close once you know it is there.

How Cyvra helps

Cyvra's Cybersecurity Consultancy, Cybersecurity Assessment and Audits & Compliance services build secure configuration baselines that hold up under audit, not just on the day they are built.

• Benchmark-based hardening: Level 1 and Level 2 rollouts scoped to your actual estate, piloted before wider deployment
• Exceptions register: documented, auditor-ready records of any recommendation that can't be applied and why, with compensating controls where needed
• Drift monitoring: recurring compliance scanning so a hardened baseline stays hardened, not just at audit time
• Compliance mapping: secure configuration evidence mapped directly to ISO 27001, PCI DSS, NIST CSF and NIS2 requirements

We assess your current configuration against the appropriate CIS Benchmarks, document justified exceptions, prioritise remediation and produce evidence you can point to for ISO 27001, PCI DSS or other compliance programmes. Contact our Cybersecurity Consultancy or Audits & Compliance team to start with a configuration baseline review.