For many defense contractors, cybersecurity compliance eventually comes down to a number.

Your SPRS score.

You complete a NIST SP 800-171 DoD Assessment, identify the security requirements your organization has implemented, calculate the score, and submit the required information to the Supplier Performance Risk System (SPRS).

But there is a question every contractor handling Controlled Unclassified Information (CUI) should be asking:

If someone challenged that score tomorrow, could you prove it?

That question has become even more important following the suspension of CMMC Phase II requirements.

The suspension does not mean cybersecurity requirements disappeared.

It does not mean CUI protection disappeared.

And it certainly does not mean organizations should stop working toward NIST SP 800-171 compliance.

In fact, this may be one of the best opportunities defense contractors have had to examine whether their cybersecurity program is actually defensible.

The CMMC Pause Isn’t a Compliance Pause

The Department announced in July 2026 that CMMC Phase II requirements, originally scheduled to take effect November 10, 2026, were being suspended while the program undergoes review.

However, Phase I self-assessment requirements remain in place.

Separate from CMMC, existing DFARS requirements continue to require applicable contractors to protect covered defense information and implement NIST SP 800-171 requirements on covered contractor information systems.

For contractors subject to these requirements, a current NIST SP 800-171 DoD Assessment is also required at the time of award.

In other words:

CMMC may be changing. Your responsibility to protect CUI has not disappeared.

What Does Your SPRS Score Actually Represent?

A Basic NIST SP 800-171 DoD Assessment is a contractor self-assessment.

But that score shouldn’t be based on assumptions.

It should reflect the actual implementation of security requirements within your environment and be based on the system security plans associated with the covered contractor information systems being assessed.

This distinction matters.

There is a major difference between:

“We have a policy requiring multifactor authentication.”

and:

“Here is our MFA configuration, here are the systems where it is enforced, here are the users subject to it, and here is the evidence demonstrating that the control is operating.”

The first is documentation.

The second begins to demonstrate implementation.

A strong cybersecurity compliance program needs both.

Documentation Is Not Implementation

This is where many organizations can get into trouble.

A company may have:

• An Access Control Policy
• An Incident Response Plan
• A System Security Plan
• A Configuration Management Policy
• An Acceptable Use Policy
• A POA&M
• A collection of cybersecurity procedures

All of those documents may look excellent.

But what happens when you compare them to the actual environment?

Your policy might say inactive accounts are disabled after a defined period.

Is that technically enforced?

Your SSP might say MFA protects remote access.

Does it protect every applicable remote access path?

Your documentation might say audit logs are reviewed.

Who reviews them?

How frequently?

Where is that review documented?

Your policy might say CUI is encrypted.

Where is CUI actually stored?

Those are very different questions from simply asking whether a policy exists.

Start With the CUI Boundary

Before worrying about individual controls, organizations need to understand something even more fundamental:

Where is your CUI?

Consider the entire lifecycle.

How does CUI enter your organization?

Where is it stored?

Who can access it?

Which endpoints process it?

Does it move through email?

Is it stored in SharePoint, OneDrive, a file server, an engineering application, or another platform?

Do employees download it locally?

Do subcontractors receive it?

Which cloud service providers or external service providers interact with the environment?

Where does CUI eventually leave the organization?

Without understanding the flow of CUI, defining the security boundary becomes extremely difficult.

And if the boundary is wrong, everything built on top of that boundary can also be wrong.

Your SSP Should Describe Reality

A System Security Plan shouldn’t describe the environment you intend to have.

It should describe the environment you actually have.

Technology changes.

Users change.

Applications change.

Cloud services change.

Network architecture changes.

Service providers change.

Organizations migrate from on-premises infrastructure to Microsoft 365. New endpoints get deployed. Employees begin working remotely. New SaaS applications appear.

Meanwhile, the SSP sometimes remains untouched.

Eventually, the documentation and the environment become two different things.

That’s a problem.

Your SSP should be treated as a living representation of your security environment—not a document created once and forgotten.

Evidence Changes the Conversation

One of the most valuable exercises a defense contractor can perform is surprisingly simple.

Pick a security requirement you believe is fully implemented.

Then ask:

What evidence would we provide if someone asked us to prove this?

Depending on the requirement, evidence might include:

• Screenshots of security configurations
• Microsoft 365 or Entra ID settings
• Group Policy configurations
• Firewall rules
• Endpoint security configurations
• Audit logs
• Access reviews
• Vulnerability scan results
• Training records
• Incident response testing records
• Account management records
• Network diagrams
• Data-flow diagrams
• Written procedures
• Tickets demonstrating recurring security activities

The specific evidence depends on the requirement and the environment.

The important part is establishing the connection between:

Requirement → Policy → Implementation → Evidence

When those four things align, your cybersecurity program becomes much easier to defend.

Don’t Forget the POA&M

Finding a gap isn’t necessarily the biggest problem.

Ignoring the gap is.

A Plan of Action and Milestones should identify deficiencies and establish how the organization intends to remediate them.

But a POA&M shouldn’t become a graveyard where unresolved security problems live indefinitely.

Organizations should periodically review:

• What remains open?
• Who owns the remediation?
• What is preventing closure?
• Has the risk changed?
• Has the technical environment changed?
• Can any items now be closed?
• Does closing the item actually change the SPRS score?

POA&M reduction should be an active security activity.

Could Your SPRS Score Survive Scrutiny?

This brings us back to the original question.

Imagine someone reviewing your environment tomorrow.

They select several NIST SP 800-171 requirements that you scored as implemented.

They ask to see your SSP.

Then they ask your technical staff to demonstrate how those requirements are actually implemented.

Then they ask for supporting evidence.

Would all three tell the same story?

Documentation.

Technical implementation.

Evidence.

If they don’t align, your organization may have more work to do.

Use the CMMC Pause as an Opportunity

The suspension of CMMC Phase II shouldn’t be viewed as permission to stop preparing.

For organizations that genuinely want to protect CUI and strengthen their position in the Defense Industrial Base, it creates something extremely valuable:

Time.

Time to correctly identify the CUI boundary.

Time to validate your SPRS score.

Time to update the SSP.

Time to reduce the POA&M.

Time to compare policies against technical configurations.

Time to organize evidence.

Time to address problems before someone else finds them.

Don’t waste that opportunity.

NTS Solutions Can Help

At NTS Solutions, we help small and mid-sized defense contractors understand what their cybersecurity documentation says, what their technical environment actually does, and where gaps exist between the two.

Our CMMC and NIST SP 800-171 readiness services can include:

• CUI scoping and data-flow mapping
• NIST SP 800-171 gap assessments
• SPRS score validation
• System Security Plan development and review
• POA&M development and remediation planning
• Policy and technical control validation
• Evidence collection and organization
• Microsoft 365 security assessments
• GCC and GCC High readiness
• CMMC readiness assessments

Our goal isn’t to help organizations simply look compliant.

It’s to help build a cybersecurity program that can be demonstrated, documented, and defended.

Is Your SPRS Score Defensible?

If your organization handles CUI and you’re unsure whether your current SPRS score accurately reflects your environment, now is the time to find out.

NTS Solutions | Never Too Secure

CMMC Readiness | NIST SP 800-171 | CUI Scoping | SPRS Validation | Cybersecurity Compliance

Disclaimer: NTS Solutions provides cybersecurity and compliance consulting services. Information provided in this article is for general informational purposes and should not be interpreted as legal or contractual advice.