CIS Controls vs NIST CSF: which to use and when

CIS Controls vs NIST CSF: which one does your organization need?

If a customer, contract or regulator asks for one of these frameworks, the short answer is that you rarely choose between them. The CIS Controls v8.1 tell you which specific safeguards to implement, while NIST CSF 2.0 tells you which outcomes to achieve and how to organize the program around them. The two are complementary, and the Center for Internet Security publishes a mapping of its 153 Safeguards in 18 Controls to the CSF 2.0 subcategories, dated June 25, 2024, so you can see where each safeguard supports a specific outcome. The CIS white paper on the v8.1 mapping to NIST CSF 2.0 is the natural starting point for that comparison.

The right emphasis depends on three questions. First, who is asking, and what do they accept as evidence? A contract that names CIS Controls expects you to show specific safeguards are in place, which points your work toward the Assessment Specification and the Safeguard-level evidence it describes. A regulator or board that asks for an outcome-based program will more likely accept a profile organized by the six CSF 2.0 functions, Govern, Identify, Protect, Detect, Respond and Recover, with Govern newly added in 2.0. Second, do you already run a risk-management program? If you do, CSF 2.0 gives you a structure to hang existing risk decisions on, and the CIS Controls supply the concrete safeguards that fill each gap. If you do not, the prescriptive CIS list is often the faster way to start. Third, confirm with the requesting party whether they want a mapped answer, a checklist, or both.

In practice, many organizations use the CIS Controls as the operational catalog and CSF 2.0 as the governance wrapper, then reuse the same evidence for both. Before you commit, ask the requester which version they reference, whether they require CSF 2.0 or an earlier release, and whether a CIS-to-CSF mapping satisfies their question. Note that NIST does not test the correctness of mappings submitted by non-NIST organizations, and listing a mapping in its catalog does not imply NIST endorsement, so treat the CIS mapping as a practical guide that your own assessor should review rather than as a conclusion in itself.

What adopting each framework involves

This table compares who writes each framework, what it costs to use, what the organization must produce and what an outside party can check. Read it as a question list: if your customer or regulator asks for one framework, the right-hand columns show what you will need to build. The main takeaway is that CIS Controls tell you what to do, while CSF 2.0 tells you what outcomes to reach, so the work and the evidence differ.

Aspect	CIS Controls v8.1	NIST CSF 2.0
Who defines the requirement	The Center for Internet Security, a US nonprofit, publishes 18 Controls and 153 Safeguards	NIST publishes six functions, 22 categories and 106 subcategories describing outcomes
Cost to use the content	Free to use under the CIS license for internal improvement; commercial use needs CIS approval	Published by NIST for use by any organization; confirm current terms on the NIST site
Level of prescription	Specific actions per Safeguard, grouped into Implementation Groups IG1, IG2 and IG3	Outcome statements that leave the method to the organization, with Tiers and Profiles for context
What the organization must produce	Evidence that each in-scope Safeguard is implemented, measured against the CIS Assessment Specification	A current and target Profile, documented priorities and evidence that outcomes are achieved
How measurement is defined	The CIS Assessment Specification sets inputs, operations, measures and metrics for each Safeguard	NIST provides no assessment procedure for the core; the organization defines its own measures
Who can verify it externally	No certification exists; CSAT self-assessment, and CREST-backed accreditation for service providers	No certification exists; an independent assessor or auditor tests against the chosen Profile and evidence
Official mapping between the two	CIS published a v8.1 to CSF 2.0 mapping dated June 25, 2024	NIST lists the CIS mapping as an informative reference but does not endorse or test it
Best starting question	Which IG1 Safeguards are not yet in place, and what evidence proves each one?	Which outcomes matter most to our business, and what is our current and target state?

When an organization uses CIS, CSF 2.0 or both

CIS Controls v8.1 tells a team which safeguards to build and in what order, while NIST CSF 2.0 describes outcomes an organization should achieve across six functions. The cards below match common requests to the framework that usually fits, and list what to confirm with the person asking before any work starts.

A customer questionnaire names CIS Controls

The customer expects answers at the safeguard level, so the CIS Controls are the working reference. Ask whether they want a self-assessment against the Safeguards, evidence for specific Implementation Groups, or a mapped answer that also references NIST CSF 2.0. Confirm which Implementation Group they expect you to meet, because IG1 and IG3 imply very different answers. CIS publishes the Controls under a non-commercial license, so confirm how the customer expects you to reference the document.

A board wants a risk-based structure

Executives who ask for a risk-based program usually want a structure they can report against, organized by outcome rather than by technical task. NIST CSF 2.0 fits that conversation because its Govern function covers risk strategy, roles and oversight. Confirm whether the board wants a current-state profile, a target profile or a summary of gaps by function. Then map the CIS Safeguards underneath those outcomes so the technical work stays traceable.

A regulator references CSF

When a regulator cites NIST CSF, the expected output is a view of the organization's posture by CSF function and subcategory. Confirm whether the regulator requires a specific profile, a maturity rating or only a statement of alignment. CIS has published a mapping of v8.1 Safeguards to CSF 2.0, which helps show where the CIS evidence supports a CSF subcategory. Treat that mapping as CIS's work, and confirm with the regulator whether they accept it as a reference.

A mature program needs common language

Teams that already run several frameworks often need one vocabulary for technical teams and another for leadership. CIS Safeguards give engineers concrete, testable tasks, while CSF subcategories give managers a shared outcome language. Confirm which audience the output serves before choosing labels. Keep one control inventory and link each Safeguard to its CSF subcategories, so a single piece of evidence answers both reporting needs without duplicated work.

Specific technical safeguards must be shown

When a contract or auditor asks for named technical safeguards, such as logging, backups, MFA or vulnerability scanning, the CIS Controls are the more direct reference. Each Safeguard has an assessment specification that defines inputs, operations and metrics, so the evidence request is concrete. Confirm the exact safeguards named, the scope of systems involved and the evidence format the requester accepts. CSF subcategories describe outcomes and do not name these controls at that depth.

Both frameworks are required

Some organizations must report against CSF 2.0 at the executive level and demonstrate CIS Safeguards to technical reviewers. Using both means CIS provides the technical depth and CSF provides the outcome structure. Confirm whether the requester wants a single combined report or two separate artifacts, and who signs off on the mapping. Neither framework is a certification, so the reader should confirm what evidence an independent assessor will review.

How CIS maps its Safeguards to CSF 2.0 subcategories

CIS published its mapping of CIS Controls v8.1 and its Safeguards to NIST CSF 2.0 on June 25, 2024. The mapping came with the v8.1 update, which realigned the security function mappings to CSF 2.0 and added the Govern function that CSF 2.0 introduced. For a CISO, the practical result is that a Safeguard-level program can be read against the six CSF functions, so board reporting on Govern, Identify, Protect, Detect, Respond and Recover can point back to specific Safeguards.

Govern coverage: 25 of the 153 Safeguards carry the Govern function in v8.1, including Safeguard 14.1, which maps to GV.RR-01, and Safeguard 15.1, which maps to GV.SC-04.
Detection and response examples: Safeguard 13.1 maps to DE.CM-01 and Safeguard 17.4 maps to RS.MA-01, so monitoring and incident management investments can be traced to outcome subcategories.
Recovery and protection overlap: Safeguard 11.5 maps to both PR.DS-11 and RC.RP-03, showing that one control can support more than one outcome.
Asset and supplier links: Safeguard 15.1 also maps to ID.AM-04, tying supplier oversight to asset understanding.

Confirm with your team which Safeguards are already in place before using the mapping to set priorities, and check the Navigator for the full list rather than relying on these examples alone.

How to run a combined CIS and CSF program

This sequence turns the two frameworks into one working program: a scoped set of CIS Safeguards, a traceable link from each Safeguard to CSF subcategories, named owners and evidence, and progress reported in the language of the six CSF functions. Each step names the artifact it leaves behind so the work can be checked at every stage.

Confirm the requirement and the requester
Start by writing down who asked for the program and what they will accept as proof. A customer questionnaire, a contract clause, a board mandate or a regulator's expectation each points to a different level of detail, so the requester's wording decides whether the output must cover CIS Safeguards, CSF subcategories or both. Compliance and the CISO sign the statement of requirement. It is done when the requirement, the requester and the accepted form of evidence appear in one document that the program owner can point to.
Choose the Implementation Group scope
Select the Implementation Group that matches the organization's size, data sensitivity and threat exposure. IG1 is CIS's stated minimum for every enterprise, IG2 adds Safeguards for more complex operations, and IG3 adds the remaining Safeguards for organizations with security specialists and regulated, sensitive assets. The scope decision lists which of the 153 Safeguards are in and out of the program. It is done when the in-scope Safeguard list is approved by the CISO and the exclusions are recorded with reasons.
Link Safeguards to CSF subcategories in the Navigator
Use the CIS Controls Navigator for v8.1 and CIS's published mapping to NIST CSF 2.0 to identify which CSF subcategories each in-scope Safeguard supports. Some Safeguards map to more than one subcategory, and the Navigator examples show that a single Safeguard can touch both Protect and Recover outcomes. Treat the mapping as a working index, not as proof of compliance, and note where your own environment differs from the generic mapping. The output is a crosswalk table with one row per in-scope Safeguard and its linked subcategories, reviewed by the team that owns each area.
Assign owners for each Safeguard
Name one accountable owner for every in-scope Safeguard, along with the teams that operate the control day to day. Ownership follows the Safeguard's asset class, such as Devices, Software, Data, Users, Network or Documentation, and its security function, so the identity team, the platform team and the security operations team each see their own items. The organization owns its controls, so these owners are employees or accountable managers, not the implementation partner. It is done when every row in the crosswalk has a named owner and a review date that the owner has accepted.
Build evidence for each Safeguard
For each Safeguard, define the evidence that shows it is operating, using the measures and inputs in the CIS Controls Assessment Specification as the checklist. Typical items include a documented process, a system export, a configuration record, a ticket trail or a test result. Open-source tools can collect many of these items, but the tool output only counts once the owner has explained what it shows. The output is an evidence register that lists, for each Safeguard, the artifact, its source system, its collection method and its owner. Confirm with the team that any tool you use can produce the artifact in the form you need.
Test the evidence against the assessment specification
Before reporting progress, check a sample of the evidence against each Safeguard's measures. The question is whether the artifact shows the Safeguard is implemented, not whether a file exists. Record gaps, unclear items and items that depend on manual steps, and send them back to the owner with a clear description of what is missing. The output is a short gap log tied to specific Safeguards. The gap log is closed when each item has a remediation owner or a documented decision to accept the risk.
Report progress by CSF function
Roll the Safeguard status up to the six CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond and Recover. Because the crosswalk links each Safeguard to subcategories, the program can show where each function stands, which gaps sit in which function and which Safeguards support several outcomes at once. Present the same data to the board in CSF terms and to engineering in CIS Safeguard terms. The output is a function-level status report with links back to the Safeguard register. It is done when the requester confirms the report answers the question in the original requirement.
Confirm the outside review path
Decide who will check the program before it is used externally. CIS Controls do not have a certification, and an independent auditor or assessor issues any attestation a customer or regulator accepts. Ask the assessor which evidence format and mapping they expect, and whether they will test the CIS Safeguards, the CSF subcategories or both. Keep the crosswalk, evidence register and gap log under version control so the review can trace each claim. The output is a written confirmation of the assessor's scope and evidence expectations, recorded in the program file.

Where CIS and CSF mappings go wrong

CIS publishes a mapping of the v8.1 Safeguards to NIST CSF 2.0, and that mapping is useful for planning. Teams get into trouble when they read it as proof of conformance, skip the assessment detail, or keep two parallel evidence sets that drift apart.

Treating a mapping as proof

A published mapping shows where a Safeguard and a CSF subcategory are related. It does not show that either one is implemented, and NIST states that it does not test the correctness of non-NIST submitted mappings. Before relying on a row, check the Safeguard in your own environment and record what you observed. Ask your assessor how they will treat mapped references in the report.

Mapping without the Assessment Specification

The mapping tells you which outcome a Safeguard supports, but not how to verify it. The CIS Controls Assessment Specification defines inputs, operations, measures and metrics for each Safeguard. Teams that map controls to CSF subcategories without reading the matching specification often record a policy as evidence of a technical outcome. Pull the specification entry for each Safeguard before you write the evidence column.

Ignoring the Govern function

CIS v8.1 realigned its security function mappings to CSF 2.0 and added Govern, which covers 25 of the 153 Safeguards. Programs built on CSF 1.1 often have no owner for these Safeguards, so policy, risk strategy and supplier oversight go unassigned. Review every Govern-tagged Safeguard, assign a named accountable role, and confirm the governance records exist before you mark the Safeguard complete.

Duplicating evidence across registers

Many organizations run a CIS tracker and a CSF tracker side by side, then update one and forget the other. Two registers quickly disagree on status, owner and last review date. Keep one evidence repository with a single record per control, and tag each record with the Safeguard ID and the CSF subcategories it supports. Reports for each framework are then generated from the same source.

Assuming one framework covers the other

A contract or regulator may name CSF while your program runs on CIS Controls, or the reverse. A mapping helps you find overlap, but it does not transfer acceptance. Illustratively, a customer asks for a CSF profile and your Safeguard evidence covers most subcategories but not a few governance outcomes. Read the clause that names the framework, list the gaps against it, and confirm with the requesting party whether the gaps are acceptable.

Who owns the controls, who prepares evidence and who verifies

The organization carries the accountability for its cybersecurity program. It decides which Implementation Group to target, which Safeguards apply to its environment, what risk it accepts, and who is responsible for each Safeguard after the project ends. Those decisions cannot be delegated to a vendor, because the Controls describe what the enterprise does every day, not a product it buys once.

Scope and risk decisions: Leadership chooses the Implementation Group, the asset classes in scope and the risk tolerance behind any Safeguard the organization does not implement.
Named control owners: Each Safeguard needs an internal owner who runs the process, reviews the output and answers for gaps.
Written policy and process: The organization approves the policies and procedures the Controls call for, since the assessment checks that these exist and are followed.
Operating the controls: Daily work such as access reviews, patch approvals and log review stays with the organization's staff or its contracted operators.
Governance under CSF 2.0 Govern: Ownership of the Govern function, including risk strategy and supplier oversight, sits with leadership.

Before engaging anyone, confirm internally who will sign each Safeguard owner entry and who approves the scope.

Questions buyers ask before choosing CIS or CSF

Does NIST CSF 2.0 replace the CIS Controls?

No. The two work at different levels and are generally used together. NIST released CSF 2.0 on February 26, 2024, organized around six functions (Govern, Identify, Protect, Detect, Respond and Recover) and describing outcomes an organization should achieve. The CIS Controls v8.1 are a prioritized set of specific safeguards meant to defend against the most prevalent attacks. CSF 2.0 tells you what outcomes to manage and the CIS Controls tell you concrete actions to take toward many of them. CIS publishes a mapping of its safeguards to CSF 2.0 subcategories, and NIST lists a CIS Controls v8.1 reference in its informative references, though NIST does not test the correctness of non-NIST mappings. Teams that already run a CSF program often use the CIS Controls as the operational detail beneath it.

Does a CIS Controls mapping to CSF prove compliance?

No. A mapping shows where a safeguard relates to a CSF subcategory, which helps you reuse evidence. It does not establish that your organization meets either framework. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, and CIS Controls cannot be certified. Conformance is shown by implementing the safeguards, testing them against the CIS Controls Assessment Specification and keeping the evidence. If a customer or regulator asks for proof, ask them which assessment method and which independent assessor they accept, because the answer determines the evidence you need to produce.

How much effort does a combined CIS and CSF program take?

The effort depends on scope, the number of systems in scope, and how much of the evidence you already have. Start by counting the Safeguards in your target Implementation Group (IG1 has 56, IG2 has 130 in total and IG3 covers all 153) and checking which of them your existing policies, tooling and logs already satisfy. Because the mappings let one piece of evidence answer several CSF subcategories, a combined program is often less work than two separate ones, but that saving only materializes if the evidence is organized once. Ask any implementation partner for a fixed-scope written estimate that lists the systems, Safeguards and deliverables included, and confirm the effort with your own security team before you commit.

Can our internal team run a CIS Controls and CSF program alone?

Often yes for a small, well-staffed team with clear ownership, but the work splits into parts that need different skills. Your organization owns its controls and decides the risk posture, and internal staff usually must own the policies, approvals and day-to-day operation. Gaps tend to appear in technical hardening, centralized logging, vulnerability workflows and assessment evidence, which is where an implementation partner can prepare systems and documentation. Independent testing and the final assessment or report must come from an outside party, not from the partner. Before deciding, check whether you have one person who can own the Safeguard inventory, the time to collect evidence each quarter, and someone who can read the Assessment Specification critically.

What does the work need from our engineers and security owners?

Expect to supply access, decisions and time from several groups. Engineers need to provide read access to asset inventories, identity systems, cloud accounts, endpoint and network tooling, and logs. Security owners must approve policy language, risk acceptances and exceptions, and assign owners for each Safeguard. Legal, HR and procurement are often needed for the policies that cover data handling, training and service provider contracts. The Assessment Specification defines inputs and measures for each Safeguard, so the team should agree early on which inputs are available from existing systems and which must be built. Ask any partner to list these dependencies in the written scope so that delays are visible from the start.

How do we show CIS Controls conformance to a customer?

Show the evidence, not a certificate, because no organization can be certified against the CIS Controls. Most teams do this in one of three ways: complete the free CIS-hosted CSAT self-assessment, produce a written report that maps each in-scope Safeguard to its Assessment Specification measures and current evidence, or ask an independent third party to assess the program and issue its own report. A customer questionnaire can ask for the CSF mapping as well, so keep one evidence register that cites each Safeguard and its CSF subcategory. Ask the customer which format they accept before you start, and confirm whether an independent assessor's report is required, since that choice drives both cost and timeline.

Which should we use first, CIS Controls or CSF 2.0?

Choose based on what your customers, regulators or board ask for. If you need a governance framework to structure risk decisions and board reporting, start with CSF 2.0 and use the CIS Controls to define the concrete safeguards beneath each outcome. If you need a prioritized, checklist-style starting point with a clear first group of safeguards, start with IG1 of the CIS Controls and use the mapping to show how that work supports CSF functions. Many organizations do both. Confirm the requirement in writing with the party asking for it, because some contracts or state laws name the CIS Controls specifically, while others accept CSF.

Which official sources to read before deciding

Before you decide whether to adopt the CIS Controls, the NIST Cybersecurity Framework 2.0, or both, read the mapping documents yourself. Start with NIST's own release of CSF 2.0 on February 26, 2024, which explains the new Govern function and the framework's purpose for all sectors and organization types. Then read the NIST CSF 2.0 Informative References catalog, which lists the CIS Controls v8.1 reference alongside other resources. Note that NIST does not test the correctness of mappings submitted by others and does not endorse them by listing them, so the catalog tells you a mapping exists, not that it is accurate for your environment.

Next, read the CIS Controls v8.1 Mapping to NIST CSF 2.0 white paper, which CIS published on June 25, 2024. Use it to trace the specific Safeguards you expect to rely on to their CSF 2.0 subcategories, and check the outcomes it claims against your own systems. Pay attention to whether a Safeguard maps to more than one subcategory, because a single control may serve several outcomes. Your own CSF profile and your existing CIS self-assessment should be compared against this mapping, not accepted as a substitute for it.

Before you commit budget or staff time, confirm the exact requirement in writing with whoever is asking for it, whether a customer, contract, regulator or internal board. Ask them to name the framework and version they expect (CIS Controls v8.1 or NIST CSF 2.0), the Safeguards or subcategories they will test, and the evidence they will accept. A requirement phrased as "align to CIS" or "map to CSF" is open to interpretation, and a written answer prevents rework after scoping.

How DeployOpen scopes a combined CIS and CSF program

DeployOpen works on CIS Controls vs NIST CSF as an implementation partner: we scope the work in writing, build and test the self-hosted open-source systems and evidence in your own infrastructure, and hand over documentation. Your organization owns its controls, and independent assessors issue any reports.

How we scope

Agree which CIS Safeguards and CSF subcategories the written scope covers, and which are out of scope.
Record the environments, asset classes and systems in scope, including cloud accounts, data centers or air-gapped networks.
Confirm with your assessor or customer which evidence format and mapping view they will accept before work starts.

How we build

Configure and integrate self-hosted open-source tooling that produces logs, inventories and configuration records for mapped Safeguards.
Test each implemented control against the Safeguard's assessment measures, recording results for each Safeguard reviewed.
Harden, back up and document the platforms so the evidence stays current as systems change.

How we hand over

Deliver a cross-reference that links each CIS Safeguard to its CSF 2.0 subcategories and to the evidence supporting it.
Document procedures, owners and review cadence so your staff can run the program after handover.
Provide the evidence package to your independent auditor or assessor, who decides what conformance means for your organization.

How we support

Fixed-scope engagements are agreed in writing, so deliverables and timelines are known before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer when the program needs to keep pace with new framework versions.
Ask for a written quote based on your scope. Confirm with us how version updates to CIS Controls and CSF will be handled in that quote.

CIS Controls vs NIST CSF