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 specific defensive actions intended to limit the most common attacks on systems and networks. The catalogue is prescriptive and prioritised, but it does not replace risk analysis. The publisher states explicitly that this is not a one-size-fits-all solution: the organisation still has to determine what is critical to it and which threat scenarios could halt its operations. ^[3]

Version 8.1 did not create Implementation Groups - those appeared back in v7.1. The 8.1 update preserved continuity with v8 and concentrated on context, consistency and coexistence with other frameworks. ^[1]

CIS Controls and CIS Benchmarks are not interchangeable terms

Controls say which capabilities need to be built; Benchmarks descend to technical settings. A benchmark can support Control 4, but on its own it does not prove that the whole control has been implemented. The official catalogue covers more than 100 benchmarks across over 25 vendor product families. The PDFs are made available free of charge, while the way they are used - commercial use in particular - 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 organisation start with this set. The typical profile described by CIS involves limited specialist expertise, low tolerance for downtime and the protection primarily of employee and financial data. That is a supporting characterisation, not a formal size limit. ^[2]

IG2 - 130 Safeguards in total

IG2 contains IG1 plus a further 74 Safeguards. It suits organisations whose services and data demand greater assurance and where the consequences of an incident go beyond a short operational disruption. It requires more formalised processes and skills.

IG3 - 153 Safeguards

IG3 contains the full catalogue: IG1, IG2 and 23 additional safeguards. It is intended for environments with high-value data or services that face targeted and advanced activity. It does not automatically mean every system in the organisation must carry an identical configuration.

Questions that decide the answer

• Which data and processes are critical, and what downtime is acceptable?
• Could disclosure, alteration or loss of data seriously harm clients, the organisation or the public interest?
• Could an adversary act deliberately against this organisation?
• What skills and capacity to maintain safeguards are realistically available?
• Do contracts or legislation impose more detailed requirements?

The answer may be mixed: IG1 as the organisational minimum plus selected Safeguards from IG2 or IG3 for critical systems. The rationale, the scope and the exceptions should be documented.

The 18 controls in version 8.1

The numbering makes identification easier, but it is not a straightforward project order. 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 devices and of virtual, cloud and IoT assets.
2. Inventory and Control of Software Assets - a list of authorised software and detection of unauthorised 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 control of deviations.
5. Account Management - the lifecycle of user, administrator and service accounts.
6. Access Control Management - granting, reviewing and revoking permissions in line with business need.
7. Continuous Vulnerability Management - continuous discovery, assessment and remediation of vulnerabilities.
8. Audit Log Management - collection, review, protection and retention of the logs needed to detect and analyse incidents.
9. Email and Web Browser Protections - reducing the risk from email and browsers.
10. Malware Defenses - preventing, detecting and controlling malicious software.
11. Data Recovery - backups, protection of recovery data and restore testing.
12. Network Infrastructure Management - secure operation of network devices and services.
13. Network Monitoring and Defense - traffic visibility and defensive action on the network.
14. Security Awareness and Skills Training - knowledge and skills matched to roles.
15. Service Provider Management - requirements, oversight and termination of supplier relationships.
16. Application Software Security - security across the lifecycle of software that is developed, hosted or purchased.
17. Incident Response Management - roles, plans, communication, exercises and improvement of response.
18. Penetration Testing - testing resilience through the controlled identification and exploitation of weaknesses.

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

Applying CIS Benchmarks safely

Most benchmarks contain Level 1 and Level 2 profiles, and some also carry STIG profiles. Level 1 aims to reduce the attack surface while keeping broad usability. Level 2 is usually more restrictive and may require additional testing. Not every benchmark has the same structure, setting count or profiles. CIS recommends testing configurations before production rollout. ^[4]

1. Match the benchmark to the exact product, release and system role.
2. Set a baseline profile and document settings that are not appropriate.
3. Test compatibility, performance, availability and the ability to roll back.
4. Deploy in stages, starting with a representative group.
5. Monitor configuration drift as well as version changes in the benchmark and the product.
6. Retain evidence: the test result, the profile version, the date, the scope and any approved exceptions.

Assessing an implementation: coverage is not effectiveness

The CIS Controls Assessment Specification (CAS) describes the inputs, operations, measures and metrics used to verify whether a Safeguard has been implemented. CIS distinguishes implementation itself from an assessment of how well a safeguard works. CAS concentrates on the first question; maturity and effectiveness require broader testing. ^[7]

For each Safeguard it is worth keeping a record covering status, asset scope, owner, evidence, verification date, exceptions, remediation plan and the date of the next assessment. A status of "not applicable" requires justification. A percentage figure without information about critical gaps can mislead the board.

CSAT helps to run a self-assessment, while the CIS-CAT tools assess configuration compliance against supported benchmarks. These are different tasks: one concerns the Controls programme, the other technical settings. ^[8]

Relationship with NIST CSF and ISO/IEC 27001

NIST CSF 2.0 describes high-level risk management outcomes across the Govern, Identify, Protect, Detect, Respond and Recover functions. It does not prescribe how to achieve them. CIS Controls supply more operational actions, so the two approaches can be combined. NIST publishes a mapping of CIS Controls 8.1 as an informative reference, but notes that such mappings are neither a confirmation of equivalence nor an endorsement of a solution. ^{[9] [10]}

ISO/IEC 27001:2022 sets requirements for an information security management system and can be the basis for certification. ISO/IEC 27002:2022 is guidance on controls; 27002 by itself is not a basis for certifying an organisation. Mapping Safeguards to ISO controls helps organise 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 create no presumption of conformity with the Polish Act on the National Cybersecurity System and do not release an entity from the obligations that apply to an essential or important entity. Since 3 April 2026 the amendment to the Polish Cybersecurity Act (KSC) transposing NIS2 has been in force; entities within its scope must analyse its current scope and deadlines rather than base their classification on a chosen framework. ^[13]

CIS can serve as a supporting catalogue of actions and a source of evidence for risk management measures such as asset, incident, continuity, supplier, vulnerability and access management. The NIS2 directive requires an all-hazards approach and measures proportionate to risk. A compliance map shows shared themes; it does not prove that every legal condition has been met. ^[14]

A practical implementation process

1. Define the scope. Identify services, data, locations, cloud, SaaS, mobile devices, IoT and OT.
2. Build a reliable inventory. Agree the data sources for assets, software, accounts and suppliers.
3. Choose the starting point. Adopt IG1 and add Safeguards that follow from risk or from legal duties.
4. Assess the current state. For each Safeguard record the scope, the evidence, the gap and the dependencies.
5. Set the order. First close the gaps that block control of other areas, for example a missing inventory.
6. Assign accountability. Every item should have a business owner and an executing owner.
7. Deploy and test. Use pilots, change control, restore tests and incident exercises.
8. Measure and improve. Periodically verify coverage, effectiveness, exceptions and drift.

There is no credible universal cost or timeline for implementing IG1, IG2 or IG3. They depend on scope, the starting state, the architecture, the number of exceptions, evidence requirements and the service model. The schedule should follow from a gap assessment, not from a ready-made table of months.

The most common mistakes

• choosing an IG purely by 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 a rollback plan;
• reporting a compliance percentage without disclosing the scope and the critical exceptions;
• omitting cloud services, SaaS, technical accounts, suppliers or OT/IoT devices;
• treating a mapping to ISO, NIST or the Polish Cybersecurity Act as proof of compliance;
• a one-off audit with no monitoring of change and no re-verification.

Frequently asked questions

Are CIS Controls v8.1 free?

CIS lets anyone use the Controls to improve their own security. Use by a vendor or consultant, or inside a product or service sold to clients, falls under separate terms and may require membership or authorisation. Always check the current CIS terms. ^[3]

Does CIS certify an organisation as compliant?

No. You can run a self-assessment or an independent assessment and issue a report stating the scope and the evidence, but it must not be called a CIS Controls certificate.

Is IG1 only for small companies?

No. CIS recommends IG1 as the starting point for every organisation. The organisational profile helps select further safeguards, but there is no formal headcount threshold.

Does full IG1 mean compliance with NIS2 or the Polish Cybersecurity Act?

No. IG1 can support some technical and organisational measures, but it does not automatically cover every legal obligation, the scope of application, governance, reporting and supervision.

Does every CIS Benchmark have Level 1 and Level 2?

Most have several profiles, but the structure depends on the product. Read the specific benchmark and apply exactly the version that matches the deployed environment.

Does a CIS-CAT result prove that CIS Controls are implemented?

No. It confirms that selected settings match a supported benchmark within a defined scope and moment in time. A Controls programme also covers processes, people, data, suppliers and activities that such a scan does not assess.

Where should implementation start?

By identifying critical services and data and building a reliable inventory of assets, software, accounts and suppliers. Then assess IG1 and add safeguards that follow from risk.

How often should the assessment be refreshed?

There is no single interval for the whole programme. Frequency should match the requirement of the specific Safeguard, how fast the environment changes, the risk and any significant changes. Benchmarks should also be re-assessed after a product, configuration or guidance version change.