Which frameworks do CIS Controls mappings cover, and what do they tell a CISO?
A customer, contract or regulator asks for one framework, and your team already runs the CIS Controls. The CIS Controls Navigator for v8.1 lists mappings to 30 frameworks and versions, including NIST CSF 2.0, ISO/IEC 27001:2022, HIPAA, CMMC v2.0, DORA and NIS2. The Navigator is the starting point for answering that request, but it does not finish the job. The answer depends on the scope you have defined, the Implementation Group you have reached, and the specific requirements of the framework the outside party cares about.
Read the mapping as a pointer, not a verdict. The Navigator says only that frameworks and standards are referenced by or mapped to CIS best practices. It does not label any mapping as equivalent, subset or superset, so a mapping does not tell you that meeting a set of Safeguards satisfies a regulatory article or a control in another standard. CIS also states that the Controls do not replace any regulatory, compliance or authorization scheme. Before you tell a customer or regulator that CIS coverage answers their question, confirm with the framework's owner or your assessor which requirements the mapping actually reaches and which need separate evidence, such as a documented policy, a risk assessment or a contract clause.
Start with a short gap review. Pull the Navigator entry for the target framework, list the Safeguards it points to, and check each one against your Implementation Group target and your current evidence. Record which requirements the mapping leaves open and assign an owner to each. Ask your assessor, in writing, whether they will accept the mapping as supporting evidence for those requirements. This keeps the mapping useful as a planning tool while the assessor, not the mapping, decides what counts.
What a CIS mapping establishes and what it does not
A CIS mapping links a CIS Safeguard to a clause, control or subcategory in another framework, so a reader can see where the two overlap in what they ask. It is a crosswalk for planning, not a finding. Use it to decide which evidence you already hold can be reused, and which target requirements have no CIS counterpart and need separate work. The mapping shows overlap, not equivalence: the Navigator says only that frameworks are referenced by or mapped to CIS best practices, and it does not label any link as equivalent, subset or superset. Read every mapping as a starting point that needs a second check against the target text.
The limits come from the publishers themselves. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, so satisfying a CIS Safeguard does not by itself satisfy HIPAA, DORA, NIS2 or CMMC. NIST goes further for its own catalog: it does not conduct correctness testing on mappings submitted by others, and listing a mapping there does not imply NIST endorsement. The CIS mapping to NIST CSF 2.0 is published by CIS, so the accuracy of that crosswalk rests on CIS's own work. Ask your compliance lead to confirm which mapping version your team is using and the date it was published, since the Navigator is maintained by CIS and can change.
An assessor still tests the target framework's own requirements and the evidence it expects. A CIS Safeguard can be implemented and documented well while a specific requirement in the target framework asks for something the Safeguard does not describe, such as a defined reporting timeline, a particular retention period or a named governance role. Before relying on a mapping in front of an auditor or regulator, walk each mapped line to the target clause, confirm the evidence format that clause requires, and record the gaps. Your implementation partner can prepare systems and evidence against that list, but only the independent auditor or assessor for the framework decides whether the requirement is met.
Which mapping to use for which question
This table compares the three CIS-related mapping sources a reader can use: the v8.1 Navigator, CIS's own NIST CSF 2.0 crosswalk and the NIST Informative References catalog. Read each row to match a source to the question in front of you, then check what that source does not establish.
| Source | Best used for | What you must still verify |
|---|---|---|
| CIS Controls Navigator (v8.1) | Broad first pass across 30 frameworks and versions, including SOC 2, DORA, NIS2, CMMC and ISO/IEC 27001:2022, to see which Safeguards a framework references | Whether a referenced Safeguard satisfies the specific clause your regulator or assessor reads. The Navigator does not label any mapping as equivalent, subset or superset |
| CIS v8.1 to NIST CSF 2.0 mapping (dated June 25, 2024) | Detailed, CIS-authored crosswalk from each Safeguard to CSF 2.0 outcomes when you run both programs or report against the CSF | That your environment meets the Safeguard as CIS describes it, and that your CSF profile and tiers reflect your own scope and risk decisions |
| NIST CSF 2.0 Informative References catalog | Locating non-NIST mappings in one place, including mappings from other organizations, when you need to compare sources side by side | Correctness of each entry. NIST does not test non-NIST submitted mappings, and listing one does not imply NIST endorsement |
| Use for: a regulator or contract asks which CIS Safeguards support a framework | Start with the Navigator, then confirm the exact clause against the framework text itself | Your legal or assessor interpretation of the clause. The mapping is a reference, not a finding |
| Use for: you already run CIS Controls and need evidence for NIST CSF reporting | Use CIS's v8.1 to CSF 2.0 mapping to tie each Safeguard to CSF subcategories | Whether the Safeguard evidence you hold covers the subcategory outcome, since a CSF subcategory can need more than one Safeguard |
| Use for: a framework is not on the Navigator list | Check the NIST catalog for third-party mappings, and ask the framework owner whether it recognizes any of them | Source provenance, version currency and whether the mapping was built against the same framework version you must meet |
| Use for: an auditor asks how a mapping was produced | Show the source, version and date of each mapping used, and record your own gap decisions | Auditor acceptance. Mappings support your narrative but do not replace assessor testing of your controls |
| Use for: deciding whether one CIS program can answer several frameworks | Map Safeguards to each framework in a single register, keyed to the source and version used | Gaps the mappings do not show, such as framework requirements with no CIS Safeguard counterpart or differing evidence standards |
How teams answer several frameworks from one CIS program
The sequence starts from one Safeguard inventory and one evidence record per Safeguard, then maps that evidence to each framework's clauses and fills the gaps the Controls do not cover. The result is one body of evidence that answers several frameworks without repeating the same work for each.
Fix the Implementation Group scope
Decide which Implementation Group the organization is targeting, for example IG1 with its 56 Safeguards, and confirm which systems, business units and data sets fall inside that scope. The CIS Controls define IG1 as essential cyber hygiene, so an organization that needs IG2 or IG3 Safeguards for a regulator should record that choice now. The output is a written scope statement that names the Implementation Group, the asset classes covered and the owner of each Safeguard. Check the scope against the Implementation Group pages before the inventory starts.
Build the Safeguard inventory
List every Safeguard in the chosen Implementation Group with its Control, asset class, security function and owner, using the v8.1 Safeguard definitions as the reference. Assign each Safeguard to one named owner who is accountable for its implementation status. The inventory should show the current state of each Safeguard as implemented, partially implemented or not implemented. The check that closes this step is a complete register with no unassigned Safeguards.
Record evidence once per Safeguard
For each Safeguard, use the measures and metrics in the CIS Controls Assessment Specification to decide what evidence proves it is in place, such as an approved policy, an exported configuration, a scan report or an access review record. Store each artifact once, with the date it was produced, the system it covers and the Safeguard it supports. The assessment specification says it defines what to measure, not how, so the evidence method should be written down and agreed. The output is an evidence register that other frameworks can cite without new collection.
Map Safeguards to framework clauses in the Navigator
Use the CIS Controls Navigator for v8.1 to list which clauses of each target framework the Safeguards reference, such as NIST CSF 2.0, ISO/IEC 27001:2022, DORA or NIS2. The Navigator states that frameworks are referenced by or mapped to CIS best practices and does not label mappings as equivalent, subset or superset, so a mapped Safeguard is a pointer to related evidence, not proof of compliance. Record each mapping with the Navigator version used, and have a compliance lead confirm that every mapping relevant to a regulator reads the way the regulator intends. The output is a clause-to-Safeguard matrix for each framework.
Identify clauses no Safeguard covers
Go through each target framework's clauses that the matrix leaves empty, and decide whether an existing Safeguard covers them in substance or whether a requirement is new. A regulator's specific reporting timeline, for example, is usually outside the technical scope of the Controls and needs its own procedure. Confirm the exact requirement against the regulator's text or the framework's official source, not a summary. The output is a gap list that names each uncovered clause and the reason it is uncovered.
Add framework-specific controls and evidence
For each gap, write the framework-specific control, assign an owner and attach evidence that the organization can produce on request. Examples include an incident notification procedure with its contact list, a register of ICT third parties or a documented contract clause. Keep these items in the same evidence register so each one carries the framework clauses it supports. The output is a complete register that links every clause of each framework to either a Safeguard or a specific control with evidence.
Export results for each audience
Use CIS-Hosted CSAT, which offers cross-mappings to NIST SP 800-53 and PCI DSS and exports results to PowerPoint, Excel and PDF, to produce the views that each reader needs. Keep the source register as the single record, and generate the framework-specific summaries from it so that a change in one place reaches every view. The check that closes this step is a reviewer confirming that each exported summary matches the register and that its cross-mappings were reviewed. An independent auditor or assessor decides whether the evidence meets each framework, so share the package with them rather than presenting it as a certification.
How the mapping differs for regulated sectors
US covered entities and business associates can use the CIS Controls to organize technical safeguards, and the Navigator maps CIS Safeguards to the HIPAA regulation text (2013). The mapping helps a security team find which CIS Safeguards support a given HIPAA safeguard, so one set of technical work can be shown against both. HHS and the Office for Civil Rights still assess the Security Rule itself, including documentation and the risk analysis that drives the program.
- Risk analysis: The mapping does not replace the documented risk analysis of electronic protected health information, which must show where that data lives and what threatens it.
- Policies and documentation: Written policies, workforce training records and sanction processes are judged as documents, and a CIS Safeguard that calls for a process still needs that process written down.
- Business associate oversight: Contracts and vendor reviews with business associates are tested directly, so a CIS Control 15 mapping does not show that agreements are in place.
- Health sector guidance: The HPH sector Cybersecurity Performance Goals are also mapped in the Navigator, but they are voluntary guidance, so confirm whether a payer or contract requires them.
- Pending rule changes: Proposed amendments to the Security Rule could change the requirement text, so check the current rule status with HHS and counsel.
Confirm the regulation version and the status of any pending rule with HHS and your counsel before relying on a mapping row.
EU financial entities subject to DORA (Regulation (EU) 2022/2554) can use the Navigator's DORA mapping to show which CIS Safeguards support ICT risk management, incident handling and recovery work. The mapping helps a platform or security team point to existing technical evidence without rebuilding it for each request. The competent authority still tests DORA on its own terms, including governance, the register of ICT third-party arrangements and the detailed technical standards that sit beneath the regulation.
- ICT risk management: The authority will look for a documented framework approved by the management body, which a Safeguard list alone does not supply.
- Incident reporting: Reporting timelines, classification criteria and the content of notifications are set by DORA and its technical standards, not by CIS.
- Resilience testing: Threat-led penetration testing follows its own methodology, so a Control 18 mapping does not establish that a qualifying test was run.
- Third-party risk: Contract provisions and the register of information are assessed separately from Control 15 safeguards.
- US-facing operations: Where a group also operates in the US, the Navigator maps FFIEC CAT (May 2017) and NYDFS 23 NYCRR Part 500, and each has its own examination approach.
Confirm the current DORA technical standards and the expectations of your national competent authority before relying on a mapping in a supervisory submission.
Essential and important entities under the NIS2 Directive (Directive (EU) 2022/2555) can use the Navigator's NIS2 mapping to connect CIS Safeguards with the risk-management measures in Article 21. The mapping helps a team show that a technical control covers a measure, which is useful when the same work also answers customer questionnaires. National authorities still assess the obligations themselves, and for certain sectors the Implementing Regulation (EU) 2024/2690 sets detailed technical requirements.
- Governance and accountability: Management body approval, training and oversight are obligations that a technical Safeguard does not prove on its own.
- Incident reporting: Early warning, notification and final report deadlines come from the Directive, so confirm them against the transposed national law.
- Supply chain security: Supplier assessments and contract terms are judged as obligations, which maps more loosely to Control 15 than to a single technical check.
- Sector-specific detail: Where the Implementing Regulation applies, its requirements are more specific than a CIS Safeguard, and the mapping does not replace them.
- National transposition: Member states have implemented NIS2 through their own laws, so scope and supervision can differ by country.
Confirm the national transposition law and the competent authority's guidance for your entity type before relying on the NIS2 mapping.
Defense contractors handling controlled unclassified information can use the Navigator's mappings to NIST SP 800-171 Rev. 2 and Rev. 3 and to CMMC v2.0 to organize the technical work behind contract requirements. The mapping helps an engineering team see where one CIS Safeguard supports a CUI requirement, which reduces duplicate evidence work across programs. The Department of Defense and the assessment body named in the CMMC program still determine whether the requirements are met, using their own procedures.
- Revision choice: Rev. 2 and Rev. 3 differ in requirement text, so confirm which revision the current contract and CMMC rule reference before mapping.
- Scoping: The mapping does not define the CUI boundary, and assessors test whether systems that process CUI are in scope.
- Scoring and submission: Any score that a contract requires is calculated under the Department's method, not from a CIS mapping.
- Assessment procedures: Assessors use the procedures in NIST SP 800-171A, which ask for specific evidence that a Safeguard list may not describe.
- Subcontractor flow-down: Requirements passed to subcontractors are tested through contract terms and their own evidence.
Confirm the CMMC level, the NIST revision and the assessment body requirements with your contracting officer before relying on a mapping in a bid or submission.
Owners and operators of bulk electric system assets subject to NERC CIP, and pipeline operators subject to TSA Security Directive Pipeline 2021-02, can use the Navigator's mappings to show how CIS Safeguards support those obligations. The mapping helps an operations and security team connect network monitoring, asset inventory and access control work to specific requirements. The regulator and its auditors still test compliance against the standards and directive text, including the asset categorization and incident reporting duties those rules set.
- Asset categorization: NERC CIP applies by asset impact category, so a Safeguard applied everywhere may not meet the requirements for each category.
- Monitoring and logging: Monitoring obligations have defined scope and retention expectations that a CIS Control 8 or 13 mapping does not replace.
- Incident reporting: Reporting timelines and content under the TSA directive are set by the directive itself.
- Operational technology: Many CIP and pipeline obligations apply to control environments that the general enterprise Safeguards may not describe, so confirm coverage for those assets.
- Directive status: TSA security directives are reissued or revised, so the Pipeline 2021-02 version in force must be checked directly.
Confirm the current NERC CIP standards in effect and the current TSA directive version with the regulator before relying on a mapping in an audit or filing.
Where mapping projects go wrong and how to avoid it
A CIS Controls mapping shows where a Safeguard relates to a clause in another framework, and that relationship is only useful when the team reads it correctly. The cards below cover the mistakes that most often turn a mapping into a false assurance, along with the check that catches each one before an assessor does.
Treating a mapping as proof of compliance
A Navigator mapping shows that a CIS Safeguard is referenced by or related to a requirement in another framework. It does not show that your environment meets that requirement. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. Before relying on a mapping, confirm that you have test evidence for each Safeguard you cite, and that an assessor will accept that evidence for the clause in question.
Mapping to an outdated framework version
Frameworks change, and mappings are tied to specific versions. The Navigator for v8.1 lists NIST CSF 2.0, ISO/IEC 27001:2022, NIST SP 800-171 Rev. 2 and Rev. 3, and other specific editions. A project that maps to a superseded edition can miss requirements that the current edition adds. Record the framework version used in every mapping and recheck it against the version your auditor or customer names.
Reading mappings as equivalence
The Navigator does not label its mappings as equivalent, subset or superset. A Safeguard may cover part of a clause, all of it, or only a related concept. Teams that assume a one-to-one match often leave gaps unnoticed. For each mapped clause, write down whether the Safeguard covers the whole requirement or only a portion, and list the remaining work as a separate item.
Mixing Implementation Groups without scope
Implementation Group 1 is the essential cyber hygiene baseline, IG2 adds Safeguards and IG3 adds the rest, for 153 Safeguards in total. A mapping that cites an IG3 Safeguard for a control that applies to a small environment can overstate what has been done, and a mapping that cites only IG1 can understate the scope a regulator expects. State the Implementation Group that applies to your organization and show which Safeguards fall inside it.
Evidence not tied to the clause
An assessor reads a specific clause and asks for evidence against it. A folder of screenshots labeled by CIS Control does not answer that question. For each mapped clause, record the Safeguard, the assessment specification measure that verifies it, the system or process producing the evidence, the date collected, and the owner. Keep the link between clause and evidence current so that the same artifact can answer several frameworks without being reworked each time.
Assuming the CSF mapping covers every framework
CIS published a mapping of v8.1 to NIST CSF 2.0 on June 25, 2024, and NIST notes that it does not test correctness of non-NIST submitted mappings. Teams often treat that one mapping as a template for others, but each framework has its own clauses and its own assessment practice. Check every mapping independently, and confirm with the framework owner or assessor which edition and clause numbering applies before you present the result.
Questions buyers ask about CIS Controls mappings
Is a CIS Controls mapping accepted as evidence by an auditor?
A mapping is not evidence on its own. It is a cross-reference that shows which CIS Safeguards relate to a clause or control in another framework, and an auditor decides whether your evidence satisfies that other framework's requirements. Auditors typically test your own policies, configurations, logs and records against the target standard. Use the mapping to find where one body of evidence can answer several frameworks, then confirm with your assessor how they will accept it. CIS itself states that the Controls do not replace any regulatory, compliance or authorization scheme.
Who maintains the CIS Controls framework mappings?
CIS maintains the mappings published in the CIS Controls Navigator for v8.1, which lists 30 frameworks and versions, including NIST CSF 2.0, ISO/IEC 27001:2022, SOC 2, PCI DSS v4.0, CMMC v2.0, DORA and NIS2. The Navigator states only that frameworks and standards are referenced by or mapped to CIS best practices, and it does not label any mapping as equivalent, subset or superset. Other bodies publish their own cross-references. NIST notes that it does not test the correctness of non-NIST submitted mappings, so confirm any mapping you rely on against the source documents.
Do we need to be certified against the CIS Controls?
No. No organization can be certified against the CIS Controls. CIS publishes the Controls for free use to improve cybersecurity, and conformance is shown through self-assessment, evidence and, where relevant, independent review. The CIS Controls Assessment Specification defines what to measure for each Safeguard, and the CIS-hosted CSAT tool supports self-assessment. Customers and regulators may still ask for proof, so agree in writing which evidence you will provide and who will review it. Where a contract or framework requires a formal report, that report comes from an independent auditor or certification body, not from CIS or DeployOpen.
Can one CIS Controls program cover ISO 27001 and DORA together?
A single CIS program can supply much of the technical evidence for several frameworks, because many Safeguards relate to the same controls. The Navigator shows those relationships for ISO/IEC 27001:2022 and DORA, but it does not replace the target requirements. DORA also covers obligations such as ICT incident reporting, resilience testing and third-party oversight that need their own process records. Expect to add framework-specific policies, governance records and reporting. Confirm the scope with your competent authority or assessor and your ISMS scope statement before assuming any overlap is sufficient.
How much work is mapping compared with a gap analysis?
Mapping is desk work: someone reads the target framework, matches it to the Safeguards, and records which evidence answers which requirement. A gap analysis goes further, because it tests your actual systems and records against each requirement and identifies what is missing. Mapping costs little beyond staff time, but it produces a plan rather than proof. Most effort goes into the gap analysis and remediation that follow. Ask any implementation partner to separate the two in the written scope, with deliverables for each, so you can see what you are paying for.
What does our team need to supply for a mapping-based program?
The organization owns its controls and must supply the inputs that show how they operate. Typical items include:
- An asset inventory and a list of in-scope systems, applications and data stores
- Current policies, standards and procedures, plus approval and review records
- Access control, change, vulnerability and log management records
- Vendor and service provider contracts and assessments
- Incident response and training records
An implementation partner such as DeployOpen can help prepare systems and assemble evidence from your environment, which runs in your own infrastructure. Only an independent auditor, assessor or certification body issues reports or certificates.
Can we run the mapping and evidence work ourselves?
Yes, many teams do. The CIS Controls and the Navigator are free to use for your own cybersecurity improvement, and the Assessment Specification describes what to measure for each Safeguard. The work is staff time for reading, mapping, collecting evidence and keeping it current, which recurs at each review cycle. Bring in outside help where internal teams lack the skills to configure tooling, collect evidence from systems or prepare for an assessment. Confirm the licensing position first: CIS content is licensed for noncommercial use with modifications restricted, and commercial use requires CIS's prior approval.
Which parts of a mapping-based program can an outside partner handle?
A partner can usually take fixed-scope work such as preparing systems for evidence collection, hardening and documenting configurations, setting up logging and scanning tools, and assembling an evidence library mapped to your target frameworks. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and runs security testing that can produce evidence. Policy decisions, risk acceptance and control ownership stay with your leadership. Agree the scope, deliverables and timelines in writing before work starts, and ask for the evidence list in the statement of work.
How DeployOpen prepares CIS-aligned evidence for several frameworks
DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For CIS Controls mappings to other frameworks, we prepare systems and evidence so one CIS program can be read against several frameworks, while the organization owns its controls and independent auditors issue any reports or certificates.
How we scope
- Engagements are fixed-scope, with the frameworks, Safeguards and systems in scope agreed in writing before work starts.
- The written scope names which mapped framework requirements the evidence is meant to support, and which are left to the organization.
- We confirm the Navigator mapping version used, so every reference point is traceable to a single dated source.
- The scope states which assessor or auditor will review the evidence, and what that reviewer has confirmed they need.
How we build
- We build one evidence register keyed to CIS Safeguard IDs, with each row cross-referenced to the mapped framework requirement.
- We configure open-source tooling in the client's cloud, data center or air-gapped network to produce logs, scans and inventories.
- We test that each evidence item actually shows the Safeguard is operating, rather than only that a document exists.
- We document where a mapping is only a reference, so teams do not treat a link as proof of equivalence.
How we hand over
- You receive the evidence register, configuration records, runbooks and a written list of open gaps and owners.
- Each cross-reference includes a note on what the mapping does and does not establish for that framework.
- Knowledge transfer sessions cover how to refresh evidence for the next assessment cycle and for version updates.
- Handover documents identify which items your auditor, assessor or certification body must review independently.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover re-running evidence collection when CIS, NIST, ISO or another framework publishes a new version.
- We can help prepare for an assessor's questions, while the assessor alone decides conformance.
- Retainer scope, frequency and fees are agreed in writing and quoted from the defined scope.
