A self-assessment score you can defend, a System Security Plan that describes the system you actually run, and Plans of Action written to close rather than roll forward. Our principal has taken an environment to 110 of 110 controls with zero open items.
Anyone can produce a self-assessment score. The question an assessor, a prime, or a DIBCAC reviewer asks is what the number was measured against, and whether the system still looks like that.
The 110 requirements expand into 320 assessment objectives. A control marked met at the requirement level frequently fails at the objective level, and that is where scores collapse under review.
A Plan of Action is a commitment with a date attached. We write them to be closed, not carried forward, because carried-forward items are the ones that get read as bad faith.
Somebody upstream wants your score, and the number currently in SPRS came from a process nobody can now reconstruct in enough detail to defend it.
Self-assessment, third party, or a government review. The sensible move is to know what will be found while there is still room to act on it.
The same items sit on the Plan of Action cycle after cycle. This is almost always an ownership problem rather than a technical one, and naming it as such is usually the unlock.
All 110 requirements tested at the objective level, evidence sampled rather than asserted, with a written basis for every determination so the position survives staff turnover.
Identity, logging, media protection, configuration baselines and access review cycles, written as specifications your team or your provider can build to, with each requirement traced to a named owner.
Each control gets an artifact, a cadence and an owner. That is what turns a point-in-time score into a position you can hold when somebody asks about it eighteen months from now.
Written against the system you run, not the system you intended. Clause-numbered and control-mapped so an assessor can trace a claim to a configuration.
With the working papers behind it, so you can answer how it was derived a year from now when the person who ran the assessment has moved on.
Sequenced by risk and by what unblocks the most other items, not alphabetically by control family.
What gets produced, how often, by whom, and where it lives. The register is what survives staff turnover.
The ones that come up most often before a scoping call.
110 of 110 with no open Plans of Action is the position that ends the conversation. We have taken an environment there. Short of that, what matters is that the score is honest and the remaining items have dates somebody owns.
NIST SP 800-171 is the control standard. CMMC is the program that verifies you meet it. The controls are the same either way, which is why the CMMC assessment pause does not change the underlying work.
Often, as a starting point. The common failure is that it was written to satisfy a request rather than to describe a system, so it claims controls the configuration does not enforce. We read it against the environment and tell you which parts hold.
We document it honestly, implement a compensating control where one exists, and put it on the Plan of Action with a date. Assessors are considerably more forgiving of a known gap with a plan than of a control claimed and not operating.
Yes, and that is usually the right structure. They know the environment and they hold the keys. We bring the control interpretation and the evidence discipline, write the work in terms they can execute, and review what they deliver. Keeping the specification and the build in separate hands is deliberate.
© 2026 CARMhaus Consulting LLC. All rights reserved. Cybersecurity · Assurance · Risk Management
We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.