Most network compliance programs do not fail at the audit. They fail on day 47 of the quarter, when an engineer pastes three lines into a distribution switch at 2 a.m. to fix a voice quality problem, the change never reaches the ticketing system, and the device quietly stops matching the standard it passed in January. The audit three weeks later is just the invoice for that moment. Device compliance is not a documentation exercise performed quarterly — it is a property of change management that has to hold every hour.
A config backup proves what a device was, not what it should be
A nightly show running-config capture is the most common thing teams mistake for compliance tooling. A backup tells you the device's state at 02:00. It says nothing about whether that state violates your baseline, and it gives you no signal at the moment the state changes. Express the standard as assertions rather than files and the scale becomes obvious: a 1,400-device fleet with a 45-line hardening baseline — SSHv2 only, AAA source interface, no transport input telnet, NTP authentication, SNMPv3, syslog host, no default community strings — is 63,000 assertions that must be true simultaneously. A quarterly audit that pulls 35 devices and eyeballs their configs checks about 2.5% of them.
That is the entire argument for continuous evaluation. Sampling was rational when verification cost a human hour per device. It is not rational when evaluation costs milliseconds.
Drift is continuous, and most of it is legitimate
If your change calendar shows 250 normal changes a month against a 1,400-device fleet, that is one touch per device every six weeks — before emergency break-fix, which in most network estates runs at 20 to 30 percent of total change volume. Add the changes that never get a ticket and the realistic figure is a fleet where every device is modified four to nine times a year by something other than a vendor upgrade. None of those engineers were being reckless. They were restoring service, and the standard was the thing standing between them and a resolved incident.
The question is not whether every device is compliant today. It is whether you would know within ten minutes if one stopped being.
Five places drift actually comes from
- Emergency break-fix. An ACL entry or a routing tweak applied under incident pressure, never folded back into the baseline.
- Hardware replacement. An RMA'd switch arrives with vendor defaults; whoever racks it restores routing but not the hardening lines.
- Software upgrades. An OS upgrade re-enables a service or resets a logging destination your baseline assumed was off.
- Automation with stale intent. A script written against last year's standard keeps faithfully applying last year's standard.
- Permanent exceptions. The temporary management VLAN opened in 2021 for a contractor, still open, still undocumented.
Only the first is visible in incident review. The other four are silent, and they are why a device can pass a January audit and fail a July one without anyone making an obvious mistake.
Remediation without a blast radius is a second outage
Auto-remediation earns its place only when the loop is boring. The sequence that works: evaluate the device against the baseline, generate the minimal diff that restores compliance — three lines, not a full config push — render it in dry-run first, apply it to one canary device per platform and hold for 15 minutes, then roll out inside the maintenance window with a pre-change snapshot pinned for automatic revert. If the device stops answering management-plane probes after the push, the revert fires without a human in the path. Anything that touches the management plane itself, or that would drop more than one interface at a time, routes to an engineer instead of executing.
Evidence is the deliverable, and it should be a query
When an auditor asks you to prove 1,400 devices met a control for 90 days, the screenshot workflow produces 1,400 PDFs per quarter, a spreadsheet mapping them to controls, and three engineer-weeks of preparation — which is 12 weeks a year spent proving something rather than fixing it. Continuous evaluation produces a timestamped, immutable record per device per check, and the answer is a query.
PCI DSS, NIST 800-53 (CM-3, CM-6), the CIS benchmarks and IEC 62443 for OT all ask substantially the same thing: configuration settings measured against an approved baseline, with change control around who modified them and when. The mapping between frameworks is mostly translation. The hard part is having per-device evidence at one-minute granularity instead of a folder of exports.
Compliance becomes a control loop, not a project
The direction is clear: evaluation moves from nightly polling to event-driven. Config-change syslog messages, NETCONF subscriptions and streaming telemetry let you detect a deviation within seconds of the commit, collapsing the gap between drift and detection from 90 days to under a minute. When that happens the audit question changes shape. It stops being "were you compliant" and becomes "show me the last time you weren't, and what the system did about it" — a question you can only answer if the policy is executable code rather than a document. A fleet that changes thousands of times a year cannot be governed by a PDF that is read four times a year.