CMMC Artifact Engineering: Building Documentation Assessors Accept

Picture a contractor with every technical control in place. Splunk is ingesting logs. MFA is enforced. Firewall rules are tight. The team walks into its C3PAO assessment confident, and the findings that come back are documentation problems: artifacts that can't be traced to specific NIST SP 800-171 requirement IDs, evidence files with no timestamps, and policies that reference system boundaries from a network architecture decommissioned months earlier.

That scenario is illustrative, but the risk is real. A CMMC Level 2 certification assessment requires a MET result for every applicable security requirement, and the security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2 ^[1][2]. Assessors judge what you can show them. Contractors can spend heavily on security tooling and still struggle because their *proof* of those tools working doesn't meet assessor expectations.

If you're preparing for a CMMC assessment, look hard at your artifact engineering, not only your security posture. And fixing it requires a fundamentally different mindset than most compliance programs teach.

Why Technical Controls Pass but Evidence Fails

Assessment trouble often doesn't come from an access control system that doesn't work. It comes from evidence about that system that fails on three dimensions: format, staleness, and traceability.

Format failures look like this: an assessor asks for proof of AC.L2-3.1.1 compliance, and you hand them a screenshot of your Azure AD user list. That screenshot has no date stamp in the image metadata, no correlation to the specific NIST control, and no indication of who generated it or why. It's a picture, not an artifact. System-generated reports with verifiable integrity are stronger evidence than manual screen captures; that is our recommendation, not a stated rule.

Staleness hurts quietly. Access control logs can be current while the evidence package that maps them to requirement IDs hasn't been refreshed since the initial self-assessment. Evidence should reflect your *current* operational state, so set a refresh cadence for continuous controls like access management and audit logging (30 days is a reasonable internal target) instead of updating once a fiscal year.

Traceability is the gap between "we do this" and "here is time-stamped proof we do this consistently, tied to a specific control requirement." Most contractors have a System Security Plan (SSP) that describes their controls in narrative form. Very few have an artifact chain where every SSP claim links to a dated, attributed, scoped piece of evidence. That linkage is what assessors actually evaluate.

Scheduling compounds the pain. If assessor calendars are full, a failed assessment costs you the remediation effort and the time to get back on a C3PAO's schedule. The business development implications are real: you can't credibly claim certification in proposals until you hold it, and vague "CMMC-ready" language gives evaluators nothing to verify.

Anatomy of an Artifact That Survives a C3PAO Demonstration

The CMMC rule itself sets a narrow floor here: the Level 2 certification assessment results a C3PAO enters into eMASS include the assessment result for each requirement objective and a list of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used ^[1]. Beyond that floor, we recommend an internal quality standard: build every artifact in your evidence package to satisfy five attributes. They are our recommendation, not a list from the rule, but missing one gives the assessor a reason to question the artifact.

• Control mapping: The artifact explicitly identifies which NIST SP 800-171 control(s) it supports, using the control ID (e.g., AC.L2-3.1.1, not just "access control")
• Timestamp chain: Creation date, collection date, and the period the evidence covers are all recorded and verifiable
• Responsible party: A named individual (not a team or role) who generated or approved the artifact
• Review cadence proof: Evidence that this artifact is part of a recurring review cycle, not a one-time collection event
• System boundary scope: Clear identification of which systems, enclaves, or CUI boundaries this artifact covers

Here's the practical difference. A screenshot of your MFA enrollment dashboard is weak evidence. A system-generated report from Azure AD's sign-in logs, exported as a CSV with SHA-256 hash verification, mapped to IA.L2-3.5.3, timestamped with the export date, attributed to your ISSO by name, and tagged with the CUI enclave identifier: that's an artifact that passes.

Your naming convention matters more than most contractors realize. I recommend this schema: `{ControlFamily}-{ControlID}_{EvidenceType}_{YYYY-MM-DD}_{Version}`. For example: `IA-3.5.3_SignInReport_2025-06-15_v2.csv`. When an assessor asks for evidence on a specific control, this naming lets your ISSO locate the right file quickly. Generic names like "MFA_Evidence_Final_v3_REAL_FINAL.pdf" signal to assessors that your evidence management process is ad hoc.

Three Requirements Where Evidence Often Falls Short

Three requirements show the evidence problem clearly: AC.L2-3.1.1, IA.L2-3.5.3, and SC.L2-3.13.1. They are continuous controls, so a one-time snapshot rarely proves them. Use them as the pattern for the rest of your package.

AC.L2-3.1.1: Authorized Access Control

This requirement says to limit system access to authorized users, processes acting on behalf of authorized users, and devices ^[3]. Strong evidence is automated provisioning and deprovisioning logs with timestamps, showing that when an employee is terminated, the account is disabled within your defined SLA and that the disablement is logged with a timestamp and correlated to an HR action. What most contractors produce instead: a quarterly access review spreadsheet where a manager checked boxes next to active usernames. That spreadsheet proves you did a review. It does not prove your account management process works continuously.

Stronger evidence: An automated export from your identity provider (Okta, Azure AD, AWS IAM) showing account creation/deletion events over the last 90 days, with each event tagged to a ticket or HR system record.

IA.L2-3.5.3: Multifactor Authentication

This requirement says to use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts ^[3]. Showing that MFA is enrolled is not the same as showing MFA is enforced. Strong evidence is the Conditional Access policy configuration export (from Azure AD, Duo, or your IdP) proving that MFA is required for all users accessing CUI systems, with no exceptions. Add sign-in logs showing that MFA challenges are actually occurring, not just configured.

Stronger evidence: The Conditional Access policy JSON export plus 30 days of sign-in logs filtered to CUI-scoped applications, with any exceptions explained.

SC.L2-3.13.1: Boundary Protection

This requirement says to monitor, control, and protect communications at the external boundaries and key internal boundaries of organizational systems ^[3]. Network diagrams should reflect *actual* CUI data flows and the boundary devices that control them. A separate requirement, SC.L2-3.13.11, says to employ FIPS-validated cryptography when used to protect the confidentiality of CUI ^[3], so label the encryption points at each boundary crossing as well. A Visio topology map from 2022 that shows your network segments but doesn't trace where CUI moves is weak evidence for both.

Stronger evidence: A current-state architecture diagram with CUI data flows annotated, FIPS-validated encryption modules identified by certificate number, and boundary devices listed with firmware versions.

Engineering an Automated Evidence Collection Pipeline

NIST SP 800-171 R2 organizes its security requirements into fourteen families ^[3], and gathering evidence for all of them by hand every cycle is slow and error-prone. Estimate your own labor hours before you pick tools; the architecture matters more than the price tag.

A pattern that works well follows three stages: SIEM collection, evidence broker, and versioned repository.

Your SIEM (Splunk, Microsoft Sentinel, or equivalent) already collects the raw telemetry. The evidence broker is a lightweight orchestration layer, typically PowerShell or Python scripts running on scheduled tasks or cron, that queries your SIEM and other source systems, formats the output into control-mapped evidence packages, and deposits them into your artifact repository.

Here's a simplified example of a PowerShell script that pulls Azure AD sign-in logs and packages them as a control-mapped artifact:

# Evidence collection for IA.L2-3.5.3 (MFA Enforcement)
$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-dd")
$endDate = (Get-Date).ToString("yyyy-MM-dd")
$logs = Get-MgAuditLogSignIn -Filter "createdDateTime ge $startDate" -All
$export = $logs | Select-Object UserPrincipalName, CreatedDateTime, 
    MfaDetail, AppDisplayName, ConditionalAccessStatus
$fileName = "IA-3.5.3_SignInLogs_${endDate}_v1.csv"
$export | Export-Csv -Path ".\artifacts\IA\$fileName" -NoTypeInformation
$hash = (Get-FileHash ".\artifacts\IA\$fileName" -Algorithm SHA256).Hash
"$fileName,$hash,$endDate,ISSO-JSmith" | Out-File -Append ".\artifacts\manifest.csv"

The repository itself should be Git-backed (for diff-able version history) or SharePoint with immutable audit logs enabled. Git is preferable because it gives you native version control: assessors can see how a policy document evolved over time, not just its current state.

Artifact freshness rules should vary by control type. A practical internal schedule: refresh access management and audit evidence every 30 days, configuration management evidence quarterly, and training and personnel security evidence annually. Build your cron schedules around these windows.

Building a Defensible Artifact Repository Across All 14 Control Families

Your folder structure should mirror the fourteen NIST SP 800-171 R2 requirement families exactly ^[3]. No creative reinterpretation.

Keep artifacts under version control. It is a practice we recommend rather than a stated CMMC requirement, and it pays off when an assessor asks about the *history* of a policy, not just the current version. If your Acceptable Use Policy was last updated in 2021 but claims to cover a CUI enclave you stood up in 2024, that's a contradiction that triggers deeper scrutiny. Git commit history or SharePoint version history provides that diff trail.

Role-based access to the repository itself matters. If you give assessors direct access, make it read-only for the evaluation window. Artifact owners (your ISSO and control leads) need write access. Nobody gets delete permissions. If you're using Git, enforce branch protection rules that require pull request approval before any artifact modification.

From Repository to Live Demo: Surviving the C3PAO Walkthrough

Stored artifacts are necessary but not sufficient. Expect an assessor to ask your ISSO to show evidence live during the assessment, for example by picking a control and saying, "Show me your current access review process. Pull up the evidence right now."

Your ISSO should be able to locate, generate, or display the relevant artifact quickly. Evidence nobody can produce on request does little for you, regardless of what's in your repository.

Build a demonstration runbook keyed to each applicable requirement. Each entry should include the pre-staged query or report generation command, the system where the evidence lives, and the expected output format. For example, the runbook entry for AU.L2-3.3.1 might read: "Open Splunk > Run saved search 'CMMC_AU_3.3.1_AuditEvents' > Export last 30 days as CSV > Verify hash against manifest."

Run a mock assessment before the real one. Schedule a half-day tabletop where someone plays the assessor role and randomly selects 20 controls. Give your ISSO a fixed time box per control (five minutes is a useful internal target) to produce the artifact. Track success rates and fix every miss before the real assessment.

Common live demo failures:

• Broken links: Evidence stored in a SharePoint site that was reorganized since the last collection cycle
• Expired credentials: The service account used to query the SIEM had its password rotated and nobody updated the evidence collection scripts
• Contradictory artifacts: The network diagram in SC.L2-3.13.1 shows three CUI enclaves, but the access control artifacts in AC.L2-3.1.1 only reference two

Proposal Narratives: "CMMC-Certified" vs. "CMMC-Ready" and Why Evaluators Care

Government evaluators can check CMMC claims in proposals. Saying "we are CMMC compliant" with no certificate number, no validity date, and no SPRS score context reads as a vague assurance, not a discriminating strength.

Specific language matters. Compare these two statements:

*Weak*: "Our organization is CMMC compliant and follows NIST 800-171 best practices."

*Strong (illustrative template)*: "Our organization holds a Final Level 2 (C3PAO) CMMC status for the in-scope environment, with a CMMC Status Date of [date] and assessment unique identifier [ID]. Our affirmation is current in SPRS."

The strong version gives the evaluator verifiable claims, because the C3PAO submits certification results into the CMMC instance of eMASS, which transmits them to SPRS ^[1]. If your status is Conditional, say so and state the POA&M closeout date, since open items must be closed out within 180 days of the status date ^[1].

When referencing your SSP in proposal volumes, summarize your security architecture at the boundary level without exposing specific IP ranges, tool configurations, or detection rules. Reference the DFARS 252.204-7021 clause explicitly and cross-reference your compliance matrix to show the solicitation's security requirements map to your certified controls.

If you haven't yet achieved certification, be honest about your status but frame it as managed risk: "Our organization is scheduled for a Level 2 certification assessment with [C3PAO name] on [date]. Our internal review found evidence for [number] of the applicable requirements." That's materially different from "We are CMMC-ready," which gives an evaluator nothing to verify.

Your 30-Day Artifact Engineering Sprint

Week 1: Gap Audit. Pull your existing evidence package and check every artifact against the five recommended attributes (control mapping, timestamp chain, responsible party, review cadence proof, system boundary scope). Score each artifact as pass, partial, or fail. Expect a meaningful share to come back partial or failing. Start remediation with the three continuous controls above: AC.L2-3.1.1, IA.L2-3.5.3, and SC.L2-3.13.1.

Week 2: Automate the Top 10. Deploy scheduled evidence collection scripts for the 10 controls where your gap audit found the weakest evidence. Start with access management, MFA enforcement, audit logging, vulnerability scanning (pull from Tenable or Rapid7 automatically), and configuration baselines. Each script should output a named, hashed, control-mapped file into your repository.

Week 3: Build the Repository. Create your folder structure mirroring all 14 control families. Migrate existing artifacts with proper metadata. Enable version control and set access permissions. Write your artifact manifest file tracking every evidence item, its freshness date, owner, and hash.

Week 4: Simulate. Run a tabletop C3PAO walkthrough. Pick 25 controls at random. Time your ISSO on each retrieval. Document failures and fix the retrieval process, not just the artifacts.

The one metric to track weekly from this point forward: percentage of applicable requirements with assessment-ready artifacts updated within their freshness window. If that number slips, your assessment readiness slips with it, regardless of how strong your technical controls are. Pin it to a dashboard. Review it every Monday. That single number tells you more about your CMMC readiness than any consultant's maturity assessment ever will.

Start the gap audit today. Pull ten artifacts from your current evidence package and check them against the five attributes. If more than three fail, you have an artifact engineering problem, and now you know how to fix it.

References

• [1]32 CFR 170.17 CMMC Level 2 certification assessment and affirmation requirements. https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170/subpart-D/section-170.17
• [2]32 CFR 170.14 CMMC Model. https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170/subpart-D/section-170.14
• [3]NIST SP 800-171 Rev. 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf
• [4]Inside Government Contracts (Covington), "CMMC Reform Task Force Updates September 2026." https://www.insidegovernmentcontracts.com/2026/09/cmmc-reform-task-force-updates-september-2026/
• [5]Holland & Knight, "DOW Suspends CMMC Phase II Requirements." https://www.hklaw.com/en/insights/publications/2026/07/dow-suspends-cmmc-phase-ii-requirements