The 320-objective problem
CMMC Level 2 has 110 controls. NIST 800-171A breaks those 110 controls into 320 discrete assessment objectives. A C3PAO grades you against the objectives, not the controls. A spreadsheet with 110 rows cannot capture which objectives within a partially-implemented control are met, which are not, and what evidence backs each. This is why most manual evidence collection efforts collapse: the unit of work is the objective, not the control.
Evidence types C3PAOs accept
- Policy. The "what we do" document — signed, dated, version-controlled.
- Procedure. The "how we do it" document — referenced from the policy, with named owners.
- Configuration. A baseline export, group policy dump, IaC manifest, or system-generated configuration report.
- Log / telemetry. SIEM output, EDR alerts, authentication logs, vulnerability scan results — operational proof the control is running.
- Screenshot. Time-stamped UI capture for controls that cannot be exported as data (e.g., admin console settings).
- Interview. Auditor interview with the named responsible party. Backed by documentation, not the only evidence.
- Inherited evidence. Cloud provider or MSSP artifacts surfaced through your SRM.
Mapping evidence to objectives
A worked example for five common controls:
- AC.L2-3.1.1 (account management): identity provider user export + JML procedure + recent provisioning ticket.
- AU.L2-3.3.1 (audit logging): SIEM ingest configuration + 90-day log sample + log retention policy.
- CM.L2-3.4.1 (baseline configuration): baseline document + IaC manifest + drift detection report.
- IA.L2-3.5.3 (MFA): MFA enforcement policy + admin console screenshot + 30-day MFA challenge log.
- SI.L2-3.14.1 (flaw remediation): patch policy + vulnerability scan output + closed remediation tickets.
Each row is one objective, multiple evidence artifacts, mapped at ingest. The trail does not work if the mapping happens at export time.
Freshness — why a 14-month-old screenshot fails
C3PAOs expect evidence that proves the control is operating currently, not that it operated once. The accepted freshness window varies by evidence type: configuration baselines within 90 days, log samples covering the last 30–90 days, policies reviewed in the last 12 months, screenshots dated within 30 days of submission. A screenshot from a year ago is not evidence — it is a historical artifact. Athena's evidence freshness radar tags every artifact with its age and flags drift before the C3PAO sees it.
How Athena automates this
Athena ingests evidence from your stack — identity provider, EDR, SIEM, vulnerability scanner, configuration tools, document repositories — and auto-links it to the NIST 800-171A objectives it satisfies. Reviewers approve or reject each link. The SSP, POA&M, and assessor evidence bundle all generate from the same ledger, so the three artifacts tell the same story by assessment day. See the workflow automation pillar for the full pipeline.