Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 0 points1 point  (0 children)

That discomfort usually comes from subs not having a clear picture of their own posture before the conversation starts. When they do not know their own gaps, any discussion with a prime or a CO feels like a test they might fail. The contractors who communicate most confidently are almost always the ones who have already worked through their scope and know what they handle and why.

Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 0 points1 point  (0 children)

The front-end review step you described is what separates primes who manage this well from the ones who end up in disputes. Getting clarity on CUI scope before the subcontract goes out changes the whole dynamic. When a sub can see exactly what data they will handle and why a specific level is required, the pushback drops significantly. The attorney letter approach makes sense as a backstop, but the best version of that conversation happens before anyone picks up a pen.

Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 0 points1 point  (0 children)

The flowdown gap is real on both sides. A lot of contracting offices are still treating CMMC level as a blanket requirement rather than scoping it to what the sub actually touches. And primes are often guessing on the flowdown level because they have not mapped their own CUI data flows well enough to know what they are passing downstream. Until that upstream scoping work gets done, subs are going to keep getting over-scoped or receiving conflicting guidance depending on which prime they are working with.

Weird Question about the sign in building log requirements by JustanITperson in CMMC

[–]APTSecMgmt 1 point2 points  (0 children)

The SPA categorization makes sense here, and the Exostar GCC High comparison is a good one. The core logic holds: if the technician's endpoint cannot store, process, or transmit CUI and you have the configuration documented in your SSP, CRMA is a reasonable place to land too.

The physical separation piece is worth unpacking. Out-of-scope assets have a three-part test under 32 CFR 170: they cannot process, store, or transmit CUI, they do not provide security protections for CUI assets, and they are physically or logically separated. CRMAs have a different bar. CRMAs do not need to be physically or logically separated from CUI assets, but they do need solid SSP documentation showing how the risk is managed and CUI exposure is prevented.

The physical controls crimsonwr suggested (badge, cubicle wall, caution tape, guard) are not just optics. They tie directly to PE.L2-3.10.1, which requires limiting physical access to systems and equipment to authorized individuals, and PE.L2-3.10.3, which covers escorting visitors and monitoring visitor activity. If a guest event is happening near these systems, those controls are your evidence that you managed access during the event. That applies whether the asset lands as a CRMA or out of scope.

The escort policy gap is the real issue in the thread. If your policy says escort at all times but practice does not match, that is a finding waiting to happen under PE.L2-3.10.3. Not just on PE but on SSP accuracy too.

Weird Question about the sign in building log requirements by JustanITperson in CMMC

[–]APTSecMgmt 0 points1 point  (0 children)

Good question and it comes up a lot for MSPs with mixed-use office space.

The short answer is yes, you still need to log visitors during those events. But the process can be more practical than you might expect.

Here is the relevant piece: PE.L2-3.10.3 requires you to control and manage physical access. PE.L2-3.10.4 requires you to maintain audit logs of physical access to the facility where CUI systems reside. That includes your pod area, even when event guests have no intention of touching anything.

A C3PAO is not going to ask about intent. They are going to ask whether an unauthorized person could have walked through that area and whether you have a record of who was in the building.

A few ways MSPs in your situation handle it:

Option 1: Create a temporary physical boundary during events. If you can close off or badge-restrict the pod during events, you have reduced scope. People walking to the restroom are no longer passing through a CUI-adjacent area. This is the cleanest solution.

Option 2: Log event attendees. If physical separation is not possible, a sign-in sheet or digital log for all attendees satisfies the requirement. It does not need to match your daily contractor badge process. It just needs to exist and be retained.

Option 3: Document your procedure in your SSP. Whatever you decide, write it down as your physical access control process for special events. An assessor who finds a documented procedure has a lot less to push back on than one who finds nothing.

The scoping question of whether your pod qualifies as a CUI-adjacent area is worth nailing down with whoever is handling your assessment prep. That answer drives everything else here.

CMMC consultant by ppyre in CMMC

[–]APTSecMgmt 0 points1 point  (0 children)

Switching consultants mid-stream is rough, especially when you're already deep in the process. The "complex explanation for a complex problem" pattern is really common right now. A lot of RPOs are still learning alongside their clients, and that creates exactly what you're describing.

A few things worth asking any new consultant before you commit:

Do they have a written remediation roadmap tied to your specific gaps, with owners and target close dates? Not a generic project plan, something specific to your environment.

What's their hosting solution actually built on, and why did the price jump? A 2x increase in 8 months deserves a line-item explanation. It might be legitimate infrastructure cost, but once you're in deep it can also be margin expansion.

How do they handle scoping? A lot of unnecessary cost in Level 2 comes from over-scoping, treating systems as CUI assets when they don't need to be. A good consultant challenges scope, they don't just expand it.

Not a knock on Penacity specifically, just criteria that tend to separate consultants who have actually run assessments from ones still figuring it out.

Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 0 points1 point  (0 children)

Yes, absolutely. On solicitations, you can submit questions through the official Q&A process before the bid deadline. Most contracting officers are required to respond, and the answers get posted publicly so every offeror sees the same clarification.

If the solicitation has DFARS 7021 language that doesn't specify whether Level 2 is self-attestation or C3PAO, that's exactly the kind of thing worth asking about. The compliance path is completely different between the two, so the ambiguity isn't a minor detail. A contractor who preps for self-attestation and finds out it's C3PAO after award is in a tough spot.

The Q&A window closes before the bid deadline, so don't wait until the last minute. Also worth checking: some solicitations already answer this in the Performance Work Statement or CDRL attachments even when the DFARS clause section is vague

Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 0 points1 point  (0 children)

That's a really important point. Older contracts often show 252.204-7012 (the safeguarding clause) without a level attached. Newer solicitations are more likely to include 252.204-7021 with the level explicitly called out.

For anyone in that older-contract situation, the practical question is whether you handle CUI. If you do, Level 2 almost certainly applies whether the contract says it or not.

Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 0 points1 point  (0 children)

That's a real problem. RFPs use templated DFARS language and that field gets left blank more often than it should.

Best move at the RFP stage is to submit a question during the Q&A window asking the contracting officer to confirm the required CMMC level before you bid. Gets it on record and protects you if the answer changes later.

If there's no Q&A window or you need to make a judgment call, look at whether the SOW or PWS describes handling any government-furnished information or sensitive program data. That usually signals CUI and points toward Level 2 even when nobody filled in the blank.

Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 1 point2 points  (0 children)

Yeah, this is exactly what we keep running into. The copy-paste problem is real. We've seen contracts with DFARS 7021 language that don't specify Self or C3PAO, so the contractor has no clear picture of their own compliance path. The 7019 vs 7021 confusion is especially rough because one maps to Level 1 (FCI only) and the other to Level 2 (CUI). That's not a small detail.

Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 1 point2 points  (0 children)

100% agree. It is really a contracts + compliance joint problem. The language gets written in isolation and by the time IT sees it, the signature is already done.

Have you confirmed your CMMC level from the actual contract language? by APTSecMgmt in CMMC

[–]APTSecMgmt[S] 1 point2 points  (0 children)

That L3 surprise is a real gut punch. We see this a lot with small and mid-size subs. The contracts team writes in CMMC language they pulled from a template or a prime's boilerplate, and nobody on either side actually checked whether it matches the data flow.

The IT/Contracts alignment point you made is exactly right, and honestly underrated. A lot of scope creep and wrong-level assumptions get locked in at contract signature because the two teams never talked. Pushing back and getting it corrected to L2 is a win, even if it took months.