The CIS Controls,
explained plainly

The CIS Critical Security Controls, commonly just "the CIS Controls", are a prioritized set of cybersecurity safeguards maintained by the Center for Internet Security (CIS). They are not a regulation and not a certifiable standard; they are a community-built, opinionated answer to one question: of everything you could do to defend an organization, what should you actually do, and in what order?

That framing is the whole point. Most frameworks tell you to consider a broad set of requirements and leave the sequencing to you. The CIS Controls instead rank the work, so a team with limited time and people knows which safeguards to put in place first and which can wait until the basics are solid. You implement them, you measure your progress against them — you do not "pass" them.

The current version is v8.1. Version 8 was published in 2021 and reduced the set from 20 controls to 18; v8.1, released in 2024, refines that set and updates the mapping so it lines up cleanly with NIST CSF 2.0. If you read older material referring to 20 controls, that describes v7 — the structure below is v8.1.

The 18 Controls run roughly from "know what you have" to "be ready when something goes wrong". They open with the foundations almost nothing else works without, inventory and control of enterprise assets, and inventory and control of software assets, because you cannot protect or patch what you do not know you run. From there they move through data protection, secure configuration, account and access management, vulnerability management, audit log management, and defenses for email, browsers and malware.

The later Controls cover the operational side of security: network infrastructure and monitoring, security awareness and skills training, service-provider management, application software security, incident response management, and penetration testing. Taken together they describe a complete defensive program, but the value is in the ordering — the early Controls carry far more risk reduction per unit of effort than the later ones.

Crucially, you do not work through all 18 Controls and every Safeguard at once. Which Safeguards you take on, and when, is decided by the implementation groups — the mechanism that turns a long list into a sequenced plan.

The defining feature of the CIS Controls is that the Safeguards are sorted into three implementation groups, each a self-assessed category describing who should do what. IG1 is essential cyber hygiene: the foundational Safeguards every organization should put in place first, achievable by a small team without deep security specialism. It is not a watered-down tier — it is the baseline that defends against the most common, untargeted attacks, and it is where almost everyone should begin.

IG2 builds on IG1 for organizations that manage more sensitive data, run more complex environments, or have the resources to go further. IG3 adds the remaining Safeguards for mature organizations facing sophisticated, targeted threats — the kind that need to withstand a determined adversary. Each group is cumulative: IG2 includes everything in IG1, and IG3 includes everything in IG2.

The intended path is to start at IG1 and grow. That is what separates the CIS Controls from a flat checklist: instead of staring at more than 150 Safeguards and freezing, a team implements IG1 first, gets real protection from a defined and achievable set, and expands to IG2 or IG3 only as its risk profile and capacity justify it.

CIS publishes two things that get confused constantly, and the distinction matters. The CIS Controls are the safeguards: the "what to do" across your whole program. The CIS Benchmarks are detailed secure-configuration guides for specific products — the "how to harden this particular system", with precise recommended settings for an operating system, database, browser or cloud platform.

You use them together, not interchangeably. A Safeguard under the secure-configuration Control might say "establish and maintain secure configurations" — and the relevant CIS Benchmark is where you find the exact settings to apply on a given platform to satisfy it. The Controls tell you the configuration needs to be secure and managed; the Benchmark tells you what "secure" means for that specific product.

The CIS Controls were built to interoperate, not to compete with the broader frameworks. CIS publishes mappings from the Safeguards to NIST CSF, ISO 27001, PCI DSS and others, and v8.1 specifically realigned its mapping to NIST CSF 2.0. That means the work you do to implement a CIS Safeguard does not sit in isolation — it can be pointed at the corresponding requirement in a framework you are also pursuing.

This is why so many teams treat the CIS Controls as a practical entry point. Because the Safeguards are concrete and prioritized, they give you a clear order of operations; because they map outward, that work feeds straight into a NIST CSF profile or an ISO 27001 control set when you take one of those on. You get a defined starting list and a head start on the broader framework at the same time.

The CIS Controls appeal to teams that want a concrete, prioritized "what do we actually do first" list rather than a broad set of requirements to interpret. That is often a growing software company, a lean IT or security team, or a managed-service provider that needs to improve its defensive posture quickly and does not have months to spend deciding where to begin.

In practice the Controls show up in two roles. They are the on-ramp before a broader framework: a way to make tangible progress and reduce real risk while a longer ISO 27001 or NIST CSF effort is still being scoped. And they are the backbone underneath one — the concrete safeguards that satisfy much of what those frameworks ask for, mapped across so the same work counts twice. Either way, the draw is the same: a prioritized list beats a blank page.

There is no CIS Controls certificate, no accredited auditor, and no pass mark. Nobody issues you a CIS Controls badge, because that is not how a voluntary safeguard set works. This sometimes reads as a weakness, but it is just a different model: the Controls are a tool for genuinely improving and demonstrating your security, not a label to acquire.

So you show progress by measuring it. Because the unit of work is the Safeguard, you can track which Safeguards are implemented, which are partial, and which are not yet started — by implementation group, so "we have completed IG1 and are part way through IG2" becomes a clear, honest statement of where you stand. CIS-CAT and CSAT exist precisely to support this self-assessment.

For customers and partners, that measured position is what you present: not a certificate, but a clear, evidenced picture of which safeguards you have in place and the group you are working toward. Kept current, it answers the security question a prospect is really asking, what do you actually do to defend this, without waiting on an audit cycle.

The right first move with the CIS Controls is almost always the same: implement Implementation Group 1. IG1 is a defined, achievable set of essential-hygiene Safeguards that any organization can put in place, and it defends against the bulk of common, opportunistic attacks. Starting there gives a small team real, measurable protection quickly, without first deciding which of more than 150 Safeguards matter.

In practice that means working the early Controls first — knowing what assets and software you run, managing accounts and access, keeping configurations secure, patching known vulnerabilities, and recording where each IG1 Safeguard stands as you go. Once IG1 is genuinely solid, you expand toward IG2 or IG3 in line with your data sensitivity, complexity and threat exposure, rather than all at once.

The CIS Controls are revised periodically as the threat landscape shifts, so part of running a program is keeping it current with the latest version. The move from v7 to v8 reorganized the set from 20 controls to 18 and regrouped the Safeguards; v8.1 then refined that work and realigned the mappings with NIST CSF 2.0. Each revision can move Safeguards between Controls or change which implementation group they fall into.

The practical implication is that a CIS Controls program is not a one-time exercise. When a new version lands, you reconcile your existing implementation against it — noting what moved, what is new, and where your measured position changes, rather than starting over. Teams that keep their safeguard status in one connected place absorb a version change as an update; teams that track it in scattered spreadsheets reconstruct it from scratch each time.