CMMC Hashing and Evidence Retention
Proving What Was True on Assessment Day
A CMMC assessment is a point-in-time determination — and that determination must be defensible for six years after the CMMC Status Date. The mechanism that makes it defensible without exposing proprietary security artifacts to the government is the DoD Artifact Hashing Tool, which creates cryptographic references so integrity can be validated on demand long after the assessment closes.
Under 32 CFR Part 170 Subpart D, assessment artifacts must be retained for six years. The Cyber AB CAP references the DoD CMMC Hashing Guide as supplemental guidance and ties it to the eMASS submission workflow. When the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) audits an organization — which can happen months or years after the original assessment — they will request the archived evidence, re-run the hashing tool, and compare the resulting hash to the value recorded in eMASS. An exact match is cryptographic proof that the files are unchanged. Any mismatch is proof that they are not.
What the Hashing Tool Does — and Why It Matters for Audit Defense
The DoD Artifact Hashing Tool generates a SHA-256 cryptographic hash — a fixed-length 64-character hexadecimal string — for each artifact in the evidence package. SHA-256 is a one-way function: the same file always produces the same hash, and any change to the file — even a single character, a metadata edit, or a filename change in some implementations — produces a completely different hash. There is no such thing as a "minor" file change in hash terms.
What a SHA-256 Hash Looks Like
Each artifact produces a unique 256-bit (64 hex character) digest. The same file always produces the same output. Any alteration — content, metadata, or encoding — produces an entirely different string.
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855↑ SHA-256 hash of an empty file. The hash of your actual access control policy will be entirely different — and will never match this value regardless of how similar the files are.
The tool produces two outputs: individual hashes for each artifact, and a hash of the complete artifact list file. The list-level hash is what enters eMASS — it represents the entire evidence corpus as a single verifiable reference. The individual artifact hashes are retained by the OSC and support document-level integrity verification during audit.
Original artifacts in read-only vault. Individual SHA-256 hashes retained. The hashing tool run record (date, file set, output) retained. Nothing in the archive is modified after the hash is generated.
How Long Must CMMC Assessment Artifacts Be Retained
The source-of-truth retention requirement is 32 CFR Part 170 Subpart D: assessment artifacts must be retained for six years from the CMMC Status Date — not three years as is sometimes cited from the earlier CAP documentation. The six-year requirement aligns with the False Claims Act statute of limitations and the DIBCAC audit window, which can extend well beyond the initial triennial certification cycle.
The six-year retention window has a practical implication for organizations in their second or third triennial cycle: the evidence from the first C3PAO assessment (Year 1) must be retained through the second triennial cycle (Year 7) before destruction is defensible. Build the archive destruction schedule from the CMMC Status Date, not from the physical assessment dates.
What Must Be Retained: Evidence Across All Three Assessment Methods
The archive must contain every artifact used to demonstrate a Met finding under each of the three assessment methods. Gaps in the archive — missing interview records, lost configuration exports, overwritten screenshots — cannot be filled retroactively. If the artifact does not exist in the archive, the hash verification fails and the finding cannot be substantiated.
Documentation Artifacts
Personnel Record Artifacts
System Evidence Artifacts
Common Integrity Failures That Break Hash Matches Later
Hash verification failures during DIBCAC audit are rarely caused by intentional tampering. They are almost always caused by routine file-handling mistakes that seem innocuous in the moment but produce cryptographically detectable changes. These four patterns account for the majority of archive integrity failures.
The most common archive failure: an updated policy is saved over the assessed version in the same folder. An HR policy that was correct on assessment day is replaced by the revised version six months later. The new file produces a completely different hash. When DIBCAC re-hashes the archive, the output does not match the eMASS record — the assessed version no longer exists.
Version drift does not require malicious intent. It happens automatically when policy owners follow their normal update procedures without awareness that the archive folder is supposed to be immutable.
Moving evidence files from a local directory to SharePoint, a cloud storage platform, or a new file server can alter file metadata — creation dates, last-modified timestamps, author fields — even when the file contents appear identical. Depending on how the hashing tool processes metadata, these changes can produce a different hash for the "same" document. The file looks unchanged in a text editor. The hash disagrees.
This failure is particularly insidious because the content is genuinely unchanged — only the container-level attributes shifted during migration. But "the content is the same" is not a defense against a hash mismatch in a DIBCAC verification.
Some organizations attempt to simplify archive management by compressing all evidence into a single ZIP file and generating one master hash for the whole package. This approach appears to create a single defensible integrity checkpoint. In practice, it destroys document-level integrity verification entirely. Assessors and auditors require the ability to verify individual artifacts against specific control findings. A single zip hash cannot tell DIBCAC whether the access control policy or the SIEM configuration was the document that changed.
Organizations that generate hashes but do not retain documentation of when the hashing tool was run, against which file set, and what the output was have a hash value with no chain-of-custody record. If DIBCAC asks "when was this hash generated and what files were in scope?" the answer must exist as a document — not a recollection. A hash without a run record is an assertion. A hash with a run record is evidence.
A Retention Playbook: Naming, Indexing, Vaulting, and Change Control
The retention architecture must be designed before the assessment concludes — not assembled retroactively after the C3PAO leaves. These five practices, taken together, produce an archive that is both technically sound and operationally defensible.
The Bottom Line
The hashing process and the six-year retention requirement are not administrative overhead. They are the mechanism by which a point-in-time assessment remains defensible — legally and cryptographically — for the entire period during which the DoD, DIBCAC, or a contracting officer might need to verify what was true on assessment day.
The operational requirements are straightforward: generate SHA-256 hashes for individual artifacts using the DoD tool, archive the original files in a read-only vault, retain the hash values and the tool run record, and maintain the archive for six years from the CMMC Status Date. The failures that break this chain are rarely intentional — they are the result of routine file management applied to files that are not allowed to be routinely managed.
The archive is not a backup — it is a legal record. Treat it accordingly: read-only from the moment the hash is generated, named and organized so any auditor can navigate it without your help, and retained for exactly as long as 32 CFR Part 170 requires. The hash in eMASS is only as trustworthy as the archive behind it.