How to sequence a CIS Controls implementation roadmap
If a customer, contract or regulator now points to the CIS Controls, the first move is to start with Implementation Group 1 (IG1). CIS recommends that every enterprise begin there. IG1 contains 56 Safeguards, IG2 adds 74 more for a total of 130, and IG3 adds the remaining 23 to cover all 153 Safeguards in v8.1. The sequence is fixed in that order, but the pace and the scope within each group depend on your environment. Your asset footprint, the sensitivity of the data you hold, and the threats you actually face determine which Safeguards need attention first and how far up the groups you need to go.
Before you schedule work, confirm three things: which business units and systems fall inside scope, which data classes are sensitive enough to raise the bar, and which attack paths your sector sees most often. CIS's Community Defense Model, updated as version 3.0 on September 21, 2026, identifies which Safeguards give the most defensive value against prevalent attacks, so it is a useful input when you decide what to prioritize after IG1. Also note that Controls 13, 16 and 18 contain no IG1 Safeguards, so network monitoring, application security and penetration testing only enter your roadmap at IG2 or IG3. Plan for that gap explicitly rather than discovering it during an assessment.
Responsibilities need to be clear from the start. Your organization owns its controls, its policies and the decisions about risk acceptance. An implementation partner can prepare systems, configurations and evidence collection, but it does not decide whether a Safeguard is met. Only an independent assessor or auditor can issue a report or attestation. Ask any partner for a written scope that lists the Safeguards in each group, the deliverables for each, and the evidence they will hand over. Plan for version updates as well: CIS released v8.1 as an iterative update, so review the change log and the Navigator mappings whenever a new version appears, and check your roadmap against the Safeguard numbering that applies to the version your contract references.
Using the Community Defense Model to order the work
The Community Defense Model v3.0, announced by CIS on Sept. 21, 2026, shows which Safeguards give the most defensive value against the most prevalent attacks. Use it to decide what to build first within your Implementation Group, and keep the Safeguard-level checks as the measure of whether each item is actually in place.
What the model is built on
CDM v3.0 is a data-driven model built on attack data, threat intelligence and MITRE ATT&CK mappings. It identifies which CIS Controls Safeguards give the most defensive value against the most prevalent attacks. Before you rely on its ranking, confirm which attack categories it studied and how those categories compare with the threats your sector actually faces, such as ransomware, credential abuse or supply chain compromise. Record that comparison in the roadmap so the sequence can be explained to auditors and boards.
Safeguard 4.1 ranks first
CDM v3.0 identifies Safeguard 4.1, establishing and maintaining a secure configuration process, as the most effective individual Safeguard across all five attack categories studied. That makes a documented, owned hardening process an early priority in most roadmaps. Ask who will own the process, which asset classes it covers and how exceptions are approved and reviewed. A written process is a starting point, not evidence that systems are configured as the process says.
Mapping attacks to attacker stages
The Active Defense Lifecycle aligns Safeguards to the stages of attacker behavior. Use it as a worksheet: list each stage, then mark which Safeguards you have implemented and which you have not. Gaps cluster in stages where no Safeguard is in place, while strengths show where existing tools already perform. Review the result with the people who run detection and response, because a stage marked as covered should be backed by a tested control, not a tool purchase.
Reconciling the model with IG1
CDM ranking does not change the IG1 starting set, which includes malware defenses, data recovery, network infrastructure, awareness training, service provider inventory and incident response Safeguards. Treat the model as a tie-breaker and a sequencing aid inside the Implementation Group you target. For example, if a team has a limited window, it might prioritize a Safeguard the model ranks highly over a lower-ranked one at the same group level. Document each sequencing decision and its reason.
Keeping the Safeguard checks in charge
CDM informs ordering. It does not replace the Safeguard checks in the CIS Controls Assessment Specification, which define the inputs, operations, measures and metrics used to verify each Safeguard. A high ranking does not mean a Safeguard is implemented. Before marking any item complete, run the checks for that Safeguard and retain the evidence they produce, such as configuration baselines, scan results or approved exception records.
Re-running the model on each version
CIS released v8.1 on June 25, 2024 as an iterative update, and CDM v3.0 is a separate model release. Plan a review point each time the model or the Controls version changes, and compare the new ranking with your current sequence. Confirm with CIS which tools and resources have been updated for the version you use, since supporting material followed the Controls release over the following year. Record which version each roadmap decision was based on.
Which Controls start at IG1, IG2 and IG3
This table lists the IG1 Safeguards within Controls 10 to 18 and shows where Controls 13, 16 and 18 enter the roadmap. Read each row as a starting point for a phase: the Safeguards in the IG1 column are the first work, and the IG2 and IG3 column names the phase where the remaining Controls begin. The full Safeguard list should be confirmed in the CIS Controls Navigator before you finalize a plan.
| Control | IG1 Safeguards to start with | Where the roadmap begins |
|---|---|---|
| Control 10: Malware defenses | 10.1 to 10.3 | Phase 1 at IG1 |
| Control 11: Data recovery | 11.1 to 11.4 | Phase 1 at IG1 |
| Control 12: Network infrastructure management | 12.1 | Phase 1 at IG1, remaining Safeguards in later phases |
| Control 13: Network monitoring and defense | None at IG1 | Enters at IG2 or IG3 |
| Control 14: Security awareness and skills training | 14.1 to 14.8 | Phase 1 at IG1 |
| Control 15: Service provider management | 15.1 | Phase 1 at IG1, remaining Safeguards in later phases |
| Control 16: Application software security | None at IG1 | Enters at IG2 or IG3 |
| Control 17: Incident response management | 17.1 to 17.3 | Phase 1 at IG1 |
| Control 18: Penetration testing | None at IG1 | Enters at IG2 or IG3 |
The phases of a CIS Controls roadmap and their outputs
The sequence moves from a verified asset baseline to IG1 remediation, then IG2 and selective IG3 work, and ends in recurring review. Each phase closes with a named artifact that the next phase depends on.
Set scope and build the asset baseline
Define which business units, networks, cloud accounts and data sets fall inside the program, then build the baseline from CIS Controls 1 and 2: the detailed enterprise asset inventory and the software inventory. The organization owns this work, with IT and security staff doing the discovery and reconciling it against cloud consoles, directories and network records. The phase is complete when the inventories are signed off by the control owners and the scope statement names every asset class in scope. The output is the inventory set and a written scope statement.
Run the IG1 gap assessment
Assess each IG1 Safeguard against the CIS Controls Assessment Specification, which defines the inputs, operations and measures used to verify implementation. Assessors record whether each Safeguard is implemented, partially implemented or missing, and capture the evidence they checked. Ask an internal reviewer or an independent party to challenge the findings, since self-scoring tends to overstate coverage. The phase closes when every IG1 Safeguard has a status and an evidence reference. The output is the gap register.
Remediate IG1 Safeguards and write the policies
Work the gap register by risk and effort, closing technical gaps such as patching, account hygiene, malware defenses and backups, and writing the documented processes the Safeguards require. CIS publishes free IG1 policy templates that teams can adapt, but the organization must approve and enforce its own policies. Track each closed gap to a configuration record, ticket or screenshot that a third party could re-check. The phase is complete when the register shows every IG1 gap closed or formally accepted by a named owner. The output is the IG1 evidence pack.
Expand to IG2 Safeguards
Once IG1 is stable, add the IG2 Safeguards that match the organization's operational complexity and sensitive data. The IG2 set brings in controls such as network monitoring, application software security and penetration testing, which have no IG1 Safeguards, so teams should confirm early whether they have the tools and staff to run them. Repeat the assessment and remediation loop for the new Safeguards. The phase is complete when the gap register covers IG2 with an owner and evidence for each item. The output is an updated gap register and a revised roadmap.
Decide whether IG3 applies
Work through IG3 only where the enterprise has security specialists and holds regulated or sensitive assets that face sophisticated, targeted attacks. Document the reasoning for including or excluding IG3, including any contractual or regulatory driver, so the decision can be defended to an assessor or customer. Where IG3 applies, scope it to the systems that need it rather than the whole estate. The output is a recorded IG3 decision and, if chosen, a scoped IG3 backlog.
Plan the recurring review cycle
Set a review cadence for the inventories, the assessment and the policies, and map any new framework version or Safeguard change into the register. Check the Community Defense Model and CIS release notes when deciding which safeguards to prioritize for the next cycle, and confirm with the vendor or CIS any updates to supporting tools. Ask whether an independent party will test the program periodically if customers or regulators require it. The phase is complete when the review calendar and owners are documented. The output is a maintained roadmap that records each review decision.
Planning for CIS Controls version updates
CIS published version 8.1 on 24 June 2024 as an iterative update to version 8, deliberately designed to minimize disruption for organizations already running a program. Supporting tools and resources were updated over the following year, so a roadmap built on v8 should not assume every template, workbook or assessment aid is still the same. The most consequential v8.1 change for planning is the realignment of security function mappings to NIST CSF 2.0 and the new Govern function, which 25 of the 153 Safeguards carry. Teams that already report against CSF functions should expect those mappings to shift, and governance Safeguards may need owners who did not previously appear in the program.
Build a change log review into the roadmap as a recurring task with a named owner, not a one-time reading. The v8.1 download includes a change log, so the first review should compare it against the Safeguards you have already documented. Record which Safeguard descriptions, asset classes or glossary definitions changed, then check whether your policies, asset inventories and configuration baselines still use the terms the standard now defines, such as what counts as a plan, a process or sensitive data. Map each Safeguard to the evidence you own, for example a named inventory export, a patch report or a signed access review, and store that mapping in a register with a version field. When a Safeguard changes, the register shows exactly which evidence needs to be refreshed and which assessment measures are affected.
Before each review cycle, confirm on cisecurity.org which version is current, because CIS publishes updates on its own schedule and tools can lag behind the standard. Ask whoever runs the assessment to state the version they tested against in the report or working papers, so a later reader can tell which Safeguard wording applied on that date. If a new version appears mid-cycle, decide in writing whether to finish the current assessment against the older version or to re-baseline now. That decision belongs to the organization, and an implementation partner or assessor can prepare the mapping, but it should be recorded by the people who own the controls.
What usually derails a CIS Controls roadmap
Most CIS Controls programs stall for predictable reasons: the foundation is skipped, the work is treated as a project with an end date, or the documents drift away from practice. Each card below names one pitfall, why it matters for the roadmap, and what to check before committing budget and staff time.
Skipping the asset inventory
Safeguards for devices, software and data assume you know what exists. Without a detailed asset inventory, hardening, patching and log collection cover only the systems someone remembered to list. Before sequencing any other work, confirm that the inventory includes unmanaged devices, cloud workloads and software, and that someone owns reconciling it against network discovery on a fixed schedule.
Treating the Controls as a one-time project
The Controls describe continuing operations such as monitoring, patching, access reviews and training. A program that is funded to reach a target score and then disbanded will decay within a few review cycles. Ask who owns each Safeguard after the initial rollout, what recurring tasks they perform, and how those tasks appear in budgets and staffing plans.
Writing policies no process follows
Many organizations produce a full set of policies and then discover that teams work from other habits. The assessment specification checks whether a documented process exists and is performed, so a policy with no operating procedure, owner or records will fail review. For each policy, identify the procedure, the system that enforces it and the artifact that proves it ran, such as a ticket, a scan report or a signed access review.
Starting with IG3 as the target
IG3 is written for enterprises with security specialists and regulated, sensitive assets facing sophisticated attacks. Teams that adopt it first often spend months on advanced Safeguards while basic hygiene remains uneven. CIS recommends that every enterprise start with IG1 and build upward. Before selecting a group, ask whether the foundational Safeguards are already performed consistently across the environment.
Missing the assessment specification measures
The Assessment Specification defines inputs, operations, measures and metrics for each Safeguard, but it does not tell you how to collect them. Teams that read only the Safeguard text often produce evidence that does not match the measure, such as a configuration screenshot where a measured rate was expected. Map each Safeguard you target to its measures in the specification, then design the logs, reports and reviews that produce those values before the assessment begins.
Ignoring version and tool updates
CIS released v8.1 as an iterative update to v8, with supporting tools and resources updated over the following year. Roadmaps built on earlier Safeguard numbering or mappings can drift from the current text, and tool outputs may change. Assign an owner to track the change log and Navigator, and schedule a review of your Safeguard mapping whenever CIS publishes a new version or a new prioritization resource.
Who owns each part of the roadmap
The organization owns its CIS Controls program in full. It chooses the Implementation Group it targets, decides which Safeguards apply to its assets and data, approves the written policies and processes that the Controls call for, and formally accepts any residual risk where a Safeguard is not yet in place. Control operation also stays with the organization: someone on staff must review alerts, approve access, run backups, and keep inventories current long after a partner has left the engagement.
- Target selection: Decide the IG target in writing, starting from the essential cyber hygiene baseline of IG1 unless a documented reason points elsewhere.
- Policy approval: Approve the policies, standards and procedures that the Safeguards require, and keep them under version control.
- Risk acceptance: Record who accepts each Safeguard gap, the reason, and the review date.
- Ongoing operation: Assign named owners for recurring activities such as access reviews, patching, log review and restore tests.
- Self-assessment: Measure progress against the Assessment Specification and the CIS-hosted self-assessment tools, then correct the gaps the results expose.
Before signing, confirm that the internal owners, budget and decision rights are named, because a partner cannot approve risk or run controls on the organization's behalf.
An implementation partner prepares the systems, configuration and evidence that the organization's controls depend on. Under a fixed written scope, the partner might deploy open-source tooling for inventory, logging or vulnerability scanning, harden configurations, collect evidence, and document how each Safeguard is met. The partner works for the organization and does not make the organization's decisions, approve its risk or certify its conformance.
- Systems preparation: Deploy and configure tools in the organization's own environment, such as inventory, logging, backup or scanning platforms.
- Configuration work: Apply hardening baselines and document the settings that Safeguards rely on.
- Evidence collection: Gather configuration exports, logs, tickets and reports that show each Safeguard operating over time.
- Documentation: Draft process and procedure documents for the organization to review, edit and approve.
- Handover: Train staff and transfer runbooks so the organization can operate the controls without the partner.
Check that the scope lists specific Safeguards, deliverables, acceptance criteria and the handover plan. Fixed-scope work of this kind is agreed in writing before it starts, so ambiguous scope is a warning sign.
An independent assessor tests whether the controls work and reports the result. The assessor is not part of the implementation team, and only an independent auditor, assessor or certification body issues a report or attestation. CIS does not certify organizations against the CIS Controls, so no CIS certificate exists. Assessor work is often framed around the CIS Assessment Specification, which defines what to measure for each Safeguard, or around a second framework the organization must meet, such as a customer contract or a regulator's expectations.
- Independence: Choose an assessor that did not design or build the controls under review, to keep the test credible.
- Testing method: Expect sampling, interviews, configuration review and observation of recurring activities.
- Reporting: The assessor issues the report in its own name, stating what was tested and what was found.
- Scope agreement: Confirm in writing which Safeguards, assets and time period the assessment covers.
- Limitations: Ask how the assessor will treat controls that were only recently started and therefore have short evidence histories.
Before engaging an assessor, confirm its qualifications, its reporting format and whether a customer or regulator accepts that format.
Questions buyers ask about the CIS Controls roadmap
Is IG1 enough when a customer asks for CIS Controls alignment?
IG1 is the starting point, not always the finish line. CIS describes IG1 as essential cyber hygiene and a minimum standard for every enterprise, so it is the right first target for most organizations. Whether it satisfies a specific customer request depends on what the contract or questionnaire asks for. Ask the customer which Implementation Group they expect, whether they want a named set of Safeguards, and how they will verify it. If the request names IG2 or IG3, or refers to Controls 13, 16 or 18, the roadmap must extend beyond IG1 because those Controls have no IG1 Safeguards.
How does the CIS Controls roadmap relate to a CIS self-assessment?
The roadmap sets the order of work, and a self-assessment records where each Safeguard stands. CIS publishes an Assessment Specification that defines the inputs, operations, measures and metrics used to verify each Safeguard, but it describes what to measure, not how. Use the specification to define the evidence for each Safeguard in your roadmap, then assess against it on a fixed cadence. A self-assessment is an internal or customer-facing statement, not a certification, because CIS states the Controls do not replace any regulatory or compliance scheme.
Can our team run the CIS Controls roadmap in-house?
Many organizations can, especially at IG1, because the Safeguards are documented and CIS provides free resources. The work still needs clear ownership. Your own staff owns the controls and decides risk, while the people who build and operate systems carry most of the configuration, logging, backup and access work. Decide early whether internal staff have the time and skills for each Control. If they do not, an implementation partner can prepare systems and evidence under a written, fixed scope, but only an independent assessor or certification body issues reports or certificates.
What does the roadmap need from internal staff?
It needs named owners, protected time and access to the systems in scope. Most early IG1 work sits with IT operations, identity administrators, security staff, backup owners and whoever manages user awareness. Later IG2 and IG3 work usually adds application developers, network engineers and penetration testing coordinators. Plan the roadmap around these roles:
- An accountable owner for each Control
- Operators who can change configurations and collect logs
- Reviewers who approve written processes and exceptions
- A business contact who can accept or reject risk decisions
Ask any consultant to name which of these roles they expect your staff to fill.
How should we sequence Controls that only start at IG2 or IG3?
Start with the IG1 Safeguards across Controls 1 to 18, then add the IG2 and IG3 Safeguards in order of your risk. CIS notes that Controls 13, 16 and 18 have no IG1 Safeguards, so they enter the roadmap at IG2 or IG3. Network monitoring, application security and penetration testing depend on earlier work such as the asset inventory, software inventory, secure configuration and logging, so do not schedule them first. Confirm the exact Safeguard list for each group in the Navigator before you commit dates.
How do we handle a new CIS Controls version in the roadmap?
Map each Safeguard in your program to the version you are using, then review changes when a new version or update is released. CIS released v8.1 on June 25, 2024 as an iterative update to v8 intended to minimize disruption, and its changes included new glossary terms, revised asset classes, clarified Safeguard descriptions and a new Govern function aligned to NIST CSF 2.0. Keep a change log in your program, reassess Safeguards whose wording changed, and update supporting tools as CIS revises them. Check with any customer or state law that refers to a version before you switch.
How should the Community Defense Model affect our priorities?
Use it to choose which Safeguards to fund first once IG1 is in place. CIS announced the Community Defense Model v3.0 on September 21, 2026. It is built on attack data, threat intelligence and MITRE ATT&CK mappings, and it identifies the Safeguards that give the most defensive value against the most prevalent attacks. CIS identifies Safeguard 4.1, establishing and maintaining a secure configuration process, as the most effective individual Safeguard across the five attack categories it studied. Treat the model as a prioritization input, not a substitute for your own risk assessment.
When to bring in outside help for the roadmap
An internal team can run the early stages of a CIS Controls roadmap if it has someone who owns the program, time to work through the IG1 Safeguards, and people who can run the technical changes. The IG1 starting set is small enough for many enterprises to manage in-house, and CIS's own prioritization resources, including the Community Defense Model v3.0 announced on Sept. 21, 2026, help a team decide what to do first. Outside help becomes worth considering when the gaps sit in areas the team has not run before, such as secure configuration baselines across many asset types, log pipelines, or Controls 13, 16 and 18, which have no IG1 Safeguards and enter the roadmap only at IG2 or IG3. Confirm internally whether you have the skills for those areas before you decide.
Partners usually add value in four places: scoping (deciding which assets, business units and Safeguards are in the program and which are not), technical hardening and integration work, evidence preparation so that each Safeguard's measures in the CIS Controls Assessment Specification can be shown, and training for staff who will own the program after the engagement ends. Your organization keeps ownership of its controls throughout. A partner prepares systems and evidence, and only the organization itself decides its risk posture. CIS Controls Accreditation applies to service providers that deliver CIS Controls services, not to customers planning a roadmap, so you should not require a partner to hold it for an internal program.
When you request a quote, ask for written scope, named deliverables and agreed timelines before any work starts. The scope should list the Implementation Group and Safeguards covered, the systems and business units in scope, the evidence each Safeguard will produce, who on your side reviews and approves each deliverable, and what happens when a version update such as v8.1 changes a Safeguard. Ask which costs are one-time (initial scoping, hardening, documentation) and which recur (monitoring, retainers, reassessment). Confirm in writing who pays for any third-party tools, and whether the partner's work product can be used by your own staff after handover.
How DeployOpen builds the roadmap and the evidence behind it
DeployOpen helps organizations sequence their CIS Controls v8.1 program in their own infrastructure, starting with the Safeguards in Implementation Group 1 and moving to IG2 or IG3 only when the written scope calls for it. Each phase produces the systems, configurations and records that an assessor or internal reviewer can check against the Assessment Specification.
How we scope
- Confirm which Implementation Group the organization is targeting and document the reasoning in the written scope.
- Map the in-scope environments, such as cloud accounts, data centers and air-gapped networks, before any work begins.
- Agree deliverables, timelines and responsibilities in writing, since most engagements are fixed-scope.
How we build
- Implement self-hosted open-source platforms for the Safeguards in the agreed sequence, starting with the IG1 set.
- Configure logging, inventory and access tooling so that each Safeguard produces evidence that can be retrieved later.
- Test controls against the Safeguard measures and record gaps in a remediation list the organization owns.
How we hand over
- Document configurations, runbooks and the roadmap so internal teams can operate and explain each control.
- Provide an evidence index that maps each delivered Safeguard to the artifacts an independent assessor would request.
- Confirm with the organization which controls remain its own responsibility and which an auditor must examine.
How we support
- Plan version updates, including the CIS Controls v8.1 change log, as a scheduled task within the roadmap.
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial delivery.
- Reassess priorities when CIS updates its prioritization resources, such as the Community Defense Model, and record the changes.
