CIS Controls v8.1Assessment and Implementation Services

The CIS Critical Security Controls are a published catalog of defensive actions maintained by the Center for Internet Security. Version 8.1 contains 18 Controls broken into 153 Safeguards. A Control is a topic, such as Account Management or Data Recovery. A Safeguard is the specific, checkable action inside it. Safeguards are what an assessment actually measures, so the Safeguard count is the number that matters when you are scoping work or comparing quotes.

What makes the framework unusually practical is that it is prioritized. Most control catalogs hand you every requirement at once and leave you to guess the order. The CIS Controls instead sort all 153 Safeguards into three Implementation Groups, so an organization with two people in IT is pointed at a defensible starting set rather than at the full catalog.

Version 8.1 was published in June 2024 and is the current version. It is an iterative update to version 8.0, which was released in May 2021. The Center for Internet Security describes the v8.1 changes as new and expanded glossary definitions for reserved words used throughout the Controls, revised asset classes with new Safeguard mappings, corrected typos, added clarification to some Safeguard descriptions, and realigned security function mappings to match NIST Cybersecurity Framework 2.0. The headline addition is a new Governance security function.

Assessment, implementation, or both

Two different pieces of work often get sold under one name. An assessment establishes where you stand: which Safeguards are implemented, which are partially implemented, which are not in place, and which we could not verify from the evidence available. Implementation is the work of closing those gaps. They are priced and scheduled separately, and the assessment always comes first, because an implementation plan written without evidence is a guess. We will tell you plainly which one you are buying.

Implementation Group 1 is not a lighter version of every Control. It is a specific selection of 56 Safeguards, and the selection is very unevenly spread. Three Controls contribute nothing at all to Implementation Group 1, and one Control contributes almost all of its Safeguards. If you are deciding whether Implementation Group 1 is enough for your situation, this table is the fastest way to find out.

The three zeros are the most important cells in the table

At Implementation Group 1 there is nothing to assess under Control 13, Network Monitoring and Defense, nothing under Control 16, Application Software Security, and nothing under Control 18, Penetration Testing. Network monitoring, secure software development and penetration testing are entirely outside the Implementation Group 1 scope.

That matters enormously depending on what you do. If you are a software company, Control 16 being absent means an Implementation Group 1 assessment says nothing about your development lifecycle, your code review, your dependency management or how you handle application vulnerabilities. That is very often the thing a customer reviewing you most cares about. We raise it rather than let a report land that answers a question nobody asked.

At the other end, Control 14, Security Awareness and Skills Training, puts 8 of its 9 Safeguards inside Implementation Group 1. Training content and per-person completion records are therefore a large share of the evidence in any Implementation Group 1 engagement, which surprises most organizations that expected the work to be about firewalls.

And Control 15, Service Provider Management, contributes exactly 1 of its 7 Safeguards at Implementation Group 1: maintain an inventory of service providers. An Implementation Group 1 organization therefore has almost no third-party risk machinery in scope, which is worth knowing if you are being assessed because somebody is managing third-party risk. See our third-party risk management page for that side of the problem.

The Implementation Groups are how the CIS Controls turn a catalog into a sequence. They are cumulative: every Safeguard in Implementation Group 1 is also in Implementation Group 2 and Implementation Group 3.

How the Center for Internet Security defines Implementation Group 1

The definition is qualitative, and it is worth reading closely because two of its three parts are about resources and one is about data. The Center for Internet Security describes an Implementation Group 1 enterprise as typically small to medium-sized with limited IT and cybersecurity expertise to dedicate to protecting IT assets and personnel, with limited tolerance for downtime, and it says the sensitivity of the data being protected is low and principally surrounds employee and financial information. The Safeguards chosen for the group are meant to be implementable with limited cybersecurity expertise and aimed at thwarting general, non-targeted attacks.

The guidance for everyone is the same: every enterprise should start with Implementation Group 1.

Put the two definitions side by side and the tension is immediate. Implementation Group 1 assumes the sensitivity of the data being protected is low and principally surrounds employee and financial information. Implementation Group 2, by contrast, is described as being for enterprises that often store and process sensitive client or enterprise information, and that employ individuals responsible for managing and protecting IT infrastructure.

So the two criteria can point in opposite directions, and for small companies they routinely do. A ten-person firm holding a customer's data meets the Implementation Group 2 data criterion on its face, while plainly failing the Implementation Group 2 staffing criterion. There is no published tiebreaker for that case. The Implementation Groups are guidance for prioritization, not a conformance boundary, and the Center for Internet Security does not publish a decision rule.

How we usually handle it

The practical answer is often to scope Implementation Group 1 as the base and quote the Implementation Group 2 delta of 74 additional Safeguards separately, so you can see both numbers and decide with the requirement in front of you. That respects the request you actually made, keeps the entry scope small, and does not leave you holding a report your customer will not accept. What we will not do is silently widen the scope or silently narrow it.

The CIS Controls Assessment Specification exists to provide a common understanding of what should be measured in order to verify that Safeguards are properly implemented. It is deliberately platform agnostic: it defines what to measure rather than how to measure it. A v8.1 edition is published openly and free to read.

For each Safeguard it sets out the basic Safeguard information, dependencies, the Inputs expected in order to measure it, the Operations performed on those inputs, the Measures and Metrics with their calculation, and in some cases a procedural review. We build the evidence request from those published Inputs, which is why our request list is specific rather than a generic document dump.

The evidence collapses onto three master artifacts

Reading the Assessment Specification across all 56 Implementation Group 1 Safeguards produces a finding that changes how an engagement should be sequenced. Most Safeguards draw on a small set of reusable inputs, and three of them dominate:

• Enterprise asset inventory, an input to 22 of the 56 Safeguards
• Configuration standard, the documented secure baseline, an input to 21
• Authorized software inventory, an input to 19

After those come the workforce roster, used in 8 Safeguards to test training coverage, the inventory of user, administrator and service accounts in 6, and the sensitive data inventory in 4.

The practical consequence is simple. If those three artifacts are in reasonable shape, a large fraction of the assessment moves quickly. If they do not exist, the same three gaps cascade across most of Implementation Group 1, and the evidence phase becomes a joint construction exercise rather than a review. That is why we ask for those three first, before committing to a delivery schedule.

Not all 56 Safeguards need the same kind of proof

Across the 56 Implementation Group 1 Safeguards, the evidence splits three ways:

• 12 are documentation only. These are the Safeguards carrying the new Governance security function: a data management process, secure configuration processes, access granting and revoking processes, a vulnerability management process and a remediation process, an audit log management process, a data recovery process, a security awareness program, and incident reporting contacts and process.
• 10 are documentation plus records. A declared artifact, plus per-person or per-entity records that prove it operated. Training completion records are the bulk of this group.
• 34 require hands-on technical verification. Configuration state, enforcement settings, encryption status, patch management run history, backup execution, multi-factor authentication enforcement read from the identity provider.

One limit of the specification, stated plainly

The Assessment Specification covers what it calls Level 1 checks, meaning whether a Safeguard is implemented. Checks that measure how well it is implemented are described as expected in future editions. So the specification gives implementation presence, not effectiveness and not maturity. Any maturity judgment in a report is the assessing firm's own methodology, and ours is disclosed as such in the report rather than presented as the framework's.

For the small documentation burden this creates, note that headcount does not reduce it proportionally. The 12 Governance Safeguards require 12 distinct written processes whether you have eight people or eighty, and Control 14 requires specific training topics with per-person records either way. For most small organizations the finding pattern is predictable: technical controls largely present through cloud platform defaults, written processes largely absent. The remediation value is in documentation and training records, not in buying tools, and we would rather tell you that before you buy anything.

Timelines are confirmed at scoping and depend on how much of the evidence already exists. As our own planning range, an Implementation Group 1 implementation commonly runs four to eight weeks, and a fuller Implementation Group 2 or Implementation Group 3 implementation three to six months depending on environment complexity. The assessment itself is shorter than either. We would rather give you a date we can hold than a fast number we cannot.

Start with the sentence that settles most of it. The Center for Internet Security's own frequently asked questions state that the CIS Controls are not a replacement for any existing regulatory, compliance, or authorization scheme. And the official CIS Controls v8.1 guide describes the Implementation Groups as self-assessed categories for enterprises.

Read those two statements together and the position is clear. There is no certificate an assessed organization can hold, no report format defined by the Center for Internet Security, no published evidence-sufficiency standard, and no body that renders a pass or fail decision about an assessed organization against the CIS Controls. Nobody can make your organization CIS certified, because that status does not exist. Petronella Technology Group, Inc. does not certify anyone against the CIS Controls, and no firm can.

There is also a contractual reason the wording matters. The Center for Internet Security's Terms of Use for non-member products bar a user from representing or claiming a particular level of compliance or consistency with those products, and the equivalent clause in its paid Services and Consulting agreement repeats the prohibition for its member products, which are defined to include the CIS Controls in any format provided. Buying a membership does not buy the right to make the claim.

So what do we actually give you

• An independent assessment report on our letterhead, stating the scope, the version, the Implementation Group, the methodology, the evidence examined, the dates, and the finding for each named Safeguard.
• Per-Safeguard implementation status using plain words: implemented, partially implemented, not implemented, or not verified, with the reason in each case.
• A prioritized remediation roadmap, ordered by risk reduction and by what unblocks other Safeguards, not by what is easiest to bill.
• A shareable written summary, kept short enough that a customer's reviewer will actually read it, and written from the start to be forwarded.
• Optionally, help completing or reviewing your customer's own questionnaire, mapped back to the assessment findings, because that is usually the artifact that actually closes a vendor review.

And what we deliberately leave out

We do not print a headline percentage or a single score on page one. A vendor-risk reader will want one, and it is exactly what a naive report would lead with, but a compliance level is the specific thing the license terms above prohibit claiming. Per-Safeguard status carries more information anyway, and it survives scrutiny if your customer's own reviewer reads it closely.

We also do not use the words certification, audit, attestation, examination, opinion or assurance about this work. Those words name regulated activities performed by licensed or accredited parties under published standards. Petronella Technology Group, Inc. is not a licensed CPA firm and this is not an engagement performed under standards of the American Institute of Certified Public Accountants or any other body, so no opinion and no form of assurance is expressed. What we express is findings, based on the evidence made available to us, on the dates stated, using the procedures described. That is the honest description, and it is also the one that holds up.

Which leaves the honest framing of value. Moving from an internal self-assessment to an independently performed, evidence-based assessment is a real and material improvement in what you can show someone. It is not a certification, it is not an examination, and it is not a substitute for SOC 2. It is the strongest artifact that exists for this framework, and the credibility comes from who signed it, the disclosed methodology, the evidence examined and the dates, rather than from a stamp.

1. Who issues the certificate, and what accredits them to issue it? For ISO/IEC 27001 the answer is a certification body accredited under ISO/IEC 17021-1. For CMMC it is a certified third-party assessment organization. For the CIS Controls there is no equivalent answer, because there is no scheme that certifies assessed organizations.
2. Show me the published report format you will follow. The Center for Internet Security does not publish one. A firm that names a standard report format for CIS Controls work is describing its own template, which is fine, as long as it says so.
3. Which version, and which Implementation Group? If the answer is not a version number and a Safeguard count, the scope is not defined. Ask for the Safeguard count in writing: 56, 130 or 153.
4. Are Controls 13, 16 and 18 in scope? At Implementation Group 1 they contribute zero Safeguards. If your customer cares about network monitoring, software development security or penetration testing, an Implementation Group 1 scope will not touch them, and you need to know that before the report is written, not after.
5. What evidence will you examine, and what will you test rather than collect? The published Assessment Specification defines inputs per Safeguard. A questionnaire-only exercise sold as a third-party assessment is a different product at a similar price.
6. Will the deliverable claim a compliance level or a percentage? If yes, ask how that squares with the license terms that prohibit representing a particular level of compliance with the CIS Controls.
7. Is remediation included or excluded? Get it in writing either way. Assessment and remediation are separate scopes, and the ambiguity is where budgets go wrong.
8. Does the price include reassessment, and against what baseline? A reassessment is only meaningful against a dated prior position.

None of those questions is hostile, and a good vendor will answer all eight without flinching. We are happy to be asked them, which is why they are on our own page.

The Center for Internet Security publishes official crosswalks from CIS Controls v8.1 to other frameworks as white papers, and makes the same mappings selectable in the CIS Controls Navigator alongside roughly thirty framework options. Two are directly relevant to most buyers:

• CIS Controls v8.1 Mapping to NIST Cybersecurity Framework 2.0, published in June 2024 on the same day as v8.1 itself. This is why we assess against v8.1 and not v8: the v8.1 security function mappings were realigned to NIST Cybersecurity Framework 2.0, including the new Governance function.
• CIS Controls v8.1 Mapping to SOC 2, which maps the Safeguards to the AICPA Trust Services Criteria.

The Navigator will apply an Implementation Group filter and a framework mapping at the same time. That means we can produce an exhibit showing which Trust Services Criteria the 56 Implementation Group 1 Safeguards specifically touch, rather than all 153, which is far more useful to a customer weighing your evidence.

The same logic applies across the other frameworks we work in. CIS Controls work builds the underlying practices and much of the evidence, which then feeds a NIST 800-171, NIST 800-53, HIPAA or CMMC program rather than duplicating it. It does not substitute for any of them. If you are comparing your options, our framework comparison page sets them side by side, and compliance risk assessment covers the step before you pick one.

1. A customer has to assess you, and the rule that obliges them names no instrument

The most common trigger we see is a customer's vendor security review. Often that customer is discharging a duty of its own. Under the Federal Trade Commission's Safeguards Rule, a covered financial institution must take reasonable steps to select and retain service providers capable of maintaining appropriate safeguards, require those safeguards by contract, and then, in the words of 16 CFR 314.4(f)(3), periodically assess your service providers based on the risk they present and the continued adequacy of their safeguards.

Two things follow. First, "financial institution" reaches much further than banks: the Safeguards Rule defines it by reference to activities financial in nature under the Bank Holding Company Act, and the rule text carries an automobile dealership example on its face, treating a dealership that leases vehicles on a nonoperating basis for longer than ninety days as a financial institution with respect to its leasing business. If you supply software or services to dealerships, lenders, mortgage brokers, tax preparers or similar businesses, this is very likely what is driving the request.

Second, and this is the part that matters commercially: the rule prescribes a periodic, risk-based assessment. It does not name SOC 2, ISO 27001 or any other instrument. An independent, evidence-based CIS Controls assessment is a defensible way for your customer to satisfy that obligation, and it is faster and cheaper than the alternatives. Our GLBA and Safeguards Rule page covers the obligation from the covered institution's side.

One nuance we state in writing rather than gloss over: if the rule binds your customer and not you, our report evidences your safeguards so that they can discharge their duty. It is not a statement that you comply with a rule that does not apply to you.

2. Proportionality is a published principle, and a small supplier is entitled to argue it

Buyers sometimes ask a ten-person supplier for the same artifact they would ask of a thousand-person one. The governing guidance does not require that, and says so in three places worth quoting to a reviewer.

• NIST SP 800-161r1 on supply chain risk management: there are a variety of acceptable validation methods, including certifications, site visits, third-party assessments and self-attestation, and the type and rigor of the required methods should be commensurate with the criticality of the service or product being acquired.
• NIST Cybersecurity Framework 2.0 states that the framework does not prescribe how outcomes should be achieved. Its supply-chain outcomes are stated without naming an artifact: suppliers are known and prioritized by criticality, and supplier risks are understood, recorded, prioritized, assessed, responded to and monitored.
• The 2023 Interagency Guidance on Third-Party Relationships, issued by the Federal Reserve, the FDIC and the OCC, says the scope and degree of due diligence should be commensurate with the level of risk and complexity of the relationship, and that where information cannot be obtained the organization should document the limitations of its due diligence rather than pretend they are absent.

The decision on acceptable evidence belongs to the customer. What these citations establish is that right-sizing is the published principle, not a concession. That is a much better conversation to have than a flat refusal.

3. Statute and insurance already recognize the framework by name

Two forms of recognition exist and are worth knowing, with their limits stated.

State safe-harbor statutes. Ohio Revised Code 1354.03 lists the Center for Internet Security critical security controls among the industry-recognized frameworks that support the affirmative defense created by Ohio Revised Code 1354.02. Texas SB 2610, passed by the 89th Legislature and effective 1 September 2025, goes further and names the framework by tier: organizations with fewer than twenty employees get simplified requirements covering password policies and appropriate employee cybersecurity training, organizations with twenty to ninety-nine employees get moderate requirements including the requirements of Center for Internet Security Controls Implementation Group 1, and organizations with one hundred to two hundred forty-nine conform to the listed NIST and ISO frameworks. The Center for Internet Security itself describes Texas as joining Ohio, Utah, Connecticut and Iowa as safe-harbor states.

Read the tier you actually fall in. A company of eight people sits in the Texas simplified tier, not the Implementation Group 1 tier, so Texas is not a supporting citation for every small business. We check which tier applies rather than citing the statute generically. Read what the protection actually is, too: these statutes bar exemplary or punitive damages in a data-breach claim. They do not create a cause of action, they do not make anyone compliant, and none of them requires a third-party assessment. Adopting a recognized framework is what the statute rewards; having someone independent look at it is a business decision about confidence and about what your customers ask for, not a statutory requirement.

Cyber insurance. The Center for Internet Security and CyberAcuView built a tool that aligns Implementation Group 1 with the questions most commonly found in cyber insurance applications. CyberAcuView is backed by a coalition of cyber insurance underwriters including AIG, AXIS, Beazley, Chubb, The Hartford, Liberty Mutual Insurance and Travelers. Underwriters treating Implementation Group 1 as evidence is genuine recognition. The domain is underwriting rather than third-party risk, and it is not a certification, but it means the work you do here is legible to your insurer as well as your customer.

Separately, the Shared Assessments program lists the CIS Critical Security Controls among the authority documents its standardized information gathering questionnaire can be mapped against, which means the framework is recognized as questionnaire content in the third-party risk world.

When the answer is genuinely SOC 2, we will say so

If your customer requires a report with an opinion from a licensed firm, or if the requirement is contractual and specific, CIS Controls work is preparation rather than substitution. It is good preparation: it builds the practices and much of the evidence, at lower cost, faster, and it tells you what the gaps are before anyone external is engaged. Then go and do the real thing. Our SOC 2 readiness assessment and SOC 2 compliance checklist pages are the next step, and it is worth noting that the CIS Controls themselves point buyers this way: Safeguard 15.5, which sits at Implementation Group 3, tells an organization assessing its own service providers that the assessment may include review of standardized assessment reports such as SOC 2 and the Payment Card Industry Attestation of Compliance.

We would rather lose the smaller engagement than sell you an artifact your customer will reject.

• Software and service suppliers facing a customer's vendor security review, who need something stronger than a self-completed questionnaire and cannot justify a full attestation program yet.
• Service providers to financial institutions whose customers are working through the Safeguards Rule service-provider obligation.
• Small and mid-sized organizations with no dedicated security staff who want a defensible starting baseline and a roadmap rather than a tool purchase.
• Organizations preparing for a larger framework, using the CIS Controls as the cheapest route to building the practices and evidence that NIST 800-171, SOC 2 or CMMC will later require.
• Organizations in a safe-harbor state that want their program aligned to a framework their statute names.
• Boards and owners who want an outside read on where the real exposure is, with a prioritized list and no headline score to hide behind.

Related work often bought alongside an assessment: vulnerability assessment and penetration testing, both of which sit outside Implementation Group 1 but inside Controls 7, 13 and 18 at the higher Implementation Groups and inside most customers' expectations regardless.