CIS Controls Guide: Implementation Groups, Safeguards and Benchmarks

Most organisations know they should "do the CIS Controls" but stall at the question of which of 153 Safeguards to tackle first and how to prove progress. The CIS Critical Security Controls, published by the Center for Internet Security (CIS), are a prioritised set of defensive actions, and the CIS Benchmarks are the separate, detailed configuration guides that sit underneath them. This guide covers the current version (v8.1), how the 18 Controls and their Safeguards are structured, how to choose between Implementation Groups IG1, IG2 and IG3, how the Benchmarks, CIS-CAT, CIS Hardened Images and the free assessment tools fit together, and how to map the work to NIST CSF 2.0, ISO/IEC 27001 and other frameworks. It is for security managers, GRC leads and engineers turning the Controls into a measurable programme.

Key takeaways

• Version 8.1 is current. It is an iterative update to v8 (May 2021) released in June 2024: 18 Controls, 153 Safeguards, a new Govern security function aligned to NIST CSF 2.0, and no changes to Implementation Group assignments.
• IG1 is the starting line for everyone. Its 56 Safeguards are what CIS calls essential cyber hygiene, and CIS's Community Defense Model v3.0 finds they cover 84 to 89 per cent of the ATT&CK techniques in the five attack types it models.
• Controls and Benchmarks do different jobs. The Controls say what to do (for example Safeguard 4.1, establish a secure configuration process); a Benchmark says exactly how to configure a given product, with Level 1, Level 2 and STIG profiles.
• Measure Safeguards, not documents. A Safeguard counts as implemented when it is in place across the assets in scope and someone can show the evidence, which is why CSAT, CIS-CAT and the Controls Assessment Specification exist.
• Map once, reuse often. The CIS Controls Navigator maps v8.1 to 30 frameworks, including NIST CSF 2.0, SP 800-53 Rev. 5, ISO/IEC 27001:2022, PCI DSS v4.0, SOC 2, NIS2 and DORA, so a CIS programme can carry evidence for several audits.

What the CIS Controls are, and how v8.1 differs

The Controls began in 2008 as the SANS Critical Security Controls, often called the SANS Top 20. CIS took ownership in 2015 with Version 6, introduced Implementation Groups in v7.1, and in v8 (May 2021) cut the list from 20 to 18 Controls, replaced Sub-Controls with Safeguards and moved from a device-centric to a more data-centric view. Older documents still say "CIS Top 20"; the current set is the CIS 18. Version 8.1 followed in June 2024 as an iterative update. According to CIS it realigned the security function mappings to NIST CSF 2.0, added a Govern function, revised the asset classes and their Safeguard mappings, expanded glossary definitions for reserved words such as "plan", "process" and "sensitive data", and clarified Safeguard wording. CIS states that no Implementation Groups were modified, so an IG1 programme built on v8 is still an IG1 programme on v8.1. CIS has said it is working on ideas for Version 9 but has published no timeline, so plan on v8.1.

Each Safeguard carries four attributes that matter for planning:

• Asset class: devices, software, data, users, network or documentation. This tells you which team owns it and which inventory it depends on.
• Security function: Govern, Identify, Protect, Detect, Respond or Recover, matching the NIST CSF 2.0 functions.
• Implementation Group: the lowest IG that includes it (IG1, IG2 or IG3).
• Measurable wording: most Safeguards contain a testable statement, for example Safeguard 8.10 "retain audit logs" sets a minimum of 90 days, and Safeguard 8.11 sets weekly audit log reviews.

The 18 CIS Controls at a glance

Implementation Groups: IG1, IG2 and IG3

Implementation Groups are cumulative. IG2 contains everything in IG1 plus more; IG3 is the whole set. CIS assigns them by risk profile and resources, not by headcount alone.

Choosing your target group

• Everyone starts at IG1: CIS calls it an emerging minimum standard. Even large enterprises should confirm IG1 before claiming IG2 or IG3, because advanced Safeguards assume the inventories exist.
• Target IG2 if you hold sensitive customer data, run a dedicated IT team, or face sector regulators. Most mid-sized organisations land here.
• Target IG3 where an outage or data loss would cause significant public harm or a regulator expects a mature security function.
• Mixed targets are legitimate: for example IG1 overall plus selected IG2 Safeguards for a cardholder data environment, with the decision recorded.

Why IG1 first: the Community Defense Model

The CIS Community Defense Model (CDM) is CIS's evidence for the prioritisation. Version 3.0, published in September 2026, draws on industry threat intelligence, breach data, Verizon DBIR findings, VERIS data and MITRE ATT&CK mappings. It models five attack types and reports the share of techniques in each that IG1 Safeguards defend against:

CDM v3.0 names Safeguard 4.1, establish and maintain a secure configuration process, as the most effective single Safeguard across all five attack types, and introduces a five-stage CIS Controls Active Defense Lifecycle showing where each Safeguard interrupts an attack. Coverage of a technique is not the same as stopping every instance, and the figures assume Safeguards are implemented across the whole estate.

CIS Benchmarks, CIS-CAT and Hardened Images

CIS Benchmarks are consensus-developed configuration guides for specific products, drafted and agreed by volunteers, vendors and community members on CIS WorkBench. Examples relevant to most estates are the CIS Amazon Web Services Foundations Benchmark (plus separate AWS compute, database and storage benchmarks), the Docker benchmark, the Kubernetes benchmark with managed variants for Amazon EKS, Azure AKS and Google GKE, and the Microsoft Windows and Linux distribution benchmarks. Benchmarks are versioned independently, so record the version you assess against. PDFs are free; Word, Excel and XML formats and tailoring are for CIS SecureSuite members.

• CIS-CAT Lite: free assessor that scans selected technologies against selected Benchmarks and gives a compliance score. Useful for a first baseline.
• CIS-CAT Pro: for SecureSuite members; assesses against tailored Benchmarks, reports results mapped to the CIS Controls and prioritises by Implementation Group.
• Build Kits: ready-made configuration content (for example Group Policy objects for Windows) that applies a Benchmark, which speeds Safeguard 4.1 but still needs testing.
• CIS Hardened Images: virtual machine images pre-hardened to the Benchmarks, sold through the AWS, Azure, Google Cloud and Oracle Cloud marketplaces. They give a hardened starting point; drift after launch is still yours to manage.
• AWS CIS benchmark checks: AWS Security Hub CSPM runs the CIS AWS Foundations Benchmark (versions 5.0.0, 3.0.0, 1.4.0 and 1.2.0, with AWS recommending 5.0.0). Many CloudWatch metric-filter requirements are marked "not supported, manual check", so a 100 per cent Security Hub score is not full Benchmark conformance. AWS also advises enabling a new version before disabling the old one to avoid gaps. See the AWS Security Guide.

For operating system hardening detail see the Linux Server Hardening Guide and the Windows Endpoint Hardening Guide.

Benchmark compliance without breaking production

• Tailor, then freeze: start from Level 1, record every recommendation you will not apply with a reason and a compensating control, and treat that tailored profile as the baseline the scanner measures.
• Score the tailored profile: scoring against the untailored Benchmark buries real drift under approved exceptions.
• Watch the risky settings: Level 2 items such as restricting legacy protocols, removing services or tightening user rights assignments are the usual cause of application outages; test them in a pilot ring first.

CIS tools for assessment, risk and mapping

Use CIS RAM to justify not implementing, or partly implementing, a Safeguard with a documented residual risk; use CSAT for a repeatable scorecard.

How to implement the CIS Controls

1. Set scope and target (weeks 1 to 2): agree which business units, environments and cloud tenants are in scope, choose the target IG with a written rationale, and name an owner for each of the 18 Controls.
2. Baseline honestly (weeks 2 to 6): run a CSAT assessment of IG1. Score each Safeguard on whether a policy exists, how widely it is implemented, whether it is automated and whether it is reported, rather than yes or no. Run CIS-CAT Lite or your existing configuration scanner against Level 1 Benchmarks for a sample of each platform.
3. Fix the inventories first: Safeguards 1.1, 2.1, 5.1 and 15.1. A patching or logging metric with an unknown denominator is meaningless.
4. Close IG1 gaps by risk: prioritise MFA (6.3, 6.4 and 6.5), the secure configuration process (4.1), vulnerability management (7.1 to 7.4), backups including an isolated recovery copy (11.2 and 11.4) and audit log collection (8.2). Track each as a work item with an owner and date.
5. Roll out Benchmark baselines in rings: apply Level 1 to a test group, then a pilot ring of about 5 to 10 per cent of each platform, then broadly. Version baselines in source control or Group Policy so a bad setting can be rolled back by reapplying the previous version, and keep an exceptions register.
6. Automate evidence: feed scanner, identity provider and backup job results into a dashboard so Safeguard status updates itself.
7. Extend to IG2 or IG3: once IG1 is above about 90 per cent implemented, add the next group's Safeguards in the same way, starting with 5.5 (service account inventory), 8.9 (centralised logs) and 13.1 (security event alerting).
8. Reassess annually and on change: rerun CSAT yearly and after mergers, cloud migrations or a new Controls version.

Where identity fits

Controls 5 and 6 are identity controls, and they hide a gap that many programmes miss. Safeguard 5.1 (inventory of accounts), 5.3 (disable dormant accounts) and 5.4 (dedicated administrator accounts) are IG1, but Safeguard 5.5, establish and maintain an inventory of service accounts, and 5.6, centralise account management, only arrive at IG2. An IG1 organisation can therefore score well on Control 5 while service accounts, API keys and cloud workload identities remain uncounted. Treat 5.5 as an early add-on whatever your IG, extend it to non-human identities such as OAuth apps and cloud roles, and make sure MFA Safeguards 6.3 to 6.5 cover administrative access to cloud consoles and identity providers. See the NHI Lifecycle Management Guide and, for continuous measurement of identity configuration, the ISPM Guide.

Mapping the CIS Controls to other frameworks

The Navigator is the authoritative mapping source; the table shows typical correspondences for planning. The Controls are a prioritised control set rather than a certifiable management system, so organisations usually demonstrate CIS compliance through self-assessment, an independent assessment against the Assessment Specification, or as evidence within an ISO/IEC 27001, SOC 2 or regulatory audit. See the Control Mapping Guide.

Regional baselines map closely too: the Navigator includes the ASD Essential Eight, NCSC Cyber Essentials v3.2 and NCSC CAF v4.0. See the NIST CSF 2.0 Guide and the ISO 27001 Certification Guide.

Measuring a CIS Controls programme

Report Safeguards implemented in your target IG, weighted by coverage: a Safeguard on 60 per cent of assets is not implemented. Useful metrics:

• IG coverage: percentage of target-IG Safeguards fully implemented, tracked quarterly, with IG1 shown separately.
• Inventory completeness: share of assets seen by network, endpoint or cloud discovery that are in the asset inventory (Safeguards 1.1 and 1.2), aiming above 98 per cent.
• Benchmark conformance: mean Level 1 conformance against the tailored profile by platform, plus count of unapproved deviations.
• MFA coverage: percentage of administrative, remote access and externally exposed application accounts enforced with MFA (6.3 to 6.5).
• Patch latency: median days to remediate critical vulnerabilities on internet-facing assets, against the Safeguard 7.7 cadence you set.
• Log coverage: percentage of in-scope assets sending logs centrally, and confirmation that 90-day retention (8.10) is met.

Common failure patterns

• Scoring policies instead of practice: a documented MFA policy scored as "implemented" while remote access still accepts passwords alone. The Change Healthcare breach began with a remote access login that lacked MFA, exactly what IG1 Safeguard 6.4 addresses.
• Skipping the inventories: teams jump to tools in Controls 10 and 13 while Controls 1, 2 and 5 are incomplete, so coverage figures look good against an undercounted estate.
• Treating SaaS and cloud accounts as out of scope: MFA and account Safeguards are applied to the corporate directory but not to cloud data platforms and SaaS tenants. The Snowflake breach showed what infostealer credentials do against accounts without MFA.
• Applying Level 2 everywhere at once: an aggressive Benchmark rollout breaks applications, gets reversed wholesale, and the organisation ends up with no baseline at all.
• Equating a tool score with conformance: a cloud posture or CIS-CAT score covers only automated checks; manual Benchmark items and process Safeguards still need evidence.
• Ignoring service accounts because they are IG2: secrets and service credentials stay unowned. The Uber 2016 breach turned on an AWS key stored in a code repository.

Practitioner checklist

• Confirm you are working from CIS Controls v8.1 and record the Benchmark versions you assess against.
• Choose a target Implementation Group with a written rationale and an owner per Control.
• Run a CSAT baseline of all 56 IG1 Safeguards, scoring implementation and coverage, not just policy.
• Complete asset, software, account, service account and service provider inventories before buying new tools.
• Enforce MFA for administrative, remote and externally exposed access, including cloud consoles and SaaS.
• Adopt a tailored Level 1 Benchmark baseline per platform, roll it out in rings, version it and keep an exceptions register.
• Use CIS RAM to document risk acceptance for any Safeguard you do not implement.
• Export the Navigator mapping for every framework you are audited against and reuse the evidence.
• Report IG coverage, inventory completeness, Benchmark conformance and MFA coverage quarterly.
• Reassess annually and after major changes.

Standards and references

• CIS: CIS Critical Security Controls Version 8.1
• CIS: CIS Controls Implementation Groups
• CIS: CIS Controls Assessment Specification, Control 8 Audit Log Management
• CIS: Community Defense Model v3.0, Turning Threat Intelligence Into Action
• CIS: CIS Benchmarks FAQ
• CIS: CIS Controls Navigator
• CIS: CIS Risk Assessment Method (CIS RAM)
• AWS: CIS AWS Foundations Benchmark in Security Hub CSPM

Related NHI Mgmt Group resources: NIST CSF 2.0 Guide · Control Mapping Guide · Linux Server Hardening Guide · Endpoint Security Maturity Model · ISPM Guide