STIG and CIS evidence for assessors: Windows and Linux
Assessors want proof, not screenshots. What evidence a configuration and patching program should produce for CMMC, NIST 800-53, and STIG reviews, and how to make it verifiable.
Every assessment eventually asks the same few questions about your servers: what should their configuration be, does it match, what changed, who approved it, and how do you know the record of all that is true. Screenshots of a console answer the first two badly and the last one not at all.
The evidence that answers the questions#
| Assessor question | Evidence that answers it |
|---|---|
| What is the required configuration? | A named baseline (CIS benchmark or DISA STIG controls) per OS, versioned |
| Does each machine meet it? | A per-machine, per-control result with a date, for every machine in scope |
| Are machines patched? | Pending updates per machine, and the results of patch runs |
| What changed, and who approved it? | A change record per action: who asked, who approved, which machines, what result on each |
| How fast is drift caught? | Drift checks on a schedule, with what differed and when it was corrected |
| Can the record be trusted? | A log that cannot be edited without detection, and an export the assessor can verify |
These map to familiar controls, for example configuration settings and baseline configuration, configuration change control, and flaw remediation in NIST SP 800-53 (CM-2, CM-3, CM-6, SI-2), which CMMC Level 2 builds on through NIST SP 800-171.
What makes evidence verifiable#
- Per-machine results, not totals. "98 percent compliant" invites the question "which 2 percent, since when?"
- Hash-chained logs. Each audit entry includes a hash of the one before it, so removing or editing an entry breaks the chain.
- Signed exports. The evidence package carries a manifest of file hashes and a signature, so the assessor knows it is the package you produced.
- An independent verifier. A small tool the assessor runs on their own machine to check the signature, the chain and that every change has a result for every targeted machine.
How Gardience produces it#
Gardience is a supported console on open-source Salt for Windows and Linux, built around this evidence:
- A scored STIG/CIS-aligned baseline on every machine, with one-click fixes and drift repair.
- Patching with pending updates per machine and every machine's result recorded.
- Governance on every change: roles, two-person approval, change windows, locks, change-ticket checks and time-limited break-glass access.
- A tamper-evident audit log of every action and every machine's result, forwarded to your SIEM over syslog (TCP or TLS).
- A signed evidence pack (fleet status, baseline results, per-machine change results, and the audit log) with an offline verifier the assessor runs themselves.
It runs fully air-gapped, with signed releases and an SBOM for every image, which matters for enclaves where the management tool is itself in scope.
Questions#
Is a screenshot of a compliance dashboard acceptable evidence?#
It shows a moment, not a record. Assessors increasingly ask for per-machine results over time and proof that the change log was not edited.
Which controls does configuration and patch evidence support?#
Typically baseline configuration, configuration settings, configuration change control, and flaw remediation, such as CM-2, CM-3, CM-6, and SI-2 in NIST SP 800-53.
Does this work for both Windows and Linux?#
Yes. In Gardience the baseline, patching, change records, and evidence pack cover Windows and Linux in one package.
Try Gardience on your own machines
One supported console for Windows and Linux on open-source Salt: patching, a scored STIG/CIS-aligned baseline, drift repair, event-driven automation, two-person approval and a tamper-evident audit log. Flat yearly pricing, not per node.
Free 90-day trial (25 nodes)See it work Compare