Evidence packs

Planned design. TractorStack is in development. This page describes how it is designed to work; nothing here is available to install yet. See the roadmap for the status of each part.

Exploring An idea we are working through, not a committed design.

Compliance evidence packs for CMMC and NIST 800-171 are something we are exploring because so much of the evidence already exists in a TractorStack environment. Hardening runs, approvals, backup tests and drift checks all leave records. The idea is to collect that evidence as a by-product of normal operations, instead of a scramble of screenshots in the weeks before an assessment.

Using TractorStack does not make anyone compliant by itself. Compliance depends on policies, people, physical security and much more than infrastructure code. InfraTractor can help with readiness; certification is done by independent assessors, not by us and not by a tool.

Evidence as a by-product of normal runs

NIST SP 800-171 sets out security requirements for protecting Controlled Unclassified Information, and CMMC (the US Department of Defense’s Cybersecurity Maturity Model Certification) builds its Level 2 on them. Many of those requirements touch areas TractorStack already plans to manage as code:

configuration baselines and hardening, applied by Ansible;
approval of changes before they are made, through change requests;
audit records of who did what, from the audit trail;
backups and the ability to restore them, proved by restore tests;
detection of unauthorised configuration changes, through drift checks.

Compliance evidence for CMMC and NIST 800-171

The approach we are exploring is to tag Ansible roles and routine checks with the control identifiers they relate to. When a run applies or checks something, its output is saved as evidence against those controls.

# planned example: an Ansible task tagged with a control
- name: Disable SSH password login
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: "^PasswordAuthentication"
    line: "PasswordAuthentication no"
  tags: [nist-800-171-3.4.2]

The mapping is a starting point for discussion with your compliance lead and assessor, not a claim that a control is met. One technical setting rarely satisfies a control on its own, and some controls have no technical part at all. Those stay with your policies and procedures.

Saved where it can’t be altered

Evidence that someone could edit later is weak evidence. The design we are exploring:

writes each run’s evidence to a RustFS bucket with object lock, so it cannot be changed or deleted before its retention period ends;
indexes it in PostgreSQL by control, host, date and run, so you can find all evidence for one control over a period;
keeps it on site, under your control, as described in Your data stays on site.

What a pack would contain

For a chosen period and scope, a pack would gather: the list of hosts and what was applied to them, the run logs and check results tagged with each control, the change approvals behind them, and any failures with how they were fixed. Failures stay in. An honest record with a fix is worth more to an assessor than a suspiciously clean one.

What it does not cover

Written policies, training, physical access and incident response plans.
Anything outside the environments TractorStack manages, such as laptops or email.
The judgement of whether a control is met. That belongs to you and your assessor.

If you are preparing for CMMC or NIST SP 800-171 and want to talk about readiness, contact sales@infratractor.com. See the roadmap for where this sits.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com