For years, security teams have approached security controls with a familiar formula:
Select the benchmark → assess the environment → identify failures → remediate → report compliance.
It is structured. It is measurable. It is auditable.
But there is a problem.
A compliance percentage can tell us how many controls passed. It does not necessarily tell us whether we have reduced the risks that matter most to the business.
An organization can be 90% compliant and still have a handful of control gaps exposing its most critical business services.
Conversely, an organization can have a lower compliance score while the remaining deviations exist on low-risk assets, are covered by compensating controls, or have been consciously accepted.
So perhaps the question we should be asking is not:
“How compliant are we?”
It should be:
“Which risks have we actually reduced through our control environment, and which material risks remain?”
That is where a risk-based approach to security controls begins.
The benchmark should be the starting point, not the destination
Take CIS as an example.
The CIS Benchmarks provide recognized secure-configuration guidance for technologies across the enterprise. That makes them extremely valuable as a control universe and security baseline.
But the mistake is turning the entire benchmark directly into a flat organizational checklist.
A control recommendation does not automatically mean that:
- it applies to every system,
- it has the same business importance everywhere,
- it carries the same urgency,
- it should be implemented in the same way,
- or its failure represents the same level of risk.
The benchmark tells us what good security configuration looks like.
Our environment determines what applies.
Our business determines what matters.
Our risk appetite determines what must happen first.
That distinction is fundamental.
Step 1: Start with the complete control universe
The first recommendation is simple:
Don’t cherry-pick controls.
Take the complete applicable CIS control/recommendation set for the technology and establish the control universe.
For every recommendation, capture the relevant context:
- Control ID
- Control objective
- Security rationale
- Threat addressed
- Technology dependency
- Asset applicability
- Business relevance
- Regulatory relevance
- Exposure
- Existing security controls
- Compensating controls
- Implementation complexity
- Operational impact
- Evidence requirements
- Control owner
At this stage, the objective is not to decide whether the organization passes or fails.
The objective is to understand what the control is actually trying to protect against.
Step 2: Evaluate every control with AI + Human Intelligence
This is where the traditional compliance model can evolve significantly.
Imagine hundreds of CIS recommendations being evaluated across thousands of systems.
Trying to perform that analysis entirely manually is difficult to scale.
AI can help.
For every control, AI can analyze:
What threat does this mitigate?
What attack technique does it disrupt?
What assets does it apply to?
What could happen if it is absent?
Are there dependencies?
Is there an equivalent control?
Is there a potential compensating control?
What additional context is required from a human reviewer?
But AI should not independently decide whether a control is mandatory.
That decision requires human intelligence.
Security architects understand architecture.
Infrastructure teams understand operational dependencies.
Application teams understand workload behavior.
Risk teams understand organizational risk appetite.
Compliance teams understand obligations.
Business owners understand business impact.
The strongest model therefore becomes:
AI for scale. Humans for context. Risk for decision-making.
Step 3: Determine applicability before determining compliance
This is one of the most important changes.
Don’t ask:
“Does the system comply with this control?”
Ask first:
“Does this control apply to this system?”
That creates three meaningful outcomes:
Applicable
The control applies and must be assessed.
Not Applicable
The control genuinely does not apply, with documented justification.
Compensating Control
The specific recommendation is not implemented exactly as prescribed, but an equivalent security mechanism provides appropriate protection.
Only after this determination should the organization calculate compliance.
This prevents a major weakness in traditional compliance reporting:
counting irrelevant or contextually protected controls as failures.
Step 4: Separate mandatory controls from good-to-have controls
Once applicability has been established, the next question is:
Which controls are non-negotiable?
I would recommend establishing two primary control classes.
Mandatory Controls
These are controls that must be implemented because failure creates unacceptable risk or because there is an explicit obligation.
Examples include controls driven by:
- Regulatory requirements
- Legal requirements
- Contractual requirements
- Internal security policy
- Critical business protection
- Critical attack paths
- Sensitive data protection
- Privileged access protection
- Material threat exposure
Non-Mandatory / Good-to-Have Controls
These controls still provide security value, but their immediate implementation may depend on:
- Asset criticality
- Threat exposure
- Architecture
- Operational impact
- Existing compensating controls
- Cost versus risk reduction
This doesn’t mean these controls can be ignored indefinitely.
It means they are prioritized according to risk reduction and business context.
Step 5: Apply implementation criticality
Now introduce a simple organizational priority model.
Mandatory → Critical
Good-to-have → High
Not Applicable → Excluded with documented justification
One recommendation here: call these implementation priorities, rather than technical severities.
A mandatory control may be “Critical” because of a regulatory requirement even if its direct exploitability is low.
Likewise, a high-severity technical weakness may not automatically justify the same priority across every environment.
This distinction makes the methodology more defensible.
The same control can represent very different risks
Consider two servers with the same failed CIS recommendation.
Technically, both have the same finding.
But now consider their environments.
Server A
It is internet-facing, supports a critical business application, contains sensitive information and has an attack path associated with active exploitation.
Server B
It is isolated, supports development activities, has no sensitive information and has no external exposure.
Same control.
Same failure.
Very different risk.
If we assign identical remediation priority simply because the benchmark identifies the same failure, we are optimizing for control closure.
If we consider asset criticality, exposure, threat activity and business impact, we are optimizing for risk reduction.
That is the difference.
This thinking should extend to vulnerability management
The same principle applies to vulnerabilities.
Suppose the organization has:
2,400 open vulnerabilities.
That number sounds alarming.
But it does not tell leadership where the material risk is.
Instead, connect:
Asset criticality
→ Exposure
→ Vulnerability severity
→ Exploitability
→ Active threat activity
→ Business impact
→ Existing controls
→ Residual risk
→ Remediation priority
Now a vulnerability becomes more than a CVE score.
It becomes a business risk decision.
A lower-scored vulnerability that is actively exploited against an externally exposed critical service may deserve attention before a higher-scored vulnerability on an isolated development system.
This is not about ignoring CVSS.
It is about putting technical severity into business context.
Step 6: Don’t implement directly in production — run a dry run
This should be a mandatory stage of the methodology.
After the controls have been rationalized and prioritized, perform a dry run.
Take a representative sample of systems and assess the proposed baseline.
Classify every control as:
- Pass
- Fail
- Not Applicable
- Compensating Control
- Not Assessed
- Exception Required
Now calculate the actual baseline.
For example:
100 applicable controls
- 72 Pass
- 23 Fail
- 5 Compensating Controls
The initial pass rate is:
72%
But don’t stop there.
Break it down by priority. Control Class Applicable Pass Fail Mandatory / Critical 40 28 12 Good-to-have / High 60 44 16 Total1007228
Now leadership can see the real picture.
The organization isn’t simply 72% compliant.
It has:
30% of mandatory controls failing.
That is a materially different conversation.
Step 7: Validate every failure
A dry run is not simply a compliance scan.
It is a validation exercise.
Every significant failure should be challenged.
Is the finding genuine?
Could it be:
- A tooling limitation?
- Incorrect detection?
- A configuration that is intentionally different?
- An architecture constraint?
- A compensating control?
- A technology incompatibility?
- An operational risk?
- A legitimate exception?
This is where human review becomes essential.
The goal isn’t to manipulate the pass rate.
The goal is to make the pass rate accurate and meaningful.
Step 8: Use the dry run to determine production readiness
Once the dry run is complete, the organization should know:
- What can be implemented safely?
- What requires engineering changes?
- What could affect availability?
- Which controls require application-owner involvement?
- Which controls have dependencies?
- Which systems require maintenance windows?
- Which controls need compensating measures?
- Which exceptions require formal risk acceptance?
Only then should production implementation begin.
This is particularly important for critical workloads.
Security hardening should never create a new operational risk greater than the risk it is trying to reduce.
Step 9: Implement in phases
Production implementation should follow risk priority rather than simply following the order of the benchmark.
Phase 1 — Critical Mandatory Controls
Start with mandatory controls affecting:
- Critical business systems
- Internet-facing assets
- Sensitive data
- Privileged infrastructure
- High-value attack paths
Phase 2 — Remaining Mandatory Controls
Expand across the rest of the applicable estate.
Phase 3 — High-Priority Good-to-Have Controls
Address additional controls based on risk reduction, exposure and operational feasibility.
Phase 4 — Exceptions and Compensating Controls
Every exception should have:
Risk owner → Business justification → Compensating control → Residual risk → Target date → Review date
An exception without an owner or expiry date can quietly become permanent.
Step 10: Measure risk reduction, not just compliance
This is where the leadership reporting needs to change.
Instead of reporting:
“CIS compliance is 91%.”
report:
Control Risk Posture
Mandatory controls implemented: 96%
Mandatory control failures: 4%
Critical assets validated: 98%
Internet-facing critical assets covered: 100%
High-priority controls implemented: 82%
Open critical control gaps: 7
Compensating controls: 14
Active exceptions: 9
Expired exceptions: 0
And, most importantly:
Material risks reduced: X%
That last metric is difficult.
But it is much more valuable.
What leadership should really be asking
The leadership conversation should move from:
“What is our compliance percentage?”
to:
“What material risks remain?”
Then:
“Which critical business services are affected?”
“Which controls are preventing those risks?”
“Which mandatory controls are still failing?”
“What is the remediation timeline?”
“What risk are we accepting?”
“What investment is required to reduce it?”
Now cybersecurity becomes a business-risk conversation rather than a technical compliance conversation.
The operating model
The entire approach can be summarized as:
CIS Benchmark
↓
Complete Control Universe
↓
AI-Based Control Analysis
↓
Human Applicability Validation
↓
Applicable / Not Applicable / Compensating Control
↓
Mandatory / Good-to-Have
↓
Risk & Business Context
↓
Critical / High Implementation Priority
↓
Dry Run
↓
Pass / Fail / Exception / Compensating Control
↓
Risk Validation
↓
Phased Production Implementation
↓
Continuous Monitoring
↓
Periodic Reassessment
That is a risk-based control engineering lifecycle.
The leadership insight
The objective should never be to make the organization 100% compliant at any cost.
The objective is to make sure the organization understands:
What controls matter.
Why they matter.
Where they apply.
What risk exists when they fail.
Which risks must be addressed immediately.
Which risks can be mitigated or accepted.
And most importantly:
No material risk should be hidden behind a compliance percentage.
A benchmark should establish the control universe.
AI should help us analyze that universe at scale.
Human intelligence should validate applicability and business context.
Risk should determine priority.
A dry run should test whether the baseline works in reality.
Phased implementation should reduce operational disruption.
Continuous monitoring should prevent configuration drift from becoming security drift.
The ultimate goal isn’t a perfect checklist.
It is a defensible, continuously validated security baseline aligned to business risk.
**Compliance tells us what the baseline expects.
AI helps us understand it at scale.
Human intelligence tells us what applies.
Risk tells us what matters.
Engineering makes it achievable.
Leadership decides what risk the organization is willing to carry.**
That is the transition from managing security controls to engineering security around risk.
