Your SPRS score is a representation to the government
This is the part that makes people uncomfortable, and it should. A score posted in SPRS is a representation made in connection with federal contracts. Posting a score you cannot substantiate is not a paperwork problem. It has been the basis of False Claims Act settlements against contractors.
If your current score was produced by a vendor questionnaire, a rushed spreadsheet, or an optimistic reading of what your MSP told you, the responsible move is to re-assess honestly and post a corrected score along with a genuine POA&M. A lower, defensible score with a credible remediation plan is a far stronger position than a 110 that evaporates under examination.
How the scoring actually works
The DoD Assessment Methodology starts you at 110 and deducts points for unimplemented requirements: 5 points for the highest-impact controls, 3 for significant ones, and 1 for the rest. Two requirements have partial-credit provisions. The floor is -203, and yes, plenty of companies genuinely start there.
Because the deductions are weighted, remediation sequencing matters enormously. Closing three 5-point requirements moves your score more than closing fifteen 1-point items, and the 5-point requirements are also the ones that can never be deferred onto a POA&M under CMMC. We plan around that arithmetic.
- 5-point requirements: the controls the DoD considers most critical to protecting CUI
- 3-point requirements: significant contributors to a defensible security posture
- 1-point requirements: important, but lower individual impact on the score
- Partial credit exists for a small number of requirements, and we apply it correctly rather than optimistically
A System Security Plan that survives contact with an assessor
The most common SSP failure is a document that describes an idealized environment instead of the one you actually operate. Assessors compare the SSP to reality. When they diverge, the SSP becomes evidence against you.
We write your SSP from the environment outward: system boundary, architecture, data flows, and then a control-by-control description of how each requirement is implemented here: which product, which setting, which policy, who is responsible. It is longer and less pretty than a template. It is also the version that holds up.
- System description, boundary definition, and network architecture
- Inventory of in-scope assets, including specialized and contractor-risk-managed assets
- Control-by-control implementation narratives tied to real configuration
- Roles, responsibilities, and named accountable individuals
- Change history so the document demonstrably stays current
POA&M discipline
A POA&M is not a place to park inconvenient requirements indefinitely. Under CMMC the rules are strict: you must already be at 88 of 110 or better, only lower-weighted requirements are eligible, and everything has to close within 180 days with verification.
We build POA&Ms that are actually executable, giving each item a named owner, a resource estimate, a milestone date, and a defined closure artifact. Then we drive them to closure rather than handing you a spreadsheet and walking away.