5
frequencies NIST SP 800-171 Rev 2 has the client define, captured as data and confirmed
3
daily jobs: evidence staleness, the ConMon calendar, outside-change routing
0
model calls in the calendar, the dates, the monthly pack or the technology review
6
years the client keeps the evidence behind each assessment, from the CMMC Status Date
The whole pipeline
Daily jobs keep each client's records current; three buttons turn them into documents.
Read or step
Rows written
The daily jobs run in a scheduler container, never on the host, and push to the consultant's phone only when one fails. Nothing here changes a mark or the score: those stay a person's decision.
1
The calendar: the client's own frequencies
Recurring work runs at the frequency the client defined, not one we picked.
- Five frequencies, as data. NIST SP 800-171 Rev 2 has the client define how often they run a risk assessment (3.11.1[a]), vulnerability scans (3.11.2[a]), security control assessments (3.12.1[a]), SSP updates (3.12.4[g]) and malicious code scans (3.14.5[a]). Each becomes a row with a value in days.
- Start from the library, replace from their documents. Each row starts at the standard library's value. The Phase 3 document pass reads the client's own policies and keeps a frequency only when its quote appears word for word in the document.
- A person confirms each one. Only a confirmed frequency goes on the calendar; an unchecked default never sets a client's schedule.
- One open occurrence per activity. A daily job keeps exactly one open occurrence of each confirmed activity, due at its last performance plus its frequency. When the consultant records a performance (the date, who confirmed it, the evidence), the next one appears.
No invented dates. An activity with no performance on record is due the day it is first scheduled, with a note asking when it last happened. Making up a past date would put a guess on the client's record.
2
Evidence that ages
A screenshot proves a setting on the day it was taken.
- Every request has a window. From 30 to 365 days, set by the kind of artifact. Each accepted artifact gets a fresh until date: when it was collected, plus the shortest window among the requests it answers.
- Refresh due, then Stale. A daily sweep marks the request Refresh due in the last quarter of its window (at least 7 days, at most 30) and Stale once past it. The client sees both in the portal.
- Stale stops counting. A stale artifact no longer counts toward the SSP or a milestone package. The objective's mark and the score are left alone: the consultant decides whether to re-mark.
- A refresh goes back through review. A new upload reopens its request for the consultant instead of inheriting last year's decision. Once accepted, the older artifact is kept and marked superseded, never deleted.
3
The CMMC dates
Recorded once, worked out every time someone looks.
| Date | The rule | How it is worked out |
|---|
| CMMC Status Date | 32 CFR 170.4: "the date that the CMMC Status results are submitted to SPRS". A Final that follows a Conditional keeps the Conditional date. | Recorded by the consultant |
| POA&M closeout | 170.21(b): within 180 days of the Conditional CMMC Status Date, or the Conditional status expires | A countdown in the portal while it is open |
| Affirmation | 170.22(a): "after every assessment, including POA&M closeout, and annually thereafter" | Due after each assessment event, then a year after the last one recorded |
| Next assessment | Level 2 within three years of the CMMC Status Date (170.16, 170.17); Level 1 annually (170.15) | From the status date and the assessment type |
The countdown is computed when the page loads, so it is never staler than the page. Nothing reads SPRS: the dates are as current as what the consultant records.
4
Change, inside and outside
Before a tool goes in, and whenever the world around the client moves.
A technology review before adoption
NIST SP 800-171 Rev 2 3.4.4 asks the client to "Analyze the security impact of changes prior to implementation." The consultant records the client's answers about a proposed tool (what it is, what for, whether it will handle CUI or protect other systems, where it runs) and one click writes the report: the likely scope category from the same rules the inventory uses, the requirements it touches with the client's status on each, any not-applicable requirement it touches, the DFARS 252.204-7012 cloud rule if a cloud service will hold CUI, and the SSP statements and evidence that would change. We advise; the client and their Affirming Official decide.
Outside changes, routed
| Source | Goes to |
|---|
| A DISA STIG release | Clients running that product |
| A change in a FedRAMP Marketplace listing | Clients using that service |
| A rule change the consultant flags | Clients with the requirement it names in scope, or every client if it names none |
Everything arrives unreviewed. The consultant marks each change relevant, with a plain note for the client, or not; only the relevant ones reach the monthly pack.
5
The monthly review and its record
One meeting a month, and a pack the client keeps.
- Prepare. The digest and a handful of views show what came due, what the client sent, what is going stale and which outside changes are waiting.
- Meet. Calendar, refreshed evidence, changes inside, changes outside, dates ahead, next steps.
- Record. Performances with who signed them off, evidence decisions, relevant outside changes, and four short notes on the month.
- Build the pack. One click assembles the month: calendar items done, overdue and coming up; evidence received with our conclusion on each; changes; key dates; the score trend. It closes by quoting 3.12.3: "Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls." Once delivered it is marked final and never rebuilt.
The evidence trail. At each milestone (a formal assessment, an annual affirmation, a closeout) the SSP and the evidence behind every MET freeze together with a SHA-256 hash of each artifact, in a zip the client keeps: "The artifacts used as evidence for the assessment must be retained by the OSA for six (6) years from the CMMC Status Date" (32 CFR 170.15(c)(2), 170.16(c)(4)).
Decision log
The calls that shaped the Maintain phase, and when they were made.
| Decision | Why | When |
|---|
| A monthly service: walk the calendar with the client, review refreshed evidence, help with change | Show the value of staying ready every month rather than every three years | 2026-09-30 |
| One living assessment per client scope | Year-over-year comparison works without copying assessments | 2026-09-30 |
| Freeze the evidence with the SSP at each milestone | The client keeps the artifacts six years; certification assessments want them hashed and listed | 2026-10-01 |
| Stale evidence stops counting; the mark and score stay human | A stale screenshot should not prop up the SSP, and a machine should not change a mark | 2026-10-01 |
| A new upload reopens its request for review | A refresh must be judged, not accepted under last year's decision | 2026-10-01 |
| Frequencies kept only with a word-for-word quote, and confirmed by a person | The calendar is only as good as the frequency behind it | 2026-10-02 |
| Deadlines worked out on every read, from recorded dates | A countdown that is an hour stale is wrong on its last day | 2026-10-02 |
| Schedule confirmed frequencies only, and invent no past dates | An unchecked default or a guessed date would be a false record | 2026-10-03 |
| Rule changes reach clients only when a person flags them | An unreviewed summary is not advice | 2026-10-03 |
Known gaps
- No email. The client sees dates and requests in the portal and in the monthly pack; reminders by email wait on a decision about how Maintain reaches the client.
- The portal is read-only for Maintain. The client cannot mark a calendar item done or download the monthly pack there yet; the consultant records and sends.
- The significant-change check is by hand. Re-scoping, testing each not-applicable requirement and writing the note for the Affirming Official follow the runbook; the automated check is not built.
- The quarterly inventory check is by hand. Nothing prompts it except the runbook.
- A product outside our catalog gets a thinner technology review, and the catalog's FedRAMP flags are only as current as their last reconciliation.