CIS Controls v8 and Framework Mapping

Every compliance framework tells you what to protect. CIS Controls v8 tells you how, in what order, and at what maturity level. That distinction makes CIS the most useful starting point for a GRC Engineer who needs to translate audit requirements into actual implementation work.

This lesson covers two things: the CIS Controls themselves, and the practice of mapping a single technical control across multiple frameworks so you implement once and satisfy many.

CIS Controls v8

The Center for Internet Security (CIS) publishes a set of 18 prioritized security control families. Unlike SOC 2 (which describes trust service criteria at a high level) or NIST CSF (which organizes security into abstract functions), CIS Controls are prescriptive. They tell you what to do, roughly how to do it, and which controls matter most based on your organization's size and risk profile.

Version 8, released in 2021 and still the current version, restructured around three ideas:

1. Activities, not devices. Earlier versions organized controls by asset type (network devices, endpoints, applications). v8 organizes by what you're doing — inventorying assets, managing software, controlling access, protecting data.

2. Implementation Groups (IGs). Not every company needs every control. CIS defines three tiers:

   • IG1 (Essential Cyber Hygiene): 56 safeguards. The baseline for any organization. Small companies with limited IT staff start here. Think of IG1 as "if you do nothing else, do these."
   • IG2 (Mid-size / moderate risk): 74 additional safeguards (130 total). Organizations with dedicated IT staff, some compliance obligations, and data that attackers would specifically target.
   • IG3 (Mature / high risk): 23 additional safeguards (153 total). Regulated industries, organizations handling sensitive data at scale, companies with dedicated security teams.

3. Safeguards, not sub-controls. Each control family contains numbered safeguards — specific, actionable items. CIS Control 6 (Access Control Management) has 8 safeguards. CIS Control 3 (Data Protection) has 14.

The IG model is why GRC Engineers care about CIS. When an auditor asks "show me your access controls," CIS gives you a checklist. When your CEO asks "are we doing enough for our size?", the IG mapping gives you a defensible answer.

CIS Controls v8 — 18 Families
════════════════════════════════════════════════════════════════

Control                                        IG1    IG2    IG3
──────────────────────────────────────────────  ─────  ─────  ─────
 1. Inventory of Enterprise Assets              ●      ●      ●
 2. Inventory of Software Assets                ●      ●      ●
 3. Data Protection                             ●      ●      ●
 4. Secure Config of Enterprise Assets          ●      ●      ●
 5. Account Management                          ●      ●      ●
 6. Access Control Management                   ●      ●      ●
 7. Continuous Vulnerability Management         ●      ●      ●
 8. Audit Log Management                        ●      ●      ●
 9. Email & Web Browser Protections             ●      ●      ●
10. Malware Defenses                            ●      ●      ●
11. Data Recovery                               ●      ●      ●
12. Network Infrastructure Management                  ●      ●
13. Network Monitoring & Defense                       ●      ●
14. Security Awareness & Skills Training        ●      ●      ●
15. Service Provider Management                        ●      ●
16. Application Software Security                      ●      ●
17. Incident Response Management                ●      ●      ●
18. Penetration Testing                                ●      ●

● = at least one safeguard in this family applies at that IG level
IG1: 56 safeguards  │  IG2: +74 (130 total)  │  IG3: +23 (153 total)

Notice the pattern: Controls 1-11, 14, and 17 all have IG1 safeguards. These are the non-negotiables. Controls 12, 13, 15, 16, and 18 kick in at IG2 — they assume you have dedicated staff to manage network infrastructure, monitor for threats, vet vendors, secure custom applications, and run penetration tests.

For a GRC Engineer at a Series A startup, IG1 is the implementation target. For a Series C company pursuing SOC 2 Type II and selling to enterprise, IG2 coverage is the expectation. IG3 maps to regulated industries — financial services, healthcare, defense contractors.

Why framework mapping matters

Here's the reality of GRC work: your company doesn't get audited against one framework. A typical B2B SaaS in 2026 needs SOC 2 for enterprise sales, ISO 27001 for European customers, and uses NIST CSF as an internal security maturity model. Some also map to CIS Controls because their security team finds them more actionable.

Each framework has its own numbering scheme, its own language, and its own auditors. But the underlying technical controls are largely the same. MFA enforcement is MFA enforcement regardless of which framework's auditor is asking about it.

The problem: without a mapping, you end up doing redundant work. One team writes a SOC 2 narrative about MFA. Another team prepares ISO 27001 evidence for the same MFA configuration. A third team documents the same thing for NIST. Three times the documentation, three times the evidence gathering, same Okta policy underneath.

Framework mapping eliminates that redundancy. You map each technical control to every framework requirement it satisfies, implement it once, and pull evidence once per audit cycle.

Take MFA enforcement as a concrete example. You configure Okta to require phishing-resistant MFA for all users. That single configuration satisfies requirements across four major frameworks:

┌──────────────────────────────────┐
                  │     Technical Control:            │
                  │     MFA enforcement via Okta      │
                  │     (phishing-resistant, all      │
                  │      users, all applications)     │
                  └──────────────┬───────────────────┘
                                 │
            ┌────────────────────┼────────────────────┐
            │                    │                     │
   ┌────────┴────────┐  ┌───────┴────────┐  ┌────────┴────────┐
   │                 │  │                │  │                 │
   │  SOC 2          │  │  ISO 27001     │  │  NIST CSF       │
   │  CC6.1          │  │  A.8.5         │  │  PR.AC-7        │
   │                 │  │  (was A.9.4.2  │  │                 │
   │  "Logical       │  │   in 2013)     │  │  "Users,        │
   │  access         │  │                │  │  devices, and   │
   │  security       │  │  "Secure       │  │  other assets   │
   │  software,      │  │  authentication│  │  are            │
   │  infrastructure │  │  technologies  │  │  authenticated" │
   │  and            │  │  and           │  │                 │
   │  architectures" │  │  procedures"   │  │                 │
   │                 │  │                │  │                 │
   └─────────────────┘  └────────────────┘  └─────────────────┘
            │                                         │
            │            ┌───────────────┐            │
            │            │               │            │
            └────────────┤  CIS Control  ├────────────┘
                         │  6.3          │
                         │               │
                         │  "Require MFA │
                         │  for          │
                         │  externally-  │
                         │  exposed      │
                         │  applications"│
                         │               │
                         │  (IG1)        │
                         └───────────────┘

   Evidence: Okta system log export, conditional access policy
   config, authentication policy screenshot, CloudTrail IdP events

One Okta configuration. One set of evidence artifacts. Four framework requirements satisfied. That is the leverage of framework mapping.

How mapping works in practice

At scale, GRC platforms handle this for you. Vanta, Drata, Anecdotes, and similar tools ship with pre-built mappings between major frameworks. You connect your cloud accounts and identity providers, the platform pulls evidence, and it automatically maps each piece of evidence to the relevant controls across all your active frameworks.

But those platforms have limits. They cover common controls well — access management, encryption, logging — but struggle with company-specific implementations. Custom data classification schemes, internal API security controls, ML model governance, anything that doesn't fit a vendor's template still requires manual mapping.

For smaller companies or teams just starting out, the GRC Engineer maintains the mapping directly. The simplest version is a spreadsheet with columns for each framework:

The key insight behind this table: implement the control once, map it to N frameworks, provide evidence once per audit cycle. A Terraform module that enforces disk encryption on all EC2 instances doesn't need to be different for SOC 2 versus ISO 27001. The evidence artifact — a Terraform plan showing the encryption configuration — satisfies both.

As the mapping matures, the spreadsheet often becomes a YAML or JSON file in version control, managed alongside the infrastructure code. Some teams build it into their CI pipeline: a control change triggers an update to the mapping, which triggers a re-pull of evidence. That's the GRC Engineering end state — controls, mappings, and evidence all living in the same codebase, versioned together.

Common pitfalls

Framework mapping sounds straightforward. In practice, three mistakes derail it repeatedly.

Mapping too loosely

The temptation is to map broadly. "Our logging infrastructure" satisfies all logging-related controls across all frameworks. That works until an auditor drills in and asks: "CC7.2 requires you to detect anomalies in log data. Your CloudWatch setup collects logs, but where's the anomaly detection?"

Loose mappings create false confidence. Each mapping should connect a specific technical implementation to a specific framework requirement, and the evidence should demonstrate that the implementation actually satisfies the requirement's intent — not just its topic area.

Mapping too granularly

The opposite mistake: splitting controls so finely that the mapping becomes unmanageable. If you create separate control entries for "MFA on AWS console," "MFA on Okta dashboard," "MFA on GitHub," and "MFA on Datadog," you've turned one control (MFA enforcement) into four. Each needs its own evidence, its own review cycle, its own audit narrative.

The right granularity is usually at the policy level. If a single Okta authentication policy enforces MFA across all integrated applications, that's one control. If you have separate MFA configurations per application with different settings, those might genuinely be separate controls.

Not maintaining the mapping

Mappings rot. Your team adds a new SaaS tool and forgets to add it to the access control mapping. Someone refactors the Terraform modules and the old module names in the mapping no longer exist. A framework releases a new version (ISO 27001:2022 renumbered most of Annex A) and the mapping still references the old control IDs.

The fix is treating the mapping as code. Store it in version control. Review mapping changes in pull requests alongside the infrastructure changes that triggered them. Run periodic reconciliation — at minimum, before each audit cycle — to verify that every mapped control still points to a real, current implementation.

Putting it together

CIS Controls give you the most prescriptive answer to "what should we implement." Framework mapping gives you the multiplier — implement once, satisfy many. Together, they form the backbone of a GRC Engineer's planning process:

1. Assess your IG level. What Implementation Group fits your organization's size, risk, and regulatory obligations?
2. Inventory your frameworks. Which frameworks do your customers, regulators, or board require?
3. Map CIS safeguards to framework requirements. CIS publishes official mappings to NIST CSF and ISO 27001. Community-maintained mappings to SOC 2 exist and are reasonably mature.
4. Prioritize implementation. Start with IG1 safeguards that map to the most framework requirements. That's your highest-leverage work.
5. Build the evidence pipeline. For each mapped control, define what evidence proves the control is operating effectively, and automate its collection.

The previous lesson in this module walked through the major frameworks individually: SOC 2, ISO 27001, and NIST CSF. The framework one-pager that follows puts them side by side for quick reference. The mapping skill you've just learned is what ties them all together.