NIS2 vs CIS Controls: which to pursue first and when to combine them
If you are an essential or important entity under NIS2 and need a practical control set, start by treating NIS2 as the legal obligation and the CIS Controls as the implementation layer. NIS2 creates no certificate of compliance. National competent authorities check compliance through inspections, security audits, security scans, information requests and administrative fines (Articles 32 to 34), so the CIS Controls give you a prioritized way to build and evidence measures, not a substitute for Article 21. Do not present a CIS mapping as proof that you satisfy Article 21, and confirm with your national competent authority how it expects evidence to be presented.
Begin with CIS Implementation Group 1, which CIS describes as essential cyber hygiene and a minimum standard for every enterprise. IG1 has 56 Safeguards. Move to IG2 once IG1 is operating and your environment adds operational complexity or sensitive information, which adds 74 Safeguards for a total of 130. Consider IG3 only when you have dedicated security specialists and sensitive assets facing sophisticated, targeted attacks, which adds the remaining 23. Your in-scope services, sector annex and threat profile decide the group, so confirm the choice against your own risk assessment rather than assuming the highest group is required.
Run the NIS2 duties that no control set covers as a separate workstream from day one. These include registration with the authorities, the staged incident reporting at 24 hours, 72 hours and one month under Article 23, and the management body training and liability duties in Article 20. Assign owners for each and rehearse the reporting path, because a Safeguard in IG1 will not tell you who notifies the CSIRT. Ask your advisers or internal counsel to confirm the transposition law in each Member State where you operate, since the national rules set the exact reporting and registration steps.
How NIS2 and the CIS Controls differ on scope, structure and licensing
This table compares who requires each framework, how each is structured, how each is measured, the license terms that govern use, and what proof each produces. Read it to decide whether the CIS Controls can serve as a practical implementation layer beneath NIS2 obligations, which they cannot fully replace.
| Dimension | NIS2 (Directive (EU) 2022/2555) | CIS Controls v8.1 |
|---|---|---|
| Who requires it | Essential and important entities in 18 sectors, through national transposition laws | Voluntary guidance; CIS states the Controls do not replace any regulatory, compliance or authorization scheme |
| Structure | Article 21 sets risk-management measures in law without prescribing specific controls | 18 Controls and 153 Safeguards, grouped by Implementation Groups |
| Implementation Groups | Not applicable; obligations apply by entity classification (essential or important) | IG1 has 56 Safeguards, IG2 adds 74 (130 total), IG3 adds the remaining 23 (153 total) |
| Governance coverage | Management body training and liability under Article 20 sits outside any control set | 25 of 153 Safeguards carry the Govern function in v8.1, aligned to NIST CSF 2.0 |
| How measurement works | Competent authorities assess through inspections, audits, scans and information requests | The CIS Controls Assessment Specification defines measures and metrics to verify each Safeguard; it covers what to measure, not how |
| License terms | Binding law in each Member State; no licensing question | Creative Commons BY-NC-ND 4.0; free for internal improvement, but commercial use needs CIS's prior approval |
| Proof produced | No certificate; oversight outcomes come from authority supervision and fines | No certificate from CIS; evidence is internal records mapped to Safeguards, plus any third-party assessment you commission |
| Ask your team to confirm | Your national transposition law and your entity classification with the competent authority | Whether any commercial use or service you plan falls under CIS approval and which CIS SecureSuite terms apply |
What the CIS to NIS2 mapping does and does not prove
The CIS Controls Navigator lists NIS2 among its mappings for CIS Controls v8.1, so you can trace which Safeguards relate to which NIS2 measures. That trace is a planning aid, not proof of compliance. ENISA states that its own mapping of Implementing Regulation 2024/2690 is not a measure of equivalence and does not assess whether a standard fully covers the regulation's requirements. The same caution applies to any third-party mapping. A Safeguard marked as related to an Article 21 measure tells you where to look for evidence; it does not tell you the measure is met in your environment.
Mappings from non-NIST sources also carry no endorsement. NIST says it does not check the correctness of non-NIST informative references and that listing a mapping does not imply endorsement. Treat the CIS-to-NIS2 link the same way: confirm each row against the current text of the Implementing Regulation and the ENISA guidance before you rely on it, and record who reviewed it and when. Ask your team to check whether a mapped Safeguard is implemented at the level the Article 21 measure expects, since the mapping itself cannot answer that question.
Your national competent authority will judge the evidence your organization produces, not the mapping. Build a traceable file for each mapped Safeguard: the asset scope, the configuration or policy in force, the operating records and the owner who signs off. Use the CIS Controls Assessment Specification to define what to measure for each Safeguard, then confirm with your authority which evidence formats and inspection methods it expects, since NIS2 creates no certificate of compliance and supervision runs through inspections, audits, scans and information requests.
Where CIS Controls work overlaps NIS2 risk management
Article 21 asks for risk-management measures covering areas such as policies, incident handling, business continuity, supply chain security and vulnerability handling, but it does not prescribe the controls that deliver them. The CIS Safeguards below are practical places to start in each area, and each card names what the authority will still expect you to document.
Asset inventory
CIS Safeguards in the Devices and Software asset classes ask you to build and keep an inventory of hardware and software in scope. For NIS2, the inventory is only useful if it feeds the risk assessment and the scope of your Article 21 measures. Check that you can show which systems support your in-scope services, who owns each one and how the list is reviewed. The inventory itself is not the evidence; the risk decisions made from it are.
Access control and identity
CIS Safeguards on user accounts, access rights and administrative privileges cover account management, least privilege and the use of multi-factor authentication where the Safeguard requires it. NIS2 Article 21 names access control and asset management among its measures, so the authority will look for your access policy, approval records and review cycle. Confirm which Safeguards apply to your Implementation Group before you claim coverage in your risk assessment.
Vulnerability and patch management
CIS Safeguards on continuous vulnerability management and patching set the cadence for scanning, prioritizing and remediating weaknesses in enterprise software. Article 21 requires measures for vulnerability handling and disclosure, and the Implementing Regulation 2024/2690 sets the technical detail for in-scope digital services. Document your prioritization criteria, exception approvals and remediation timelines, since a control that runs without records will not satisfy an inspector.
Backup and recovery
CIS Safeguards on data recovery cover backup scope, protection of backup data, testing of restores and the recovery of enterprise assets after an incident. Article 21 links these measures to business continuity, including backup management and disaster recovery. Keep restore test results, recovery time objectives set by the business and the record of who approved them. A successful backup job does not, on its own, show that a service can be recovered.
Logging and detection
CIS Safeguards on audit log management and security alerting cover which events are collected, how long logs are kept and how alerts are reviewed. These support the incident detection and handling measures in Article 21 and the reporting staging in Article 23. Confirm that logs are retained long enough to reconstruct an incident, and that your team can meet the 24-hour early warning clock with the alerts you have. The authority will ask for the process, not only the tool.
Supplier security
CIS Safeguards on service provider management cover how you inventory third-party services, assess their security and monitor them over time. Article 21 requires supply chain security measures, including the security relationships with direct suppliers and service providers. CIS does not give you contract clauses or supplier assurance evidence, so you still need to document due diligence, contractual security requirements and what you do when a supplier is breached.
The NIS2 duties no control set covers
Adopting the CIS Controls, even all 153 Safeguards across IG1 to IG3, does not discharge the NIS2 duties that sit outside the technical risk-management measures in Article 21. The first is registration. Essential and important entities must be known to their national competent authority, and Articles 3 and 27 set out who must register and what they must provide. A Safeguard inventory cannot stand in for that filing, so confirm with your national authority which entity category you fall into and which registration portal and deadline apply to you. The CIS Controls also state that they do not replace any regulatory, compliance or authorization scheme, so treat them as the engineering layer beneath these legal obligations rather than as the obligations themselves.
The second group is process and accountability. Article 23 requires staged incident reporting: an early warning, an incident notification and a final report, due within 24 hours, 72 hours and one month. Each stage needs named recipients, a decision owner and a template your on-call team can actually use, which no Safeguard produces by itself. Article 20 places training and liability on the management body, so the board must approve the risk-management measures and complete training. Plan for minutes, training records and a signed owner for each risk decision, and ask your legal counsel how your national transposition law assigns that personal exposure.
The third group is supervision. Essential entities face ex ante supervision and important entities face ex post supervision under Articles 32 and 33, and Articles 32 to 34 give authorities power to run inspections, security audits, security scans and information requests, and to impose administrative fines. NIS2 creates no certificate, so a CIS Controls assessment, however thorough, produces internal evidence rather than an authority-issued result. Build an evidence index that maps each Safeguard to the artifact an inspector would ask for, and confirm with your regulator which evidence formats and fine levels its transposition law applies.
Using CIS IG1, IG2 and IG3 as the implementation layer
IG1 is CIS's definition of essential cyber hygiene and a minimum standard for every enterprise. It contains 56 of the 153 Safeguards in CIS Controls v8 and v8.1. For a smaller essential or important entity, IG1 is usually the first layer to make concrete, because it turns Article 21 risk-management measures into a bounded set of tasks that a small team can own and evidence. It does not cover the full NIS2 scope on its own.
- Asset and account basics: Inventory of devices, software and accounts, with named owners for each system in scope of the entity's services.
- Access hygiene: Administrative privileges limited to people who need them, strong authentication for remote and privileged access, and removal of dormant accounts.
- Patch and configuration baseline: A repeatable process for applying updates and securing standard configurations on endpoints and servers.
- Backups and recovery: Protected backups tested by restoring them, since this supports the Recover function that NIS2 incident handling depends on.
- Incident and contact records: Current contact lists and a simple response plan that supports the staged reporting clock in Article 23.
Confirm with your national competent authority and your own risk assessment whether IG1 alone is a credible baseline for your sector and the services you provide.
IG2 adds 74 Safeguards on top of IG1, for a total of 130. CIS describes it as the layer for enterprises with more operational complexity that often hold sensitive information. An entity with multiple sites, several business units, outsourced IT or customer data in more than one system typically needs IG2 to cover the wider attack surface that IG1 does not address. The added Safeguards are where logging, network segmentation, data protection and supplier oversight become concrete.
- Centralized logging and alerting: Audit logs collected from critical systems and reviewed, which supports detection and the evidence an authority may request.
- Network and service segmentation: Separation of administrative, production and third-party access paths.
- Data protection: Classification and encryption for sensitive data stores, aligned with the entity's own data inventory.
- Supplier and service provider management: Inventory and review of third parties that touch systems in scope, relevant to supply chain duties under Article 21.
- Security awareness for staff: Role-based training that reaches people who handle sensitive information.
Illustrative example: an entity running a hosted customer portal and an internal ERP may find that its IG1 inventory is complete but its logs do not reach the portal's identity provider. That gap is the kind of item IG2 addresses. Confirm the scope with your authority and assessor before treating IG2 as sufficient.
IG3 adds the remaining 23 Safeguards, covering all 153 in v8.1. CIS targets it at enterprises with security specialists and regulated, sensitive assets facing sophisticated, targeted attacks. For an in-scope entity, IG3 is usually relevant when it runs its own security operations, handles regulated data or depends on systems whose compromise would affect many users. Full adoption demands dedicated staff, and the decision should follow a documented risk assessment rather than a sector label.
- Advanced detection and response: Safeguards that extend monitoring and incident handling beyond baseline logging.
- Security architecture review: Ongoing review of application and network architecture against the entity's threat model.
- Specialized testing: Regular testing of defenses, which complements the testing approaches your entity chooses separately.
- Governance duties: Mapping of Safeguards to the Govern function, which CIS reports covers 25 of the 153 Safeguards in v8.1.
- Verification records: Evidence built against the CIS Controls Assessment Specification, which defines what to measure for each Safeguard.
Confirm with your authority whether they expect IG3 for your entity type and whether your own risk assessment justifies the staffing it requires.
Who assesses each and what proof it produces
This table compares who checks compliance under NIS2 and under the CIS Controls, and what evidence each produces. Read it to separate regulator supervision from an optional accreditation for service providers, since neither gives an organization a certificate for its own environment.
| Question | NIS2 (Directive 2022/2555) | CIS Controls v8.1 |
|---|---|---|
| Certificate or attestation issued to the organization | No certificate of compliance is created by NIS2. | No CIS certification scheme for organizations appears in the supplied facts. Confirm with CIS before claiming any CIS-issued status. |
| Who checks compliance | National competent authorities, through inspections, security audits, security scans and information requests (Articles 32 to 34). | The organization, using the CIS Controls Assessment Specification as a measurement guide. External checks are your own choice. |
| Supervision model | Essential entities face ex ante supervision. Important entities face ex post supervision (Articles 32 and 33). | Not applicable. The Controls do not replace any regulatory, compliance or authorization scheme. |
| Enforcement tools | Administrative fines and orders set through national transposition law (Article 34). | None from CIS. Enforcement is a matter for the regulator that applies to your sector. |
| Accreditation for providers | Not applicable to NIS2 itself. | CIS Controls Accreditation, run with CREST, covers SecureSuite member organizations that deliver implementation, auditing or assessment services. Application fees are $1,500 for CREST members and $2,500 for non-members. |
| Who pays for assessment | The entity bears the cost of supervisory audits and any remediation. Confirm fee and recovery rules with your national authority. | The entity pays its own staff or an external firm. Accreditation fees apply only to the provider seeking accreditation. |
| Assessment cycle | Set by each national authority under its transposition law. Confirm the frequency and triggers with your competent authority. | Set by your own governance or contract. CIS does not set an external audit cadence in the supplied facts. |
Doing both: order of work and shared evidence
This sequence lets one team meet NIS2 obligations and use CIS Controls as the practical control layer, so each measure is built once, verified once and reported against both sets of duties.
Confirm scope and entity category
Start by establishing whether the organization is in scope of NIS2 at all, which sector annex applies, and whether it is classified as an essential or important entity under Article 3. Legal or compliance leads should own this, with the management body approving the outcome. The step is done when the scope statement names the entities, services and national transposition law in force, and the category decision is written down. Classification drives how supervision works (ex ante for essential entities, ex post for important entities), so it must be settled before any control work is sized.
Run a gap view against Article 21 and 23
Map the current security program against the Article 21 risk-management measures and the Article 23 reporting duties, listing each measure, its current owner and the evidence that exists today. Security and compliance leads run this with input from IT operations and legal. The output is a gap register that separates control gaps from legal duties that no control set covers, such as registration, incident reporting timelines and management body duties. The step closes when every Article 21 and Article 23 item has a status and an owner.
Adopt CIS IG1 as the baseline
Use CIS Implementation Group 1, which CIS describes as essential cyber hygiene and a minimum standard for every enterprise, as the first implementation layer. IG1 contains 56 Safeguards, so the baseline is bounded and can be scheduled. Security engineering leads own the work, mapping each IG1 Safeguard to the gaps found in the previous step. The step is complete when each IG1 Safeguard is marked implemented, not applicable with a reason, or assigned to a remediation item with an owner.
Define verification with CAS measures
For each Safeguard in the baseline, take the measures and metrics in the CIS Controls Assessment Specification to define how implementation will be verified. The CAS states what to measure but not how, so the team must write its own test procedure, evidence source and frequency for each measure. Control owners and internal audit should agree the method before evidence is collected. The step is done when every IG1 Safeguard has a written verification method that an independent reviewer can repeat.
Add IG2 and IG3 as risk requires
Extend the program to IG2 and IG3 only where the documented risk assessment justifies it, for example where the entity holds sensitive information or faces targeted threats. IG2 adds 74 Safeguards and IG3 adds the remaining 23. Risk owners and the security function make this decision, and the rationale must be recorded so it can be defended to a supervisor. The step closes when each added Safeguard is linked to a named risk and to its verification method.
Build governance and reporting evidence
Add the NIS2 duties that no control set covers: management body approval and training records, the incident reporting procedure with its staged notifications, registration evidence and supplier oversight. Compliance leads own these records, and the management body signs off the governance pack. The step is done when each of these duties has a documented procedure, an owner and a sample of the record that would be shown during an inspection or information request.
Reuse one evidence set for both
Store each verification result once, tagged with the CIS Safeguard it supports and the NIS2 Article 21 or 23 duty it covers, so one test run answers both sets of questions. Evidence owners maintain the register and review it on the schedule set in the verification methods. Be clear that a shared mapping shows where the topics overlap, not that the entity complies with NIS2, because the mapping does not establish equivalence. The step is complete when a sample request for any Article 21 measure can be answered from the register within the team's own process.
Use CIS Controls internally under the license
Confirm with legal that internal use fits the license: CIS states that the Controls are free for any organization to use to improve its own cybersecurity, while the content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 and commercial use needs CIS's prior approval. Legal or procurement owns this check, and any consultant or product that resells CIS-derived content should be reviewed separately. The step is done when the license position is recorded and any commercial use question has a written answer.
Questions buyers ask before hiring help for NIS2 and CIS Controls
Do CIS Controls make an entity NIS2 compliant?
No. Using the CIS Controls does not make an entity NIS2 compliant, and the published mapping does not change that. CIS maintains a mapping to NIS2 in its Navigator, but mapping is not equivalence: CIS states that its Controls do not replace any regulatory, compliance or authorization scheme. ENISA makes the same point about its own mapping, saying it does not assess whether a standard fully covers the regulation's requirements. The Controls cover much of the technical content behind Article 21, but registration, the 24-hour, 72-hour and one-month incident reports under Article 23, and management body duties sit outside any control set. Ask your national competent authority or legal adviser how they expect those duties to be evidenced.
What drives the effort of a CIS Controls and NIS2 project?
Four factors drive most of the effort. The first is entity size and the number of systems in scope. The second is the Implementation Group you target: IG1 has 56 Safeguards, IG2 adds 74 for a total of 130, and IG3 adds the remaining 23, covering all 153. The third is how complete your existing asset inventory is across devices, software, data, users, network and documentation, because most Safeguards depend on knowing what you run. The fourth is your supplier chain, since Article 21 risk management reaches supplier security. Each factor moves the work up or down, so ask any provider to show how they assessed each one before quoting.
What does the work need from our team?
Expect to supply named owners, asset data, access to systems and management time. Named owners are needed for each Safeguard area, because a control without an accountable person rarely survives an audit. Asset data, such as device lists, software inventories, identity sources and network diagrams, is usually the longest input to gather. Access to systems is needed to check configurations and collect evidence. Management time matters because NIS2 places accountability on the management body under Article 20, and governance decisions on risk acceptance cannot be delegated away. Confirm these inputs and their owners in the written scope so delays are visible early.
Can we implement the CIS Controls in-house?
Yes. CIS states that the Controls are free for any organization to use to improve its own cybersecurity, and its license is Creative Commons Attribution-NonCommercial-NoDerivatives 4.0. Internal use does not need CIS's prior approval, but commercial use does, so check the license terms if you plan to sell services built on the Controls. Running the program in-house means your team pays for staff time, tooling and any external testing, and those costs recur as systems change. Outside help is useful when your team lacks capacity, needs an independent view of evidence, or wants a fixed-scope plan with defined deliverables.
Is there a NIS2 certificate we can obtain for the CIS Controls?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. Any firm offering a NIS2 certificate for implementing the CIS Controls is offering something the Directive does not provide, and that claim should be treated with caution. Ask what the authority in your Member State accepts as evidence and how the work will be documented so it can be shown during supervision. Assessments of CIS Controls implementation can be made by qualified assessors, but they do not create a regulator-issued NIS2 certificate.
How do the CIS Controls Assessment Specification metrics help?
The CIS Controls Assessment Specification defines, for each Safeguard, the inputs, operations, measures and metrics used to verify that it is implemented. CIS says it covers what to measure, not how, so your team still designs the test method and tooling. For a NIS2 program, this gives you a consistent way to show an auditor or authority what was checked, when, and with what result. Ask any provider how they will map each Safeguard to a CAS measure, what evidence they will retain, and how gaps will be recorded and tracked to closure. The CAS also has terms of use that should be reviewed before reusing its content in client deliverables.
What should a written fixed-scope quote for this work include?
A written fixed-scope quote should state the entity and systems in scope, the targeted Implementation Group, the Safeguards and NIS2 duties covered, and the ones explicitly excluded such as registration or incident reporting. It should list each deliverable, such as an asset inventory, gap register, configuration evidence and a remediation plan, with acceptance criteria. Ask for the assumptions behind effort, the client inputs and owners, the timeline and its dependencies, and what happens if scope changes. Also confirm who is responsible for ongoing evidence after handover, and whether support or testing is a separate retainer. DeployOpen agrees scope, deliverables and timelines in writing before work starts and quotes from that written scope.
How DeployOpen prepares evidence for both frameworks
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it prepares systems, controls and evidence for assessments. It does not issue audit reports, attestations or certificates, and it is not an official partner of NIS2 authorities or CIS. For an NIS2 entity, the practical point is that the evidence you hand to a national competent authority must come from your own management system, while DeployOpen's role is to make the technical controls behind that evidence exist, work and be documented in a form your assessor can test.
Scoping comes first and is written down before work starts. The fixed scope typically separates three things: the NIS2 duties that a control set cannot cover, such as registration, the staged incident reporting at 24 hours, 72 hours and one month under Article 23, and management body training under Article 20; the technical Safeguards that map to the NIST CSF 2.0 functions you need to evidence; and the CIS Implementation Group that sets the depth of each Safeguard. Ask DeployOpen to state which IG level applies to each asset class (Devices, Software, Data, Users, Network or Documentation) and which Safeguards are in or out of the agreed scope. Illustrative example: a regional operator may scope IG2 for its corporate estate and IG3 only for a segment handling sensitive operational data, and the written scope should say so.
Ask for the deliverables in the same written scope so you can check them later. Typical items include a documented mapping from each in-scope Safeguard to the evidence it produces, configuration baselines for the self-hosted platforms, backup and upgrade procedures, and test records. The CIS Controls Assessment Specification defines measures and metrics for each Safeguard, so confirm whether the evidence plan follows it. Costs are driven by how many platforms, Safeguards and IG levels are in scope and how much documentation you need, and they are quoted only from that written scope. Retainers for ongoing support, upgrades and continuous testing are available, and you should decide early which parts recur after the initial engagement.
How DeployOpen scopes, delivers and supports NIS2 and CIS readiness
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For NIS2 vs CIS Controls, we turn a chosen Safeguard set and your Article 21 obligations into a written scope, built controls and handover evidence that your team can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Scope maps which CIS Safeguards in IG1 to IG3 your entity will implement, and which NIS2 duties sit outside them.
- Scoping lists the NIS2 duties a control set does not cover, such as registration, incident reporting and management body duties.
How we build
- We implement the agreed Safeguards in your own cloud accounts, data centers or air-gapped networks.
- Configuration is tested against the Safeguard measures and metrics you confirm, using the CIS Controls Assessment Specification as the reference.
- Security testing of applications, APIs and infrastructure can check that implemented controls behave as documented.
How we hand over
- Deliverables include documented control implementation, evidence records and the mapping you use with your regulator.
- Handover covers runbooks for the systems your staff will operate after the engagement ends.
- Documentation states clearly which NIS2 obligations remain with management, such as training, reporting and supervisory contact.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can keep evidence current as CIS Controls versions change or as national NIS2 transposition rules are updated.
- Ask us to confirm in writing which support, testing and upgrade items your retainer includes before you sign.
