CIS Controls v8 and v8.1 changes from v7 explained

What changed from CIS Controls version 7 to v8 and v8.1

If a customer, contract or regulator now points at CIS Controls v8.1 and your program was built on version 7, the core change is structural: v8 reduced the top-level Controls from 20 to 18, renamed the Sub-Controls as Safeguards and grouped them by activity rather than by how things are managed. v8.1, published on 24 June 2024 and released on 25 June 2024 according to CIS's press release, is an iterative update that realigned security function mappings to NIST CSF 2.0 and added the Govern function. The current version contains 153 Safeguards across 18 Controls.

The practical impact depends on how your organization mapped its v7 Sub-Controls to v8 Safeguards and what evidence it holds for each one. Some v7 Sub-Controls split, merged or moved under a different Control, and some v8 Safeguards, such as those tied to cloud services, mobile devices and service provider management, have no direct v7 equivalent. Confirm whether your existing evidence was indexed by Safeguard number or by the old Sub-Control number, and check that each Safeguard you claim has a current, dated artifact. Ask CIS's Navigator for v8.1 which v7 items map to which v8.1 Safeguards before you rebuild your register.

The organization owns its controls and decides how to meet each Safeguard. An implementation partner can help prepare systems, configurations and evidence, but an independent assessor reviews the result and issues any opinion on it. CIS states that the Controls do not replace any regulatory or compliance scheme, so the v8.1 mapping should be checked against the specific obligation your customer or regulator cites. Plan the rework as a one-time gap analysis followed by recurring evidence upkeep as the Safeguards are reviewed.

How v8 restructured the Controls and Safeguards

CIS Controls v8 kept the core idea of prioritized safeguards but changed the structure most v7 mappings depend on. The cards below cover the reduced Control count, the renamed Safeguards, the activity-based grouping and the consolidated v7 areas, with what each change means for an existing mapping.

Twenty Controls became eighteen

CIS reduced the top-level Controls from 20 in version 7 to 18 in version 8, and the version 8.1 update kept that structure. Some v7 Controls were merged, moved or dropped, so a v7 control number no longer points to the same subject area. Before you reuse an old v7 spreadsheet, confirm which v8.1 Control now covers each v7 requirement against CIS's own documentation, rather than assuming a one-to-one match.

Sub-Controls renamed as Safeguards

The v7 Sub-Controls became Safeguards in version 8, and version 8.1 has 153 of them. Each Safeguard carries its own Implementation Group assignment, so a Safeguard can be prioritized without the rest of its Control. Teams that tracked progress at the Sub-Control level should rebuild their tracker at the Safeguard level and confirm which Safeguards replaced each old Sub-Control, since some were reworded or split.

Activity-based organization of Controls

In version 8, CIS grouped the Controls by the activity they support rather than by how the work is managed. Asset inventory, data, configuration and monitoring work now sits under activity-oriented headings, which changes who owns each Control in a RACI chart. Review ownership assignments after the move, because a Control that used to belong to one team may now span several.

Email, web and malware areas consolidated

Version 7 tracked email and web browser protections, malware defenses and related boundary controls as separate areas, while version 8 folds the same concerns into the Controls for email and web protections and malware defenses with updated Safeguard wording. Some v7 requirements that sat in one place now appear across several Safeguards. Compare each v7 control's evidence against the v8.1 Safeguard list to confirm that nothing dropped out during the consolidation.

Cloud, mobile and service provider coverage

Version 8 added explicit coverage for cloud and mobile technologies, supported by companion guides, and introduced a Service Provider Management Control for cloud services. Version 7 handled much of this implicitly or not at all. Ask which Safeguards now cover your cloud accounts, mobile devices and third-party providers, because the answers determine which evidence your assessor will request.

Govern function added in version 8.1

Version 8.1 realigned its NIST CSF mappings to CSF 2.0 and added the Govern security function. In the v8.1 dataset, 25 of the 153 Safeguards carry the Govern function, covering governance activities that version 7 did not label this way. If your v7 mapping was built on the older five-function view, update it to include Govern and check which Safeguards now map to it.

What v8.1 added: Govern, CSF 2.0 alignment and clarified Safeguards

CIS released v8.1 on June 25, 2024 as an iterative update to v8, and its stated aim was to minimize disruption for organizations already working from v8. The structure stays at 18 Controls and 153 Safeguards. What changed is the metadata and wording around the Safeguards, so an existing program is mostly re-labeled and clarified rather than rebuilt. The most visible addition is the new Govern security function, which aligns with the Govern function added to NIST CSF 2.0. CIS realigned its security function mappings to CSF 2.0, so a Safeguard that once mapped to an older CSF category may now sit under a different function. Teams that report against CSF should refresh their mapping tables rather than assume the old ones still hold.

Under v8.1, each Safeguard carries exactly one asset class (Devices, Software, Data, Users, Network or Documentation), exactly one security function (Govern, Identify, Protect, Detect, Respond or Recover) and its Implementation Groups. CIS states that 25 of the 153 Safeguards carry the Govern function. Those 25 are the ones most likely to need new documents, such as a documented governance process or a named owner for cybersecurity risk, so check them first. Also review the revised asset classes and clarified Safeguard descriptions, which can change what an assessor expects to see as evidence. Expanded glossary definitions for terms such as plan, process and sensitive data are worth reading closely, because these words now set the bar for what counts as a documented process.

Supporting tools and resources were to be updated over the year following the v8.1 release, so confirm the current version of each tool you use, including any assessment workbook, policy template or self-assessment platform, before you rely on it. Ask your tool vendors or your implementation partner which v8.1 Safeguard identifiers and function labels their outputs use. Minor typo fixes are included in the update, but they do not change obligations. If your evidence register or policy set cites v8 Safeguard wording, map each item to its v8.1 text and record the date of that review.

What the change means for each team

The executive owner decides whether the program adopts v8.1 and who is accountable for the Govern Safeguards. The v8.1 change that matters most at this level is the new Govern security function, which CIS aligned with the NIST Cybersecurity Framework 2.0. Govern work is about direction, not technology, so it lands on leadership's desk even when the day-to-day work sits elsewhere.

Accountability for Govern: Confirm a named owner for the Safeguards that carry the Govern function, since the v8.1 assessment specification assigns each Safeguard one security function.
Scope of the 25 Govern Safeguards: Ask for a list of which Safeguards are Govern items and which Implementation Group each one belongs to.
Decision records: Confirm that approvals for the program, risk acceptances and exceptions are written down and reviewed on a set cycle.
Budget ownership: Ask who funds the tooling, staffing and any outside support, and whether that funding is planned for the next version update.
Partner or assessor questions: Ask the assessor how they will test Govern records and who on your side must sign off on them.

Before approving the move to v8.1, confirm that a named executive has reviewed the Govern Safeguard list and accepted the governance records as the organization's own.

How to move an existing v7 program to v8.1

This sequence moves a CIS Controls v7 program to v8.1 by reusing the evidence you already hold and mapping it to Safeguards, asset classes and security functions. Each step produces a record that your assessor or implementation partner can review before the program is restated against v8.1.

Inventory existing v7 evidence
Your security team, working with the control owners, lists every policy, procedure, scan report, log extract, ticket and configuration record the program uses today, and tags each item to the v7 control it supported. Keep the list in one register with an owner, a storage location and a date last reviewed for each item. The step is complete when every v7 control with a working practice has at least one named artifact and an owner, and the controls without artifacts are listed separately as gaps.
Map v7 controls to v8.1 Safeguards
Version 8 replaced the v7 Sub-Controls with Safeguards and regrouped the Controls by activity, so a v7 control rarely maps one to one. Use the v8.1 Safeguard list to assign each artifact to one or more Safeguards, and record the asset class (Devices, Software, Data, Users, Network or Documentation) and the security function each Safeguard carries. The output is a mapping workbook. The check is that every artifact maps to at least one Safeguard and that each mapping names the v8.1 Safeguard identifier.
Identify Safeguards with no evidence
The Govern function is new in v8.1, and 25 of the 153 Safeguards carry it. Many v7 programs have no direct equivalent for governance tasks such as defining roles, setting risk strategy and overseeing suppliers, so expect gaps here. Mark every Safeguard without mapped evidence, and review the Govern Safeguards first. The output is a gap list showing each Safeguard identifier, its security function and an owner. Confirm with your assessor which gaps they expect you to close before testing begins.
Update processes and glossary terms
v8.1 added and expanded glossary definitions, including plan, process and sensitive data, and clarified several Safeguard descriptions. Read each documented process against those definitions and revise any wording that uses terms differently from the Controls. Route changes through your normal policy approval process and record version numbers and approval dates. The step is complete when each process cites the v8.1 Safeguards it supports and the approved version sits in your document control system.
Collect evidence against assessment measures
The CIS Controls Assessment Specification defines, for each Safeguard, the inputs, operations, measures and metrics used to verify implementation. It sets out what to measure and leaves the method to the organization, so your team should document how each measure is produced. For each mapped Safeguard and each gap, gather the inputs the specification names, run the operations your tooling supports, and store the output with a timestamp. The check is that every Safeguard has evidence matching at least one measure.
Close gaps and record decisions
Prioritize remediation for each gap by asset class and security function, and assign an owner and a planned action to each one. Where a Safeguard will not be implemented in full, record the decision, the reason, the accepting owner and the compensating measure in your risk register. Ask your implementation partner or assessor to review these decisions. The output is an updated gap log and risk register that match the mapping workbook, with no Safeguard left without an owner or a recorded status.
Retain the mapping for future revisions
Keep the mapping workbook, the evidence index and the decision log as living records, because CIS describes v8.1 as an iterative update and future revisions will change Safeguard wording and mappings. Assign an owner to review the records on a schedule you set and confirm the review timing with your assessor. The step is complete when the records are stored with version history and a named owner, so the next revision can be compared against the current state.

Where v7 programs break when moved to v8.1

Most v7 programs did not fail on technology. They broke on structure: Sub-Controls that no longer map one to one, governance evidence nobody was asked for before, and ownership gaps around cloud, mobile and vendors. The cards below cover the six pitfalls that show up most often when a team re-baselines against v8.1 and what to do about each.

Assuming one-to-one Sub-Control mapping

Version 7 Sub-Controls were renamed Safeguards in v8, and the top-level Controls fell from 20 to 18 across 153 Safeguards. Teams that carry old Sub-Control numbers into a spreadsheet often find that one legacy item now spans several Safeguards, or that a Safeguard draws from more than one legacy item. Rebuild the register from the v8.1 Safeguard list, then trace each legacy item forward to its new Safeguards so no requirement is dropped.

Missing evidence for Govern Safeguards

v8.1 aligns its security function mappings to NIST CSF 2.0 and adds the Govern function, which covers Safeguards about governance, policy and oversight. Version 7 programs rarely kept dated approvals, risk acceptances or management review records for these items, so they have little to show an assessor. Name an accountable owner for each Govern Safeguard and store signed policy approvals and review minutes alongside the technical evidence.

Outdated glossary definitions

v8.1 added and expanded glossary definitions, including terms such as plan, process and sensitive data, and it clarified several Safeguard descriptions. A program written against v7 wording may define a process as a one-time document or treat sensitive data more narrowly than v8.1 does. Re-read each policy and procedure against the v8.1 glossary and update any term whose meaning shifted, then record the change in the document history.

Cloud and mobile Safeguards without owners

CIS released companion guides for cloud and mobile with v8, which brought cloud and mobile technologies into the core Controls. In many v7 programs, cloud accounts and mobile devices sat with a platform team or an end-user team, so no one owned their Safeguards end to end. Assign a named owner for each cloud and mobile Safeguard, covering accounts, device management and data stores, and confirm that the owner can produce the inventory and configuration records an assessor will ask for.

Service provider management gaps

v8 added Control 15, Service provider management, which covers the management of cloud services and other providers that hold sensitive data or run critical processes. Version 7 had no matching Control, so many contracts were never reviewed against a provider inventory, a classification or a secure decommissioning step. Build a provider inventory, classify each provider by the data and systems it touches, and check that contracts carry the security requirements and monitoring rights the Control describes.

Unclear asset classes

In v8.1 each Safeguard maps to one asset class: Devices, Software, Data, Users, Network or Documentation. v8.1 also revised these asset classes and their Safeguard mappings. Teams that tagged assets by business unit or by v7 category often find that a Safeguard lands in a class their inventory cannot filter by. Tag every asset in the inventory with a v8.1 class, confirm the Safeguard-to-class mapping in the Navigator, and report coverage by class so gaps show up before the assessment does.

Frequently asked questions about moving from CIS Controls v7 to v8.1

Do we have to move to CIS Controls v8.1?

No law or standard body forces a move, but the reasons to move are practical. CIS released v8 as a restructured version of the Controls, and v8.1 as an iterative update to v8 intended to minimize disruption to existing users. CIS says the Controls are free for any organization to use to improve its own cybersecurity, so the choice is yours. The stronger driver is contractual or regulatory: if a customer, auditor or state law refers to a specific version, that version governs your obligation. Confirm which version your contracts and any safe harbor law name before you plan the work, and check with the customer or regulator if the wording is unclear.

Is v8.1 a major rewrite of v8?

No. CIS describes v8.1 as an iterative update to v8. Its listed changes are new and expanded glossary definitions, revised asset classes with new Safeguard mappings, minor typo fixes, clarified Safeguard descriptions, NIST CSF security function mappings realigned to CSF 2.0, and the new Govern function. The Safeguard count stays at 153 across 18 Controls. Most of the work for a v8 program carries over to v8.1, but teams should re-check asset class labels, Safeguard wording and the Govern mappings against the v8.1 documents, and update their program records to match.

What is the Govern function?

Govern is the security function added in v8.1 to align the Controls with the NIST Cybersecurity Framework 2.0. In v8.1, each Safeguard carries one security function: Govern, Identify, Protect, Detect, Respond or Recover. Twenty-five of the 153 Safeguards carry the Govern function, covering the governance activities that set direction for the rest of the program. In practice, expect to document the policies, roles, risk decisions and oversight that tie technical work to the organization's goals. Map your existing evidence to these Safeguards and confirm the assignment in the v8.1 Navigator and assessment specification.

Can we do the migration ourselves?

Often yes, for an internal team with security and IT staff who can read the v8.1 Safeguards and the Assessment Specification. CIS publishes the Controls, the Navigator and the self-assessment tools at no charge for organizations to use internally. The effort is in mapping your current controls to the revised Safeguards, updating documentation, closing gaps and collecting evidence. Cost is mostly internal staff time, which you should estimate from your own environment. A partner adds value when the team lacks capacity, when the scope spans many systems, or when an independent review is needed before an assessment.

What does a migration partner do, and what does the auditor or assessor do?

The organization owns its controls and decides what to change. An implementation partner, such as DeployOpen, can plan the migration, prepare systems, configure tooling, document processes and organize evidence for each Safeguard. An independent assessor or auditor reviews that evidence and reports on it. Only an independent auditor, assessor or certification body issues reports or certificates. No organization is certified against the CIS Controls, so no partner can issue that status. Ask any partner to state its role in writing, and ask any assessor to state the scope and method of its review.

Does a safe harbor law require us to update to a new version?

Some do, and the rule depends on the statute. Under Iowa Code section 554G.3, when a listed framework publishes a final revision, a covered entity must reasonably conform its program to the revision no later than one year after the revision's publication date. The statute applies to the frameworks it lists, so confirm whether the CIS Controls and each revision are covered for your entity and check the current text of the law. Other state laws may set different conditions. Record the date of your version adoption and your gap analysis, since these dates are the evidence you would rely on.

What evidence should we keep when we move from v7 to v8.1?

Keep a dated crosswalk from each v7 Sub-Control to its v8.1 Safeguard, a gap register, the updated policies and procedures, and records showing the change was approved. For each Safeguard, keep the inputs, operations and metrics that the CIS Controls Assessment Specification describes for verification, such as inventory exports, configuration baselines, access reviews and scan results. Store these in a version-controlled repository so you can show what changed and when. Ask your assessor which format they expect before you start collecting.

When to bring in outside help for the migration

The organization owns its CIS Controls program, and every decision inside it. That includes which Implementation Group to target, which Safeguards apply to which asset classes, what risk is accepted and what the written policies say. An outside implementation partner can help move from v7 sub-controls to v8.1 Safeguards by preparing systems, configurations, inventories and the documented process that each Safeguard asks for. It does not decide what the program should be, and it does not certify that the organization meets the Controls. Before hiring anyone, write down which Safeguards the partner will touch, which remain with internal staff, and who signs off on the mapping from your existing v7 controls to v8.1 Safeguards.

Ask for a fixed scope in writing before any work starts. A useful scope names the Implementation Group or Safeguards in play, the asset classes and environments covered (for example, cloud accounts, endpoints or the network segments in the change), the deliverables such as configuration baselines, policy updates and evidence packs, the acceptance criteria, and the client responsibilities that the timeline depends on. If the proposal cannot name these items, the work is not yet scoped. Confirm that the partner is not the party that will assess your program, and ask whether any assessor you plan to use has a relationship with the implementation team.

Confirm the assessor's independence before you commit budget to remediation. CIS does not certify organizations against the Controls, so any report or conformance statement you rely on should come from an independent party with clear scope and methodology. Ask the assessor which Assessment Specification measures they will use, how they will test each Safeguard, and what evidence they expect to sample. Then ask the implementation partner to produce evidence in that form from the start. Clarify also who holds the evidence after handover, because your team will need to reproduce it for the next version update.

How DeployOpen maps, implements and prepares evidence for CIS Controls v8.1

DeployOpen starts from what changed between CIS Controls version 7 and v8.1: 18 Controls, 153 Safeguards, activity-based grouping and the Govern function. We scope the work against those Safeguards, build and document the self-hosted open-source systems that produce evidence, and hand over records the client's own team and independent assessors can review.

How we scope

We agree a written scope that names the v8.1 Safeguards and Implementation Groups the work covers.
We map each in-scope Safeguard to its asset class and security function, including the 25 Govern Safeguards.
We confirm which Safeguards the client owns internally and which need a service provider or independent assessor.

How we build

We deploy and harden self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks.
We configure inventory, logging, access and vulnerability tooling to the measures the Assessment Specification describes for each Safeguard.
We test the configured controls, including security testing of applications, APIs and infrastructure, before handover.

How we hand over

We document the processes and written policies the v8.1 Safeguards call for, reflecting the client's actual operations.
We deliver evidence records and a Safeguard-level register that show how each control is implemented and where it is tested.
We train the client's staff to operate the platforms and keep the evidence current. The client owns its controls and its conformance claims.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, which helps teams track updates such as v8.1 and later revisions.
Confirm with us which parts of the client's own roadmap, staffing and assessment plan remain internal before you sign the written scope.

CIS Controls v8 and v8.1: what changed from version 7