CIS Controls v8.1: The 18 Controls and 3 Implementation Groups

The CIS Controls are the most practical answer to a question every security programme eventually asks: out of everything we could do, what should we do first?

They are not a certification. Nobody audits you against them and there is no certificate at the end. That is exactly why they are useful — this is a prioritised list of things that demonstrably reduce risk, published by the Center for Internet Security and maintained from real attack data.

What the CIS Controls are

The current release is v8.1: 18 Critical Security Controls, containing 153 Safeguards between them.

The distinction between the two levels is the one people get wrong. A Control is a theme — “Inventory and Control of Enterprise Assets”. A Safeguard is the individual, testable action inside it. You do not implement a Control; you implement its Safeguards, and each one is something you can assign, evidence and check.

Version 8.1 of the CIS Controls was an alignment release rather than a restructure. CIS describes it as updated alignment to evolving industry standards and frameworks, revised asset classes and Safeguard descriptions, and one genuinely new element: the addition of a Governance security function. That addition tracks the direction every serious framework has moved in — technical controls without accountability do not survive contact with an organisation.

Two design decisions make the set unusual, and both are worth understanding before you adopt it:

• They are ordered. The sequence reflects what prevents the most damage soonest. Control 1 is inventory of enterprise assets because everything downstream depends on knowing what you have.
• They are tiered. Not every organisation is expected to do all 153 Safeguards, which is where Implementation Groups come in.

The three CIS Controls Implementation Groups

Implementation Groups are based on an organisation’s risk profile and the resources it has available. Each group identifies the subset of the 153 Safeguards that applies to it.

The groups are cumulative: IG2 builds on IG1, and IG3 contains both. The honest way to choose is to match your actual capability and risk, not the tier that sounds most impressive to a customer. An organisation claiming IG3 while failing IG1 asset inventory is worse off than one doing IG1 properly.

Why the ordering of the CIS Controls matters

Most control frameworks present their requirements as a flat set and leave prioritisation to you. That is defensible for an auditable standard and useless when you have three months and one security hire.

Inventory comes first — enterprise assets, then software assets — because every other control silently assumes it. Vulnerability management covers the systems you know about. Access control governs the accounts you have listed. Malware defences run on the endpoints you can see. A gap in Control 1 quietly becomes a gap in everything after it.

The second cluster is equally deliberate: data protection, secure configuration, account management and access control management — Controls 3 through 6. These are what stop a foothold becoming a breach, and they are mostly configuration and process rather than procurement. The expensive capabilities sit further down the list on purpose.

What adopting the CIS Controls actually involves

Nothing in the CIS Controls requires a purchase order. What it asks for is a small number of things maintained properly:

• An asset inventory that is maintained, not a spreadsheet produced once for an audit. This single artefact determines whether the rest works.
• A software inventory, distinguishing what is authorised from what is merely present.
• A chosen Implementation Group, recorded with the reasoning, so scope is a decision rather than a drift.
• Safeguard-level ownership. Each of the Safeguards in your group needs a name against it.
• Evidence that they operate — the same discipline any assessed framework demands, even though nobody is coming to assess.
• A review cycle, because the estate changes faster than the documentation describing it.

That last point is where self-directed frameworks quietly fail. No external auditor forces the annual re-examination, so it has to be scheduled deliberately or it does not happen.

How the CIS Controls relate to certifiable frameworks

The useful framing: the CIS Controls answer “what should we do”, and certifiable standards answer “how do we prove we did it”. Organisations that adopt only the second end up with well-documented programmes that still miss basics.

Where to start with the CIS Controls

1. Choose an Implementation Group honestly, and write down why you chose it.
2. Do Controls 1 and 2 properly — enterprise assets and software assets — before touching anything further down the list.
3. Assess against the IG1 Safeguards and record which are met in practice rather than in policy.
4. Fix in the published order. The sequence is the value; reordering it to suit what is easy discards the research behind it.
5. Assign every Safeguard an owner and a review date.
6. Re-assess annually, and whenever the estate changes materially.

Most of IG1 needs no tooling budget at all, which is the quiet advantage the CIS Controls have over every framework that starts with a platform. What it needs is someone to own the inventory, and the discipline to work down an ordered list rather than across a comfortable one.

This guide reflects v8.1 as published by the Center for Internet Security at 15 August 2026. CIS revises the set periodically and keeps v8 and v7.1 resources available separately — confirm the current version before building a programme around specific Safeguard numbering.

The CIS Controls v8.1 Toolkit provides 40 editable documents covering the asset and software inventories, the Safeguard implementation records, the Implementation Group determination and the review artefacts — the parts that turn an ordered list into something a team can actually run.