Policy Compliance

Policy Compliance checks that your systems are configured the way your standards require. Where vulnerability assessment asks "is anything broken here", policy compliance asks "is this built the way we said it should be".

Configuration, not vulnerabilities

The distinction matters because the two are fixed by different people in different ways.

	Vulnerability	Policy compliance
Typical finding	A missing patch, an exploitable flaw	A setting that does not meet the standard
Typical fix	Apply an update	Change a configuration
Typical source	A vulnerability scanner	A benchmark check
Usually owned by	Application or platform teams	Infrastructure and platform teams

A server can be fully patched and still fail policy compliance — password rules too weak, logging not enabled, an unnecessary service running.

Controls and postures

The control library. Each control is a check with a defined expected state.

A control is a single requirement: "password minimum length is 14". A posture is the observed state of that control on a particular system — met, or not met.

So one control assessed across two hundred servers produces two hundred postures. This is why policy compliance volumes are so much larger than vulnerability volumes, and why the module is built around bulk assessment rather than individual findings.

How assessment works

1. Controls are defined, usually derived from a benchmark such as CIS.
2. An audit applies those controls to a set of systems.
3. Results are imported from the tool that performed the checks.
4. Each control-on-system produces a posture: compliant or not.
5. Non-compliant postures are remediated and reassessed.

Reading the numbers

Compliance is usually expressed as a percentage — compliant postures over total postures. Two things to keep in mind when reading it:

• The denominator moves. Adding systems or controls changes the total, so the percentage can fall without anything getting worse.
• Not all controls matter equally. A high overall percentage can still hide failures on the controls that matter most. Read the failures, not only the ratio.

Reassessment is what changes a posture

Fixing the configuration does not update NxSAM. The system must be checked again and the result imported. Between the fix and the next assessment, the posture legitimately still shows as non-compliant.

Working effectively

• Group by control rather than by system when one setting fails widely — that is a single configuration-management fix, not hundreds of separate ones.
• Prioritise by the sensitivity of the systems affected, not by count alone.
• Where a control genuinely cannot be met on a given system, record the exception deliberately rather than leaving it perpetually failing.