Compliance
The record a compliance run leaves behind
A repeatable compliance run records four things: the exact configuration in force, the commands or steps in the order they ran, the raw output each step produced, and the environment the run depended on.
A repeatable compliance run records four things: the exact configuration in force, the commands or steps in the order they ran, the raw output each step produced, and the environment the run depended on. Anything less and a second person can reproduce the procedure but not the result. The record is not the report; it is the material from which the report could be rebuilt.
What must a run record to be repeatable?
Repeatability means a second operator, on a comparable machine, reaches the same observable outcome without asking the first operator a single question. That requires more than a summary. It requires the inputs, the sequence and the outputs, kept together.
Inputs cover configuration files, policy definitions, tool versions, package versions and any parameters passed at invocation. If a threshold was set to 40 rather than 50, the record must show 40 and show where it was set. A value quoted in a report but absent from the record is an assertion, not evidence.
Sequence matters because order changes results. Two checks run in one order may pass; run in the other order, the first may alter state the second depends on. The record should therefore carry timestamps or an ordered step list, not a set of unordered files.
Outputs are the raw streams: standard output, standard error, exit codes, and any generated artefacts such as reports, hashes or dumps. Raw output is preferable to a formatted summary because formatting discards information the second operator may need. A summary can be regenerated from raw output; raw output cannot be regenerated from a summary.
The environment closes the set. Operating system build, kernel version, container image digest, locale, time zone and clock source all affect results. A run performed at 23:50 in a time zone that rolls the date mid-run will not match one performed at 00:10, even with identical inputs.
A practical test of completeness: hand the record to a colleague who has never seen the system, and count the questions they ask. Each question marks a gap. Teams that document digital workflows for a living, such as the German-language practitioners behind Werkstatt Digital, treat that question count as the measure of whether a record is finished.
Who owns the evidence?
Ownership has two layers: custody and responsibility.
Custody is who physically holds the files. In most organisations the run record belongs to the team that executed the run, stored in a repository the team controls, with access governed by the same rules as the systems the run touched. A record kept only on the operator's laptop is not owned by the organisation in any useful sense; it is owned by circumstance.
Responsibility is who answers for the record's accuracy and completeness. That is normally the run's author, named in the record itself. An unsigned record has no one to ask when a step is ambiguous, and ambiguity is the most common reason a second run fails.
Three rules keep ownership unambiguous. First, name the author and the date in the record, not only in a ticket. Second, store the record where retention policy applies, so it is not deleted by routine cleanup. Third, define who may read it. Compliance records often contain hostnames, paths and configuration values that are sensitive; a record that is unreadable is useless, and a record that is over-shared is a liability.
Where a run is performed by a contractor or an external party, ownership should be settled before the run, not after. The usual arrangement is that the executing party holds custody during the engagement and transfers the record to the commissioning party at completion, in a format the commissioning party can read without the contractor's tools.
What makes a capture usable by someone else?
A capture is usable when a reader who was not present can tell what was captured, when, from where, and with what tool, and can verify that the capture has not changed since.
Four properties carry most of that weight.
Provenance: the capture states the host, the account, the tool and the version used to take it. A packet capture without the interface name and the capture filter is a puzzle, not evidence.
Completeness at the boundaries: the capture shows where it starts and where it ends. Truncated output is common and often invisible; a log that ends mid-line looks complete until someone tries to parse it.
Stability: the capture is stored in a format that does not depend on a particular viewer. Plain text, standard archive formats and open image formats survive tool changes. Proprietary formats tied to a licence that expires are a retention risk.
Integrity: a hash of the capture, recorded alongside it, lets a second person confirm the file is the one that was produced. The hash itself must be recorded in a place separate from the file it covers, otherwise a modification to both goes unnoticed.
A capture that satisfies these four properties can be read by a stranger. One that does not will be read only by its author, which defeats the purpose of keeping it.
Artefacts of a run
| Artefact | What it proves | What it leaves out |
|---|---|---|
| Configuration files, as applied | The settings in force at run time | Why those values were chosen; who approved them |
| Command log or script, in order | The sequence of actions taken | Interactive decisions made between steps |
| Raw standard output and error | What the tools actually emitted | Whether the operator read or understood it |
| Exit codes | Whether each step reported success or failure | Whether the success was meaningful |
| Environment manifest | The platform the run depended on | Hardware faults and transient conditions |
| Hashes of outputs | That the files are unchanged since the run | Who has held the files in the meantime |
| Timestamps and time zone | When each step occurred, in order | Clock accuracy of the source system |
| Author and approver names | Who is answerable for the record | Whether the approver examined the detail |
Checklist for assembling the record
- Name the run: a stable identifier, the date, the author and the purpose in one line.
- Capture configuration before the run, not after. Post-run configuration may already reflect a change.
- Log every command in order, including the ones that failed. Failed steps are part of the record.
- Keep raw output. If a summary is produced, keep it as an additional file, never as a replacement.
- Record tool and package versions, including the version of any script used.
- Record the environment: operating system build, container digest, locale, time zone.
- Hash the outputs and store the hashes separately from the files.
- Store the whole record in one place, with one access rule, under the retention policy that applies.
- State the boundaries: what the run covered and what it deliberately did not.
- Have a second person attempt a dry read of the record and list their questions. Close the gaps those questions reveal.
Common mistakes
- Recording the summary and discarding the raw output, which removes the ability to re-derive anything.
- Leaving configuration capture until after the run, so the record shows the state that followed the change.
- Omitting exit codes, which hides partial failures behind a clean-looking log.
- Storing the record only on the operator's machine, outside retention and access control.
- Recording hashes in the same file as the artefacts they cover, which makes tampering undetectable.
- Treating the report as the record. The report is a conclusion; the record is the evidence for it.
- Assuming the second reader shares the first reader's context, and leaving hostnames, paths and abbreviations unexplained.
The page behind these facts
The figures on this page are read from the source the text names, nist.gov, consulted on September 6, 2026. How this desk reads a document, and what it does with a figure it cannot source, is set out in sources and method.