How much of NIST CSF 2.0 does the CIS Controls v8.1 mapping cover?
The NIST Reference Tool export links 48 of the 106 CSF 2.0 Subcategories to 49 distinct CIS Controls v8.1 Safeguards, so the CIS mapping covers a little under half of the Core. If a customer or contract asks for CSF alignment and you plan to use CIS Controls as the route, expect the Safeguards to answer the technical Subcategories well and the organizational ones poorly. Before you commit, confirm the current mapping rows in the NIST CSF 2.0 Reference Tool export yourself, because the count is only as current as the export you pull. The gap is concentrated in Govern. The mapping does link GV.SC-01 to Safeguard 15.2, but the rest of the Govern Categories (organizational context, risk management strategy, roles, policy and oversight) ask for decisions and records that a Safeguard cannot supply. Someone at the organization must define risk appetite, assign accountability, approve policy, and decide what the board sees. Identify outcomes such as risk assessment and improvement, and Recover outcomes such as recovery communication, carry similar organizational work. Treat those rows as governance tasks with named owners, not as Safeguard tasks that a configuration change will close. The mapping is an informative reference, not proof of alignment. NIST states that it does not check the correctness of non-NIST mappings and that listing one does not imply endorsement. Your assessor will look for evidence that the organization's own outcomes are achieved, and an assessor can test the Safeguard evidence only as one input. Record the mapping you used, the version of the export, and the owner for each uncovered Subcategory so that the claim you make to a customer can be traced and defended.
Where the 48 mapped Subcategories fall across the CSF Functions
This table compares each CSF 2.0 Function with the evidence the CIS Safeguards help produce and the work the mapping leaves to the organization. The Reference Tool export links 48 of the 106 Subcategories to 49 distinct Safeguards, so coverage is partial in every Function. Filter the export by Function to confirm the exact links before you plan evidence collection.
| CSF Function | What CIS Safeguards help evidence | What the mapping leaves to the organization |
|---|---|---|
| Govern (GV) | Supplier inventory evidence for GV.SC-01, linked to Safeguard 15.2 in the Reference Tool export | Risk management strategy, policy, roles, oversight and supplier due diligence standards |
| Identify (ID) | Asset inventory evidence; CIS places Safeguard 1.1 in the Identify security function | Risk assessment, threat context, risk response and prioritization decisions |
| Protect (PR) | Access evidence: Safeguard 5.1 links to PR.AA-01 and PR.AA-05 in the CIS Navigator, and to SP 800-53 AC-2 | Access policy, authorization decisions, awareness and training content, data protection choices |
| Detect (DE) | Monitoring and event evidence; confirm which DE Subcategories the export links to specific Safeguards | Which events to monitor, alert thresholds, and criteria for declaring an incident |
| Respond (RS) | Logging and incident handling inputs; confirm the RS links in the export before relying on them | Incident response plan, roles, triage decisions, stakeholder and regulator reporting |
| Recover (RC) | Backup and recovery inputs; confirm the RC links in the export before relying on them | Recovery plan, recovery priorities, verification criteria and recovery communications |
| All Functions | 48 of 106 Subcategories linked to 49 distinct Safeguards in the export | Assessment scope, Target Profile choices, and evidence an independent assessor accepts |
Where Implementation Groups fit when you adopt CSF through CIS
CIS Controls v8.1 sorts its 153 Safeguards into three Implementation Groups, each a cumulative set of safeguards for organizations with different resources and risk. The cards below explain how the groups work, why one Safeguard appears in all three, and where the choice of group stops affecting your NIST CSF 2.0 coverage.
IG1 as essential cyber hygiene
IG1 is the smallest set of Safeguards in CIS Controls v8.1 and CIS presents it as essential cyber hygiene for organizations with limited IT security expertise. It is the baseline most organizations should meet before choosing any higher group. Check whether your IG1 Safeguards have named owners, recurring evidence and a review date, because a Safeguard that exists only on paper will not satisfy an assessor or a customer questionnaire.
IG2 scope for growing teams
IG2 adds Safeguards for organizations with more staff, more systems and more sensitive data, and it builds on the IG1 set rather than replacing it. Before adopting IG2, confirm that the IG1 controls are already operating, since IG2 items such as more detailed logging or stricter access reviews assume that the basic inventory and account processes exist.
IG3 scope for mature programs
IG3 is the largest set of Safeguards and targets organizations with dedicated security staff and sensitive data or regulated operations. Its additions are the ones most likely to need dedicated tooling, longer evidence histories and formal review cycles. Ask whether your team can produce evidence for each IG3 Safeguard every review period, not only configure it once.
How to pick a group
Choose the group from two inputs: your risk profile and the obligations you must meet. A contract or regulator that names a specific control set may require a particular group regardless of company size. Document the choice in your risk register and state which group you target, so that the scope of your CSF assessment has a clear and defensible boundary.
Why Safeguard 1.1 sits in all three groups
Safeguard 1.1, which asks you to establish and maintain a detailed enterprise asset inventory, is assigned to IG1, IG2 and IG3 and falls in the Devices asset class under the Identify function. Because every group depends on knowing what assets exist, this Safeguard is the first place to confirm your inventory is accurate. It feeds directly into asset management outcomes in the CSF Core.
Group choice does not change CSF coverage
Selecting an Implementation Group does not by itself change which CSF 2.0 Subcategories the mapping covers. The mapping links Safeguards to Subcategories regardless of group, so a higher group adds more Safeguards that map to outcomes already in the Core. Use the group to decide how much work to take on, and use your Current and Target Profiles to decide which outcomes matter.
How to run a CSF-to-CIS implementation in phases
This sequence turns the CSF-to-CIS mapping into a working plan: it fixes the target outcomes first, then assigns Safeguards to owners, collects evidence, and hands the outcomes the mapping does not cover to governance.
Confirm the target Profile first
Before touching any mapping, the organization's leadership confirms which CSF 2.0 Subcategories form its Target Profile and records the current state for each one. This is owned by the CISO or equivalent with input from business and risk owners, since the Target Profile reflects risk decisions the organization makes, not a list a mapping hands over. The step is done when the Target Profile is approved, versioned and stored where the other steps can reference it. Ask any implementation partner to work from this approved document rather than from a default list.
Pull the Reference Tool export
The engineering or GRC lead downloads the NIST CSF 2.0 Reference Tool export, which includes the Core, Implementation Examples and informative references, and records the export date and version alongside the Target Profile. NIST updates informative references separately from the framework document, so the export date matters for later audit questions. The step is done when the file is stored in the evidence repository with a reference to its download date, and the team confirms it contains the CIS Controls v8.1 mapping.
Filter the CIS mappings against the Target Profile
The team filters the export to CIS Controls v8.1 rows and intersects them with the Target Profile, so each in-scope Subcategory shows which Safeguards are linked to it. The export links 48 of the 106 Subcategories to 49 distinct Safeguards, so most Subcategories will need work beyond CIS. The output is a working matrix with one row per in-scope Subcategory, its linked Safeguards, and a blank column for Subcategories with no CIS link. Check each row against the Navigator, because a single mapping can be narrower or broader than the outcome it sits beside.
Select Implementation Groups for the organization
Leadership and the security team decide which Implementation Groups (IG1, IG2 and IG3) the organization will target, based on its size, data sensitivity and the obligations it actually faces. IG1 Safeguards are the essential cyber hygiene set, and each Safeguard is assigned to the IGs in which it applies, so the selection determines which rows of the matrix are mandatory for the program. The output is a signed scope decision naming the IGs, plus the list of Safeguards that fall outside the selected IGs. Record the reason for any Safeguard left out so an assessor can follow the logic.
Assign an owner to each Safeguard
Each Safeguard in the scoped matrix receives one accountable owner, usually a named role in IT operations, security engineering or the business unit that runs the system. Owners confirm the technology they run, the process they follow and the record they produce, and flag any Safeguard that depends on a third party. The step is complete when every row has an owner, a backup owner for critical items and a documented escalation path. Owners do not need to be the people who implement tools, but they must be the people who can answer for the control in an assessment.
Collect evidence per Safeguard
Owners gather evidence that the Safeguard operates as described, such as inventory exports, access review records, configuration baselines, scan reports or change tickets, and store each item against its Safeguard and the CSF Subcategory it supports. The CIS assessment specification explains what each Safeguard asks for, so teams should test the evidence against that wording rather than against the mapping label alone. The output is an evidence index where each entry names the Safeguard, the artifact, the collection date and the person who captured it. Use self-hosted tools where they produce this evidence automatically, and confirm each tool's output format with its vendor or documentation before relying on it.
Record residual Subcategories for governance review
The Subcategories with no CIS link, and the Govern Subcategories that a technical Safeguard cannot satisfy on its own, are recorded as residual items. These typically include organizational context, risk management strategy, roles, policy, oversight and supplier obligations, which depend on decisions and documents rather than configurations. The output is a residual register with each item, its current state, the accountable executive and the forum where it will be reviewed. The step is complete when governance has accepted the register, so the CSF program does not appear finished simply because the CIS Safeguards are met.
What the mapping leaves to governance
The CIS Controls v8.1 mapping gives technical Safeguards a path into the CSF Core, but many Subcategories depend on decisions that only the organization can make. These cards cover the governance outcomes, and the parts of risk, improvement and response work, that stay with leadership even when every linked Safeguard is in place.
Organizational context and mission
GV.OC covers the mission, stakeholder expectations, dependencies and the legal, regulatory and contractual requirements that frame cybersecurity risk. No CIS Safeguard records which obligations apply to your business, so the list must come from legal, contract and operations owners. Check whether your customer and regulator requirements appear in the risk register and whether they are reviewed when contracts change. Mapping cannot identify these obligations for you.
Risk appetite and tolerance
GV.RM asks the organization to set risk objectives, appetite and tolerance, and to integrate cybersecurity risk with enterprise risk management. Safeguard implementation shows what controls exist, but not how much residual risk leadership accepts. Confirm that a named executive approves risk tolerance statements and that the standard risk method used for scoring is documented and applied the same way across business units.
Roles and accountability
GV.RR covers leadership accountability, defined cybersecurity roles, adequate resources and cybersecurity in HR practices. A Safeguard can require an inventory of accounts, but it cannot decide who owns that inventory or who approves exceptions. Check that each Safeguard in your program has a named owner, that staffing is sized to the work, and that background checks and onboarding responsibilities are assigned in writing.
Policy and oversight
GV.PO requires a cybersecurity risk management policy that is kept reviewed and updated, and GV.OV requires leaders to review strategy outcomes and risk performance so they can adjust direction. Technical evidence from tooling does not replace a signed policy or board-level review. Ask for review dates, approval records, and minutes that show leaders examined CIS Safeguard results and changed priorities where needed.
Supplier and supply chain decisions
GV.SC sets out the C-SCRM program, supplier prioritization, contract terms, due diligence and offboarding. The mapping links GV.SC-01 to CIS Safeguard 15.2, but that Safeguard covers only part of the supplier life cycle. Decide which suppliers are critical, which contract clauses require security obligations, and how supplier exits are handled, then confirm these decisions with procurement and legal owners.
Risk, improvement and response decisions
Parts of ID.RA, ID.IM, RS and RC need judgment that tools do not provide, such as risk response choices, decisions about which lessons from exercises change plans, and whether a recovery is declared complete. Confirm who approves risk acceptance, who signs off on incident plan updates after exercises, and who may declare an incident over, and record each decision with a date and owner.
Who owns the controls, who prepares the evidence, and who assesses it
The organization owns its cybersecurity program, its risk decisions and every control it claims to operate. A mapping between CIS Controls v8.1 and CSF 2.0 does not transfer that ownership to anyone. It shows where a Safeguard contributes to a CSF outcome, and the organization still decides whether the Safeguard fits its environment, what it accepts as residual risk and which Subcategories it adopts as its Target Profile. NIST's Reference Tool lists informative references and does not check whether a mapping is correct for a given business.
- Risk decisions: Choosing which outcomes matter, how much risk to accept and what to defer stays with leadership and the risk owners.
- Control operation: Staff must run the Safeguards day to day, such as reviewing accounts or handling alerts.
- Policy and governance: The Govern Function outcomes, including GV.PO policy and GV.RR roles, cannot be delegated to a vendor.
- Exceptions and sign-off: Any mapped Safeguard the organization does not perform needs a documented reason and an owner.
Before you sign any statement of alignment, confirm that your internal owners can name who operates each mapped Safeguard and who reviews its evidence.
An implementation partner such as DeployOpen works inside the client's own infrastructure to prepare the systems, configurations, mappings and evidence that the organization's controls depend on. Work is typically agreed in a fixed scope with written deliverables. The partner does not decide which controls the organization should own, and it does not issue reports, attestations or certificates. DeployOpen prepares systems and evidence for compliance assessments; independent auditors and certification bodies issue reports.
- Systems preparation: Deploying and hardening self-hosted open-source platforms that produce Safeguard evidence, such as identity, inventory and logging tools.
- Mapping work: Building a traceable register that links each in-scope Safeguard to its CSF Subcategory, system owner and evidence source.
- Evidence pipelines: Configuring exports, reports and retention so the organization can show results to an assessor.
- Documentation and handover: Writing runbooks and records that the internal team can maintain after the engagement.
- Testing support: Running security tests that check whether mapped controls work as described.
Ask the partner to state in writing which deliverables it produces and which decisions remain with your team.
An independent assessor, auditor or certification body is the only party that issues an assessment report or certificate. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program. This means no body can certify that an organization meets CSF 2.0 on NIST's behalf. Assessors who test against CSF 2.0 do so under their own methods, and they need to be independent of the team that built the controls.
- Independence: The assessor should not design or operate the controls it tests.
- Test procedures: Assessors sample evidence, interview owners and check configurations against the claimed Safeguards.
- Scope agreement: The organization and assessor agree in advance which systems, Subcategories and Safeguards are in scope.
- Reports and attestations: Only the assessor issues the output that a customer or regulator may accept.
- Qualifications: Ask which credentials and methods the assessor uses for CSF work, and whether it has worked with CIS Controls v8.1 mappings.
Confirm with the assessor and your customer or regulator which output they accept before the assessment starts.
Costs in this model fall into three buckets, and each bucket is paid to a different party. Internal staff time is the largest recurring cost because the organization operates its controls every day. Implementation work by a partner is usually one-time for setup, with optional retainers for upgrades and testing. Assessment fees are paid to the independent assessor and recur on the assessment cycle. The mapping itself is free to read, but turning it into a working register takes effort.
- Internal time: Operating Safeguards, reviewing evidence and maintaining policy recurs with the organization's own staffing.
- Partner scope: A fixed-scope build covers agreed deliverables, and a retainer covers ongoing support if you choose it.
- Assessor fees: Paid to an independent firm, and driven by scope, number of systems and evidence volume.
- Tooling: Open-source platforms have no license fee, but hosting and staff effort still apply.
- Quote requests: Ask each party for a written list of deliverables, assumptions and exclusions so costs can be compared.
Request a quote that separates partner, internal and assessor effort so no role is assumed to cover another.
Questions about using the CIS mapping for NIST CSF 2.0
Does mapping CIS Controls to NIST CSF prove CSF alignment?
No. A mapping shows which CIS Safeguards relate to which CSF Subcategories, but it does not show that your program achieves those outcomes. NIST describes informative references as mappings between the Core and other content, and some are narrower than a Subcategory while others are broader. One Safeguard may address only part of an outcome, and some outcomes depend on governance decisions, risk judgments and people processes that no Safeguard covers. To support a claim of alignment, assess your own implementation of each relevant Subcategory and keep evidence that the controls operate. Treat the CIS mapping as a navigation aid for choosing controls and collecting evidence, not as the assessment itself.
Does NIST certify organizations or products against CSF 2.0?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. Any claim that a product, service or organization is certified to NIST CSF 2.0 has no basis in NIST's program. Alignment is a position you document and, where a customer or regulator requires it, an independent assessor tests. If a vendor or partner makes a certification claim, ask which body issued it, what scope it covers and whether the CIS mapping was the basis for the claim. A credible answer will point to your own assessment records and to the evidence behind each Subcategory you say you meet.
How many NIST CSF Subcategories does the CIS mapping cover?
In NIST's CSF 2.0 Reference Tool export, the CIS Controls v8.1 mapping links 48 of the 106 CSF 2.0 Subcategories to 49 distinct CIS Safeguards. By subtraction, 58 Subcategories have no CIS link in that export, so the mapping cannot stand in for the whole Core. Coverage is also uneven across the six Functions. Before you plan around the mapping, open the export and count the linked Subcategories in each Function, then decide which of the unlinked outcomes need controls from other standards or from your own governance and process work. The export is the authoritative list for the version it reflects, so confirm the date of the download in your records.
Is CIS Controls IG1 enough to cover NIST CSF 2.0?
No, IG1 alone does not cover the CSF. IG1 is the set of essential cyber hygiene Safeguards that CIS identifies for organizations with limited resources. Implementation Groups are a prioritization of Safeguards, and they operate separately from the CSF Functions. The CIS mapping links Subcategories to Safeguards across all three groups, so an IG1-only program will leave some linked outcomes without matching controls. Safeguard 1.1, for example, is assigned to IG1, IG2 and IG3. Check the Implementation Group assignment of each Safeguard you rely on in the CIS assessment specification, and list the Subcategories that remain uncovered after your IG1 work. Those gaps set the scope for IG2 and IG3 work or for controls from other sources.
What must our organization do itself when using the CIS mapping?
Your organization owns its controls, risk decisions and evidence. Plan to:
- Set the risk strategy, scope and Target Profile that the Govern Function requires
- Decide which Subcategories apply to your environment and record the reasons
- Implement and operate the controls, then collect evidence that they work over time
- Assess results, track gaps and record exceptions and their approvals
An implementation partner can configure systems, prepare evidence and draft documentation, and a qualified assessor can test the results. Neither of them can make your risk decisions or accept residual risk for you. Ask any partner for a written scope that names the systems, Subcategories and deliverables it covers, and confirm who approves each control decision before work starts.
How do we confirm the current CIS to CSF links?
Download the current Reference Tool export and check the CIS Controls v8.1 rows against the CIS Controls Navigator for the same Safeguard and Subcategory pairs. Record the download date and the version of each source you used. NIST notes that it does not check the correctness of non-NIST mappings and that listing a mapping does not imply endorsement, so verify the specific links you rely on. For example, the Reference Tool links GV.SC-01 to Safeguard 15.2, and that link should be confirmed against CIS's own documentation before it appears in your assessment. Review the NIST Cybersecurity Framework updates archive at each assessment cycle, since NIST publishes new mappings and Quick-Start Guides there.
Checks before hiring a partner for CSF and CIS work
Bringing in outside help for NIST CSF and CIS Controls work can mean three different jobs: preparing systems, verifying mappings and issuing an independent assessment. The cards below cover the checks that keep those roles separate and make sure the organization keeps the evidence it pays for.
Ask for written scope first
Ask for a scope document that names the CSF Functions, Categories and CIS Safeguards in play, the systems and business units covered, and the deliverables. Confirm which items are preparation work and which are outputs the organization owns. Fixed scope agreed in writing before work starts makes it possible to compare quotes on equal terms and to tell when work has drifted beyond what was bought.
Separate preparation from assessment
A partner that configures tools, writes procedures and collects evidence is preparing the environment. Only an independent auditor, assessor or certification body can issue an assessment result. Ask the partner to state in writing that it does not issue reports or scores, and check that the organization, not the partner, owns each control and its risk decisions.
Confirm assessor independence
If an assessor is involved, confirm it has no role in designing or operating the controls it will test. A firm that built the CIS Safeguard implementations and then scores them has a conflict. Ask who will perform the assessment, how their independence is documented, and whether the same team has been on both sides of the same engagement.
Ask how mappings are verified
The NIST Reference Tool lists the CIS Controls v8.1 mapping, but NIST does not check the correctness of non-NIST mappings. Ask the partner how it confirms each link from a CSF Subcategory to a Safeguard, including the one-to-many and partial matches, and whether it reads the Safeguard against the CIS assessment specification. Ask for the mapping worksheet as a deliverable.
Check experience with both frameworks
Ask for examples of prior work that combined CSF 2.0 outcomes with CIS Controls v8.1 Safeguards, and ask how the team handled Implementation Groups when scoping. Ask who on the team holds practical knowledge of the CIS Controls Navigator and of the CSF Core. Request references that the organization can verify directly, and do not accept unnamed case studies.
Confirm handover of evidence
Ask what the organization receives at the end: system configurations, policy documents, the mapping workbook, evidence index and open items. Confirm the files are stored in the organization's own repository and can be read without the partner's tools. A clear handover lets internal staff maintain CSF and CIS evidence after the engagement ends, and lets an assessor trace each claim to its source.
How DeployOpen scopes CIS-based CSF work and hands over evidence
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the systems and evidence that show how CIS Controls v8.1 Safeguards map to NIST CSF 2.0 outcomes. Your organization owns the controls and the governance decisions, and an independent assessor or auditor issues any report.
How we scope
- We agree a written scope listing which CSF 2.0 Subcategories and mapped CIS Safeguards are in and out of the work
- We record which governance outcomes, such as GV.SC-01 and policy decisions, stay with your leadership and risk owners
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any work starts
How we build
- We configure the self-hosted platforms that produce evidence for the Safeguards you select, inside your cloud accounts or data centers
- We check each mapped Safeguard against the CIS assessment specification and record where a platform only partly covers it
- We test the evidence pipeline so the same Safeguard can be shown to an assessor on request
How we hand over
- We deliver a traceability workbook linking each CSF Subcategory to its CIS Safeguard, owning team and evidence source
- We document the configuration, runbooks and known gaps so your staff can operate and explain the setup
- We confirm with your assessor which mappings they will accept before final handover
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- A retainer can refresh the mapping when NIST or CIS publishes new reference material, after we review the change
- We do not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work
