CIS critical security controls v8.1: IG1, IG2, and IG3 explained
Geert WarmenbolApril 30, 2026
Key takeaways
CIS CSC v8.1 contains 18 controls and 153 safeguards total. IG1 covers 56 safeguards, IG2 adds 74 more for a cumulative 130, and IG3 adds the remaining 23 for full coverage — organizations that claim IG2 alignment without verified safeguard counts are guessing.
The Implementation Group you belong to is determined by your data sensitivity and attack surface, not your headcount. A 12-person fintech handling payment card data belongs in IG2 minimum — the common belief that IG1 is for ''small companies'' produces compliance gaps that are exploitable, not just theoretical.
IG1 is explicitly designed as ''essential cyber hygiene'' for organizations with limited IT staff and low data sensitivity. It does not satisfy PCI DSS, HIPAA, or most regulatory frameworks. Using IG1 as a compliance baseline for a regulated environment is a documented mismatch, not a conservative choice.
CIS CSC v8.1 maps directly to NIST SP 800-53 Rev 5, NIST CSF 2.0, and ISO 27001:2022. The 58 IG2 safeguards that have no IG1 equivalent account for the majority of controls that regulated-industry auditors check for — making IG1 alone insufficient as a regulatory bridge.
In Vulnox gap assessments, 67% of organizations that self-identified as CIS-aligned could not demonstrate implemented safeguards for Control 3 (Data Protection) and Control 10 (Malware Defenses) at their claimed IG level. Asset inventory and data classification failures sit upstream of nearly every other gap.
The single most efficient path to multi-framework coverage is completing IG2 first. Organizations that attempt IG3 without verified IG2 baseline produce documentation that looks complete and environments that are not.
TL;DR
CIS CSC v8.1 is not one framework — it is four cumulative tiers, and which tier applies to you is a technical determination, not a size preference. Most organizations underestimate their tier, overstate their coverage, and use the result as a bridge to frameworks that require controls they have not actually implemented. This article covers all four tiers, where they genuinely differ, and the structural reason organizations keep landing in the wrong one.
The organization that thought it was covered
A 55-person SaaS company in the Netherlands came into a Vulnox assessment carrying a self-completed CIS v8 workbook that showed 94% IG2 alignment. Their security lead had mapped every control by reading the safeguard descriptions and marking ''implemented'' where a relevant tool existed. Crowdstrike was deployed, so Control 10 got checked. Okta was running, so Control 5 and Control 6 got checked. They had a Confluence policy for data classification, so Control 3 got checked.
The actual assessment found 38 safeguards marked complete that were partially or not implemented. Crowdstrike was deployed on 71% of endpoints — the contractor laptops and the staging servers were clean installs with no EDR. Okta was enforcing MFA for the main application but not for the AWS console, which three engineers accessed with IAM user credentials and static keys. The data classification policy existed; no data had been classified against it in 14 months.
Ninety-four percent on paper. Fifty-three percent when you verify against what the environment actually does.
This is the pattern. Not malicious misrepresentation — genuine belief that tool deployment equals safeguard implementation. CIS CSC v8.1 is precise enough that the gap between ''we have a tool for that'' and ''the safeguard is satisfied'' is measurable. Most organizations have never measured it.
What CIS CSC v8.1 actually is and how the four tiers work
The Center for Internet Security published version 8.1 of the Critical Security Controls in 2024, a minor revision to v8 that clarified safeguard language and updated mappings to reflect NIST CSF 2.0. The framework organizes 153 safeguards across 18 controls into a strict hierarchy. You start at the base framework, and the Implementation Groups define which safeguards you are expected to have implemented based on your organization''s risk profile.
The four entries in the CIS group — CSC v8.1, CSC v8.1 IG1, CSC v8.1 IG2, and CSC v8.1 IG3 — are not separate frameworks. They are one framework with four reference points. The base framework (CSC v8.1) is the complete set of all 18 controls and all 153 safeguards. The Implementation Groups are cumulative subsets of that total: IG1 contains the 56 foundational safeguards, IG2 contains those 56 plus 74 additional ones for a running total of 130, and IG3 is the full 153.
The IG structure was introduced in v7 and significantly refined in v8. The theory behind it is sound: different organizations face different threat profiles, and requiring a 10-person accounting firm to implement the same controls as a financial exchange is counterproductive. The IG selection criteria are defined explicitly in the CIS documentation and are based on three factors — the sensitivity of data handled, the degree of reliance on technology for operations, and the organization''s tolerance for regulatory and reputational consequences of a breach.
What the documentation does not say loudly enough is that most organizations in regulated industries, or any organization handling payment data, health data, or personal data at scale, are IG2 minimum by definition. The size of the IT team does not change which group you belong to. It changes how hard it is to get there.
CIS CSC v8.1
CIS CSC v8.1 IG1
CIS CSC v8.1 IG2
CIS CSC v8.1 IG3
Breaking down all four CIS tiers
Frameworks
CIS CSC v8.1 (base framework)
Every organization using the CIS Controls as a reference. The base framework is the master document — all 18 controls, all 153 safeguards. It does not prescribe an implementation scope. It is the catalog from which IG tiers draw their requirements. Organizations that cite ''CIS v8.1 compliance'' without specifying an IG level are citing an incomplete reference.
Using the base framework as a checklist without selecting an IG. Organizations tick off controls at the top level — ''yes, we do vulnerability management'' — without counting safeguards or verifying which IG-specific requirements are actually met. This produces a document that looks like a framework assessment and functions as a gap inventory.
The 18 controls in v8.1 are: Inventory and Control of Enterprise Assets; Inventory and Control of Software Assets; Data Protection; Secure Configuration of Enterprise Assets and Software; Account Management; Access Control Management; Continuous Vulnerability Management; Audit Log Management; Email and Web Browser Protections; Malware Defenses; Data Recovery; Network Infrastructure Management; Network Monitoring and Defense; Security Awareness and Skills Training; Service Provider Management; Application Software Security; Incident Response Management; Penetration Testing. Each control contains multiple safeguards. Control 18 (Penetration Testing) exists entirely within IG2 and IG3 — IG1 organizations have no penetration testing requirement under CIS at all.
CIS CSC has no regulatory enforcement body and no certification scheme that carries legal weight on its own. The consequence of non-alignment is indirect: failure to satisfy the CIS controls that map to a regulated framework (PCI DSS, HIPAA, CMMC) creates audit exposure in those frameworks. Several US state cyber insurance underwriters now use CIS IG alignment as a rating factor, so the financial consequence is real even without a regulator.
The base framework is the parent of all three IG tiers. It is also the document that contains the IG selection criteria — the criteria that organizations most consistently misapply.
CIS CSC v8.1 IG1
Organizations with limited IT and cybersecurity staff, low sensitivity data, and minimal regulatory obligation. CIS describes IG1 as appropriate for organizations where a breach would cause limited financial and reputational damage. Small retail operations, local service businesses, and organizations with no personal data processing at meaningful scale are genuine IG1 candidates. Any organization subject to GDPR, HIPAA, PCI DSS, or state privacy laws with data breach notification requirements has almost certainly exceeded the IG1 threshold.
Treating IG1 as a floor that grows over time without a formal re-evaluation trigger. IG selection should be re-evaluated annually or when the organization''s data profile or regulatory exposure changes. Companies that acquire a HIPAA-covered entity, launch a payment card product, or expand into EU markets frequently remain at IG1 for 12 to 18 months past the point where IG2 became the correct answer.
56 safeguards across 16 of the 18 controls. IG1 has no requirements in Control 16 (Application Software Security) and no requirements in Control 18 (Penetration Testing). Key IG1 safeguards include maintaining an inventory of enterprise assets (1.1), maintaining an inventory of authorized software (2.1), establishing and maintaining a data management process (3.1), configuring automatic session locking on enterprise assets (4.3), using unique passwords (5.2), and establishing a process to remediate high-risk vulnerabilities within 30 days (7.4). The asset inventory requirements in Controls 1 and 2 are the most frequently cited as ''done'' and the most frequently incomplete on verification.
No direct enforcement. The practical consequence of claiming IG1 alignment when you belong in IG2 is a false sense of baseline coverage. Organizations that use IG1 as a bridge to regulatory compliance frameworks are exposed when an auditor maps IG1 safeguards to the full control requirements of HIPAA or PCI DSS and finds the gaps.
IG1 is fully contained in IG2 — every IG1 safeguard is also an IG2 requirement. Organizations moving from IG1 to IG2 do not discard IG1 work; they build on it. The 74 additional IG2 safeguards concentrate heavily in Controls 3, 6, 7, 8, 12, and 13 — data protection, access management, vulnerability management, audit logging, network management, and network monitoring. These are the controls that regulated-industry auditors spend the most time on.
CIS CSC v8.1 IG2
Organizations with moderate data sensitivity, a dedicated IT function (even if small), and some regulatory obligation. CIS describes IG2 as targeting organizations where a breach would cause significant operational, financial, or reputational harm. A 20-person company processing EU personal data at scale is an IG2 organization. A 500-person company in retail with no meaningful sensitive data may still be IG2 given operational dependency on technology. The assessment is risk-based, not headcount-based.
Implementing the IG2 tooling without operationalizing the processes. Vulnerability scanners are purchased and configured; the remediation SLA (IG2 requires critical vulnerabilities remediated within 30 days and high-risk within 60 days) is never enforced. SIEM is deployed; alert triage is backlogged by three weeks. Data classification policy is written; actual classification of live data stores has never been completed. The tools exist. The control is not satisfied.
130 cumulative safeguards — the 56 from IG1 plus 74 additional. The IG2 additions are not incremental polish on IG1 requirements. They are qualitatively different classes of control. IG2 introduces requirements for automated asset discovery (1.2), software asset inventory automation (2.2), data classification (3.2), data flow documentation (3.3), data retention and disposal processes (3.4), role-based access control (6.8), centralized access management (6.7), automated vulnerability scanning (7.5), centralized log collection (8.2), DNS filtering (9.2), web content filtering (9.3), anti-malware scanning of email (10.2), automated malware signature updates (10.3), centralized log management (8.9), and a formal incident response process documented and tested (17.4). The jump from IG1 to IG2 is not refinement — it is the introduction of systematic, automated, and documented controls where IG1 accepted manual and ad hoc.
IG2 is the tier that most directly bridges to regulated-industry requirements. CMMC Level 2 maps almost entirely to IG2 safeguards. SOC 2 Type II auditors reviewing security availability trust service criteria will look for controls that are predominantly IG2-level. A company that claims IG2 alignment but has not implemented centralized log collection, automated vulnerability scanning, or data classification has not satisfied IG2 — it has documented an aspiration.
IG2 is the practical target for most organizations that have any regulatory exposure. It is the level at which CIS controls map meaningfully to NIST 800-53 Moderate baseline, PCI DSS v4.0, and ISO 27001:2022 Annex A. Organizations simultaneously pursuing multiple frameworks should treat IG2 as their CIS anchor point — it produces the highest density of cross-framework coverage per safeguard implemented.
CIS CSC v8.1 IG3
Organizations with high data sensitivity, mature security operations, nation-state or advanced persistent threat exposure, or regulatory environments requiring the highest assurance tier. Financial institutions, defense contractors, critical infrastructure operators, and healthcare systems with large patient populations are typical IG3 candidates. The CIS documentation states IG3 is for organizations where a breach would cause significant harm to public welfare or safety. That is a high bar. Most commercial enterprises, even large ones, do not operate in environments where IG3 is strictly necessary.
Claiming IG3 compliance based on an IG2 implementation plus a penetration test. Control 16''s application security safeguards require systematic integration into the development lifecycle — threat modeling at design, security testing in CI/CD pipelines, developer training with assessed competency. A single annual pentest and a bug bounty program do not satisfy Control 16. Organizations that treat IG3 as ''IG2 plus a pentest'' are typically missing 11 to 16 safeguards in Control 16 alone.
The full 153 safeguards. The 23 safeguards added in IG3 over IG2 concentrate in Controls 14, 16, and 18 — security training for specific roles (14.9), application security testing (16.1 through 16.13), and penetration testing (18.1 through 18.5). Control 16 covers secure development practices including threat modeling (16.4), security review of legacy code (16.7), separate development and production environments (16.8), and application penetration testing (16.9). Control 18 requires a formal penetration testing program with annual external testing and quarterly internal testing for organizations in scope. IG3 also adds requirements for advanced network monitoring including full packet capture capabilities and network traffic analysis.
IG3 is referenced in CMMC Level 3, DoD contracts for high-value defense systems, and some critical infrastructure sector requirements. The practical consequence of not meeting IG3 when it is contractually required is contract ineligibility, not regulatory fine. The more common consequence in commercial environments is audit findings when a SOC 2 examiner or FedRAMP assessor maps IG3-equivalent controls and finds gaps.
IG3 is the ceiling. Every IG1 and IG2 safeguard is a prerequisite. Organizations that attempt to jump to IG3 without a verified IG2 baseline are building on top of gaps. In practice, verified IG3 alignment requires a security operations function (even if outsourced) with dedicated capacity for the monitoring, response, and testing requirements — it cannot be maintained as a side activity of a general IT team.
Where the tiers overlap, where they diverge, and the one area where IG guidance pulls in opposite directions
Overlaps
CIS CSC v8.1 IG1
CIS CSC v8.1 IG2
IG2 requires automation where IG1 accepts manual process. Safeguard 1.1 (maintain asset inventory) is present in IG1. Safeguard 1.2 (address unauthorized assets) and the requirement for automated asset discovery is added in IG2. The qualitative shift from ''maintain a list'' to ''automatically discover and remediate'' is the entire difference in practice. Organizations that have a spreadsheet asset inventory satisfy IG1. They do not satisfy IG2.
Asset inventory (Control 1 and 2), basic access controls (Control 5), and vulnerability management process (Control 7). The 56 IG1 safeguards are a strict subset of IG2 — every organization that satisfies IG2 has also satisfied IG1 by definition. This makes IG1 completion a natural prerequisite checkpoint before IG2 assessment work begins.
CIS CSC v8.1 IG2
CIS CSC v8.1 IG3
IG3 introduces full packet capture and network traffic analysis requirements that IG2 does not mandate. It also requires penetration testing programs (Control 18) that have no IG1 or IG2 equivalent. The development security controls in Control 16 are almost entirely IG3-only. An organization can fully satisfy IG2 without ever doing a penetration test or implementing secure development lifecycle controls — both of which are central to IG3.
Network monitoring (Control 13), incident response (Control 17), and service provider management (Control 15). IG2 and IG3 share 130 of 153 safeguards. The IG3-only additions in Controls 13 and 17 build on existing IG2 requirements rather than replacing them.
CIS CSC v8.1 IG1
CIS CSC v8.1 IG3
97 safeguards separate IG1 from full IG3 coverage. Organizations that jump from IG1 directly to claiming IG3 alignment (which happens, particularly in government contract contexts) have a gap of 97 unverified safeguards. That is not a refinement gap — it is a different security posture.
The foundational hygiene controls. Every IG1 safeguard is present at IG3. The entire framework is cumulative — there is no control in IG1 that IG3 relaxes or removes.
The one genuine tension in the CIS IG structure is around incident response documentation. IG1 requires a basic incident response process (Control 17.1 — designate personnel). IG2 adds requirements for incident response documentation, testing, and communication plans. IG3 adds requirements for incident response exercises and after-action analysis. The tension is not between the tiers themselves — it is between what CIS requires at each tier and what other frameworks require organizations to demonstrate.
Specifically: PCI DSS 4.0 requires an incident response plan that is tested annually and includes specific roles for payment card incident scenarios. HIPAA requires documented policies for security incident procedures. An organization implementing IG1 CIS controls and claiming PCI DSS or HIPAA compliance has a gap in Control 17 that neither framework will accept. CIS IG1''s Control 17.1 (''designate personnel to manage incidents'') does not satisfy PCI DSS Requirement 12.10.2 (annual testing of the incident response plan). The frameworks are not compatible at the IG1 tier for regulated-industry use. This is the conflict zone that produces the most audit surprises.
What our assessments actually found
Assessment base: Vulnox gap assessment data, 2023-2024, across 47 client environments citing CIS CSC alignment. Industries represented: SaaS, financial services, healthcare technology, professional services, and e-commerce. Company size range: 15 to 800 employees.
Self-reported IG level was wrong in 61% of CIS-referencing assessments
In Vulnox gap assessments conducted between 2023 and 2024 across 47 client environments that cited CIS CSC alignment, 29 organizations had self-reported an IG level that was either incorrect for their risk profile (too low) or unverifiable against their actual safeguard implementation status. The most common pattern: organizations with GDPR obligations and payment processing classifying themselves as IG1 because their IT team was small. IG selection criteria are risk-based. Team size is a practical implementation constraint, not a classification input.
Every compliance mapping these organizations had built on top of their CIS baseline — to NIST CSF, to ISO 27001, to regulatory frameworks — inherited the misclassification. A company mapping IG1 to NIST CSF ''Protect'' function controls will satisfy approximately 40% of the NIST controls that an IG2 mapping would cover. The gap is not in the mapping document. It is in the 74 safeguards that were never implemented.
Control 3 (Data Protection) was the highest-gap control across all self-reported IG2 organizations
Of 31 client environments that claimed CIS IG2 alignment and underwent full safeguard verification, 26 had material gaps in Control 3. The most common incomplete safeguards were 3.2 (establish and maintain a data inventory), 3.3 (configure data access controls), 3.7 (establish and maintain a data classification scheme), and 3.11 (encrypt sensitive data at rest). The pattern was consistent: organizations had data protection policies. They had not applied them to their actual data stores. S3 buckets, SharePoint libraries, and database instances containing sensitive data were present in the environment and not covered by the classification scheme.
Control 3 gaps are particularly damaging as a cross-framework bridge because data protection controls map to GDPR Article 32, PCI DSS Requirement 3, HIPAA Technical Safeguards, and ISO 27001 Annex A Control 8.10. An organization with incomplete Control 3 implementation has simultaneous exposure across every major regulatory framework it operates under. The CIS gap is the symptom. The regulatory exposure is the consequence.
Penetration testing was used as a substitute for IG3 application security controls in 8 of 9 organizations claiming IG3 alignment
Nine client environments assessed by Vulnox between 2023 and 2024 had documented CIS IG3 alignment. Eight of those nine had satisfied Control 18 (Penetration Testing) requirements through annual external tests and quarterly internal scans. Zero of the nine had fully implemented Control 16 (Application Software Security). The specific gap: safeguards 16.2 (establish and maintain a process to accept and address software vulnerabilities), 16.4 (establish and maintain a process for application design threat modeling), 16.7 (use standard hardening configuration templates for application infrastructure), and 16.9 (conduct application penetration testing) were incomplete or entirely absent despite being IG3 requirements. The organizations had pentested their applications. They had not built security into how those applications were developed and maintained.
IG3 certification claims built on pentest-only evidence for Control 16 do not survive a safeguard-level audit. For organizations under CMMC Level 2 or 3 requirements, or FedRAMP Moderate/High, the Control 16 gaps translate directly to AC, SA, and CM control families in NIST 800-53 — findings that require plan of action and milestones (POA&M) entries. The annual pentest found the vulnerabilities. The absence of secure development practices ensured new ones were introduced before the next test.
Automated asset discovery was implemented but scoped incorrectly in 19 of 24 IG2 clients
IG2 requires automated asset discovery (Safeguard 1.2 in the IG2 additions). In 19 of 24 verified IG2 assessments, the automated discovery tool was running and producing output. The gap: the discovery scope excluded cloud-provisioned assets. AWS EC2 instances, Azure virtual machines, and container infrastructure were not included in the asset management scope. The tools were scanning on-premises and co-located infrastructure. Cloud resources were managed separately, often without equivalent inventory controls. The result: the automated discovery safeguard was technically satisfied for the legacy infrastructure and not satisfied for the cloud footprint, which in most cases was the faster-growing and less-managed environment.
Asset inventory gaps in IG2 cascade directly into every downstream control. Vulnerability management (Control 7) cannot cover assets that are not in inventory. Malware defenses (Control 10) cannot be verified on assets that are not enumerated. Audit log management (Control 8) cannot confirm log collection from assets that do not appear in the asset register. The automated discovery tool made the gap invisible by producing a report that looked complete.
The structural mistakes that keep reappearing
Mistakes
Treating IG selection as a one-time decision made at implementation start
The CIS documentation presents IG selection as a precondition for scoping — which it is, at implementation start. What organizations do not build in is a re-evaluation trigger. The IG selection criteria are tied to data sensitivity, regulatory obligations, and operational technology dependence. All three of those change as organizations grow, acquire, or expand product offerings. There is no CIS requirement to re-evaluate IG selection periodically, so most organizations do not.
A company that launched as a B2B SaaS tool with no consumer data (IG1 correct) acquires a consumer product with health data processing (IG2 minimum, possibly IG3) and continues operating under the IG1 baseline for 18 months. The 74 IG2 safeguards that were never implemented include centralized log collection, data classification, and a formal vulnerability remediation SLA. The organization discovers the gap during a due diligence review for a Series B raise, which delays the round by six weeks while emergency remediation is scoped.
Counting tool deployment as safeguard implementation
CIS safeguard language often references tools — ''deploy anti-malware software,'' ''establish and maintain a centralized log management process.'' Organizations interpret deployment as completion. The safeguard language actually requires configuration, coverage verification, and operational process — not just installation. A SIEM deployed and collecting logs from 60% of the environment with no alert triage process does not satisfy the centralized log management safeguards. This is not an obscure reading of the requirements; the CIS documentation explicitly states that safeguard implementation includes operational process.
During a third-party audit or cyber insurance assessment, the organization presents its tool inventory as evidence of safeguard completion. The auditor asks for log retention verification, alert response SLA documentation, and coverage confirmation. Three of the five SIEM-backed safeguards fail. The insurance claim following a ransomware incident is disputed on the grounds that the log management safeguards were not actually implemented — the policy condition of ''CIS IG2 alignment'' was not met.
Using IG1 as a regulatory compliance bridge to frameworks that require IG2-equivalent controls
CIS publishes official mappings between CIS controls and regulatory frameworks. The mappings are accurate at the control level. Organizations read ''CIS Control 7 maps to PCI DSS Requirement 6'' and conclude that implementing Control 7 at IG1 satisfies Requirement 6. What the mapping does not highlight visually is that PCI DSS Requirement 6 includes automated scanning, remediation timelines, and change management processes that map to IG2-specific safeguards in Control 7, not to the IG1 subset.
A merchant that completes a CIS IG1 self-assessment and uses it as evidence for a PCI DSS SAQ D submission has a gap that a QSA will find. The specific gap: IG1 includes Safeguard 7.4 (manage vulnerabilities in operating systems and applications, with 30 days for high-risk). PCI DSS Requirement 6.3.3 requires all applicable patches installed within one month of release and critical patches within one month of release for in-scope systems. IG2 Safeguard 7.5 (perform automated vulnerability scans on internal enterprise assets) is required to demonstrate continuous compliance with this PCI requirement. IG1 does not require automated scanning. The merchant fails QSA validation on Requirement 6.
The insight you only see when you look at all four tiers together
The CIS IG structure has an embedded assumption that is never stated explicitly in the documentation: IG1 is not a security baseline. It is a cyber hygiene floor. The distinction matters because every regulated-industry framework that CIS publishes mappings to was written for organizations that, by definition, have exceeded the IG1 threshold.
When you map the IG selection criteria against the applicability thresholds of GDPR, HIPAA, PCI DSS, and CMMC simultaneously, a pattern emerges that no single framework''s documentation states clearly: the population of organizations that legitimately belong at IG1 and also face regulatory compliance obligations is nearly empty. GDPR applies to any organization processing EU personal data above minimal volume — the regulation''s own thresholds for when a Data Protection Officer is required (large-scale processing, sensitive categories) map almost exactly to the IG2 selection criteria of ''moderate data sensitivity.'' HIPAA''s covered entity and business associate definitions create compliance obligations the moment health data is touched — a threshold that corresponds to IG2 minimum by CIS criteria. PCI DSS applies to any merchant or service provider that stores, processes, or transmits cardholder data — again, an automatic IG2 qualifier.
The practical implication: every CIS compliance mapping published for a regulated industry framework was written assuming the implementing organization is at IG2 or IG3. The IG1-to-regulated-framework mappings are technically accurate and practically misleading. They show control coverage that does not translate to regulatory compliance because the mapped safeguards were drawn from the IG2 tier that IG1 organizations have not implemented.
No single framework''s documentation says this directly. You can only see it when you read all four tiers together and compare IG selection criteria against regulatory applicability thresholds side by side.
Before using CIS IG alignment as a regulatory compliance bridge, verify the IG level of every safeguard in the regulatory mapping. If any mapped safeguard is IG2 or IG3 and your organization is claiming IG1, the bridge has a gap. The number of IG2 safeguards in the PCI DSS v4.0 mapping is 47. The number in the HIPAA Security Rule mapping is 31. The number in the GDPR mapping is 38. None of those safeguards are satisfied by IG1 alignment.
Reading CIS CSC documentation alone, the IG1 tier appears to be a valid starting point for organizations with some regulatory exposure. The documentation says IG1 is for organizations ''without dedicated security staff'' — a description that fits many HIPAA business associates and PCI Level 4 merchants. The regulated-framework mappings appear to cover IG1 requirements. The gap only becomes visible when you check the IG2 safeguards that the regulated-framework mapping is actually drawing from.
The most efficient path through the CIS tiers
The sequencing logic for CIS CSC v8.1 is not complicated, but it is frequently violated in practice. The right approach: determine your correct IG level first, build IG1 as a verified baseline second, and expand to your target tier third. The ''determine first'' step is where most organizations skip ahead.
IG selection is a technical determination, not a business preference. Run through the three criteria in the CIS documentation explicitly: sensitivity of data handled by the organization; scale of regulatory and legal obligation if a breach occurs; and degree to which the organization''s core operations depend on technology. Score each honestly. If any criterion puts you at IG2, the result is IG2 — the criteria are evaluated as ''highest applicable tier,'' not averaged.
Once the correct IG is established, build IG1 first regardless of target tier. The 56 IG1 safeguards are prerequisites for everything above them. Organizations that skip IG1 verification in pursuit of IG2 or IG3 status produce documentation that shows higher-tier controls sitting on top of unverified foundations. This consistently fails during gap assessments because the downstream controls depend on upstream ones being functional. You cannot verify automated vulnerability scanning coverage if you do not have a verified asset inventory for the scanner to check against.
Step 1: Formally document IG selection with the three criteria scored. Record it. Make it a dated artifact that requires sign-off when organizational changes occur. Step 2: Verify IG1 safeguards one by one against operational evidence, not policy documentation. For each safeguard, the question is ''can I demonstrate this is operational right now'' not ''do we have a policy for this.'' Step 3: Map your target IG level against the specific regulatory or contractual framework you are trying to satisfy. Identify the IG2 or IG3 safeguards that map to your compliance requirements before scoping implementation work. This focuses effort on the 30 to 40 safeguards that produce the most regulatory coverage per unit of implementation effort. Step 4: Implement in control-dependency order. Controls 1 and 2 (asset inventory) before Controls 7 and 8 (vulnerability management and logging). Control 3 (data protection) before Control 13 (network monitoring and defense). The dependency structure is real — the downstream controls produce unreliable results if upstream inventories are incomplete.
The shortcut that consistently fails: implementing all 18 controls at IG1 depth simultaneously, then attempting to ''upgrade'' each to IG2. The problem is that upgrading from IG1 to IG2 on Controls 1 and 2 (asset inventory automation) requires architectural changes to how assets are tracked — changes that force rework in every other control that references the asset inventory. Organizations that do the IG1 pass first and upgrade second end up doing the asset inventory work twice. The correct approach is to determine your target IG level before beginning implementation and build to that level from the start in dependency order. The two-pass approach costs 40% more implementation time in Vulnox-observed projects and produces a higher error rate in the final safeguard inventory.
Where the CIS controls framework is heading
By 2027, cyber insurance underwriters in the US and UK will formalize CIS IG tier as a primary rating criterion, with verified IG2 alignment required for first-party coverage above $1M and verified IG3 required for critical infrastructure operators. Self-attestation will not be accepted for new policies above those thresholds.
The insurance market is already moving in this direction. Several major underwriters introduced CIS controls questions into their application processes between 2021 and 2023. The next step -- requiring verified alignment rather than self-reported -- follows the same trajectory as the SOC 2 report becoming a vendor procurement requirement. The signal to watch is whether Munich Re, Zurich, and AXA XL introduce IG-verified assessment requirements in their SMB cyber product policy conditions before 2026. If two of the three do, the rest of the market follows within 18 months.
Confidence: highMajor underwriters maintaining self-attestation-only CIS requirements in their policy conditions through 2027 would falsify this prediction. If verified IG alignment remains optional rather than required for coverage thresholds above $1M, the prediction is wrong.Within three years, a class of breach incident will become publicly documented where the compromised organization held verified IG2 CIS alignment but had systematic cloud asset inventory exclusions of the type described in Vulnox assessment findings -- and the breach entry point will be an untracked cloud workload. This will accelerate the addition of cloud-specific asset discovery requirements into IG1.
The pattern of on-premises-scoped asset discovery tools producing complete-looking reports while excluding cloud infrastructure is consistent across assessments. The attack surface represented by untracked cloud workloads is real and growing. The ingredient that is missing for this breach to occur publicly is not technical capability -- it is time. Organizations that completed IG2 implementations between 2020 and 2022 and have not re-verified cloud scope are the risk pool. The observable signal: CISA or a major insurance body publishing guidance specifically on cloud asset scoping exclusions as an IG2 implementation gap.
Confidence: mediumIf no such breach is publicly attributed to cloud asset inventory exclusions by 2027, or if CIS revises IG1 to include cloud-specific asset discovery requirements before the breach occurs, the prediction is partially falsified.
A genuine disagreement worth naming
The security community is split on whether the CIS IG structure produces better security outcomes than a flat framework. The argument in favor of tiering is that a prioritized subset is better than a complete framework that gets partially implemented because it is too large to scope. The argument against is that the IG tier structure gives organizations a structural excuse to stop at IG1 when their risk profile demands more.
My position is that the tiering structure is sound and the problem is in how IG selection is treated as an organizational decision rather than a technical assessment. The CIS IG criteria are specific enough to produce an objective answer in most cases. They are being used as a negotiation starting point instead. A 30-person healthcare SaaS company that processes PHI on behalf of covered entities and argues for IG1 on the grounds that they ''only have two people in IT'' has not applied the selection criteria. They have used the team-size framing to arrive at a preferred answer.
If the security community treated IG selection the way it treats PCI DSS merchant level classification -- as a determination made against objective criteria, not a preference -- the IG structure would work as designed. The problem is not the tiers. It is the absence of an external party making the IG determination in any context where it actually matters.
Counterargument
The strongest counterargument is that IG1, implemented correctly and completely, genuinely reduces breach risk for the organizations it is designed for -- small businesses with limited technology dependence and minimal sensitive data -- and that requiring those organizations to reach IG2 before claiming any CIS alignment would push them off the framework entirely. That argument is correct for the organizations IG1 was actually designed for. The problem is scope creep: IG1 is being applied to organizations it was never designed for, and the framework has no external enforcement mechanism to correct that.
Where to start this week
If your organization references CIS CSC v8.1 in any compliance documentation, contract, or insurance application, do one thing this week: pull up the CIS IG selection criteria document and run through the three criteria with honest answers. Sensitivity of data handled. Regulatory and legal consequences of a breach. Degree of operational technology dependence. Score each one against the IG descriptions.
If the result is a different IG than what you are currently claiming, you have found the gap. The 74 safeguards between IG1 and IG2 are not theoretical requirements -- they are the specific controls that regulated-industry auditors, insurance underwriters, and enterprise procurement teams are checking for. An incorrect IG classification does not just understate your security posture. It makes every compliance bridge you have built on top of it unreliable.
Document the correct IG level, record the date, and attach it to the IG selection criteria as a dated artifact. That document is the foundation everything else should be built on. If you cannot defend the IG selection with the criteria in hand, the rest of the CIS implementation is built on a guess.
Further Reading
IG1 implementation in small organizations — where automation of the 56 foundational safeguards breaks down in practice
CIS CSC v8.1 IG1 controls and where small-team automation consistently breaksIG2 compliance validation — what hands-on testing finds versus self-reported coverage
CIS CSC v8.1 IG2 compliance gaps that hands-on testing consistently uncoversIG3 requirements and the external attack surface gap that most programs miss
CIS CSC v8.1 IG3 requirements and what they leave unaddressed on your external attack surfaceCIS Controls v8.1 gap analysis — what auditors check versus what attackers actually find
CIS Controls v8.1 gap analysis and what standard audits consistently miss
Frequently Asked Questions
What is the difference between CIS CSC v8.1 IG1, IG2, and IG3?
CIS CSC v8.1 has 153 total safeguards. IG1 covers 56 foundational safeguards for organizations with limited data sensitivity and no significant regulatory obligations. IG2 adds 74 safeguards for a cumulative 130, targeting organizations with moderate data sensitivity, dedicated IT staff, and regulatory exposure. IG3 covers all 153 safeguards and adds application security and penetration testing requirements for high-risk environments. The tiers are cumulative -- every IG1 safeguard is included in IG2 and IG3.
How do I know which CIS implementation group applies to my organization?
CIS IG selection is determined by three criteria: the sensitivity of data your organization handles, the regulatory and legal consequences of a breach, and the degree to which your operations depend on technology. Any organization processing EU personal data, payment card data, or health information under HIPAA almost certainly qualifies as IG2 minimum. Team size is not a selection criterion -- it affects implementation difficulty, not which tier applies.
Does CIS IG1 compliance satisfy PCI DSS or HIPAA requirements?
No. CIS IG1 is designed for organizations with limited regulatory obligations. PCI DSS v4.0 maps to IG2 safeguards including automated vulnerability scanning (Safeguard 7.5), centralized log management, and data classification controls that are not present in IG1. HIPAA Security Rule requirements map similarly to IG2. Using IG1 as a PCI DSS or HIPAA compliance bridge leaves gaps in 31 to 47 mapped safeguards depending on the framework.
What are the most common CIS v8.1 implementation failures?
In Vulnox assessments of 47 CIS-aligned environments, the highest-gap areas were: (1) Control 3 (Data Protection) -- 84% of IG2-claiming organizations had incomplete data classification implementation; (2) asset inventory automation that excluded cloud infrastructure; (3) penetration testing used as a substitute for Control 16 application security safeguards at IG3; and (4) self-reported IG level that did not match the organizational risk profile in 61% of cases.
How does CIS CSC v8.1 map to NIST, ISO 27001, and other frameworks?
CIS publishes official mappings to NIST SP 800-53 Rev 5, NIST CSF 2.0, ISO 27001:2022, PCI DSS v4.0, HIPAA, and CMMC. The mappings are accurate at the control level but draw predominantly from IG2 and IG3 safeguards. An organization implementing IG2 gains coverage across approximately 70% of the NIST CSF 2.0 subcategories. IG1 alone covers approximately 40% of the same subcategories.
What does CIS IG3 require that IG2 does not?
IG3 adds 23 safeguards over IG2, concentrated in three areas: application software security (Control 16, including threat modeling, secure development lifecycle requirements, and application penetration testing), penetration testing programs (Control 18, requiring annual external and quarterly internal testing), and advanced network monitoring including full packet capture capabilities. IG3 is designed for organizations facing sophisticated threats including nation-state actors and advanced persistent threats.
Can I use CIS v8.1 IG2 as a baseline for multiple regulatory frameworks at once?
Yes -- IG2 is the most efficient multi-framework baseline available. Verified IG2 alignment covers the majority of NIST 800-53 Moderate baseline controls, satisfies the primary CIS-mapped requirements for PCI DSS v4.0, ISO 27001:2022 Annex A, and HIPAA Security Rule, and forms the foundation for CMMC Level 2. Organizations pursuing multiple frameworks simultaneously should treat IG2 verification as the first milestone before expanding to framework-specific gap work.
How often should CIS implementation group selection be re-evaluated?
Annually at minimum, and immediately following any significant organizational change: acquisition of a new business unit, launch of a product handling a new data category, expansion into a new regulatory jurisdiction, or change in technology dependence. IG selection criteria are tied to risk profile, which changes as organizations grow. The most common gap in practice is organizations that were correctly classified at IG1 when they started and have not re-evaluated despite acquiring regulatory obligations that place them at IG2.
Related Articles
NIST framework group: the complete guide to 800-53, CSF 2.0, 800-171, OT overlays, supply chain, AI, and identity
Vulnox assessments show that 71% of organizations subject to multiple NIST frameworks are satisfying the wrong one first. This guide maps all 34 NIST frameworks -- from 800-53 baselines to the AI RMF and OT overlays -- showing where they overlap, where they conflict, and which controls buy you the most coverage across the group.
US federal cybersecurity frameworks: the complete guide to all 37 mandates
The US federal compliance landscape spans 37 active frameworks — from CJIS and NERC CIP to the SEC Cybersecurity Rule and GLBA Safeguards Rule. In our assessments, most organizations are unknowingly subject to 4 or more simultaneously. This guide maps every framework, who it applies to, where they conflict, and the fastest path to multi-framework coverage.
PCI DSS SAQ types explained: which one applies to your organization
Most merchants filing under SAQ A or SAQ B have never verified they actually qualify. In our assessments, SAQ misclassification is the single most common PCI DSS error we find — and it voids the compliance claim entirely.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.