CIS Controls, in the order that matters.
The value of the CIS Controls is not the list — it is the ordering, and the Implementation Groups that tell you how far along it you need to go. Which is exactly the question an organisation with a new AI estate and a finite security budget is actually asking.
What are the CIS Controls?
A prioritised set of defensive actions maintained by the Center for Internet Security. Version 8 organises them into 18 controls and 153 safeguards, grouped into three Implementation Groups so an organisation can tell which subset applies to it. Voluntary, widely mapped to other frameworks, and unusually opinionated about sequence.
- Version CIS Controls v8 Reorganised from v7.1 by activity rather than by who manages the device.
- Structure 18 controls, 153 safeguards Safeguards are what v7.1 called sub-controls.
- Scoping Three Implementation Groups IG1 is the floor for everyone; IG2 and IG3 add depth.
- Status Voluntary No certification. Frequently used as the implementation layer under CSF or ISO.
Why implement CIS Controls?
Because a new AI estate almost always fails the first two controls, and everything downstream depends on them.
- Nobody has the inventory Models arrive through product teams rather than procurement. The asset list is the highest-value artefact and it usually does not exist.
- It answers "what first" The prioritisation is the product. Most frameworks tell you what good looks like; this one tells you the order to build it in.
- It maps to everything else Published mappings to CSF, ISO 27001 and others make it a practical layer under a framework rather than a competitor to one.
- Budget is finite Implementation Groups give an honest answer to "is this enough" without requiring a maturity model nobody believes.
- Benchmarks come with it CIS also publishes configuration benchmarks per technology, which turn Control 4 from a principle into a checklist.
How iDharma supports CIS Controls
Assessed in the framework's own order, with the AI estate treated as in scope rather than as an annex.
| Control area | What the review does |
|---|---|
| Asset and software inventory | Every model, endpoint, notebook environment and pipeline listed with an owner — the artefact every other control is scoped from. |
| Data protection | Training corpora, retrieval indexes, prompt and response logs and evaluation sets, classified before they are controlled. |
| Secure configuration | Model serving, notebooks and pipelines against a hardened baseline rather than a default. Prompt logging in particular deserves a decision. |
| Account and access management | Who can read training data, launch a fine-tune and change production inference — reviewed against the current team, not the one that set it up. |
| Vulnerability and patching | The ML stack included, which it usually is not, along with the third-party components inside your own applications. |
| Audit log management | Whether AI systems log usefully, whether logs are retained, and whether anyone reads them. |
| Service provider management | Model and cloud providers as providers, with the contract terms and ongoing review that implies. |
| Incident response | Whether the plan covers an AI-specific incident and whether anyone has exercised it. |
The CIS Controls sit under a framework rather than beside one. Use CSF or ISO 27001 to decide which outcomes matter, and CIS to decide what to build first.
What the assessment produces
Six areas, each delivering an artefact rather than an opinion.
Asset inventory and management
Everything else is scoped from this
Models, endpoints, notebooks, pipelines and the vendors behind them, each with a named owner. Expect the list to be larger than predicted — it always is.
Vulnerability management
Including the ML stack
Scanning cadence, remediation priority and whether the pipeline components and model-serving layer are inside the programme or quietly outside it.
Access control and authentication
The broadest gap
Account inventory, multi-factor coverage, privileged separation, and whether access to training data and weights reflects the team you have now.
Security monitoring and logging
Both halves
What is captured, how long it is kept, and whether anyone reads it. Logging nobody reads is storage, not a control.
Incident response and recovery
Exercised, not scheduled
A plan that covers AI-specific incidents, named responders, and a restoration path that has been tested rather than diagrammed.
Policy and compliance tracking
Mapped, not duplicated
Safeguards mapped across to CSF and ISO 27001 so one body of evidence answers several asks instead of three overlapping programmes.
Complete CIS Controls v8 safeguards coverage
All eighteen controls, assessed in the framework's own order and scoped to the Implementation Group you choose.
- 1–2 Asset and software inventory Where every AI estate fails first
- Covered by the assessment
- 3–4 Data protection and configuration Classify, then harden
- Covered by the assessment
- 5–6 Account and access management Who exists, and what they can reach
- Covered by the assessment
- 7–8 Vulnerability and audit logs Find it, and be able to see it
- Covered by the assessment
- 9–11 Email, malware and recovery The defences and the way back
- Covered by the assessment
- 12–13 Network infrastructure and defence The layer nobody owns
- Covered by the assessment
- 14–15 Training and service providers People, and the people you buy from
- Covered by the assessment
- 16–18 Applications, response and testing Build, react, and check
- Covered by the assessment
Asset inventory tracking
The AI estate enumerated first, because every other safeguard is scoped from a list that usually does not exist yet.
Vulnerability management
The ML stack inside the scanning programme rather than outside it, which is where we normally find it.
Incident response
A plan that covers a model failing quietly as well as a system failing loudly.
Multi-framework mapping
Safeguards tagged to CSF and ISO 27001, so one assessment answers more than one question.
18 CIS Critical Security Controls
Prioritised, and the priority is the point: inventory before configuration, configuration before defence, defence before testing. A page that reorders them for visual balance loses the one thing the framework is actually selling.
Inventory and control of enterprise assets
You cannot protect what you have not listed
- Active discovery of connected devices
- An asset register that is maintained, not refreshed annually
- Unauthorised assets addressed rather than logged
Inventory and control of software assets
Including what nobody approved
- Authorised software inventory
- Unsupported software identified and removed
- Allowlisting where the environment permits it
Data protection
Classify, then control
- Data inventory and classification
- Access control lists by sensitivity
- Encryption at rest and in transit
- Retention and disposal that actually runs
Secure configuration of assets and software
Defaults are not a baseline
- A hardened baseline per platform
- Configuration drift detected
- Default credentials removed at build
Account management
Who exists, and why
- Inventory of accounts including service accounts
- Dormant accounts disabled
- Administrative accounts separated from daily use
Access control management
What those accounts can reach
- Access granted and revoked by process
- Multi-factor authentication where it matters
- Role-based access reviewed against the current team
Continuous vulnerability management
Finding is half; fixing is the half that counts
- Automated scanning on a defined cadence
- Remediation prioritised by exposure
- Patch process with owners and deadlines
Audit log management
Both halves: capture and read
- Logging enabled and centrally collected
- Retention set deliberately
- Review that a person actually performs
Email and web browser protections
Where most intrusions still begin
- Supported browsers and clients only
- DNS filtering and URL protection
- Attachment and content controls
Malware defences
Deployed, updated, and monitored
- Anti-malware on assets that can carry it
- Signatures and behaviour rules current
- Autorun and removable media controlled
Data recovery
Backups you have actually restored from
- Automated backups on a defined schedule
- Backups protected and isolated
- Restoration tested rather than assumed
Network infrastructure management
The layer nobody owns
- Network devices kept current
- Secure network architecture documented
- Management traffic separated
Network monitoring and defence
Would anything notice?
- Traffic monitoring at boundaries
- Intrusion detection and alerting
- Alerts that reach someone who acts
Security awareness and skills training
Role-appropriate, and evidenced
- Awareness programme with attendance recorded
- Role-specific training for privileged staff
- Content refreshed against real incidents
Service provider management
New prominence in v8, and rightly so
- Inventory of providers holding or processing data
- Security requirements in the contract
- Ongoing review rather than one-off diligence
Application software security
Including the software you bought
- Secure development process
- Third-party component inventory
- Vulnerability handling for your own applications
Incident response management
A plan, and people who have used it
- Designated personnel and contact routes
- Documented process and escalation
- Exercises run rather than scheduled
Penetration testing
The check on everything above it
- A programme with defined scope
- Findings tracked to remediation
- Retest to confirm the fix held
Implementation Groups explained
The framework's own answer to "is this enough". Pick one deliberately and write down why — that reasoning is what a supervisor or a customer will actually probe.
Essential cyber hygiene
The floor for every organisation
- Limited IT and security expertise
- Data sensitivity is low to moderate
- Main concern is keeping the business running
- For a small AI estate this is often the whole realistic target for year one
- Every safeguard here is expected of everyone
Managed
Where most funded teams belong
- Dedicated people responsible for security
- Data whose loss would be materially damaging
- Multiple departments with differing risk profiles
- Regulatory or contractual obligations in play
- Includes everything in IG1
High assurance
Chosen rarely, and defensibly
- Security experts across specialised functions
- Data whose loss carries public consequence
- Facing targeted rather than opportunistic attackers
- Availability and integrity are the primary concerns
- Includes everything in IG1 and IG2
The group is a decision, not a discovery. IG1 is the floor for everyone. Beyond that it is a judgement about the data you hold and who might want it — and it should be recorded as a decision rather than drifted into.
CIS Controls v8 vs v7.1
What changed in the v8 reorganisation, and why it matters for anyone whose environment is now mostly cloud and mostly somebody else's hardware.
| v8 | v7.1 | |
|---|---|---|
| Number of controls | 18 | 20 |
| Terminology | Safeguards | Sub-controls |
| Organising principle | By activity | By who manages the device |
| Cloud and mobile | Addressed throughout | Largely implicit |
| Service providers | Its own control | Distributed across others |
| Boundary defence | Folded into network monitoring and defence | A separate control |
| Implementation Groups | Central to scoping | Introduced, less prominent |
The reorganisation matters most if your v7.1 programme was structured around device ownership. In an environment where the assets are containers, managed services and hosted models, organising by activity is the change that makes the framework usable again.
36-week implementation roadmap
A sequence that follows the framework's own priority rather than a calendar. The weeks are elapsed position, not effort — and phases overlap in practice.
-
Weeks 1–8
Foundation
Controls 1–6: list it and lock it
- Inventory enterprise and software assets
- Classify data including prompts and logs
- Establish hardened configuration baselines
- Account inventory and access review
- Choose and record the Implementation Group
-
Weeks 9–18
Core defence
Controls 7–11: find, see and survive
- Vulnerability scanning on a cadence
- Centralised logging with retention set
- Email and browser protections
- Malware defences deployed and monitored
- Backups tested by restoring from them
-
Weeks 19–28
Advanced protection
Controls 12–15: network, people, suppliers
- Network infrastructure brought current
- Monitoring that produces actionable alerts
- Awareness training with attendance recorded
- Service provider inventory and contract terms
- Model and cloud providers assessed as providers
-
Weeks 29–36
Maturity and validation
Controls 16–18: build, react, check
- Secure development for the ML pipeline
- Incident response exercised, not scheduled
- Penetration testing with findings tracked
- Retest to confirm remediation held
- Re-assess against the chosen group
CIS Benchmarks integration
The Controls tell you to harden your configuration. The Benchmarks tell you what hardened looks like for a specific technology — which is what turns Control 4 from a principle into a checklist.
Operating systems
The oldest and deepest coverage
Server and desktop platforms with detailed configuration guidance, including the base images your model-serving containers are built from.
Cloud platforms
Where the AI estate actually lives
Provider-specific guidance covering identity, storage, networking and logging — the settings most likely to be left at their defaults in a fast-moving ML environment.
Network devices
The layer nobody owns
Configuration guidance for the infrastructure between your users and your services, which is rarely in the same team's remit as the models.
Databases
Including vector stores
Guidance for common database platforms. Retrieval indexes and feature stores deserve the same treatment even where a specific benchmark does not yet exist.
Applications and servers
Web and middleware
Configuration for the application and server software in front of your models, which is where an exposed inference endpoint usually turns out to live.
Mobile devices
The endpoint you do not control
Guidance for mobile platforms, relevant wherever staff reach model tooling or production data from a device the organisation does not own.
Benchmarks are separate from the Controls and complementary to them. The Controls set the objective; a benchmark gives you a settings list you can actually apply and audit against.
Complete security policy repository
Ready-to-use templates aligned to the CIS Controls, with mapping across to NIST CSF and ISO 27001 so one set of documents answers more than one question.
Asset management
- Asset Inventory Standard
- Software Inventory & Allowlisting
- Data Classification Policy
- Secure Configuration Baseline
- Change Control Procedure
- Decommissioning Standard
+ 4 more policies
Access & protection
- Account Management Policy
- Access Control Standard
- Multi-Factor Authentication Standard
- Privileged Access Procedure
- Encryption Standard
- Service Provider Security Terms
+ 3 more policies
Monitoring & response
- Audit Log Management Standard
- Vulnerability Management Procedure
- Incident Response Plan
- Backup & Recovery Standard
- Penetration Testing Programme
- Security Awareness Plan
+ 4 more policies
Frequently asked questions
What comes up in every CIS Controls scoping call.
Are the CIS Controls mandatory?
No. They are voluntary and carry no certification. What they carry instead is a defensible order of work, which is why they are frequently adopted underneath a framework that does get named in contracts.
Are they a replacement for ISO 27001 or NIST CSF?
No — they sit underneath one. A framework tells you which outcomes matter; the CIS Controls tell you what to build and in what order. Organisations that adopt only the Controls tend to have good hygiene and no governance story; those that adopt only a framework tend to have the reverse.
Which Implementation Group should we target?
IG1 is the floor for everyone. Beyond that it is a judgement about the data you hold and who might want it, and it should be recorded as a decision rather than drifted into. Most funded AI teams land at IG2.
Is there a certification?
No, which makes the Controls excellent as an internal engineering agenda and useless as a customer-facing claim. Pair them with something certifiable if you need the latter.
What changed between v7.1 and v8?
Twenty controls became eighteen, sub-controls became safeguards, and the whole set was reorganised by activity rather than by who manages the device. Cloud and mobile are addressed throughout, service provider management became its own control, and boundary defence was folded into network monitoring and defence.
Do we have to implement all 153 safeguards?
Only if you are targeting IG3. The Implementation Groups exist precisely so that a smaller organisation has a defensible subset rather than an unachievable list. What you cannot do is pick safeguards individually to suit what you have already built.
How do the Controls relate to CIS Benchmarks?
They are separate and complementary. Control 4 says configure securely; a Benchmark tells you what that means for a specific platform, as a settings list you can apply and audit against.
Why does inventory matter so much for AI?
Because AI systems arrive through product teams rather than procurement, so the security function usually has no list. Every subsequent control is scoped from that list, which means an incomplete inventory silently caps the effectiveness of everything else.
What is the most common finding?
Prompt and response logs holding sensitive data — created by a default setting, retained indefinitely, classified never, and reachable by more people than anyone expects. It is a five-minute configuration decision that nobody was asked to make.
Are model weights covered by these controls?
They should be. Weights are an enterprise asset under Control 1 and data under Control 3, and they are frequently expensive to produce, valuable to an attacker, and stored under controls designed for build artefacts rather than for crown jewels.
Do the Controls cover AI-specific risks like prompt injection?
Not by name, and mostly by substance. Untrusted input reaching a system that can call tools or read data is an access-control and application-security problem; the novelty is the channel, not the category. What the Controls will not give you is the model-behaviour side — that is what NIST AI RMF is for.
Ready to secure the AI estate?
Inventory, classification, configuration, access and logging — in the order that finishes rather than the order that stalls.
This page is guidance on how we scope an assessment, not legal advice.