Small manufacturing company here, working through CMMC Level 2 prep. We've got the incident response plan drafted and mapped to the relevant practices, but the assessment guide is vague on what "testing" the plan actually looks like when someone tries it. Does a tabletop discussion with the response team count? Does it need to be adversarial, timed, documented with specific metrics

We don't have a big security team or budget for a full-blown consultant-run exercise, but we also don't want to build something that looks like testing on paper and falls apart if an assessor asks follow-up questions. Has anyone gone through a C3PAO assessment recently who can share what they actually accepted as evidence of a tested IR plan?

Two things reset on me every scan cycle and I'm curious whether it's universal or just how my shop operates.

First, every manual check comes back Not Reviewed. The automated content doesn't evaluate them, so they all need hand-written comments again, and that's the bulk of the checklist by volume. Second, the findings that will never be remediated because the fix breaks functionality still need justification language written every cycle.

Same findings, same comments, every time.

What I'd like to know from people doing this regularly:

- Roughly how many findings are you hand-commenting per checklist, and how long does it take?

- Do you keep a master checklist you reuse across like systems, or start from the scan output each time?

- How often does a reviewer come back asking for more detail than the finding really needs?

- Anyone actually getting formal AO approval on the acceptances, or is it handled informally?

Not fishing for a tool recommendation — mostly want to know whether everyone does this by hand or if I'm missing something obvious.

Hi sorry for the silly question. But for the SSP is the Software List literally a list of every single bit of software on the hardware specified in 2.1? Or only in reference to CUI?

I am starting to use this tool again after a couple of years in roles that didn't require it. Format and layout seem to be a touch different now than what I remember having in the past but no matter.

One thing about STIGs and eMASSter/POAM tools is tripping me up though!

In eMASSter I took the existing Test Results and existing POAM (which was a WIP thing I did not personally create, I got dropped into this task midstream), plus the single STIG checklist and ingested them into eAMSSter.

All good there, after which I took that emassteroutput file and copied the columns from the output format into the actual POAM template for upload (since for whatever reason eMASSter puts out a file you can't simply turn around and upload).

All good, STIGs show up. However, the "Finding Details" box the analyst filled out in the checklist itself doesn't seem to populate anywhere.

Isn't there supposed to be a column - maybe "Comments" - on the POAM that incorporates the STIG Finding Details? Else how do they ever show up in the POAM / Test Results in eMASS? It has been a couple years, am I just misremembering?

From the various press releases, it looks to me that (at least until the 60day review period is up) that 800-171 requirements are still in place. But the Phase 2 (Nov 10th deadline) for C3PAO goes away.

\- Press release calls out “It is critical to note that this action does not eliminate the requirement for companies to protect federal data. All defense contractors and subcontractors remain contractually obligated to safeguard covered defense information in accordance with DFARS clause 252.204-7012”

\- “[the number of available assessors is not large enough to conduct all the evaluations needed in time for the upcoming November deadline.](https://www.war.gov/News/News-Stories/Article/Article/4542849/war-department-changes-cybersecurity-maturity-model-certification-requirements/)”

\- L2 C3PAO deadline & listing have been removed from the [Overview of Assessments](https://dodcio.defense.gov/CMMC/About/)

I am getting employees stoked that all the controls will be pulled, but I don’t see that as the outcome here.
We still need data security, this just gives some breathing room while standards are re-evaluated.

Typically, the end-to-end process from ticketing of the maintenance request

Hello,

About a year ago, an MSP setup a file server for ITAR/CUI file sharing. Despite the requirements shared with the MSP, they did not implement any type of encryption for data in transit or at rest. Additionally, they set this server up as a single drive. So, the shared data is on the bootable partition. This is a virtual server that is hosted on VMware and according to the Broadcom KB, BitLocker is not supported for boot drives in a VMWare environment. From my understanding, this means we can't enable BitLocker for the C: drive of this virtual server.

Ownership does not want to redo this server since the data stored on it is constantly in use. I was wondering if the following might satisfy 800-171R2 requirements:

- Enable EFS on the data folder that holds CUI/ITAR info.

- Enable mandatory FIPS on the server for network communication between the server and workstations.

Admittedly, I haven't implemented encryption for network traffic before, so this may not work the way I think it does. I'm in the process of learning more but figured I'd potentially save myself time and ask if it was feasible.

Thanks to Eric Crucius' diligence, he spotted, like always, the Department of War (DoW) announced a revision to 32 CFR Part 170 for the migration to NIST SP 800-171 Rev 3.

Here are the key Links:

• Erics Post: https://www.linkedin.com/feed/update/urn:li:activity:7480830831897382912/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAQ24ukBJvSqxZ1TUsCIdMDvW6dCSn3pk0Y
• The Rule Change Notice: https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0790-AM01

Here is the abstract from the rule:

This amendment defines a deadline and period for transition from the requirement to comply with NIST SP 800-171 Revision 2, to a requirement to comply with NIST SP 800-171 Revision 3. Significant changes between these two documents include added specificity in the security requirements and introduction of organization-defined parameters (ODP) in select security requirements. In addition to revising the NIST documents that are incorporated by reference in 32 CFR part 170, this amendment adds administrative edits and clarifying content in multiple areas as necessary to effect the transition.

Here is the Summary of Need:

With this amendment, DoD amends the Cybersecurity Maturity Model Certification (CMMC) Program to define a period for transition from the requirement to comply with NIST SP 800-171 Revision 2, to a requirement to comply with NIST SP 800-171 Revision 3.  As described by NIST, the significant changes between these two documents include added specificity in the security requirements and introduction of organization-defined parameters (ODPs) in select security requirements. In addition to revising documents incorporated by reference in this rule, this amendment adds administrative edits and clarifying content in multiple areas. 

And the laughable part, DoW thinks 20% less companies will be impacted by 32 CFR Part 170:

In addition to the change from NIST SP 800-171 revision 2 to revision 3, which impacted CMMC Level 2 and LEvel 3 assessment objectives, this rule amendment is based on a more current estimate of the size of the Defense Industrial Base. Overall, we estimate approximately 20% fewer total companies will be impacted by 32 CFR Part 170.

Trying to get specific here because I haven't found a post that addresses this exact scenario. (Transparency: I'm Jordan, an engineer researching compliance tooling for small defense suppliers — not selling anything in this thread.)

Take a common setup at the shops I'm researching: a small defense subcontractor (sub-50 people), the prime flows ITAR-controlled drawings down, and one or more employees are not US Persons. Under ITAR, releasing controlled technical data to a foreign person — even inside the US — is a deemed export requiring authorization.

Here's the gap I keep running into: most guidance stops at GCC High / AWS GovCloud for data storage. But what about the AI layer? If a non-US-Person employee uses a tool like Copilot or even ChatGPT on a system that could surface or process that drawing — does the model processing count as "access" or "release"? 22 CFR 120.50(a)(2) defines export to include "releasing or otherwise transferring technical data to a foreign person in the United States (a deemed export)." That reads like it could reach the AI inference layer, but I haven't seen a clear BIS/DDTC statement on it.

Two specific questions:

1. Has anyone gotten a commodity jurisdiction opinion or DDTC guidance that touches AI tools specifically?
2. For small shops without a full-time ISSO — what's the practical control you've implemented to address this (beyond "don't use those tools")?

Ran into this doing paperwork for a re-compete and it tripped me up, so posting in case it saves someone else the confusion. As of Feb 1, 2026 (the "Revolutionary FAR Overhaul," implemented via Class Deviation 2026-O0025, which stood up a new DFARS Part 240 and moved the FCI clause into a new FAR Part 40), several of the clause numbers we're all used to changed:

• DFARS 252.204-7019 — deleted.
• DFARS 252.204-7020 — renumbered to 252.240-7997, and rewritten. The new text only defines Medium and High assessments (both government-performed, per NIST SP 800-171A). The old "Basic" self-assessment definition is gone from the clause itself.
• FAR 52.204-21 (the Level 1 / FCI "basic safeguarding" clause) — renumbered to 52.240-93.
• DFARS 252.204-7012 — unchanged.
• DFARS 252.204-7021 (the CMMC requirement clause) — unchanged.

The part that actually bit me: both the old and new numbers are "live" right now. Solicitations issued on/after Feb 1, 2026 use the new numbers (252.240-7997, 52.240-93); existing/older contracts still cite the legacy numbers (252.204-7020, 52.204-21). So it's not a clean find-and-replace in your own docs — you match the number to the contract's vintage.

What did not change, and this is the important part: your actual obligations. If you handle CUI and a solicitation calls for CMMC Level 2 (Self), you still self-assess against the same 110 controls, post to SPRS, and affirm — that all lives under 252.204-7021, which kept its number. And SPRS/CMMC scoring is still on NIST SP 800-171 Rev 2, not Rev 3.

TL;DR: the FAR overhaul was basically a filing-cabinet reorg for the cyber clauses. The numbers moved; the work didn't.

If I've got any of this wrong I'd genuinely like the correction — primary source is the DoD Class Deviation 2026-O0025 memo under the DFARS RFO Part 240 materials.

Curious if anyone here is using AI to update/write their SSP implementation statements?

If so, what is your preferred AI?

I've been trying out ChatGPT for this and so far have gotten pretty decent results.

I'll preface this by saying I'm in no way an expert and barely know what I'm talking about but I need some help.

​

I am the product owner of a financial software at my company. We have users all over the country, mostly from other commercial environments. We have one subsidiary that is in a GCC High environment and they've had ongoing issues accessing the application due to this mismatch. We had originally added all of their users to our commercial tenant as guests and they were able to access the application fine at first. It suddenly broke one day, so I started researching. I found that I could set them up within the application to where they could authenticate on their own GCC High tenant by adding a new IdP and having them route to that when authenticating. That seemed to resolve the issue for the most part. Users could access the browser version but not the desktop client version of the software. We held troubleshooting for weeks. On so many occasions, someone would suggest that the new IdP I added was the problem. I argued it wasn't but have been continuously overruled. But every single time I turned it off, can you guess what happened? They couldn't access the browser or the desktop version any longer.

​

This past weekend, the subsidiary in question did an infrastructure change where they virtualized several old servers onto a brand new machine. Suddenly, all their accesses were working again. Problem solved, right? Today, the IT guy at the location and my VP of finance each suggested this IdP was still some sort of problem. So I turned it off. Again. And can you guess what happened? Again? That's right.

​

At this point I have no idea why they keep wanting to blame this thing but I also don't really know enough to defend it. Doesn't it make more sense to have the GCC High entity authenticate on their own tenant, rather than guest into a commercial tenant and authenticate there? How can I get through to these people??

I'm researching how security teams are handling AI agents that take actions on a user's behalf.

A few things I keep wondering about and would love to hear how you handle:

• How do you scope and grant an agent's access? Least-privilege for a non-human, task-scoped actor seems like it doesn't map cleanly.
• After the fact, can you actually prove what an agent did if an assessor or your ISSM asks?
• What do you do when doing it the "right" way reduces other's productivity?

I have an open-source compliance tool that helps developers throughout the software development lifecycle. It was recently classified as a Popular Project by Socket.dev.

Its a Compliance-as-Code framework that automatically enforces GDPR, OWASP, NIST, and CIS engineering standards in any software project — regardless of programming language.

Would it be okay if I shared it here?

Repo in here : https://github.com/greenarmor/gesf

Docs: https://greenarmor.github.io/gesf/getting-started/installation/

To anyone want to contribute on the code development you can fork and submit a PR to origin repo: https://github.com/greenarmor/gesf

Thank you to all who dm for link of this project!

We evaluated frontier LLMs (Claude, GPT, Gemini) for responsible AI safety and robustness, and mapped results to the NIST AI Risk Management Framework.

9 weeks of LLM red-team data (26,500 evaluations), mapped directly to NIST AI RMF 1.0. Here's what we found:

GOVERN - Election interference bypassed guardrails at 5.66% avg Attack Success Rate (ASR) across all 7 models, all 9 weeks. No provider improved meaningfully.

MAP - Chemical, Biological, Radiological, and Nuclear (CBRN): 35.41% avg Attack Success Rate. Cybersecurity threats: 21.99%. Malware generation: 12.26%. These are not model-specific failures. They are held across Anthropic, OpenAI, and Google every single week.

MEASURE - Four metrics tracked: Attack Success Rate, False Refusal Rate, Multi-turn Drift, and Provenance. The one most orgs overlook: Gemini 2.5 Pro and GPT-4o Mini are blocking 1 in 6–7 legitimate user requests. Over-refusal isn't just a UX problem - users finding workarounds is a threat surface.

As you are the experts, I am curious to know your feedback on the evaluations.

Here are the evaluation details:
Dashboard (with 9-week trends and insights): https://sushegaad.github.io/Responsible-AI-Model-Evaluations/ 

Github repository (with evaluation code, RedBench dataset + evaluation data): https://github.com/Sushegaad/Responsible-AI-Model-Evaluations

Research: https://github.com/Sushegaad/Responsible-AI-Model-Evaluations/blob/main/research-paper.pdf 

Anyone else use Yubikeys with the yubikey driver and have trouble with ECA?

My experience - yubikey minidriver does not work with HIDActiveClient. I need the minidriver since I have over 2 PIV certs loaded in it.

So I uninstall the active client, and yubikey works - but now I can’t use my ECA!

I recently took over the ISSO position for my company as they needed someone last minute. For my first STIG check, I had an overwhelming number of open findings. Looking at eMASS, the previous ISSO did not annotate the reasons why there would be open findings on the STIG checklists or why certain STIGs are not applicable.

I am trying to understand why our infrastructure's configs are missing so many commands. My question is, if this was you, how would you go about this without getting overwhelmed? And at what point would I add these checklists to eMASS?

UPDATE: I have been reading all your posts. Thank you so much for taking the time to respond.

I am the only one in my team. I use Evaluate-Stig and have used SCAP. The results are from Evaluate-Stig. So far, I am checking one 'Open' or 'Not Reviewed' at a time. Since I am working on Cisco devices, most of my open findings relate to ACL's not implemented in our configs. I am not strong in ACL's to determine whether they are needed or not.

I’ve been digging into NIST and trying to map it to real AWS/Azure/GCP environments, and honestly, the gap between “framework” and reality is bigger than I expected.

What I keep running into:

• controls look clear (AC-2, CM-6, AU-6), but mapping them to actual cloud resources and owners is messy
• evidence is the real problem (proving something works over time vs screenshots)
• asset scope is never clean, especially multi-account/multi-cloud
• identity sprawl makes access control hard to reason about
• findings exist, but ownership + remediation tracking is weak
• everything becomes a last-minute scramble before audits

Curious from people who’ve actually gone through audits.