A CIS classification that helps organisations stage control adoption based on risk and available resources. IG1, IG2, and IG3 are not maturity labels. They are rollout guides that help teams decide which safeguards are reasonable to implement first and how far to expand over time.
Expanded Definition
An Implementation Group is a staged rollout lens, not a scorecard. In the CIS Controls model, IG1, IG2, and IG3 help organisations choose safeguards that fit their risk exposure, operational complexity, and available resources. The classification is often used to separate “what to do first” from “what to do eventually,” which is why it is useful for planning, budgeting, and sequencing control adoption.
Usage varies across vendors and advisory content, but the core idea is consistent: IG1 focuses on foundational protection, IG2 expands into broader and more targeted controls, and IG3 supports the most rigorous environments. That staging concept aligns well with the NIST Cybersecurity Framework 2.0, which also encourages outcome-based prioritisation rather than checklist-only compliance. For identity-heavy environments, the same logic often determines when teams move from basic inventory and credential hygiene to stronger governance for NHIs and privileged access. The most common misapplication is treating IG levels as maturity rankings, which occurs when organisations present IG2 or IG3 as proof of overall cyber maturity rather than as a deployment guide.
Examples and Use Cases
Implementing CIS guidance rigorously often introduces sequencing constraints, requiring organisations to balance immediate risk reduction against staffing, tooling, and change-management capacity.
- A small organisation starts with IG1 to lock down asset inventory, baseline logging, and credential controls before taking on broader hardening work.
- A mid-sized enterprise uses IG2 to prioritise protections for exposed systems, remote access, and sensitive data paths once foundational safeguards are stable.
- A heavily regulated business maps IG3 to high-value systems that support critical operations, where stronger segmentation, monitoring, and recovery planning are justified.
- An NHI programme uses staged adoption to first inventory service accounts, then rotate secrets, then add policy enforcement around high-risk automation. The Ultimate Guide to NHIs is useful here because it highlights how quickly unmanaged service accounts can outgrow manual processes.
- A security team aligns roadmap decisions to the control baseline expected for the organisation’s exposure profile rather than trying to implement every safeguard at once.
In practice, IGs are most helpful when paired with authoritative guidance such as the NIST Cybersecurity Framework 2.0, which helps teams translate broad priorities into operational outcomes.
Why It Matters for Security Teams
Implementation Groups matter because they prevent two common failures: overcommitting to controls the organisation cannot sustain, or underinvesting until an avoidable incident forces action. For security teams, the value is practical. IGs help define sequencing for logging, access control, secret handling, endpoint visibility, and response readiness without confusing adoption order with assurance.
That distinction becomes especially important in NHI governance. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, and only 20% have formal processes for offboarding and revoking API keys. Those conditions make a “build everything at once” approach unrealistic, but they also make “do the minimum forever” dangerous. A staged implementation plan lets teams reduce the highest-risk exposure first, then expand coverage as operational maturity improves. The Ultimate Guide to NHIs is a strong reference point for understanding why privilege, rotation, and visibility often need to be phased rather than bolted on after the fact.
Organisations typically encounter the limits of their chosen Implementation Group only after an audit finding, a breach, or an overwhelmed operations team makes the gap impossible to ignore.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-1 | Risk-informed prioritisation matches the staged adoption logic behind Implementation Groups. |
| OWASP Non-Human Identity Top 10 | NHI governance benefits from phased rollout of inventory, rotation, and privilege reduction. | |
| NIST SP 800-53 Rev 5 | RA-2 | Security categorisation supports deciding which safeguards fit each implementation phase. |
Stage NHI controls so the highest-risk identities are remediated before broader coverage.
Related resources from NHI Mgmt Group
- How should security teams split identity governance from implementation work?
- How should security teams plan an IAM implementation for non-human identities?
- Why do non-human identities complicate least-privilege implementation?
- What breaks when a custom SSO implementation is too tightly coupled to tenant-specific IdP settings?
