Most security frameworks tell you what good looks like. Very few tell you what to do on Monday. The CIS Critical Security Controls are an attempt at the second problem, and that is the reason to be interested in them.
They are a prioritized set of defensive actions maintained by the Center for Internet Security, ordered so that an organization starting from nothing can work down the list and get the largest risk reduction earliest. The current release is CIS Controls v8.1, which added a governance security function and revised the asset classes and safeguard descriptions.
What makes them different from a control catalog
A catalog like NIST SP 800-53 is comprehensive and unordered by design. It describes controls thoroughly and leaves selection to a separate risk process, which is correct for its purpose and unhelpful if the question is where to start.
The CIS Controls make the opposite trade. They are less complete and they are sequenced, and the sequence encodes a judgment about which actions prevent the most common attacks. That judgment is the product.
Two structural features follow. Each control is expressed as an activity rather than a capability, so it describes something an organization does rather than something it owns. And each control decomposes into safeguards, which are the individually assessable units, so that progress can be measured in something finer than whole controls.
The ordering, and why the first two matter most
The controls begin with inventory, of enterprise assets and then of software. Organizations frequently find this anticlimactic and want to move to the interesting ones.
The ordering is deliberate and worth respecting. Every subsequent control is scoped by those inventories. You cannot patch what you have not listed, protect data you have not located, or detect anomalies on a device you do not know exists. An organization that skips to endpoint protection has bought a control whose coverage it cannot state.
Data protection appears early for the same reason. CIS Control 3: Data Protection asks organizations to develop processes and technical controls to identify, classify, securely handle, retain and dispose of data, and again the sequence is process before tooling.
The controls that follow cover secure configuration, account and access management, continuous vulnerability management, audit log management, protections for email, browsers, malware defenses, data recovery, network infrastructure, awareness, service providers, application security, incident response and penetration testing. The list is recognizable as the same territory covered elsewhere in this cluster, which is the point: the substance is broadly agreed, and what differs between frameworks is the arrangement.
Implementation groups
The feature that makes the controls usable for smaller organizations is the division of safeguards into implementation groups.
The first group is the subset intended as essential cyber hygiene, achievable by an organization with limited resources and no dedicated security staff. The second adds safeguards for organizations with more complexity and some specialist capacity. The third covers organizations facing targeted attack, with mature capability to match.
This matters because it converts a long list into a defensible scope. An organization can state that it is working to the first group, which is a meaningful commitment, rather than reporting partial compliance against everything. It also gives a natural roadmap: complete one group before beginning the next.
The common misuse is to treat group membership as a maturity badge and self assign upward. The groups describe the threat profile an organization faces and the resources it has, not its ambition.
How they relate to NIST and ISO
These frameworks are not competitors and are frequently used together, because they answer different questions.
The NIST Cybersecurity Framework supplies the outcome structure and the language for governance and reporting, covered in the NIST Cybersecurity Framework. NIST SP 800-53 supplies the detailed control catalog for organizations that need one, covered in NIST SP 800-53 security controls. ISO/IEC 27001 supplies a management system and, uniquely among these, a certification, covered in ISO/IEC 27001 and information security management.
The CIS Controls supply the ordering. A workable combination for a mid sized organization is to report against the NIST framework, because executives and auditors recognize it, and to sequence the work using the CIS Controls, because they answer what to do next. Published mappings between the sets exist, so work done against one can be evidenced against another without being redone.
What none of them is, and this is worth stating because it is regularly implied in marketing, is a certification you can buy. The CIS Controls are not something an organization becomes certified in.
Governance, added in the current version
The addition of a governance security function in the current release is a small change with a large implication, and it mirrors the arrival of a govern function in the NIST framework at around the same time.
Both changes reflect the same finding: technical safeguards fail predictably when nobody owns the decisions behind them. A patching safeguard with no agreed window, no exception route and no accountable owner does not get implemented, however well it is described. Adding governance as a first class element makes that explicit rather than leaving it implied.
For an organization adopting the controls, this means the early work is not entirely technical. Establishing who decides, who accepts risk and how often the position is reviewed belongs alongside building the asset inventory, not after the technical work is finished.
Service providers, and the control most often skipped
One of the controls covers service provider management, and it is consistently the least implemented in organizations that otherwise score well.
The reason is structural. Suppliers are contracted by departments, assessed once at onboarding if at all, and rarely reviewed afterwards. Meanwhile a growing share of an organization's data sits with them and a growing share of its access is granted to them.
The practical minimum is an inventory of providers holding data or holding access, a record of what each can reach, a risk based tier so that the significant ones receive more scrutiny than the trivial ones, and a defined offboarding step so that access ends when the relationship does. None of that requires a formal vendor risk program, and all of it is better than the common position of not knowing the list.
Using them without turning them into paperwork
The failure mode of any control set is the spreadsheet: a self assessment produced once, scored generously, and filed.
What makes the controls useful is treating a safeguard as implemented only when it is operating and evidenced, not when a tool capable of it has been purchased. The distinction is the same one made throughout this cluster between a control existing and a control working, and it is the only version of the assessment that predicts anything about an incident.
Scoring honestly produces a lower number and a more useful one. An organization that reports sixty percent of the first implementation group, with the gaps named and owned, is in better shape than one reporting ninety percent on the basis of purchases.
Where they fit for a smaller organization
For an organization without a security team, the first implementation group is probably the single most useful artifact in the field. It is finite, it is ordered, it assumes no specialist staff, and completing it addresses the great majority of opportunistic attacks.
It also gives a defensible answer to the question a customer or an insurer increasingly asks, which is what your security program consists of. Naming a recognized control set and reporting progress against it is a far stronger answer than a list of products.
What the controls do not do
They do not consider your specific business risk, which is why they complement rather than replace the assessment work described in cybersecurity risk assessments. A prioritized general list cannot know that one particular system is the one your organization cannot operate without.
They also do not implement themselves, and the recurring operation of the safeguards is the work described in the managed cybersecurity lifecycle. Inventory decays, configuration drifts, accounts accumulate, and a safeguard assessed as implemented last year may not be implemented now.
LABUSA uses recognized control sets to structure and sequence the work delivered through managed cybersecurity services delivered by LABUSA, and to report progress in terms a buyer, an auditor or an insurer already understands.
Sources
- Center for Internet Security, The 18 CIS Critical Security Controls.
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024.
- NIST, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5.