Check device configurations against security and regulatory baselines. Define rules that inspect configuration content, group them into reusable policies, apply those policies to devices, and attach configlets that automatically remediate violations.
NCM Compliance compares a device's stored configuration against a defined baseline and reports which devices meet it. Where monitoring asks whether a device is healthy, compliance asks whether it is configured the way your organisation requires. Baselines can reflect vendor hardening guides such as the CIS benchmarks, regulatory frameworks such as HIPAA or SOX, or your own internal standards.
Compliance is built from three layers. The navigation menu lists them in the reverse of the order you build them in, so it is worth understanding the structure before configuring anything.
Rules A single check against configuration content | → | Rule Groups Related rules bundled into a reusable set | → | Policy Rule groups applied to a set of devices |
| Layer | Description |
| Rule | One test, such as confirming that SSH version 2 is enabled. Each rule carries a severity and can optionally attach a configlet that fixes the violation. |
| Rule Group | Related tests, such as SNMP rules, banner rules, or AAA rules. Groups are the reusable unit that policies are built from. |
| Policy | The baseline itself, such as CIS Cisco IOS Policy. Combines one or more rule groups, targets a set of devices, and defines how strictly the result is judged. |
Cloudmon ships with pre-defined rules, rule groups, and policies covering common vendor and regulatory baselines, so in many environments the work is selecting and associating rather than authoring from scratch.
All compliance views are accessible under Network → NCM → Compliance in the Cloudmon navigation bar, which contains Dashboard, Policies, Rule Groups, and Rules.
Compliance is evaluated against the configuration NCM has already retrieved and stored, not by querying the device at the moment of the check. A device therefore needs a working NCM backup before any policy can return a result.
Device Live configuration | → | NCM Backup Collect and store via SSH or Telnet | → | Policy Rules evaluated against the stored config | → | Result Compliant or non-compliant, with a score |
Note: Not Available is not the same as non-compliant. It means no compliance result exists yet, usually because devices have not been associated with the policy or no configuration has been retrieved for them. Check association and backup before investigating rule logic.
Navigate to Network → NCM → Compliance → Dashboard. The dashboard summarises compliance posture across three panels, then lists every policy with its current score.
| Section | What it shows |
| Policies panel | Total policies, split into Non Compliant, Compliant, Not Available, and Partial. Partial indicates a policy where some associated devices meet the baseline and others do not. |
| Devices panel | Total devices under compliance checking, split into Non Compliant, Compliant, and Not Available. |
| Rules panel | Rule results grouped by severity across Critical, Trouble, and Attention, alongside Compliant and Unknown counts. This identifies whether outstanding violations are serious or advisory. |
| Policies table | Every policy with its compliance score as a percentage, the number of associated devices, whether it checks the Startup or Running configuration, and a count of compliant and non-compliant devices. A policy with no associated devices, or one not yet evaluated, reports a score of zero. |
Rules are the individual checks compliance is built from, so they are created first. Navigate to Network → NCM → Compliance → Rules and click Add. The form is divided into three sections.
| Field | Description |
| Name* | A descriptive name for the check, such as "Enforce NTP Server". Naming rules after the condition they enforce makes violations self-explanatory in reports. |
| Description | An explanation of what the rule verifies and why it matters. |
| Severity* | The severity assigned when this rule is violated. Options are Critical, Trouble, and Attention, defaulting to Attention. Severity determines how the violation is counted on the dashboard, and is used by policies configured to act only on higher severities. |
Defines what the rule checks for in the device configuration. Each condition row consists of a condition selector, a pattern entered as either a plain string or a regular expression, and a numeric value. Three modes are available, increasing in scope.
| Mode | Description |
| Simple | A single condition evaluated against the whole configuration. Suitable for checks that come down to one presence or absence test, such as confirming a specific command is configured. |
| Advanced | Multiple conditions evaluated against the whole configuration. Conditions are added with Add Criteria and can be removed individually. Suitable where compliance depends on several settings together. |
| Custom | Multiple conditions evaluated only within a defined configuration block. Two additional fields set the scope: Block Start, a required pattern marking where each block begins, and Block End, an optional pattern marking where it closes. Conditions are evaluated separately within every matching block, so this is the mode for checks that must apply per interface or per line rather than globally. |
Attaches an automatic fix for violations of this rule. Remediation is optional, and a rule without it reports violations without changing device configuration.
| Field | Description |
| Remediation Configlet | The configlet applied to bring a device back into compliance with this rule. Configlets are created under NCM Configlets and can be selected here once defined. Learn more. |
| Remediation Description | Notes describing what the fix does. Worth completing, since the remediation changes live device configuration and the next person to review the rule needs to know what applying it will do. |
Click Save to create the rule. Use Reset to clear the form without saving.
Rule groups bundle related rules so they can be applied together. Navigate to Network → NCM → Compliance → Rule Groups and click Add.
| Field | Description |
| Name* | A descriptive name for the group, such as "Cisco Security Group". Grouping by function, such as SNMP, banner, or AAA rules, keeps groups reusable across policies. |
| Description | An explanation of what the group covers. |
| Rules* | The rules included in this group, searched and selected from all defined rules. A rule can belong to more than one group. |
Click Save to create the group. Cloudmon ships with pre-defined groups covering control plane, data plane, password, SNMP, access, banner, AAA, and SSH rules across multiple vendors, so an existing group can often be used rather than creating a new one.
A policy applies rule groups to devices and defines how the result is judged. Navigate to Network → NCM → Compliance → Policies and click Add. The form is divided into three sections: Policy Details, Rule Groups, and Devices.
| Field | Description |
| Name* | A descriptive name for the policy, such as "CIS Cisco IOS Policy". |
| Description | An explanation of the baseline the policy enforces. |
| Config Type* | Whether the policy checks the Running configuration currently active on the device, or the Startup configuration the device loads on reboot. Defaults to Running Config. Checking the startup configuration catches cases where a compliant running state has not been saved and would be lost on restart. |
| Violation Criteria* | How strictly the result is judged. Any Rule Violated marks a device non-compliant if any rule fails, and is the default. Critical & Trouble Only marks a device non-compliant only when a Critical or Trouble rule fails, so Attention-level findings are reported without failing the device. |
| Rule Groups* | The rule groups this policy checks against. A policy can combine several groups, so a vendor baseline and an internal standard can be enforced together. |
| Devices | The NCM-managed devices to check against this policy. Optional at creation time, as devices can also be associated later from the Compliance Dashboard. |
Click Save to create the policy. Associate only devices for which the policy's rules are meaningful, since a Cisco IOS baseline applied to a FortiGate will report violations that reflect the mismatch rather than a genuine configuration problem.
Navigate to Network → NCM → Compliance → Policies to view all policies. The list shows each policy's name, description, config type, violation criteria, and associated device count, with the following actions available on each row.
| Action | Description |
| Enable / Disable | Turns compliance checking for the policy on or off without deleting it. Useful for suspending a baseline during a migration rather than removing it. |
| Associate / Dissociate Devices | Adds devices to the policy or removes them, without editing the rest of the policy configuration. |
| Edit | Reopens the policy form to change its details, rule groups, or devices. |
| Delete | Removes the policy. The rule groups and rules it referenced are unaffected and remain available to other policies. |
Where a rule has a remediation configlet attached, a detected violation can be corrected through NCM Configlets rather than by logging into the device. The full cycle runs from detection through to verification.
Detect A rule fails during evaluation | → | Review Check the rule, severity, and affected device | → | Remediate Apply the configlet to the device | → | Verify Re-evaluate and confirm the rule now passes |
Caution: Not every failed rule is safe to remediate automatically. A configlet changes live device configuration, so validate the intended change, the device scope, the vendor syntax, and your organisation's change process before applying one. NCM configuration history and version comparison can be used to confirm exactly what changed before and after.
| Issue | What to check |
| Policies show a score of 0% and a status of Not Available | Not Available means no compliance result exists yet. Confirm devices have been associated, since a policy with no devices cannot produce a score. Then confirm those devices have a stored configuration in NCM, because compliance is evaluated against the backed-up configuration rather than by querying the device directly. |
| A device is marked non-compliant but the violation looks minor | Check the policy's Violation Criteria. With Any Rule Violated, a single Attention-level finding is enough to mark the device non-compliant. Switching to Critical & Trouble Only reports lower-severity findings without failing the device. |
| A device passes against the running configuration but fails against startup | The compliant configuration is active but has not been saved to the startup configuration, so the device would revert on reboot. Save the configuration on the device, then allow the next backup and evaluation cycle to run. |
| A rule never reports a violation even on devices that should fail it | Review the criteria pattern. Patterns accept plain strings or regular expressions, so a pattern intended as literal text may be interpreted as an expression. For rules using Custom mode, confirm the Block Start pattern actually matches a block in the device configuration, since conditions are only evaluated inside matching blocks. |
| A rule passes but the device is still configured insecurely | The rule is likely too broad. A check that looks for a command anywhere in the configuration will pass even when the command is applied in the wrong place. Rewrite it in Custom mode so the condition is evaluated within the correct configuration block. |
| Remediation configlet cannot be selected on a rule | Configlets must exist before they can be attached as remediation. Create the configlet under NCM Configlets first, then reopen the rule and select it. |