What CMMC assessment evidence must look like to count
A contractor preparing for a Level 2 assessment because a DoD contract requires it needs one rule above all others: a requirement is MET only when all applicable assessment objectives are satisfied with evidence in final form. Working papers, drafts and unapproved policies do not count, however complete they look. The organization owns its controls, and an implementation partner can prepare systems, documents and evidence, but neither the partner nor the organization issues the result. A Level 2 certification result comes from a C3PAO, and a self-assessment result is recorded by the organization itself and posted to SPRS under its own accountability.
The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026 and would have required C3PAO certification for applicable Level 2 contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so the evidence standard applies now to any self-assessment a contract depends on. Confirm with the contracting officer which requirement applies to each contract, because the answer changes what a contractor must produce and by when.
What changes for each organization is the contract it holds, the level it must reach and the system boundary the evidence describes. A firm with a Level 2 self-assessment obligation should inventory its contract clauses, match each to a level, and then check that every artifact it plans to use is dated, approved and stored in its final form. Ask any consultant to show which artifacts they would hash and retain for the required period, and confirm how the scoring record in SPRS will be backed by that same evidence.
How assessors examine, interview and test each objective
Examining means the assessor reviews documents, records, configurations and artifacts to determine whether a requirement's objectives are met. The assessor is checking what the organization has written down and recorded, and whether those records match the system as it is configured. Examine evidence is usually the most common type in a CMMC assessment, and it is the type most often rejected for being in the wrong form.
- Final-form documents: The assessor reads approved, dated and version-controlled policies, plans and procedures. Drafts and working papers do not count toward MET.
- Configuration exports: Baselines, group policy or cloud policy exports, and firewall rule sets that show the system's current state.
- System inventories and diagrams: Asset lists and boundary diagrams that agree with the System Security Plan.
- Logs and records: Samples of audit records, change tickets and access reviews with dates and named approvers.
- Ready before the team arrives: A document index mapping each artifact to the objective it supports, with hash values prepared for the C3PAO upload.
Confirm with your assessor which artifact formats and naming conventions they expect, and check that every examine artifact is the approved version rather than a copy from a working folder.
Interviewing means the assessor asks personnel questions to understand how a process actually works and whether people know their responsibilities. Interviews test whether the documented process matches daily practice. An interview that contradicts the written procedure is a finding, so preparation should focus on consistency between what people say and what the records show.
- Role coverage: Assessors typically speak with people in security, system administration, help desk, and management roles who own the controls in question.
- Consistent answers: Staff should be able to describe their own duties, where the procedure lives, and what evidence they produce.
- Process walkthroughs: Staff may be asked to explain a recent change, access request, or incident from start to finish, using real records.
- Awareness of the SSP: Personnel should know the System Security Plan exists, and understand the parts relevant to their role.
- Ready before the team arrives: A brief for each interviewee covering their controls, the artifacts they own, and the sequence of steps they perform.
Confirm the interview schedule and whether the assessor will sample staff or interview by role, since that determines who needs preparation.
Testing means the assessor observes a mechanism operate, or runs or watches a technical check, to confirm that a control works as described. Testing is the method that moves a claim from paper to behavior. CAP v2.0 expects the team to use testing along with examination and interviews, and much of it can be carried out through demonstrations shown by the contractor.
- Demonstrations: Live or recorded views of a control working, such as an account being disabled after a termination or multifactor authentication being enforced at sign-in.
- Recent scan results: Vulnerability scans and their remediation records, showing the dates the scans ran and the outcomes.
- Sampling: The assessor selects a sample of systems, users or changes and checks each one, increasing the sample when evidence is questionable.
- Virtual evidence: Much testing can be done remotely by mutual agreement, so screen-sharing environments and read-only consoles should be prepared in advance.
- Ready before the team arrives: Tested accounts, sample systems, and a rehearsed walkthrough for each demonstration, along with the hash values of any recorded outputs.
Confirm with the assessor which systems they will sample, how they want remote demonstrations delivered, and whether they will accept a recording in place of a live view.
How sampling depth changes the evidence load
Sampling decides how much evidence an assessment team pulls from each system, so the same control can require a handful of artifacts or many. The cards below cover the factors that set sample size and the habits that keep evidence consistent across systems, which is where many self-assessments lose time.
Nonstatistical sampling at FOCUSED
CAP v2.0 directs the assessment team to use nonstatistical sampling at the FOCUSED value for both depth and coverage. The team selects artifacts by judgment rather than by a statistical formula, so there is no fixed sample count you can compute in advance. Ask your C3PAO or assessment lead how they will select samples for each system boundary, and prepare a complete artifact set for every system that touches CUI so no selection leaves a gap.
Increasing the sample when evidence is questionable
When an assessor finds evidence that looks inconsistent, incomplete or out of date, the expectation under CAP v2.0 is to widen the sample rather than accept a thin set. A single misconfigured host or an expired review record can therefore pull in more systems and more artifacts. Before the assessment, check each evidence set for dates, owners and matching configuration, because one weak artifact can expand the work for the whole control family.
Consistency across similar systems
Assessors sample across the population of systems, so identical controls should be evidenced the same way on every server, endpoint and cloud account in scope. Use one configuration baseline, one naming convention for artifacts and one evidence template per control. Inconsistent exports, such as a screenshot from one host and a CLI output from another, make the assessor widen the sample and slow the review.
Scoping drives the population
The size of the population from which samples are drawn depends on how accurately the CUI boundary is defined. Systems left out of scope but still able to reach CUI enlarge the risk of a finding, while over-scoping enlarges the artifact load. Maintain an asset inventory that tags each system as in scope, out of scope or as a specialized asset, and confirm the boundary with the assessor before evidence collection starts.
Virtual evidence collection by agreement
Much evidence collection may be done virtually if the assessment team and the organization agree to it. Virtual review works when artifacts are complete, time stamped and hashed before upload, and when screen sharing or live demonstrations are arranged in advance. Confirm with the assessor which artifacts they will accept electronically, which demonstrations they expect on video, and how remote access to systems will be handled, if at all.
Keeping evidence sets current for sampling
Samples are drawn from evidence that exists at assessment time, so stale artifacts create the most avoidable risk. Recent scan results, current system inventories, configuration baselines and multifactor authentication records should reflect the same period. Set a review cadence for each artifact type, record who approved it, and store the final-form version that you will hash and retain for six years from the CMMC status date.
Hashing artifacts and keeping them for six years
This sequence turns the evidence you rely on into a fixed, verifiable record that the C3PAO can load into eMASS and that you can produce later. Each step produces an output the next step depends on, so an assessor can confirm that the artifacts reviewed are the same ones you retained.
Finalize each artifact before hashing
Confirm that every document, export, screenshot and log used as evidence is in final form, approved and dated, with no working drafts or unapproved policies left in the set. Your compliance lead or system owner signs off on the artifact list. The output is a frozen evidence set, because hashing a draft would force you to rehash it after any later edit.
Hash each artifact with a NIST-approved algorithm
Run a NIST-approved hash function, such as one of the SHA-2 or SHA-3 family algorithms, against every artifact in the frozen set. Your internal assessment lead or IT staff can do this with standard tooling, and the process should be the same for every file. The output is one hash value per artifact, and you confirm completeness by checking that the number of hashes matches the number of artifacts on your list.
Record names, hash values and algorithm
Create a register that lists each artifact name, its hash value and the algorithm used, and store it alongside the evidence in a controlled location. Keep the register under version control so any change is visible. The output is a single record that a reviewer can use to match each file to its fixed hash without relying on memory or on file names alone.
Provide artifact names and hashes to the C3PAO
Give the C3PAO the artifact names, hash values and algorithm, as 32 CFR 170.17(c)(4) requires, so the assessment team can load them for upload to eMASS. Confirm the handoff format and channel with the C3PAO in writing before the assessment begins. The output is the C3PAO's written acknowledgment that it received the register, which becomes part of your assessment file.
Upload artifacts to eMASS through the assessor
Ask the C3PAO to confirm that the uploaded artifacts match the names and hash values you supplied. Your team should not treat the upload as complete until the assessor confirms the match. The output is an eMASS record that ties each artifact to its hash, which supports the assessment conclusions and any later review of the evidence.
Retain hashed artifacts for six years
Keep the hashed artifacts, the register and the handoff records for six years from the CMMC status date, as 32 CFR 170.16(c)(4) and 170.17(c)(4) require. Store them in a location that preserves integrity and allows retrieval, and assign an owner for the retention period. Confirm the status date and retention end date with your contracts or compliance team. The output is a retained, verifiable evidence archive that can be produced if the status is questioned.
Recheck hashes before any evidence reuse
Before you reuse, update or resubmit any artifact, recompute its hash and compare it with the value in the register. A mismatch means the file changed after the record was created, so you must treat it as a new artifact and update the register and handoff records. The output is a documented decision for each changed file, which keeps the retained archive consistent with what was assessed.
Can a NOT MET requirement be fixed during the assessment?
Yes, in a narrow window. Under 32 CFR 170.17(c)(2), a requirement scored NOT MET may be re-evaluated during the active assessment and for 10 business days after the active assessment period ends, but only if additional evidence exists. Three conditions bound that right. Results already scored MET are unaffected, so the team does not reopen them. The window closes once the Assessment Findings Report has been delivered. And the new material has to be genuinely new evidence, not a reworded version of what the assessors already reviewed. Treat the window as a short, fixed deadline that starts running the moment the assessment ends, and plan the internal calendar around it.
The evidence you submit in that window must meet the same test as everything else: it has to be in final form. A corrected access review signed off by the approver, a configuration baseline exported from the live system, or a scan report generated after the fix all qualify. A draft policy, a working spreadsheet or a promised screenshot does not, and an objective the assessors cannot verify stays unmet. Before anything goes to the C3PAO, confirm the artifact name, its hash and the algorithm, because those values must match what is retained under the six-year rule. Ask the C3PAO in writing which artifacts it will accept and how it wants them delivered, since upload and verification steps vary by assessment.
Decide what to submit, and that decision belongs to the organization. The implementation partner can help prepare systems, collect logs and assemble artifacts, but it cannot choose which evidence goes to the assessors, and it cannot vouch that a control works. Review each NOT MET item against the assessment objectives in NIST SP 800-171A and ask whether the new evidence actually satisfies every applicable objective. If it does not, a POA&M or an operational plan of action may be the honest path, and the difference matters for scoring. Record the decision and its reasoning in your assessment file so a later reviewer can see why each artifact was or was not submitted.
How POA&Ms, operational plans of action and enduring exceptions are scored
A plan of action and milestones (POA&M) covers assessment deficiencies that the contractor must fix within 180 days, as defined in 32 CFR 170.4 and governed by 32 CFR 170.21. It is a remediation commitment, not a way to avoid a finding. Under the scoring rules, a requirement with an open POA&M is recorded as a deficiency, so the assessor scores it against the assessment objectives and the contractor must show that it is working toward closure. The POA&M should name each deficient requirement, the planned fix, an owner and the milestone dates that fall inside the 180-day window. Assessors check that the entries match the system security plan and the actual state of the environment. The points below set the boundaries.
- Scope of use: A POA&M is for deficiencies the contractor must correct to meet the requirement, not for ongoing vulnerabilities with no fix date.
- Deadline: The fix must occur within 180 days. Entries that roll forward without evidence of progress weaken the record.
- Evidence of progress: Keep change tickets, configuration output or test results that show each milestone was reached.
- Consistency: Each entry should align with the system security plan and the affected assets in the asset inventory.
- Owner and approval: Name an accountable person for each item and keep the approval record in final form.
Before the assessment, confirm with your C3PAO or self-assessment lead how they want POA&M items presented and whether any requirement is ineligible for a POA&M.
An operational plan of action is the mechanism tied to CA.L2-3.12.2 for tracking vulnerabilities that exist in an ongoing way and do not have a remediation timeline in the same sense as a POA&M. Under 32 CFR 170.4, it is distinct from a POA&M. Under 32 CFR 170.24(b), a temporary deficiency that is properly tracked in an operational plan of action is assessed as MET. That scoring outcome depends on the deficiency being genuinely temporary, documented in the right place and tracked to resolution. An operational plan of action does not cover a requirement that was never implemented, and it does not replace the system security plan. The assessor reads it to see whether the contractor knows the gap exists and is managing it.
- Temporary status: The deficiency must be a short-term condition, such as a patch awaiting a maintenance window, not a permanent design choice.
- Tracking record: Each item needs an identifier, a description, the affected requirement, and the compensating activity that continues in the meantime.
- Review cadence: Show that the plan is reviewed on a schedule the contractor sets and records the result of each review.
- Closure: When the vulnerability is resolved, record the closure with evidence so the item does not linger.
- Link to the SSP: The system security plan should describe the operational plan of action process so the assessor can trace it.
Ask your assessor how they expect the operational plan of action to be laid out before you rely on it for scoring.
An enduring exception is a long-term condition in which full compliance with a requirement is not feasible for a particular asset. Common examples named in the rule include medical devices, test equipment, operational technology and Internet of Things devices. Under 32 CFR 170.24(b) and 170.4, an enduring exception that is documented with mitigations in the system security plan is assessed as MET. The key is the documentation. The exception must be written into the system security plan, identify the asset and the requirement it affects, explain why full compliance is not feasible, and describe the mitigations that reduce the risk in the meantime. Whether the assessor accepts the exception depends on their reading of that documentation, so the write-up needs to be specific and internally consistent.
- Identification: Name the specific asset class or system, not a broad category that could cover systems the contractor did not intend to exempt.
- Feasibility rationale: Explain the technical or operational reason that full compliance cannot be applied to this asset.
- Mitigations: Describe the controls that reduce exposure, such as segmentation, access restriction and monitoring.
- Boundary: Show how the asset is isolated from the CUI environment so the exception does not reach beyond its intended scope.
- Review: Record when the exception was last reviewed and whether the rationale still holds.
Before the assessment, check with your assessor that the exception write-up meets their reading of the documentation, because scoring is not automatic.
Which evidence type fits which requirement family
This table pairs common evidence types with generic CMMC requirement families to show what an assessor usually expects to examine, who produces each artifact, and how long it stays current. The rows are illustrative, not a control-by-control mapping, so check each requirement ID against NIST SP 800-171A objectives. The main takeaway is that every artifact must be in final form, approved, dated and hashed before it counts.
| Evidence type | Typical families it supports | Who produces it | How long it stays valid |
|---|---|---|---|
| Approved policy or procedure | Security assessment, awareness and training, incident response | Organization owner, approved by management | Valid only when final, approved and in force; keep every version for six years |
| Configuration export or baseline | Configuration management, system and communications protection | Administrator, exported from the system | Valid for the period it reflects; re-export after each approved change |
| Log sample with time stamps | Audit and accountability, identification and authentication | System generating logs, pulled by the administrator | Needs a sample covering the assessed period; retain for six years |
| Vulnerability scan report | Risk assessment, system and information integrity | Scanning tool operated by the organization or its service provider | Assessors typically look for recent scans; confirm the currency expected in the CAP |
| System or asset inventory | Configuration management, media protection, maintenance | IT or asset management team | Must match the live environment at assessment time; date and hash each version |
| Ticket or change record | Configuration management, flaw remediation, maintenance | Change board or service desk, system-generated | Shows approval and implementation; keep the original record, not a retyped copy |
| Interview record | Any family where personnel practice must be confirmed | Assessor records what staff describe | Confirms practice only when consistent with documents and tests; cannot replace them |
| Demonstration or test result | Access control, multifactor authentication, boundary protection | Live system observed by the assessor during the assessment | Valid for that assessment; capture screenshots or logs and hash them if retained |
What usually causes evidence to fail review
Most CMMC evidence failures are not missing controls. They are documents and records that an assessor cannot accept as final, current, dated and tied to the assessed boundary. The five cards below cover the gaps that appear most often and the checks that catch them before an assessor does.
Stale vulnerability scan results
A scan report from months ago does not show that vulnerabilities are being found and remediated today. Assessors look at the scan date, the scanner version, the scope of assets covered and whether the findings were tracked to closure under RA.L2-3.11.2. Before the assessment, run a current scan across the in-scope boundary, keep the report with its timestamp, and record how each finding was fixed or entered into a POA&M or operational plan of action.
Screenshots without timestamps
A screenshot of an access setting or log configuration proves little unless the assessor can see when it was taken and which system it came from. Undated images also invite questions about whether the setting was changed afterward. Capture evidence with the system clock visible or export the configuration directly, include the hostname and date in the file name or header, and store the export alongside the hash record the assessment team will ask for.
Policies never approved
A policy in draft, or one with no owner signature and approval date, is a working paper, not evidence. Under 32 CFR 170.24(b), a requirement is MET only when its objectives are satisfied with evidence in final form, and unapproved policies are not acceptable. Confirm that each policy and procedure that supports a Level 2 requirement has a named approver, an approval date, a version number and a review cycle, and that the version the staff follow is the version on file.
Inventories that do not match the boundary
An asset inventory that omits systems inside the CUI boundary, or lists devices that are no longer there, undermines every control built on it, from configuration baselines to access reviews. Assessors compare the inventory against the system security plan and the network diagrams. Reconcile the inventory with directory, network discovery and cloud account records, and confirm that each CUI asset, and each system that can reach one, appears with an owner and a status.
Exceptions without SSP mitigations
An exception for equipment that cannot meet a requirement, such as test equipment, OT or certain medical devices, is accepted as MET only when it is documented with mitigations in the system security plan. A verbal explanation or a note in a ticket is not enough. For each enduring exception, describe the asset, the requirement it cannot meet, the compensating controls and the boundary segregation, and make sure the SSP version the assessors receive contains that entry.
Evidence questions buyers ask before an assessment
Can we submit draft policies as CMMC assessment evidence?
No. Under 32 CFR 170.24(b), a requirement is MET only when all applicable assessment objectives are satisfied with evidence in final form. Working papers, drafts and unapproved policies are not acceptable, so the document an assessor reads must be the approved version that the organization actually follows. In practice, that means a dated or approved policy, a system security plan at its current revision, and records showing the control operated after the approval date. Gaps often appear when a policy was rewritten shortly before the assessment and no operating records exist yet. Before you start, confirm with your assessor how they want approval records presented, such as a workflow export or a signed PDF, and whether a screenshot of a draft from a collaboration tool is ever accepted. Assume it is not.
How long must we keep CMMC assessment evidence?
Six years from the CMMC status date. For a Level 2 self-assessment, 32 CFR 170.16(c)(4) requires you to keep the artifacts used as evidence for six years. For a Level 2 certification assessment, 32 CFR 170.17(c)(4) adds that you must hash each artifact with a NIST-approved algorithm, give the C3PAO the artifact names, hash values and algorithm for upload to eMASS, and retain the hashed artifacts for the same period. Retention is your obligation, and it continues after the assessment ends. Plan for storage that remains readable for years, access controls that keep evidence unaltered, and a named owner who can retrieve any file on request. Ask your assessor whether they expect the hash record in a specific format and how retained files should be indexed.
Can a partner produce our CMMC evidence for us?
A partner can prepare the systems, configuration exports, log settings, inventories and documentation that evidence depends on, but the organization still owns its controls and must be able to show that they operate. Independent assessors are the only parties that issue findings or certification. For Level 2 certification, that means a C3PAO authorized or accredited by The Cyber AB, as described in 32 CFR 170.9. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own environment and prepares systems and evidence for assessment. It does not issue reports, attestations or certificates. Most engagements are fixed-scope, so ask which artifacts the partner will produce, who will review them internally, how hash values will be recorded, and who keeps the files for the six-year period.
Is a POA&M item scored as MET in a CMMC assessment?
Not automatically, because a POA&M and an operational plan of action are different records. Under 32 CFR 170.4 and 170.21, a POA&M covers assessment deficiencies that must be fixed within 180 days. An operational plan of action, tied to requirement CA.L2-3.12.2, tracks ongoing vulnerabilities that have no remediation timeline. Under 32 CFR 170.24(b), temporary deficiencies properly tracked in an operational plan of action are assessed as MET. Do not assume that an open item in a POA&M will be credited the same way. Before the assessment, confirm with your assessor which category each open item belongs in, what the tracking record must contain, and whether the owners, dates and status updates are documented well enough to support the score.
Can we fix a NOT MET requirement during the assessment?
Yes, within limits. Under 32 CFR 170.17(c)(2), a NOT MET requirement may be re-evaluated during the assessment and for 10 business days after the active assessment period, provided additional evidence exists, other MET results are unaffected, and the Assessment Findings Report has not been delivered. The re-evaluation works on evidence that already exists. A fix made during that window is only credited if it produces records of operation that the assessor can examine, interview staff about and test. Keep a dated change record for every fix, collect operating evidence as it is generated, and confirm with your assessor how they will receive the new evidence and by what date it must arrive. Work that falls outside this provision needs a separate plan, so confirm with your assessor how it will be handled.
How do assessors test whether a CMMC control works?
Assessors use the three methods in NIST SP 800-171A: examine, interview and test. The CMMC Assessment Process v2.0 requires all three, and assessors apply nonstatistical sampling at the FOCUSED value for depth and coverage, increasing the sample when evidence is questionable. For illustrative purposes, if a configuration baseline applies to every workstation, the assessor may choose a sample of machines, ask to see the configuration, interview the administrators who maintain it and check a live system. Much evidence collection may be done virtually by mutual agreement. Under the DoD Assessment Methodology, High assessments can review recent scanning results, system inventories, configuration baselines and multifactor authentication settings without network access by assessors. Ask which systems and people will be sampled, and which evidence can be shared remotely.
Are enduring exceptions for OT and test equipment scored as MET?
Yes, when they are documented properly. Under 32 CFR 170.24(b) and 170.4, an enduring exception covers situations where full compliance is not feasible, such as medical devices, test equipment, operational technology or IoT. An enduring exception documented with mitigations in the system security plan is assessed as MET. The documentation should state why full compliance is not feasible, which requirements are affected, what compensating mitigations are in place, and who owns them. The record must also match what is running on the network, so a device that changes role or moves to another segment needs its entry updated. Confirm with your assessor that your wording and mitigations meet their expectations, and keep each exception under review as equipment and configurations change.
How DeployOpen prepares systems and evidence ahead of the assessment
DeployOpen plans, builds and documents self-hosted open-source platforms inside your own environment so the evidence an assessor examines is produced in final form. We prepare systems and evidence; the organization owns its controls, and only an independent assessor or certification body issues the result.
How we scope
- Engagements are fixed-scope, with systems, requirements and deliverables agreed in writing before work starts.
- Scope names which requirements, systems and enclaves produce evidence, and which assets are documented as exceptions.
- Confirm with your assessor and sponsor which assessment objectives and sampling expectations apply to your environment.
How we build
- We configure self-hosted platforms so logs, baselines, inventories and access records are generated automatically.
- Each artifact is captured in final form, versioned and dated, with the owner and approval recorded.
- We test evidence collection in a dry run so examine, interview and test steps work before the assessor arrives.
How we hand over
- You receive an evidence register mapping each requirement to its artifacts, owners and locations.
- Hashing procedures, with the algorithm and artifact names, are documented for submission and six-year retention.
- Documentation covers the system security plan, plans of action and enduring exceptions, written for your assessor to read.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support can cover gap fixes during the assessment window, reviewed with your team before anything is changed.
- Ask any provider to confirm how they will keep evidence current between assessments and who signs each artifact.
