Compliance Without the Spreadsheet: Continuous Posture for Network Devices

Compliance work has a credibility problem. Most teams "do compliance" by sampling a handful of devices once a quarter, exporting the result to a spreadsheet, and presenting it to an auditor who has no way to reproduce the test. Everyone agrees the process is theatre. Nobody has the time to fix it.

The Compliance panel is what fixing it looks like. Every rule is code. Every score is reproducible. Every drift is timestamped.

Rule packs

A rule pack is a versioned bundle of checks targeting a specific standard or internal policy. Packs ship for common ground — CIS-style hardening, basic PCI controls, sane SSH and AAA defaults — and you can author your own. Each rule declares its category, severity, the platforms it applies to, and the remediation guidance shown when it fails.

What a rule looks like

{
  id: "ssh.disable-v1",
  category: "access",
  severity: "high",
  applies: ["cisco_ios", "cisco_xe"],
  check: ({ config }) => !/ip ssh version 1/.test(config),
  remediation: "no ip ssh version 1\nip ssh version 2"
}

The function form keeps rules expressive without dragging in a regex DSL. Most rules end up being a single predicate over the parsed config; complex ones can reach into the structured device facts.

Scoring

Each device gets a score per pack: weighted by severity, normalised to 0-100, and stored as a row in history. The dashboard graphs the score over time so you can see the impact of a hardening sprint instead of guessing.

Evidence the auditor will accept

Every finding records the exact config snippet that triggered the rule, the timestamp it was collected, and the script that collected it. Export the bundle and an external auditor can reproduce the result without ever touching the device. That is the difference between a compliance program and a compliance slideshow.

Drift and exemptions

Real fleets have legitimate exceptions. The panel supports time-bound exemptions with required justifications and approval metadata. Exemptions show up in the report explicitly — never hidden — and expire on their own so nobody inherits a permanent waiver from a previous engineer.

Authoring a custom rule pack

• Start by codifying the things you already check by hand during change windows.
• Tag rules with the same categories your security team uses; cross-walking to their framework is half the work of an audit.
• Write the remediation snippet in the same form your engineers paste into devices — copy-paste is a feature.

Integration with the rest of the platform

Compliance findings flow into the same store the RCA engine reads, so a configuration change that breaks a policy can show up alongside the operational symptoms it caused. That correlation is impossible when your compliance data lives in a separate spreadsheet.

What to try first

Pick a single device class, run the default pack, and look at the lowest-scoring rule. Nine times out of ten it will be something everyone agreed to fix two years ago. Fixing it is now a single PR away.