Automating Compliance Evidence Collection

Use a read-only automation path: an Ansible playbook that runs show commands (or NETCONF get-config) against each device, writes raw output to a timestamped artifact store, and parses it into a compliance report. Do not use configuration-changing modules for evidence collection; use network_cli or netconf with a service account limited to read-only commands.

Tamper-evidence: commit parsed results and raw artifacts to a Git repository with signed commits, or hash each artifact and store hashes in an append-only log. The quarterly report references commit IDs so an auditor can verify the evidence was not altered after collection.

Unreachable devices: the playbook must record a distinct status for timeouts and refused connections, not silently skip. Maintain an inventory source of truth (e.g., a CMDB export) and reconcile the set of devices contacted against it; any device in the CMDB but not contacted is flagged as a gap requiring manual follow-up. Schedule collection to avoid maintenance windows where possible, and run a second pass for failures.

Abstract vendor differences behind a role structure: a common compliance role that defines the checks, and vendor-specific roles that implement how to obtain each fact (e.g., show version parsing differs by vendor). Use a normalized data model: each device returns a dictionary with fields such as ntp_servers, aaa_configured, logging_host, snmp_community, and os_version. The compliance checks operate on the normalized model, so adding a vendor means adding a parser, not rewriting checks.

For approved versions, maintain a version allow-list in the Git repository, reviewed by the change board. The check compares the parsed version against the list and reports pass/fail with the observed version. Handle version string variations (e.g., suffix letters) with explicit parsing, and include a unit test with sample outputs from each vendor to prevent false passes.

Treat the allow-list as code: changes go through pull request and review, so the compliance definition itself is auditable.

First, scope and credentials: the automation runs with a dedicated account, least privilege, and credentials stored in a vault, not in the repository. Access to run the playbook is limited to the network team and logged.

Second, change control: the playbook and compliance rules live in Git with protected branches, mandatory review, and CI that runs syntax checks and unit tests on every change. Production runs are triggered from a tagged release, and the tag plus commit ID appear in the evidence report.

Third, blast radius: evidence collection is read-only, but the change board will still ask what happens if the playbook misbehaves. Limit concurrency, set timeouts, and test against a lab or a small canary group before the full run. Document the rollback (none needed for read-only, but state it).

Fourth, audit trail: retain run logs, artifacts, and hashes for the required retention period, and define who can access them. Present the change board with the read-only design, the review process, and a pilot result to secure approval.