CIS Benchmarks
prescriptive hardening evidence for OS, cloud, containers, and network baselines

CIS Benchmarks: prescriptive configuration baselines for the technologies you actually run

CIS Benchmarks are 100+ prescriptive configuration hardening guides published by the Center for Internet Security. Each benchmark names the exact settings, registry keys, configuration values, and audit commands an operator can run to evidence a defensible baseline against a specific operating system, cloud account, container platform, network device, mobile platform, or database. The benchmarks are written as executable specifications rather than as guidance documents: each recommendation carries the prescribed setting, the rationale, the impact, the audit procedure, the remediation procedure, and the references back to the wider control catalogues. A programme that operates the benchmarks produces evidence as a side effect of running them rather than as a separate documentation exercise.

CIS Benchmarks and the CIS Critical Security Controls are companion catalogues with different scopes. The Controls are the 18 prioritised cyber programme priorities and 153 safeguards that describe what a security team should do at the programme level. The Benchmarks are the prescriptive configuration baselines that describe how specific technologies should be configured. The Controls reference the Benchmarks for the configuration evidence in Control 4 Secure Configuration of Enterprise Assets and Software. Programmes commonly operate both: the Controls catalogue at the programme layer, the Benchmarks catalogue at the asset layer, with the per-asset benchmark evidence rolling up into the per-safeguard Controls assessment.

External frameworks read the benchmark output as evidence rather than as the framework itself. ISO 27001 Annex A 8.9 expects configuration management; benchmark output is the underlying evidence. SOC 2 CC6.6 expects logical access security measures including secure configuration; benchmark output is what the assessor reads. PCI DSS Requirement 2 expects secure configuration standards applied to all in-scope system components; benchmark output is the standard and the evidence at the same time. NIST SP 800-53 CM-6 expects configuration settings established and implemented; benchmark output is the implementation evidence the assessor reads. Programmes that operate the benchmarks once and reuse the evidence across these reads spend less time at audit than programmes that produce framework-specific evidence per certification cycle.

The benchmark catalogue at a glance

The catalogue is organised into broad asset categories. Each category contains multiple benchmark families, and each benchmark family contains versioned benchmarks against the named platform versions actually shipping in production. The total catalogue exceeds 100 active benchmarks across the categories below.

Level 1 versus Level 2 profiles and the deployment-context variants

Each benchmark organises recommendations into Level 1 and Level 2 profiles. Level 1 is the practical baseline that does not significantly impact functionality and is the floor most regulated programmes are expected to reach. Level 2 is the stricter baseline that may break functionality, performance, or compatibility and typically requires explicit risk acceptance against the asset criticality and the threat model. Some benchmarks also publish deployment-context variants per operating mode (server vs workstation, domain-joined vs standalone, on-premises vs cloud, container host vs cluster control plane). The profile decision is the single most consequential scoping decision in a benchmark programme because every audit conversation reads against it.

Scored versus Not Scored recommendations and what the scanner score does not tell you

CIS classifies each recommendation as Scored or Not Scored. The distinction matters at evidence time because most third-party scanners report a benchmark score against the Scored items only, while the framework reads expect evidence on both. A programme that reads the scanner score as the entire benchmark posture ships an evidence pack that misses every Not Scored item the assessor will still ask for.

Building the benchmark evidence pack

Evidence packs fail review when artefacts are scattered across drives, ticket systems, and screenshots without a clear link back to a benchmark recommendation. Build the pack as you go, keep raw scanner output alongside the per-recommendation summary, and tie every artefact to the engagement record. The pairs below are what the assessor actually reads when the benchmark is the underlying evidence for the configuration management control.

Turning failed recommendations into tracked work

The benchmark scan output is a snapshot of the configuration baseline at a single point in time. A snapshot is not a programme. Each failed Scored recommendation and each Not Scored recommendation without procedural evidence should produce a remediation item with a planned fix, target date, and named owner. SecPortal's findings management is built around the same model: a finding has severity, an owner, a control mapping, and a remediation timeline. Treat the benchmark register per asset as a live view of open work, not as a quarterly export.

Anti-patterns that produce silent benchmark drift

Six anti-patterns recur in programmes that ship benchmark output without an underlying operating discipline. Each pattern produces a posture gap the scanner output cannot surface, because the scanner output is the wrong evidence source for the question.

Continuous benchmark monitoring rather than annual snapshots

A benchmark that runs once a year against an asset reconfigured weekly produces a posture that expires faster than the assessment cycle expects. The structural fix is matching cadence to change rate per asset class: continuous or near-continuous benchmark assessment for the highest-velocity assets (cloud account configuration, Kubernetes cluster configuration, container image baselines), weekly or biweekly for medium-velocity assets (server operating systems, database platforms, web server software), monthly or quarterly for low-velocity assets (network devices on a slow change cadence, locked-down kiosk endpoints, regulated infrastructure with a controlled change window). The continuous monitoring workflow and the authenticated scanning capability are the patterns the workspace uses to produce that record without manual chasing. Pair them with the cloud security posture remediation workflow for the cloud foundations benchmarks, the patch management coordination workflow for the operating system benchmarks, and the compliance audits workflow for the multi-framework evidence reads against the benchmark output.

Cloud foundations benchmarks and the platform engineering handoff

Cloud foundations benchmarks (CIS AWS Foundations, CIS Microsoft Azure Foundations, CIS Google Cloud Platform Foundations) read against the account control plane (identity, logging, networking, key management, storage default settings) rather than against the workloads running inside the account. The result is the account-level configuration baseline that the workload-side scanner output assumes. Cloud security and platform engineering teams operate the foundations benchmark on a per-account basis; the workload teams operate the application-side scanner output against the workloads inside.

The handoff between the platform engineering team and the workload teams matters at audit: a workload that fails an authenticated scan inside an account that also fails CIS AWS Foundations carries two separate findings against two separate owners. The benchmark register per account and the finding register per workload sit on the same workspace so the assessor sees both sides of the configuration assurance posture without reconciling across consoles.

Kubernetes and container benchmarks across the source-to-runtime layers

The Kubernetes and container benchmarks read across three layers: the manifests at source, the images at build, and the cluster at runtime. Source-side coverage through code scanning catches the manifests that define the cluster (Kubernetes YAML, Helm charts, Kustomize overlays, Terraform) against IaC scanning expectations. Build-side coverage catches the image hygiene at the registry against image scanning expectations. Runtime coverage sits on the running cluster and is captured against the live configuration during the authenticated assessment window. A programme that operates only one of the three layers inherits a benchmark coverage gap; the workspace record carries findings from all three sources against the same cluster reference so the gap is visible.

Multi-framework crosswalk: one benchmark, multiple framework reads

The economic case for the benchmark catalogue is the multi-framework crosswalk. A single CIS Linux Benchmark assessment against a production host produces evidence that answers ISO 27001 Annex A 8.9 configuration management, SOC 2 CC6.6 logical access security measures, PCI DSS Requirement 2 secure configuration standards, NIST SP 800-53 CM-6 configuration settings, NIST CSF 2.0 PR.PS-01 configuration management practices, and CIS Controls Safeguards 4.1 through 4.7. The same evidence supports the FedRAMP authorisation package, the HIPAA Security Rule administrative safeguard for security management, the DORA digital operational resilience reads on ICT systems, and the NIS2 Annex II configuration management expectations. The control mapping cross-framework crosswalks workflow is the workspace pattern for capturing the benchmark recommendation once and reading it against each framework control reference without rebuilding the evidence pack.

Where SecPortal fits in the CIS Benchmarks workflow

SecPortal is the operating layer for the benchmark programme, not a replacement for the CIS catalogue or the assessor. The platform handles scope, per-asset benchmark scope decisions, scanner output ingestion, findings management, remediation tracking, and the assessor-ready output, so the benchmark assessment runs as a structured workflow rather than a long email thread. Compliance tracking covers the benchmark crosswalk to the frameworks an enterprise entity frequently has to satisfy.

Honest scope: where SecPortal stops and the rest of the toolchain takes over

SecPortal is the operating record and the multi-framework evidence layer. It is not a replacement for the per-recommendation native benchmark scanner, the configuration management tooling that performs the remediation, or the asset management platform that carries the inventory. The honest scope statement below names where SecPortal sits in the toolchain and where the programme continues to operate other tools alongside.

For programmes that need a parallel prioritised technical control set, the Essential Eight catalogue covers a similar configuration baseline discipline under the Australian Government Protective Security Policy Framework with a maturity model rather than a Level 1 and Level 2 profile pair. For the broader programme-layer cyber hygiene catalogue the Benchmarks support, the CIS Critical Security Controls page covers the 18 controls and 153 safeguards that the per-asset benchmark evidence rolls up into.

Looking for the assessor-side workflow that brings the benchmark evidence into a multi-framework audit? The compliance audits use case captures how to run multi-framework assessments where benchmark evidence is reused across ISO 27001, SOC 2, PCI DSS, NIST 800-53, and NIST CSF control mappings without rebuilding the bundle from scratch. Security leadership reporting covers how the per-asset benchmark posture rolls up into the board-level configuration assurance view.