CIS Controls v8.1 vs NIST CSF 2.0: The Complete Control Mapping

Q: Is there an official CIS Controls v8.1 to NIST CSF 2.0 mapping?

Yes. CIS publishes CIS Controls v8.1 Mapping to NIST CSF 2.0, dated 25 June 2024, mapping the CIS Controls and individual Safeguards to NIST CSF 2.0. It is free from cisecurity.org, and the same mappings are browsable in the CIS Controls Navigator alongside mappings to NIST SP 800-53 Rev. 5, SP 800-171, ISO/IEC 27001:2022, PCI DSS v4.0, HIPAA, CMMC v2.0 and SOC 2.

Q: Does implementing all of CIS Controls v8.1 make me NIST CSF 2.0 compliant?

No. CSF 2.0 is a framework of outcomes rather than a compliance standard, and even against a Target Profile a complete CIS implementation leaves the GOVERN Function largely unaddressed. No CIS Safeguard requires documenting organisational context, stating a risk appetite, assigning executive accountability, or establishing board-level oversight - the GV.OC, GV.RM, GV.RR and GV.OV outcomes.

Q: Which should we adopt first, CIS Controls or NIST CSF?

If you are building capability from a low base, start with CIS Controls IG1 - 56 concrete Safeguards deliver defensive value in weeks. If a board, regulator, insurer or major customer is asking, start with CSF 2.0, because they expect an answer in Functions and Tiers. Most organisations run both, with CSF as the reporting and target-setting layer and CIS Controls as the implementation backlog.

Short answer: CIS Critical Security Controls v8.1 and NIST Cybersecurity Framework 2.0 are complements, not competitors. CIS v8.1 gives you 18 Controls and 153 prescriptive Safeguards, prioritised into three Implementation Groups, that tell an engineer what to configure. NIST CSF 2.0 gives you six Functions, 22 Categories and 106 Subcategories of outcomes that tell an executive what the organisation must be able to demonstrate. CIS publishes an official mapping between the two — CIS Controls v8.1 Mapping to NIST CSF 2.0, dated 25 June 2024 — and v8.1 itself exists largely to realign the Controls with CSF 2.0.

The mapping is genuinely useful and genuinely incomplete. CIS Safeguards cover the technical outcomes in PROTECT, DETECT, RESPOND and RECOVER densely. They cover GOVERN thinly, because GOVERN is about accountability, risk appetite, policy and oversight — things you cannot configure. Implementing all 153 CIS Safeguards will not satisfy CSF 2.0. It will satisfy most of four Functions and comparatively little of the newest one.

Most organisations arrive at this question the same way. Someone senior — a board member, a regulator, an insurer, a customer's third-party risk team — asks for the organisation's NIST CSF profile. The security team, which has been running a CIS Controls programme for three years and has the scan results to prove it, wants to know how much of that work counts. The honest answer is "a great deal of it, and not the part you are about to be asked about."

That gap widened rather than narrowed when NIST released Cybersecurity Framework 2.0 on 26 February 2024. CSF 2.0 added a sixth Function, GOVERN, and placed it first — ahead of IDENTIFY, which had opened the framework since 2014. GOVERN contains 31 Subcategories about organisational context, risk management strategy, roles and authorities, policy, oversight and cybersecurity supply chain risk management. Almost none of it is a technical control. CIS responded four months later with Controls v8.1, whose headline change was to realign the security-function tagging on every Safeguard to CSF 2.0 and to add GOVERN as a security function of its own.

This article is the reference page we wanted and could not find: every one of the 18 CIS Controls mapped to CSF 2.0 Functions and Categories, the reverse view for people who start from a CSF profile, an honest treatment of Implementation Groups against CSF Tiers, and a clear statement of where the mapping is one-to-many, partial, or simply absent. Where a mapping is contestable we say so. Where CSF asks for something no CIS Safeguard delivers, we name it.

153 Safeguards across the 18 CIS Controls in v8.1 CIS Implementation Group 3

106 Subcategories in NIST CSF 2.0, across 6 Functions and 22 Categories NIST CSWP 29, Appendix A

56 CIS Safeguards in IG1 — the essential cyber hygiene baseline CIS Implementation Group 1

31 Subcategories in the GOVERN Function alone — the least covered by CIS Safeguards NIST CSWP 29, CyberSilo count

Table of Contents

The category difference: prescriptive vs outcome-based
What CIS Controls v8.1 changed, and why
GOVERN: the newest Function and the widest gap
The complete mapping: all 18 CIS Controls to CSF 2.0
The reverse view: CSF 2.0 Categories to CIS Controls
Implementation Groups, profiles and CSF Tiers
Where the mapping breaks down
Which framework to use, and when
Running both together: best practices
Frequently asked questions

The category difference: prescriptive controls vs outcome-based framework

The single most common mistake in this area is treating CIS Controls and NIST CSF as two competing answers to the same question. They are not the same kind of object, and a great deal of wasted effort follows from assuming they are.

CIS Controls v8.1 is a prioritised list of things to do

The CIS Critical Security Controls are prescriptive. Safeguard 5.3 does not say "manage the account lifecycle appropriately"; it says disable dormant accounts after 45 days of inactivity. Safeguard 4.7 does not say "harden platforms"; it says manage default accounts on enterprise assets and software. That specificity is the point. A Safeguard can be handed to an engineer, implemented on a Tuesday, and tested by a scanner on the Wednesday.

CIS v8.1 contains 18 Controls holding 153 Safeguards in total, and — critically — it tells you the order to do them in. Implementation Group 1 is a defined subset of 56 Safeguards that CIS calls essential cyber hygiene. IG2 adds a further 74, for a running total of 130. IG3 adds the final 23, reaching all 153. That prioritisation is the feature practitioners value most and the one no other framework of comparable scope offers. It is the difference between a control catalogue and a plan.

The defining property of CIS Controls

Prioritisation. Every other major control set — NIST SP NIST SP 800-53, ISO/IEC 27001 Annex A, CSF 2.0 itself — tells you what good looks like. CIS Controls tells you what to do first, second and third, and defines those tiers precisely enough that two organisations reading IG1 will implement the same 56 things.

NIST CSF 2.0 is a way of organising and communicating a programme

The Cybersecurity Framework, released in its 2.0 form on 26 February 2024, deliberately does not tell you how to do anything. Its Core is a taxonomy of outcomes arranged in six Functions — GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER — subdivided into 22 Categories and 106 Subcategories. A Subcategory such as PR.AA-05 describes a state the organisation should be in, not a configuration it should apply. NIST is explicit that the Framework is not a checklist and does not prescribe implementation.

What CSF gives you instead is three things CIS Controls does not. It gives you a common vocabulary that survives contact with a board, an insurer or a regulator. It gives you the Profile mechanism — a Current Profile and a Target Profile, with the gap between them being your programme plan — which is the most under-used part of the framework and the most useful. And it gives you Tiers, which characterise the rigour of your cybersecurity risk governance rather than the count of controls you have deployed.

Why most mature organisations run both

Once you see the categorical difference, the combination becomes obvious. CSF 2.0 is the reporting and governance layer: it structures how you describe the programme, how you set a target, how you report progress upward, and how you talk to third parties. CIS Controls v8.1 is the implementation layer: it is what the engineering team actually works from, and it is what a configuration scanner can measure.

In practice the pattern that works looks like this. Build a CSF 2.0 Current Profile to establish where you are across all six Functions. Set a Target Profile with the business. Then, for the technical Subcategories in the gap, use CIS Controls — usually IG1 first, then IG2 — as the implementation backlog, because CIS has already done the prioritisation work that CSF deliberately leaves to you. Report progress in CSF language upward and manage delivery in CIS language downward. Neither framework does both jobs well, and using CSF as an implementation plan or CIS as a board report is the source of most of the frustration teams report with each.

Dimension	CIS Critical Security Controls v8.1	NIST Cybersecurity Framework 2.0
Type	Prescriptive, prioritised control set	Outcome-based framework and taxonomy
Publisher	Center for Internet Security	NIST (US Dept of Commerce)
Current version	v8.1, published 24 June 2024	CSF 2.0, published 26 February 2024
Top-level structure	18 Controls	6 Functions
Second level	153 Safeguards	22 Categories
Third level	—	106 Subcategories
Prioritisation built in	Yes — IG1 (56), IG2 (130), IG3 (153)	No — you set your own Target Profile
Answers "what do I configure?"	Yes	No
Answers "what am I accountable for?"	Partly	Yes
Governance coverage	Thin — a handful of process Safeguards	Extensive — the whole GOVERN Function
Supply chain coverage	Control 15 only (7 Safeguards)	GV.SC (10 Subcategories)
Machine-testable	Largely yes — via CIS Benchmarks and scanners	No — assessed, not scanned
Maturity model	Implementation Groups (scope of adoption)	Tiers 1–4 (rigour of risk governance)
Typical audience	Security engineering, IT operations	CISO, board, risk committee, regulators
Cost	Free to download; SecureSuite membership optional	Free

Sources: CIS Controls v8.1, CIS IG1, IG2 and IG3 pages; NIST CSWP 29 (CSF 2.0). Subcategory and Category counts derived from CSWP 29 Appendix A.

Building a CSF 2.0 Current Profile from an existing CIS programme? CyberSilo's NIST CSF compliance service maps existing technical evidence into CSF Functions and Categories so you can see the governance gap rather than rediscover it in an audit.

See NIST CSF services

What CIS Controls v8.1 changed over v8, and why CSF 2.0 caused it

CIS Controls v8.1 was published on 24 June 2024, four months after CSF 2.0. It is explicitly an iterative update rather than a new major version, and CIS maintains backwards compatibility with v8 throughout. The Control count did not change. The Safeguard count did not change. If you have a v8 programme, none of your work was invalidated.

What did change matters more than the size of the changelog suggests. CIS lists five updates in v8.1:

1Realigned NIST CSF security function mappings to match NIST CSF 2.0

Every Safeguard in the CIS Controls carries a security-function tag. Under v8 those tags followed the five CSF 1.1 Functions. v8.1 re-tagged them against CSF 2.0. This is the change that makes a Function-level CIS-to-CSF view coherent at all, and it is the reason a v8 mapping and a v8.1 mapping will not agree.

2Added the GOVERN security function

CIS adopted GOVERN as a security function in its own right, applying it to the Safeguards that establish and maintain processes, policies and inventories rather than technical state. This is the single most consequential change in v8.1 and we treat it separately below.

3Revised Asset Classes, with new mappings to Safeguards

Each Safeguard is tagged with the class of asset it protects, so that a team responsible for, say, network infrastructure can filter the Controls down to what applies to them. v8.1 revised those classes and re-mapped Safeguards against them. If your programme uses asset-class filtering to assign ownership, re-run that filter after upgrading — the assignments will have moved.

4New and expanded glossary definitions

Unglamorous and quietly important. A large share of implementation disputes in CIS programmes are definitional — what counts as an enterprise asset, what counts as sensitive data, what counts as a service provider. An expanded glossary reduces the number of arguments an assessor and an engineer can have about the same Safeguard.

5Clarified thin Safeguard descriptions and fixed minor typos

CIS's own wording is that it "added clarification to a few anemic Safeguard descriptions." Nothing was added or removed; several were made testable where previously they were ambiguous.

Notice what is not in that list. No Safeguards were added, removed or renumbered. No Implementation Group assignments were restructured. The v8.1 update is almost entirely about metadata, vocabulary and framework alignment — which is exactly what you would expect from a release whose purpose is to keep the Controls legible to organisations that now report in CSF 2.0 language.

What this means for an existing programme

Upgrading from v8 to v8.1 is a documentation exercise, not a re-implementation. Update your Safeguard descriptions, re-run any asset-class-based ownership assignments, and replace your CSF 1.1 function tags with CSF 2.0 ones. Your evidence, your exceptions and your scan results all remain valid.

GOVERN: the newest CSF Function and the widest CIS gap

GOVERN is the reason this comparison is worth writing in 2026 rather than 2019. It is the newest part of CSF 2.0, the least covered in practitioner content, and the place where a mature CIS programme most often discovers it has a hole.

What GOVERN actually contains

NIST places GOVERN first in the Core and describes it as establishing, communicating and monitoring the organisation's cybersecurity risk management strategy, expectations and policy. It holds six Categories and 31 Subcategories — more Subcategories than PROTECT, and nearly three times DETECT.

Category	ID	Subcats	Outcome NIST is asking for	Nearest CIS v8.1 coverage
Organizational Context	GV.OC	5	Mission, stakeholder expectations, legal and regulatory obligations, critical dependencies and resilience requirements are understood	None — no CIS Safeguard requires this
Risk Management Strategy	GV.RM	7	Risk objectives, appetite and tolerance statements are established, communicated and used in operational decisions	None — CIS assumes risk decisions, does not produce them
Roles, Responsibilities and Authorities	GV.RR	4	Accountability is assigned, resourced and reflected in HR practices	Partial — Controls 14 and 17 assign specific duties only
Policy	GV.PO	2	Cybersecurity policy is established, communicated and enforced, and reviewed on change	Partial — the "establish and maintain a process" Safeguards in Controls 3, 4, 5, 7, 8, 11, 14, 16, 17
Oversight	GV.OV	3	Risk management performance is reviewed and used to adjust the strategy	None — no CIS Safeguard covers governance review
Cybersecurity Supply Chain Risk Management	GV.SC	10	A supply chain risk programme is established, integrated with enterprise risk management, and applied across the supplier lifecycle	Partial — Control 15 (7 Safeguards) plus Safeguard 16.4

Category identifiers, names and Subcategory counts from NIST CSWP 29, Appendix A. Coverage assessment is CyberSilo's, derived from the CIS Controls v8.1 Safeguard list and the official CIS Controls v8.1 Mapping to NIST CSF 2.0.

How CIS v8.1 responded

CIS's response was to add GOVERN as a security function and re-tag the relevant Safeguards with it. This is a real improvement, and it is worth understanding precisely what it does and does not achieve.

What it achieves: it makes visible a category of Safeguard that had always existed but was previously filed under IDENTIFY or PROTECT. The CIS Controls contain a consistent pattern where the first Safeguard in a Control establishes and maintains a documented process — 3.1 for data management, 4.1 for secure configuration, 5.1 for account inventory, 7.1 for vulnerability management, 8.1 for audit log management, 11.1 for data recovery, 14.1 for a security awareness programme, 16.1 for a secure development process, 17.4 for an incident response process. Those are governance artefacts, and tagging them GOVERN correctly signals that the Safeguard is satisfied by a document and a review cadence rather than a configuration.

What it does not achieve: it does not add governance content. No new Safeguard was written for v8.1. The GOVERN tag was applied to Safeguards that already existed, and those Safeguards are process-establishment requirements scoped to a specific technical domain. There is no CIS Safeguard that asks you to state a risk appetite, to identify your critical external dependencies, to place cybersecurity accountability with a named executive, or to review programme performance at board level. Those are GV.RM, GV.OC, GV.RR and GV.OV outcomes, and CIS simply does not go there — by design, because CIS Controls has always been a technical control set.

The practical consequence

An organisation at IG3 — all 153 Safeguards implemented and evidenced — can still score poorly against the GOVERN Function of a CSF 2.0 assessment. This is not a failure of the CIS programme. It is a category boundary. Governance evidence comes from risk committee minutes, policy documents, RACI matrices and board reporting packs, not from a scanner.

Why GOVERN moved first, and what it changed about assessments

The placement is not cosmetic. In CSF 1.1 the framework opened with IDENTIFY, which made asset and risk identification the entry point and left governance implied. By elevating GOVERN to a Function and putting it first, NIST made the framework read as: decide who is accountable and what your risk position is, then identify assets and risks against that position, then protect, detect, respond and recover.

For anyone being assessed, this reordering has a practical effect. Assessors now open with governance questions, and technical maturity no longer compensates for governance immaturity in the way it did under CSF 1.1. The most common finding we see in first CSF 2.0 assessments of technically strong organisations is a high PROTECT and DETECT score sitting next to a Tier 1 or Tier 2 governance picture — a programme that works because good engineers built it, not because the organisation governs it.

The complete mapping: all 18 CIS Controls to NIST CSF 2.0

This is the centrepiece table. It maps each of the 18 CIS Controls v8.1 to the CSF 2.0 Functions and Categories its Safeguards contribute to, and states the strength of the relationship. Read it as a Control-level summary of the official CIS mapping, which operates at Safeguard-to-Subcategory granularity; where you need to know which of the 153 Safeguards satisfies which of the 106 Subcategories, download the CIS workbook cited beneath the table.

A note on how to read the coverage column. Direct means the Control's Safeguards substantially deliver the named Category's outcomes. Partial means they deliver some Subcategories within the Category and leave others open. Supporting means the Control contributes evidence toward the Category without being the primary source of it. No CIS Control fully satisfies a Category on its own, and several Categories require several Controls — the relationship is many-to-many in both directions.

#	CIS Control v8.1	Sg	CSF 2.0 Function(s)	CSF 2.0 Categories	Coverage
1	Inventory and Control of Enterprise Assets	5	IDENTIFY, DETECT	ID.AM (primary), DE.CM	Direct to ID.AM inventory outcomes; does not deliver asset criticality prioritisation
2	Inventory and Control of Software Assets	7	IDENTIFY, PROTECT, DETECT	ID.AM (primary), PR.PS, DE.CM	Direct — software inventory plus allowlisting sits squarely in ID.AM and PR.PS
3	Data Protection	14	PROTECT, IDENTIFY, GOVERN, DETECT	PR.DS (primary), ID.AM, PR.AA, GV.PO, DE.CM	Direct to PR.DS; the data management process Safeguard supports GV.PO only for the data domain
4	Secure Configuration of Enterprise Assets and Software	12	PROTECT, GOVERN	PR.PS (primary), PR.IR, PR.AA, GV.PO	Direct — the densest PR.PS coverage in the whole Control set
5	Account Management	6	PROTECT, IDENTIFY	PR.AA (primary), ID.AM	Direct to identity lifecycle outcomes within PR.AA
6	Access Control Management	8	PROTECT, GOVERN	PR.AA (primary), GV.RR	Direct — authentication, authorisation and MFA outcomes; GV.RR only incidentally, via role definition
7	Continuous Vulnerability Management	7	IDENTIFY, PROTECT	ID.RA (primary), PR.PS, ID.IM	Direct to vulnerability identification and patching; ID.RA risk prioritisation and response tracking only partial
8	Audit Log Management	12	DETECT, PROTECT, GOVERN	DE.AE (primary), DE.CM, PR.PS, GV.PO	Direct — log generation, retention, protection and review
9	Email and Web Browser Protections	7	PROTECT, DETECT	PR.PS, PR.IR, DE.CM	Supporting — a threat-vector Control that contributes to several Categories without owning one
10	Malware Defenses	7	DETECT, PROTECT	DE.CM (primary), PR.PS	Direct to endpoint and removable-media monitoring outcomes in DE.CM
11	Data Recovery	5	RECOVER, PROTECT, GOVERN	RC.RP (primary), PR.DS, GV.PO	Direct to backup creation, protection and testing; recovery plan execution outcomes only partial
12	Network Infrastructure Management	8	PROTECT, IDENTIFY	PR.IR (primary), PR.PS, PR.AA, ID.AM	Direct — the principal source of PR.IR technology-infrastructure-resilience evidence
13	Network Monitoring and Defense	11	DETECT, PROTECT, RESPOND	DE.CM (primary), DE.AE, PR.IR, PR.AA, RS.MI	Direct — with Control 8, the backbone of the whole DETECT Function
14	Security Awareness and Skills Training	9	PROTECT, GOVERN	PR.AT (primary), GV.RR	Direct to PR.AT; the only Control that meaningfully touches personnel-related GOVERN outcomes
15	Service Provider Management	7	GOVERN, IDENTIFY	GV.SC (primary), ID.AM, ID.RA	Partial — covers the supplier lifecycle but not supply chain risk programme integration
16	Application Software Security	14	PROTECT, IDENTIFY, GOVERN	PR.PS (primary), PR.DS, ID.RA, ID.IM, GV.SC	Direct to secure development outcomes; Safeguard 16.4 is the third-party component link into GV.SC
17	Incident Response Management	9	RESPOND, RECOVER, IDENTIFY, GOVERN	RS.MA (primary), RS.CO, RS.AN, RC.CO, RC.RP, ID.IM, GV.RR	Direct to incident management and communication; forensic-analysis depth in RS.AN is partial
18	agentic penetration testing	5	IDENTIFY	ID.RA, ID.IM	Direct to the "improvements identified from security tests and exercises" outcome in ID.IM

Safeguard counts per Control from the CIS Controls Navigator (summing to 153). Function and Category identifiers from NIST CSWP 29. The authoritative row-level source is CIS's own CIS Controls v8.1 Mapping to NIST CSF 2.0 (published 25 June 2024), which maps individual Safeguards to individual Subcategories; the table above is a Control-level synthesis of that mapping and the coverage judgements in the final column are CyberSilo's.

How to read this mapping

The relationship is many-to-many, not one-to-one. Control 17 alone touches seven Categories across four Functions. Category PR.PS draws on at least six different Controls. Any tool or spreadsheet that presents this as a tidy one-to-one crosswalk is simplifying to the point of being misleading.
"Primary" is where the evidence lives. When an assessor asks how you satisfy DE.CM, Controls 10 and 13 are the answer. When they ask about PR.AA, Controls 5 and 6 are. Knowing the primary Control per Category is what makes an assessment go quickly.
GOVERN appears in seven rows and owns none of them. Controls 3, 4, 6, 8, 11, 14, 15, 16 and 17 all carry some GOVERN weight, but only Control 15 has a GOVERN Category as its primary destination — and it covers GV.SC only partially.
Function coverage is uneven by design. PROTECT and DETECT are densely covered because that is what a technical control set is for. GOVERN is thinly covered for the same reason. Do not read low GOVERN coverage as a defect in CIS Controls; read it as a statement about what CIS Controls is.
Safeguard count is not coverage. Control 3 has 14 Safeguards and Control 18 has 5, but Control 18 delivers an ID.IM outcome that nothing else in the Control set delivers. Weight by outcome, not by volume.

One evidence set, two frameworks

Most organisations end up maintaining CIS evidence and CSF evidence separately, then reconciling them by hand before every assessment. CyberSilo's compliance automation collects technical evidence once and presents it against CIS Controls v8.1 Safeguards and NIST CSF 2.0 Subcategories simultaneously — so the CSF profile is a view of the programme rather than a second programme.

Explore NIST CSF 2.0 services Book a 30-minute demo

The reverse view: CSF 2.0 Functions and Categories to CIS Controls

People search this mapping in both directions, and the two directions serve different jobs. The Control-to-Function view above is what you use when you already run a CIS programme and need to describe it in CSF terms. The Category-to-Control view below is what you use when you have a CSF 2.0 Target Profile, know which Subcategories you are short on, and need to know what to actually build.

The second column of this table is the one to work from. It is where a CSF gap becomes an engineering backlog.

Function	Category	ID	Sub	CIS Controls that address it	Strength
GOVERN	Organizational Context	GV.OC	5	—	Gap
	Risk Management Strategy	GV.RM	7	— (Controls 7 and 18 supply inputs to risk decisions, not the strategy)	Gap
	Roles, Responsibilities and Authorities	GV.RR	4	14, 17	Partial
	Policy	GV.PO	2	3, 4, 5, 7, 8, 11, 14, 16, 17 (domain process Safeguards)	Partial
	Oversight	GV.OV	3	—	Gap
	Cybersecurity Supply Chain Risk Management	GV.SC	10	15, 16	Partial
IDENTIFY	Asset Management	ID.AM	7	1, 2, 3, 5, 12, 15	Strong
	Risk Assessment	ID.RA	10	7, 15, 16, 18	Partial
	Improvement	ID.IM	4	7, 17, 18	Partial
PROTECT	Identity Management, Authentication and Access Control	PR.AA	6	3, 5, 6, 12, 13	Strong
	Awareness and Training	PR.AT	2	14	Strong
	Data Security	PR.DS	4	3, 11, 16	Strong
	Platform Security	PR.PS	6	2, 4, 7, 8, 9, 10, 16	Strong
	Technology Infrastructure Resilience	PR.IR	4	4, 9, 12, 13	Strong
DETECT	Continuous Monitoring	DE.CM	5	1, 2, 8, 9, 10, 13	Strong
DETECT	Adverse Event Analysis	DE.AE	6	8, 13, 17	Strong
RESPOND	Incident Management	RS.MA	5	17	Strong
	Incident Analysis	RS.AN	4	8, 17	Partial
	Incident Response Reporting and Communication	RS.CO	2	17	Strong
	Incident Mitigation	RS.MI	2	13, 17	Partial
RECOVER	Incident Recovery Plan Execution	RC.RP	6	11, 17	Partial
RECOVER	Incident Recovery Communication	RC.CO	2	17	Partial

Category names, identifiers and Subcategory counts from NIST CSWP 29, Appendix A (six Functions, 22 Categories, 106 Subcategories). CIS Control attributions derived from the official CIS Controls v8.1 Mapping to NIST CSF 2.0; strength ratings are CyberSilo's assessment.

What the reverse view makes obvious

Two things jump out of that table that the forward view hides.

The first is the shape of the coverage. Eleven of the 22 Categories are strongly covered by CIS Controls, nine are partially covered, and two — GV.OC and GV.OV — have no CIS Safeguard at all. Every one of the gaps and most of the partials sit in GOVERN. If you plotted CIS coverage across the CSF Core it would look like a solid block across IDENTIFY through RECOVER with a hole punched in the top-left corner.

The second is the load on Control 17. Incident Response Management is the sole or joint source of evidence for six Categories — RS.MA, RS.AN, RS.CO, RS.MI, RC.RP and RC.CO — plus contributions to ID.IM and GV.RR. Nine Safeguards are carrying the entire RESPOND and RECOVER Functions between them. That is a real structural imbalance, and it explains why organisations with excellent CIS scores often assess weakly on RESPOND and RECOVER: the Control is satisfied, but CSF asks for more granularity in those Functions than nine Safeguards can deliver.

If you only take one thing from the reverse table

A complete CIS Controls v8.1 implementation gives you strong evidence for roughly half the CSF 2.0 Categories, workable evidence for another nine, and nothing at all for organisational context and oversight. Budget separately for the governance work. It is not large, but it is not free, and no scanner will produce it for you.

Implementation Groups, organisational profile and CSF Tiers

This is the comparison most often got wrong, so it is worth being blunt at the outset: CIS Implementation Groups and NIST CSF Tiers do not measure the same thing, and there is no official mapping between them. Any table claiming IG1 equals Tier 1 is asserting something neither CIS nor NIST has published.

Implementation Groups measure scope of adoption — how many of the 153 Safeguards you have implemented, chosen by CIS according to which threats they defeat and how much expertise they require. Tiers measure rigour of risk governance — whether cybersecurity risk decisions are made ad hoc, are informed by risk objectives, are formalised as organisation-wide policy, or are adaptive and embedded in culture. An organisation can be at IG3 and Tier 1 (excellent engineering, no governance), or at IG1 and Tier 3 (modest technical scope, but genuinely well governed). Both are common.

What the two do share is a sense of organisational profile, and that is the honest basis for putting them side by side. The table below sets out CIS's own descriptions of the IG1, IG2 and IG3 enterprise, alongside the Tier that organisations of that description typically reach — with the caveat above applying to every row.

Implementation Group	Safeguards	CIS enterprise profile	Threat model CIS designs for	Typical CSF Tier (indicative only)	What the IG does not give you
IG1 Essential cyber hygiene	56 (56 cumulative)	Small to medium-sized, limited IT and cybersecurity expertise, low tolerance for downtime, data sensitivity principally employee and financial information	General, non-targeted attacks; commodity malware and opportunistic intrusion	Tier 1–2 (Partial to Risk Informed)	Any GOVERN outcome beyond basic process documentation; no risk appetite statement, no oversight cadence
IG2 Intermediate	+74 (130 cumulative)	Employs staff dedicated to managing and protecting IT infrastructure; multiple departments with differing risk profiles; stores sensitive client or enterprise information; loss of public confidence is a major concern	Increased operational complexity; some regulatory exposure; targeted-but-not-sophisticated adversaries	Tier 2–3 (Risk Informed to Repeatable)	Supply chain risk programme integration; board-level oversight; formal risk tolerance
IG3 Advanced	+23 (153 cumulative)	Employs security specialists across risk management, penetration testing and application security; assets subject to regulatory and compliance oversight; successful attacks can cause significant harm to public welfare	Targeted attacks by sophisticated adversaries; reducing zero-day impact	Tier 3–4 (Repeatable to Adaptive)	GV.OC and GV.OV outcomes entirely; these remain unaddressed at every IG

IG safeguard counts and enterprise profiles quoted from the CIS IG1, IG2 and IG3 pages. Tier names and definitions from NIST CSWP 29. The Tier column is CyberSilo's indicative observation, not an official mapping. Neither CIS nor NIST publishes an IG-to-Tier correspondence, and Tiers are assigned on governance rigour, not Safeguard count.

Using Tiers properly

NIST is careful to say that Tiers characterise the rigour of an organisation's cybersecurity risk governance and management practices and provide context for how the organisation views cybersecurity risk. They are not a maturity score to be maximised. Tier 4 is not the goal for every organisation; the appropriate Tier is the one that matches the organisation's risk exposure and resources.

The productive way to use Tiers alongside Implementation Groups is as two independent axes on the same plan. Decide the Tier your risk profile and regulators require — that drives governance work: policy, accountability, oversight, risk appetite. Decide the Implementation Group your threat model requires — that drives technical work: the Safeguard backlog. Track them separately, because progress on one does not produce progress on the other, and conflating them is how organisations end up over-invested in tooling and under-invested in the governance that a CSF assessment will actually examine.

Where the mapping breaks down

Mapping documents are useful precisely because they are approximations, and dangerous for the same reason. These are the six failure modes we see most often when organisations lean on a CIS-to-CSF crosswalk harder than it can bear.

1. Implementing all of CIS v8.1 does not satisfy CSF 2.0

This is the headline caveat and it deserves stating without hedging. All 153 Safeguards, fully implemented and evidenced, leave GV.OC and GV.OV entirely unaddressed and GV.RM effectively unaddressed. That is 15 of the 106 Subcategories with no technical control behind them, all of them in the Function a CSF 2.0 assessor opens with. Treating a completed CIS programme as CSF compliance is the single most expensive misunderstanding in this space, because it is usually discovered during an assessment rather than before one.

2. The relationship is many-to-many in both directions

A crosswalk implies a row-to-row correspondence that does not exist. Control 17 contributes to seven Categories; Category PR.PS draws on seven Controls. When you build a compliance matrix in a spreadsheet, the natural instinct is one row per control with one mapped requirement, and that instinct produces a document that is quietly wrong. Model it as a many-to-many relationship or accept that your matrix is a summary rather than evidence.

3. Partial coverage is reported as full coverage

Most mapping tools mark a Subcategory green if any mapped Safeguard is implemented. That is not what the Subcategory asks. RC.RP contains six Subcategories about executing a recovery plan, verifying integrity of restored assets, and declaring the end of recovery. CIS Control 11's five Safeguards deliver excellent backups and tested restores — which is a genuine but partial contribution. A tool that reports RC.RP as satisfied because Control 11 is implemented has told you something false in a form that looks authoritative.

4. Governance, supply chain and improvement outcomes are the standing gaps

Three clusters recur in every gap analysis we run. Governance: organisational context, risk appetite, executive accountability, board oversight. Supply chain: CIS Control 15 manages service providers well, but GV.SC asks for a supply chain risk management programme integrated with enterprise risk management, applied across the whole technology lifecycle, and reflected in incident planning with suppliers — a programme, not a vendor inventory. Improvement: ID.IM asks for improvements identified from evaluations, from security tests, and from operational processes and lessons learned. CIS Control 18 covers the security-test half; nothing in CIS covers structured lessons-learned feeding back into the programme.

5. Mapping direction changes the answer

Mapping CIS to CSF and mapping CSF to CIS produce different pictures of the same programme, and both are legitimate. Forward mapping flatters you: nearly every Safeguard lands somewhere useful, so coverage looks broad. Reverse mapping is the honest one: it starts from the outcomes you are accountable for and asks what evidence exists, which surfaces the empty Categories immediately. If you are preparing for an assessment, run the reverse direction. If you are writing a status report, be aware which direction you have run.

6. Version drift between the two frameworks

The official CIS mapping is anchored to CIS Controls v8.1 and CSF 2.0 as they stood in June 2024. A mapping built against CIS v8 and CSF 1.1 will disagree with it — the security-function tags alone were re-cut in v8.1, and CSF 1.1 had no GOVERN Function to map into. Check the version pair on any mapping document before you rely on it, and re-check when either framework moves. Mapping documents age badly and rarely announce that they have.

Which framework to use, and when

The default answer for a mature organisation is both, in the roles described earlier. But the sequencing depends on what is driving the work, and starting with the wrong one wastes a quarter.

If you are starting from nothing

Start with CIS Controls IG1. Fifty-six Safeguards, defined precisely enough that a small team can work through them without a consultant, and chosen by CIS specifically to defeat the attacks that actually hit organisations of that size. Do not begin with a CSF Current Profile assessment: you will spend six weeks documenting the absence of things and finish with a report rather than a control.

If a board, regulator or insurer is asking

Start with CSF 2.0. The question being asked is a governance question, and it wants an answer in Functions and Tiers, not Safeguard counts. Build a Current Profile, agree a Target Profile with the business, and present the gap. Then use CIS Controls to close the technical part of that gap — but lead with the framework your audience already speaks.

If you already run a CIS programme and now need CSF

Run the reverse mapping in this article against your implemented Safeguards, and you will have most of a Current Profile in a day rather than a quarter. Then focus the actual assessment effort on GOVERN, where you have no existing evidence, and on RESPOND and RECOVER, where Control 17 alone will not carry the weight CSF expects.

If you are US federal, a federal contractor or in a NIST-anchored sector

CSF 2.0 is the organising framework and is likely to be named in your obligations directly. CIS Controls remains valuable underneath it as the implementation layer, and CIS publishes mappings to NIST SP 800-53 Rev. 5 and to SP 800-171 Rev. 2 and Rev. 3 as well, so the same Safeguard evidence carries across all three.

If you are ISO 27001 certified and being asked for CSF

You already hold most of the GOVERN evidence — an ISMS produces exactly the organisational context, risk methodology, policy set and management review that GV.OC, GV.RM, GV.PO and GV.OV ask for. Your likely gaps are technical depth in PROTECT and DETECT, which is where CIS Controls fits. This is the inverse of the CIS-first organisation's problem, and it is a more comfortable position to be in.

If you are an MSSP, consultancy or shared-services provider

Run both, but report in CSF. Clients rarely have a shared view of technical maturity, and Safeguard counts do not travel between organisations of different sizes. Functions, Categories and Tiers do. Maintain the CIS programme as your delivery backlog and the CSF profile as your client-facing artefact.

Running both together: best practices

Collect evidence once, present it twice

The most common operational failure is maintaining two evidence sets — a CIS one from the scanners and a CSF one assembled by hand before each assessment. They diverge within a quarter. Tag evidence at the point of collection — compliance automation platforms do this natively — with both the CIS Safeguard number and the CSF Subcategory identifiers it supports, and generate both views from the same store. This is more work in month one and dramatically less work in month twelve.

Use CSF Profiles as the plan and Implementation Groups as the sequence

The Target Profile tells you which outcomes matter to your organisation; the Implementation Groups tell you the order to build the technical ones. Used together they solve each other's weakness — CSF's lack of prioritisation and CIS's lack of business context. Used separately you get either a prioritised backlog nobody agreed to or an agreed target with no delivery order.

Budget explicitly for the governance gap

Put GV.OC, GV.RM, GV.OV and the unaddressed parts of GV.RR and GV.SC on the programme plan as named work packages with owners and dates. They will not appear in a scan report, they will not be raised by an engineer, and they will be the first thing an assessor asks about. The work itself is not large — a documented organisational context, a risk appetite statement, an accountable executive, a quarterly oversight cadence — but it needs someone senior to own it.

Reinforce RESPOND and RECOVER beyond Control 17

Nine Safeguards are carrying twelve Subcategories across two Functions. Supplement them deliberately: incident categorisation and severity criteria, forensic evidence handling, integrity verification of restored assets, criteria for declaring recovery complete, and defined internal and external recovery communications. None of these are CIS requirements, all of them are CSF outcomes, and all of them will be exercised for real eventually.

Record the framework versions on every artefact

State "CIS Controls v8.1" and "NIST CSF 2.0" on every mapping, profile, report and exception. Mapping documents from the v8 and CSF 1.1 era are still in wide circulation and still look current. A version stamp on your own artefacts costs nothing and prevents the reconciliation work that version drift otherwise creates.

Treat the official CIS mapping as the authority, not a vendor's crosswalk

CIS publishes the mapping itself and updates it. Vendor-supplied crosswalks embedded in GRC and CSPM platforms vary in quality, in the version pair they were built against, and in whether they distinguish partial from full coverage. Where a platform's mapping disagrees with the CIS document, the CIS document wins — and the disagreement is worth raising with the vendor.

Assess in the reverse direction before an audit

Forward mapping produces a flattering picture; reverse mapping produces an accurate one. Before any external assessment, walk the 22 Categories and ask what evidence exists for each, rather than walking your Safeguards and asking where they land. The gaps surface immediately and you find them rather than the assessor.

Do not chase Tier 4

NIST describes Tiers as characterising the rigour of risk governance and providing context, not as a maturity ladder to be climbed to the top. The correct Tier is the one your risk exposure, regulatory position and resources justify. Organisations that target Tier 4 without the risk profile to warrant it produce a great deal of process and very little additional security.

Free download: CIS v8.1 to NIST CSF 2.0 Mapping Workbook

Both directions of the mapping in a working spreadsheet — all 18 Controls against the six Functions and 22 Categories, the reverse Category-to-Control view, coverage ratings, a dedicated gap register for the GOVERN outcomes no Safeguard addresses, and an IG-versus-Tier planning sheet. Version-stamped to CIS Controls v8.1 and NIST CSF 2.0.

Download the workbook

Frequently asked questions

Is there an official CIS Controls v8.1 to NIST CSF 2.0 mapping?

Yes. CIS publishes CIS Controls v8.1 Mapping to NIST CSF 2.0, dated 25 June 2024, which maps the CIS Controls and individual Safeguards to NIST CSF 2.0. It is available free from cisecurity.org, and the same mappings are browsable interactively in the CIS Controls Navigator, which also carries mappings to NIST SP 800-53 Rev. 5, SP 800-171 Rev. 2 and Rev. 3, ISO/IEC 27001:2022, PCI DSS compliance v4.0, HIPAA compliance, CMMC compliance v2.0, SOC 2 compliance and others. Use the CIS document as the authority rather than a vendor's embedded crosswalk.

How many Controls, Safeguards, Functions, Categories and Subcategories are there?

CIS Controls v8.1 has 18 Controls containing 153 Safeguards. Those Safeguards are grouped into Implementation Groups: IG1 has 56, IG2 adds 74 for a cumulative 130, and IG3 adds the final 23 to reach all 153. NIST CSF 2.0 has six Functions — GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER — containing 22 Categories and 106 Subcategories.

Does implementing all of CIS Controls v8.1 make me NIST CSF 2.0 compliant?

No, and this is the most important caveat on the whole mapping. CSF 2.0 is a framework of outcomes rather than a compliance standard, so there is no "compliant" state to reach — but even against a Target Profile, a complete CIS implementation leaves the GOVERN Function largely unaddressed. No CIS Safeguard requires you to document organisational context, state a risk appetite, assign executive accountability for cybersecurity, or establish a board-level oversight cadence. Those are GV.OC, GV.RM, GV.RR and GV.OV outcomes and they need separate work.

What changed in CIS Controls v8.1 compared with v8?

CIS lists five changes: NIST CSF security function mappings were realigned to CSF 2.0; the GOVERN security function was added; Asset Classes were revised with new mappings to Safeguards; glossary definitions were added and expanded; and thin Safeguard descriptions were clarified alongside minor typo fixes. No Controls or Safeguards were added, removed or renumbered — the counts stayed at 18 and 153 — and CIS maintains backwards compatibility with v8. Upgrading is a documentation exercise, not a re-implementation.

What is the GOVERN Function in NIST CSF 2.0 and why does it matter?

GOVERN is the sixth Function, introduced in CSF 2.0 and placed first in the Core. It covers how the organisation establishes, communicates and monitors its cybersecurity risk management strategy, expectations and policy, across six Categories: Organizational Context (GV.OC), Risk Management Strategy (GV.RM), Roles, Responsibilities and Authorities (GV.RR), Policy (GV.PO), Oversight (GV.OV) and Cybersecurity Supply Chain Risk Management (GV.SC). It matters because it holds 31 of the 106 Subcategories — more than any other Function — and because assessors now open with it. Technical maturity no longer compensates for governance immaturity the way it did under CSF 1.1.

Do CIS Implementation Groups map to NIST CSF Tiers?

Not officially, and they measure different things. Implementation Groups describe the scope of Safeguard adoption — 56, 130 or all 153. Tiers describe the rigour of cybersecurity risk governance, from Partial (Tier 1) through Risk Informed and Repeatable to Adaptive (Tier 4). An organisation can sit at IG3 with Tier 1 governance, or at IG1 with Tier 3 governance. Treat them as two independent axes of the same programme plan rather than as a single maturity scale.

Which should we adopt first, CIS Controls or NIST CSF?

It depends on what is driving the work. If you are building security capability from a low base, start with CIS Controls IG1 — 56 concrete Safeguards give you defensive value in weeks. If a board, regulator, insurer or major customer is asking the question, start with CSF 2.0, because they are asking a governance question and expect an answer in Functions and Tiers. Most organisations end up doing both, with CSF as the reporting and target-setting layer and CIS Controls as the implementation backlog underneath it.

Where does the CIS-to-CSF mapping most often mislead people?

In four places. It presents a many-to-many relationship as a row-to-row crosswalk. It marks a Category green when only some of its Subcategories are covered — RC.RP and GV.SC are the usual offenders. It hides the load on CIS Control 17, whose nine Safeguards are asked to carry the whole of RESPOND and RECOVER. And it ages silently: a mapping built against CIS v8 and CSF 1.1 will disagree with the current one, because v8.1 re-cut the security-function tags and CSF 1.1 had no GOVERN Function to map into. Always check the version pair.

The bottom line

CIS Controls v8.1 and NIST CSF 2.0 answer different questions, and the organisations that get the most from both are the ones that stop trying to pick a winner. CIS tells you what to build and in what order; CSF tells you what outcome you are accountable for and gives you the language to report it. The official CIS mapping between them, published in June 2024, is a genuinely good document and worth downloading — provided you read it as an approximation of a many-to-many relationship rather than a crosswalk.

The one thing to carry away is the shape of the coverage. Across the 22 CSF 2.0 Categories, CIS Safeguards give you strong evidence for roughly half, partial evidence for another nine, and no evidence at all for organisational context and oversight. Every gap and most of the partials sit in GOVERN. That is not a weakness in CIS Controls — it is what happens when a technical control set meets a governance framework — but it is the part of your programme that a CSF 2.0 assessment will open with, and the part no scanner will build for you.

So run the reverse mapping before someone runs it for you, put the governance work packages on the plan with named owners, and version-stamp everything. The technical half of this problem you have probably already solved.

Book a NIST CSF 2.0 readiness demo Explore NIST CSF services

Sources and verification. CIS Controls v8.1 structure, change list and Implementation Group definitions verified against the CIS Controls v8.1 page, the CIS Controls list, the CIS Controls Navigator and the CIS IG1, IG2 and IG3 pages. NIST CSF 2.0 Functions, Categories, Subcategories and Tiers verified against NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, published 26 February 2024; Subcategory totals are counted from Appendix A. The authoritative control-level mapping is CIS's own CIS Controls v8.1 Mapping to NIST CSF 2.0, published 25 June 2024. Coverage ratings, gap assessments and the indicative IG-to-Tier column are CyberSilo analysis, clearly marked as such, and are not published by CIS or NIST. Where a fact could not be verified from a primary source, this article says so rather than estimating.