The gap is almost never the control
Walk into a mid-size defense supplier that has been told it needs CMMC Level 2 and you will usually find something like this: multifactor authentication is on, endpoints are managed, the network is segmented reasonably well, backups run, and somebody genuinely knows what is happening. Then ask for the artifact that proves account reviews happened in March, and the room goes quiet. That gap — between a control that works and a control you can demonstrate — is where readiness projects go from three months to eighteen.
It is worth being precise about why. Level 2 is the one hundred and ten security requirements in NIST SP 800-171. Those requirements are what you implement. But an assessment is conducted against the assessment objectives — the determination statements published in NIST SP 800-171A, which break each requirement into the specific things that must be true. A requirement is not scored on a general impression. Every applicable objective under it has to be satisfied, and a single unsatisfied objective takes the whole requirement down.
That structure is the reason a firm can be substantively secure and still score badly. Take a requirement like limiting system access to authorized users. The control is on. The objectives ask you to show that authorized users are identified, that the set is defined somewhere, and that access is in fact limited to that set. Three separate things to evidence, and the third one is a record over time rather than a setting.
Assessors work with three methods: examine, interview, and test. Examine means reading your artifacts. Interview means asking the people who do the work. Test means exercising the control — watch this account get locked out, show me this alert firing. Evidence has to hold up under all three, and the three fail in different ways. Documents fail by being aspirational. Interviews fail when the person doing the work describes a different process than the document does. Tests fail when something was configured for the assessment rather than for the business.
You are probably here because
- A consultant handed you a spreadsheet with 110 rows and an empty evidence column
- Your prime asked when you will have a status in SPRS and you do not have a real answer
- Somebody quoted you a readiness engagement measured in quarters and you want to know why
- You have a shared drive full of screenshots and no idea whether it is enough
The four-kinds-of-evidence section is the map. The twelve-week sequence near the end is the plan. If you already have a managed service provider producing monthly reports, read the last section first — you may need a librarian more than an engineer.
Four kinds of evidence, and only one of them scales
Everything you will hand an assessor falls into one of four categories. They differ in how long they take to produce, how fast they go stale, and whether a human has to touch them every month forever.
Policy. What the organization requires. Short, signed, dated, and owned by a named person. Policy is cheap to write and cheap to keep, and it is the layer people over-invest in because it is the one you can finish in a weekend.
Procedure. How the requirement is actually carried out here, on these systems, by these roles. This is where most packages are weakest, because the procedure in the binder was written by someone who does not perform it.
Configuration artifact. The state of a system at a point in time — a policy export from your identity provider, a firewall ruleset, an endpoint baseline, a group membership listing. Static, verifiable, and stale the moment something changes.
Generated record. Proof that the process ran. A ticket with a timestamp, a log retention report, an access review with an approver's name on it, a training completion export, a media destruction certificate. This is the only category that demonstrates the control operated over time rather than existed on one day, and it is the category that decides whether an assessment goes smoothly.
| Evidence type | What it proves | How it fails | How to make it self-renewing |
|---|---|---|---|
| Policy | The organization requires the thing | Written for a different company; unsigned; nobody named as owner | Short documents, one owner each, an annual review date in the same system you use for everything else |
| Procedure | Somebody specific does the thing, on these systems | Describes a process the person interviewed has never followed | Written by the person who performs it, reviewed after the first real execution |
| Configuration artifact | The system is in the required state | Screenshot from eight months ago; a setting changed and nobody re-captured it | Scripted export on a timer, written to a dated folder, never captured by hand |
| Generated record | The control operated, repeatedly, with names and dates on it | Does not exist, because the process runs by memory rather than by ticket | Route the recurring task through a system that already produces records — ticketing, HR, endpoint management |
The screenshot folder is the failure mode
The most common evidence package we see is a shared folder of screenshots, captured in a burst, organized by control family, taken by one person over two weeks. It fails for three reasons and they are all structural.
It is a point-in-time capture of something that has to be true continuously. It has no chain of custody — a cropped image of a settings page shows a setting, not which tenant, which date, or who took it. And it cannot be refreshed without repeating the entire two weeks, which means it is refreshed once, before the assessment, and never again. The annual affirmation then attests to a state that nobody has re-verified.
The replacement is not more effort. It is a different source. Almost every artifact worth having can be produced by a system you are already paying for: identity provider reports, endpoint management inventories, ticket exports, log platform retention summaries, HR training records. Write the export once, put it on a timer, land it in a dated folder, and the evidence package maintains itself. That single change is the difference between an evidence program that takes a year and one that takes a quarter, and it has nothing to do with buying tools.
There is a second-order benefit that matters more than the assessment. Evidence generated automatically tells you when a control has quietly stopped working, months before an assessor would have. A collection process that runs on human diligence tells you nothing until the diligence lapses.
Organize around objectives, not families
The instinct is to work down the fourteen control families in order — Access Control first, then Awareness and Training, then Audit and Accountability, and so on to System and Information Integrity. Do not do that. Two better orderings exist and they should run in parallel.
Order by score weight. Level 2 scoring subtracts 5, 3, or 1 point per unimplemented requirement, and the weighting is deliberately unequal — forty-two requirements carry five points each. A readiness program that works alphabetically spends the same money for a worse number. Find the five-point items and put them first.
Order by what cannot be fixed later. Six requirements can never sit on a plan of action and milestones at any score: the two access-control requirements covering external connections and control of publicly posted information (AC.L2-3.1.20 and AC.L2-3.1.22), the system security plan itself (CA.L2-3.12.4), and the three physical-access requirements covering visitor escorting, physical access logs, and management of physical access (PE.L2-3.10.3, PE.L2-3.10.4 and PE.L2-3.10.5). If any of those six is unmet, no conditional path exists regardless of your total. Check those in the first week. It takes an afternoon and it can change the whole plan.
Then, within a requirement, write the evidence against the objectives rather than against the requirement text. Pull the determination statements from NIST SP 800-171A, list them, and name one artifact per statement. When an artifact covers four statements, say so once and reference it — a good package is heavily cross-referenced and much smaller than people expect. When a statement has no artifact, you have found a real gap, and you found it in week two rather than during the assessment.
How much of a typical package can be produced automatically — our read
Our judgment from building these environments, not a survey. The two bottom rows are where a manufacturer's real work sits, and they are the ones nobody budgets for.
A twelve-week order of operations
This is not a promise that every firm finishes in twelve weeks. It is the order that keeps the calendar honest, because it puts the items with unavoidable waiting time at the front.
Weeks 1–2. Boundary and the six. Decide what is inside the assessment scope before anything else. The rule's asset categories — CUI assets, security protection assets, contractor risk managed assets, specialized assets, out of scope — are the actual budget instrument, and a firm that assesses its whole corporate network instead of a deliberately small enclave pays for a much larger assessment than the contract requires. In the same fortnight, check the six requirements that can never sit on a plan of action. Those two decisions govern everything downstream.
Weeks 2–4. Turn on the record generators. Before writing a single policy, make the systems start producing artifacts. Enable the logging you are missing, set retention, script the exports, create the dated folder structure, route the recurring tasks through ticketing. Every week you delay this is a week of history you will not have at assessment time, and history is the one thing you cannot buy later.
Weeks 3–7. The system security plan, written as you go. The plan is itself a requirement that cannot be deferred, and it is the document an assessor reads first to decide how the rest of the week will go. Write it against the objectives, name the artifacts, and keep it in version control rather than in a word processor on somebody's laptop.
Weeks 5–10. Remediation, five-point items first. Fix what is broken, in weight order. Multifactor authentication and FIPS-validated cryptography are the two requirements with partial credit built into the scoring, which makes them unusually good value: moving from partial to full implementation on each recovers points that no amount of documentation can.
Weeks 8–11. Interview readiness. The people who perform the procedures read the procedures, and where the two disagree, the document changes to match reality. This is the single most under-practiced step and it is nearly free.
Weeks 10–12. Mock assessment against the objectives. Somebody who did not write the package walks it, objective by objective, and marks each one met or not met without charity. The output is a short list, and the list is short because the previous ten weeks were spent on the right things.
What genuinely cannot be hurried
Three things resist compression, and honest planning starts by naming them.
History. Some objectives are satisfied only by records that accumulate. A quarterly access review cannot show a pattern in three weeks. Retention periods have to have actually elapsed. This is the reason the record generators go on in week two rather than week ten, and it is the single most common cause of a slipped assessment date.
Third-party dependencies. Cloud service attestations, a customer responsibility matrix from a provider, an external service provider's own status, a shared responsibility summary from a managed service provider. You are waiting on somebody outside your company to answer. Ask in week one; some of these take months and none of them take five minutes.
Physical and media controls in a real facility. Visitor logs, escorting, and controlled areas are the requirements that a software-shaped readiness program forgets and a plant already half-solves. If your business has a floor, walk it with the requirement text in hand rather than assuming the office rules cover it.
Where you do not need us, or anyone
Plenty of firms reading this can do the whole thing without outside help, and it is worth saying which ones.
If your entire environment is one identity provider, managed endpoints, and one cloud tenant, and a competent managed service provider already sends you monthly reports, your evidence problem is organizational rather than technical. Someone needs to map existing reports to objectives and set up the folder discipline. That is a careful few weeks of internal work by someone methodical, and paying an outside firm for it is paying for a project manager at engineering rates.
If you only ever handle federal contract information and no controlled unclassified information, Level 1 is fifteen requirements assessed by you, and the evidence burden is a fraction of what is described here. Confirm which category actually applies before spending anything — that determination is upstream of every decision in this article.
Outside help earns its keep in three situations: when the boundary has to be designed and built rather than described, when the record generators do not exist and someone has to write the integrations, and when an assessment is close and an independent reader is needed who has no stake in the answer. Those are engineering problems. The rest is discipline, and discipline is cheaper in-house.
The mistakes we see most
- Collecting evidence before setting the boundary — every artifact for an out-of-scope system is wasted work
- Working alphabetically through the families instead of by score weight and by what cannot be deferred
- Screenshots as the primary artifact, undated, uncredited, and impossible to refresh
- Policies written from a template that describe a company with a security operations center it does not have
- Procedures nobody who performs the work has read, which fail at the interview rather than at the document review
- Turning on logging in the final month, leaving no history for objectives that require a period of operation
- No named owner per requirement, so the package decays the week after the assessment ends
- Treating the system security plan as a deliverable rather than as the index the whole package hangs from
Before you book an assessment
- The boundary is drawn, documented, and as small as the work allows
- The six requirements that can never be deferred are confirmed met
- Every objective has a named artifact, or an honest gap on the plan
- Artifacts are generated on a timer, not captured by hand
- Enough history exists for the objectives that require a period of operation
- Each requirement has a named human owner inside the company
- The people who perform the procedures have read them and agree with them
- External providers have supplied their responsibility matrices in writing
- Someone independent has walked the package objective by objective
- The person who will sign the annual affirmation has read what they are affirming
Bottom line
Readiness stalls on evidence far more often than on security. The controls are usually closer than the client thinks and the proof is much further away, and the fix is to stop treating evidence as something you gather and start treating it as something the system produces. Set the boundary first, check the six requirements that cannot be deferred, turn on the record generators in the first month, and write against the assessment objectives rather than the requirement summaries. Do that and the calendar is measured in weeks. Skip it and the calendar is measured in the number of times somebody re-photographs a settings page.
Frequently asked questions
Enough to satisfy every assessment objective under it. The objectives in NIST SP 800-171A are the operative list, and a requirement is met only when all of its applicable objectives are met. In practice that means one artifact often covers several objectives and some objectives need a record over time rather than a configuration snapshot. The assessment process guidance published by the accreditation body describes how evidence adequacy and sufficiency are judged; read the current version rather than an older summary, because that document has been revised.
They can be, for genuine point-in-time configuration facts, when they are dated, identify the system and tenant, and are reproducible. The problem is not the format. It is using screenshots for objectives that ask whether a control has been operating, and building a package that cannot be regenerated without repeating weeks of manual capture. Scripted exports do the same job, carry their own provenance, and refresh themselves.
You can, and you will throw a lot of it away. Scope decides which systems are assessed against the full requirement set, which are documented and risk-managed, and which are out of scope entirely. Collecting artifacts for machines that end up outside the boundary is wasted effort, and the boundary decision is expensive to reverse once the system security plan is written around it.
The security requirements are identical, and a named official affirms the result in SPRS either way. That affirmation is the part with legal weight, and it does not care who performed the assessment. A self-assessment with thin evidence is not cheaper; it is the same claim made with less support behind it. Build the package as though someone else will read it, because eventually someone will.
They handle some of it, and the useful step is to get in writing exactly which requirements they cover, which they share, and which remain yours. Ask for a responsibility matrix rather than an assurance. External service providers sit inside the scoping rules and the assessment will ask how you oversee them, so their reports become part of your evidence and their gaps become yours.