TL;DR · Key Takeaways
- VCF Operations scores compliance by running your objects against a benchmark and returning a percent per object and per group. A host that fails 3 of 60 rules shows 95 percent, not a red or green light.
- The built-in choices are the VCF Security Baseline plus regulatory frameworks like PCI DSS, HIPAA and NIST. CIS and CSA come as separate compliance packs you install from the Marketplace.
- A green score and no drift are two different questions. Score answers do you match the rule set today. Drift answers has this cluster moved away from the state it was signed off in.
- VCF Operations shows you the violations and the drift. Continuous enforcement and automatic desired-state remediation across the whole stack is the Advanced Cyber Compliance add-on in 9.1, not base Operations.
- Exceptions are the part people skip. An unmanaged exception list turns a 100 percent target into permanent noise, so document every accepted deviation with an owner and a review date.
Compliance is the part of day-2 that most teams treat as a once-a-year fire drill, then wonder why the audit hurts. I have sat in enough of those rooms to know the pattern. Someone exports a config, an auditor finds forty settings that drifted since the last review, and nobody can say when or why they changed. VCF Operations exists to make that a continuous readout instead of an annual surprise, but only if you understand what its compliance score actually measures and where it stops.
This part is about configuration compliance and drift: how VCF Operations builds a score, which benchmark is grading you, why a green cluster can still have drifted, and the honest line between what base Operations does and what needs the Advanced Cyber Compliance add-on. I run this for real environments, so I will be blunt about the settings that bite.
How VCF Operations turns config into a score
Compliance in VCF Operations is a data-model problem before it is a security problem. Operations already collects properties on every object it manages: an ESX host advertises its NTP config, its lockdown mode, its syslog target, its shell timeout. A benchmark is just a set of rules that read those properties and decide pass or fail. Run the rules against the object, count the passes, and you get a compliance score expressed as a percent. Roll the objects up into a group and the group gets a weighted score too.
The percent hides the risk weighting
Here is where I disagree with how most dashboards present this. A 95 percent host sounds fine. But the three failing rules could be trivial (a cosmetic banner) or they could be the ones that matter (an unauthenticated syslog target, lockdown mode disabled). The score treats a banner and an open management path with the same weight unless you look at the individual findings. I tell teams to stop reporting the number to leadership and start reporting the list of failed high-severity rules. The percent is for trend, not for decisions.
The objects VCF Operations can score cover the core stack: ESX hosts and clusters, vCenter, vSAN, NSX managers and logical switches, distributed virtual switches, and the SDDC Manager itself. For any of those to be scored, the matching data source has to be connected first, which is the adapter work we covered back in Part 3. No adapter, no properties, no score.
Which benchmark is grading you?
This is the question I ask first on any new environment, because a compliance score is meaningless until you know the rule set behind it. VCF Operations ships with the VCF Security Baseline and a set of regulatory frameworks. Other well-known benchmarks, CIS and the Cloud Security Alliance pack, arrive as separate compliance packs you install from the Marketplace. They are not on by default, and I have watched teams assume they were CIS-compliant when nothing had ever loaded the CIS pack.
One practical note on versions. The CIS pack tracks a specific benchmark release (the ESXi benchmark, for example, is pinned to a dated version), so when the CIS body publishes an update your pack does not silently follow. Check the pack version against what your auditor expects before you present a number.
Why a green cluster can still have drifted
Compliance score and drift answer different questions, and conflating them is the most common mistake I see. A benchmark score asks whether the object matches the rule set right now. Drift asks whether the object has moved away from the known-good state it was signed off in. A host can pass every benchmark rule and still have drifted, because someone changed an advanced setting the benchmark does not check. And a host can be flagged as drifted while still scoring 100 percent on the baseline.
Seen this go wrong
That is why I keep both signals on. Benchmark scoring is your security posture against a public standard. Drift comparison is your consistency against your own baseline, and it catches the human changes that never make it into a change ticket.
What base Operations does, and what needs the add-on
This is the line I most often have to draw for people who read a launch blog and expect automatic remediation. Base VCF Operations is strong at showing you the state: it scores objects against benchmarks, surfaces failed rules, tracks drift against templates, and trends the whole thing over time. What it does not do out of the box is continuously enforce a desired state or push fixes back across the full stack automatically. In VCF 9.1 that continuous, always-on compliance with desired-state remediation across workloads and infrastructure is the Advanced Cyber Compliance add-on, assessed and remediated against benchmarks like PCI DSS and the VCF security guidelines.
Whether you buy the add-on depends on scale and appetite for automation. If you have a handful of clusters and a disciplined change process, base Operations plus a monthly review is enough. If you are running dozens of clusters under PCI or federal mandates where drift has to be corrected on a clock, manual remediation does not hold and the add-on earns its cost. Do not buy it to compensate for a broken change process; automation of a bad process just breaks faster.
The exception list is where compliance lives or dies
Every real environment has settings that will never pass a public benchmark, for a legitimate reason. A legacy app needs an older TLS cipher. A monitoring tool needs shell access the benchmark wants disabled. If you leave those as failing rules, your score sits at a permanent 94 percent and everyone learns to ignore it. Document each accepted deviation as an exception, with an owner, a reason, and a review date. An exception without a review date is just permanent debt with a nicer name.
Rolling the score up across groups and sites
In a single cluster the score is easy to read. Across a multi-site estate it is not, because a group score is an average and averages hide the one bad host. I build custom groups that match how I actually operate: one per site, one per environment tier such as prod and non-prod, and one for anything in PCI scope. Then I score each group against the benchmark that group is held to, rather than grading everything against a single baseline. A dev cluster does not need to pass PCI, and pretending it does just floods you with findings you will never act on.
Weighted averages lie about outliers
A 200-object group sitting at 99 percent can still hide ten hosts with lockdown mode off, because the average absorbs them. So I never alert on the group percent alone. I alert on the count of objects below a per-object floor: any host under 90 percent, or any host with an open high-severity finding. That turns a soft average into a hard list of names to go fix. For multi-site it also stops one noisy site from dragging a healthy site down and masking a genuine problem in the healthy one. This is the same grouping discipline that pays off for capacity and cost earlier in this series, and it is what makes a multi-cluster estate manageable instead of a wall of red.
A worked example: scoring a four-host cluster
Say you have a production cluster of four ESX hosts and you run the VCF Security Baseline against it. The baseline has, for argument, 60 host-level rules. Three hosts pass all 60. One host fails 3 rules: an outdated TLS cipher (legitimate, a legacy app needs it), lockdown mode disabled (not legitimate, someone turned it off to troubleshoot and forgot), and an NTP source pointing at the wrong server (a real drift).
Per host that is 57 of 60, so 95 percent. The cluster group score averages to roughly 98.75 percent, which looks great and hides the fact that one host has lockdown off. Work the three findings: the TLS cipher becomes a logged exception with a review date, so it stops dragging the score. Lockdown mode gets re-enabled, a real fix. The NTP source gets corrected back to the baseline. After remediation the host returns to 60 of 60 minus one documented exception, and the cluster reads a clean posture with one tracked deviation instead of a vague 98.75.
What I’d do
Signs it’s healthy
A healthy compliance setup looks like this: every managed cluster is scored against a named benchmark you actually chose, the exception list is short and every entry has an owner and a future review date, drift alerts fire within a day of a change and get triaged rather than muted, and the trend line is flat or climbing rather than sawtoothing every time someone touches a host. If your score bounces around and nobody can explain the dips, you have drift you are not catching, not a scoring problem.
Common questions
Does a 100 percent score mean I am secure?
No. It means you match the rules in whichever benchmark you loaded. A benchmark is a floor, not a full threat model, and it does not check settings outside its scope. Pair the score with drift comparison and your own known-good template.
Why did my score change when I did not touch anything?
Two usual causes. Either a host actually drifted through an unlogged change, or you updated a compliance pack and the new rule set grades differently. Check the pack version history before you assume someone changed a host.
Do I need CIS if I already run the VCF Security Baseline?
Only if an auditor or internal standard specifically asks for CIS. The baseline covers the VCF stack well. Running two overlapping benchmarks doubles the findings you have to reconcile, so add CIS because you must report it, not for extra comfort.
Can base Operations fix a violation for me?
Base Operations shows and tracks; it does not enforce or auto-remediate across the stack. Continuous enforcement and desired-state remediation is the Advanced Cyber Compliance add-on in 9.1. Without it, remediation is your runbook and your hands.
How often does drift get checked?
On the collection schedule for that object, typically daily. That is fast enough to catch an unlogged change the next morning, but it is not real-time. If you need instant enforcement, that is again add-on territory.
« Previous: Part 9 | VCF 9 Operations Complete Guide | Next: Part 11 »
References
- Broadcom TechDocs: VCF Benchmarks based on the VMware Cloud Foundation Security Baseline
- VCF Blog: Continuous Compliance and Enhanced Platform Security for VCF 9.1
- VMware VCF Security and Compliance Guidelines (GitHub)
- Related: VMware Cloud Foundation 9 Complete Guide
- Related: Upgrading VCF to 9.1 full-stack runbook
About The Author
DrJha