CIS Controls v8.1: 18 Controls, Implementation Groups, and CIS Benchmarks

What CIS Controls v8.1 are

CIS describes the Controls as a recommended set of concrete defensive actions intended to reduce the most common attacks against systems and networks. The catalogue is prescriptive and prioritized, but it does not replace risk analysis. CIS explicitly states that it is not a one-size-fits-all solution: an enterprise still has to determine what is critical to it and which threat scenarios could interrupt its operations.^[3]

Version 8.1 did not introduce Implementation Groups; they first appeared in v7.1. The 8.1 update preserved continuity with v8 and focused on context, consistency, and coexistence with other frameworks.^[1]

Status: CIS Controls are voluntary guidance. CIS does not certify organizations as "CIS Controls compliant". Accreditation of companies that provide implementation or assessment services is a separate matter described in CIS documentation.^[3]

CIS Controls and CIS Benchmarks are not interchangeable terms

Controls describe which capabilities should exist; Benchmarks go down to technical configuration. A Benchmark can support Control 4, but it does not by itself prove that the entire Control has been implemented. The official catalogue includes more than 100 Benchmarks covering over 25 vendor product families. PDF documents are available without charge, while usage, especially commercial usage, is subject to CIS terms.^[4][5]

IG1, IG2 and IG3: choosing the scope

IG1 - 56 Safeguards

CIS calls IG1 essential cyber hygiene and recommends that every enterprise start with this set. The typical profile described by CIS includes limited specialist expertise, low tolerance for downtime, and a primary need to protect employee and financial data. This is a supporting profile, not a formal company-size threshold.^[2]

IG2 - 130 Safeguards in total

IG2 includes IG1 plus 74 additional Safeguards. It is appropriate for organizations whose services and data require greater assurance and where the consequences of an incident go beyond short operational disruption. It requires more formalized processes and stronger capabilities.

IG3 - 153 Safeguards

IG3 contains the full catalogue: IG1, IG2 and 23 additional Safeguards. It is designed for environments with high-value data or services that may be targeted by sophisticated adversaries. It does not automatically mean that every system in the organization must use identical configurations.

Decision questions

• Which data and processes are critical, and how much downtime is acceptable?
• Could disclosure, alteration, or loss of data seriously harm customers, the organization, or the public interest?
• Could an adversary intentionally target the organization?
• Which skills and operational capacity to maintain safeguards are actually available?
• Do contracts or laws impose more detailed requirements?

The result can be mixed: IG1 as an organizational baseline, supplemented by selected IG2 or IG3 Safeguards for critical systems. The rationale, scope, and exceptions should be documented.

The 18 controls in version 8.1

Numbering makes identification easier, but it is not a simple implementation sequence. Dependencies matter more: without a reliable asset inventory it is difficult to assess configurations, vulnerabilities, logging, or backups.

1. Inventory and Control of Enterprise Assets - inventory and control of endpoints, virtual assets, cloud resources, and IoT devices.
2. Inventory and Control of Software Assets - inventory of authorized software and detection of unauthorized or unsupported components.
3. Data Protection - identification, handling, retention, and protection of data.
4. Secure Configuration of Enterprise Assets and Software - secure configuration baselines and management of deviations.
5. Account Management - lifecycle of user, administrator, and service accounts.
6. Access Control Management - granting, reviewing, and revoking access according to business need.
7. Continuous Vulnerability Management - continuous discovery, assessment, and remediation of vulnerabilities.
8. Audit Log Management - collection, review, protection, and retention of logs required for detection and incident analysis.
9. Email and Web Browser Protections - reducing risks associated with email and browsers.
10. Malware Defenses - prevention, detection, and control of malicious software.
11. Data Recovery - backups, protection of recovery data, and restoration testing.
12. Network Infrastructure Management - secure maintenance of network devices and services.
13. Network Monitoring and Defense - network visibility and defensive actions.
14. Security Awareness and Skills Training - knowledge and skills tailored to roles.
15. Service Provider Management - requirements, oversight, and termination of provider relationships.
16. Application Software Security - security of the lifecycle of software developed, hosted, or acquired by the organization.
17. Incident Response Management - roles, plans, communication, exercises, and improvement of incident response.
18. Penetration Testing - testing resilience by controlled identification and exploitation of weaknesses.

Full descriptions and the assignment of Safeguards to Implementation Groups should be taken from the current CIS document or spreadsheet, not from outdated summaries found online.^[6]

Applying CIS Benchmarks safely

Most Benchmarks contain Level 1 and Level 2 profiles, and some also contain STIG profiles. Level 1 is intended to reduce attack surface while preserving broad usability. Level 2 is usually more restrictive and may require additional testing. Not every Benchmark has the same structure, number of settings, or profiles. CIS recommends testing configurations before production deployment.^[4]

• Choose the Benchmark that exactly matches the product, release, and system role.
• Select a baseline profile and document settings that are not applicable.
• Test compatibility, performance, availability, and rollback capability.
• Deploy in stages, starting with a representative group.
• Monitor configuration drift and changes in both the Benchmark and the product.
• Retain evidence: test results, profile version, date, scope, and approved exceptions.

An automated scan result is technical evidence for a particular time and scope. It does not prove that the organization correctly manages exceptions, risk, or business continuity.

Assessing an implementation: coverage is not effectiveness

The CIS Controls Assessment Specification (CAS) describes inputs, operations, measures, and metrics used to verify whether a Safeguard has been implemented. CIS distinguishes implementation from assessing how well a Safeguard performs. CAS focuses primarily on the former; maturity and effectiveness require broader testing.^[7]

For every Safeguard it is useful to maintain a record of status, asset scope, owner, evidence, verification date, exceptions, remediation plan, and reassessment date. A status of "not applicable" requires justification. A percentage score without disclosure of critical gaps can mislead management.

CSAT supports self-assessment, while CIS-CAT tools assess technical configuration against supported Benchmarks. These are different tasks: one concerns the Controls program and the other concerns specific settings.^[8]

Relationship with NIST CSF and ISO/IEC 27001

NIST CSF 2.0 describes high-level cybersecurity risk-management outcomes in the Govern, Identify, Protect, Detect, Respond, and Recover functions. It does not prescribe a single way to achieve them. CIS Controls provide more operational actions, so the two approaches can be combined. NIST publishes CIS Controls 8.1 mappings as informative references, while making clear that mappings are not proof of equivalence or endorsement.^[9][10]

ISO/IEC 27001:2022 contains requirements for an information security management system and can form the basis of certification. ISO/IEC 27002:2022 provides guidance on information security controls; ISO/IEC 27002 itself is not a basis for organizational certification. Mapping Safeguards to ISO controls can help organize evidence, but it does not replace risk assessment, the Statement of Applicability, or the management-system requirements of ISO/IEC 27001.^[11][12]

CIS Controls, the Polish Cybersecurity Act and NIS2

CIS Controls are neither Polish nor EU law. They do not create a presumption of compliance with the Polish Act on the National Cybersecurity System and do not release essential or important entities from their statutory duties. Since 3 April 2026, the amended KSC implementing NIS2 has been in force; entities within its scope must assess the current legal criteria and deadlines rather than determine their status from a selected framework.^[13]

CIS can serve as a supporting catalogue of actions and evidence for risk-management measures such as asset management, incident response, continuity, supplier security, vulnerability management, and access control. NIS2 requires an all-hazards approach and measures proportionate to risk. A crosswalk can show common topics; it does not prove that every legal condition has been satisfied.^[14]

A practical implementation process

1. Define scope. Identify services, data, locations, cloud services, SaaS, mobile devices, IoT, and OT.
2. Build a reliable inventory. Agree on data sources for assets, software, accounts, and suppliers.
3. Choose a starting point. Adopt IG1 and add Safeguards required by risk or regulation.
4. Assess the current state. For each Safeguard, record scope, evidence, gaps, and dependencies.
5. Prioritize. First remove gaps that prevent control of other areas, such as an unreliable inventory.
6. Assign responsibility. Every element should have a business owner and an implementation owner.
7. Implement and test. Use pilots, change control, restoration tests, and incident exercises.
8. Measure and improve. Periodically reassess coverage, effectiveness, exceptions, and drift.

There is no credible universal cost or implementation time for IG1, IG2, or IG3. They depend on scope, starting maturity, architecture, exceptions, evidence requirements, and the service model. The schedule should result from a gap assessment, not from a generic table of months.

The most common mistakes

• choosing an Implementation Group solely from headcount or budget;
• treating the purchase of a SIEM, EDR, or scanner as implementation of an entire Safeguard;
• applying a Benchmark without compatibility testing and rollback planning;
• reporting a compliance percentage without disclosing scope and critical exceptions;
• omitting cloud services, SaaS, technical accounts, suppliers, or OT/IoT devices;
• treating a mapping to ISO, NIST, or KSC as proof of compliance;
• performing a one-time assessment without change monitoring and reassessment.