Validating a NIST implementation problem: translating engineering procedures into policy
I’m looking to validate a pattern I’ve seen in NIST-aligned compliance work, especially at companies under roughly $1B in revenue.
The problem is that GRC, security, and engineering often hold different parts of the same context, and the translation between them is weak.
A policy owner may need to document training, secure development practices, review cadence, control ownership, and evidence requirements. They go to engineering leadership for answers: what training is mandatory, how often it is refreshed, who owns it, and how completion is tracked.
Engineering may have real practices in place, but those practices often do not exist in the format compliance expects. A team may not have “Python training” because Python proficiency is part of hiring. Secure development may happen through code review, architecture review, internal standards, threat modeling, incident reviews, and senior engineer mentorship. Those mechanisms can be meaningful, but they are rarely written in a way that maps cleanly to NIST language or audit evidence.
The result is often generic policy: accurate enough to pass review, but too abstract to change behavior, which in my opinion NIST is what it's all about. It creates work for GRC, creates translation burden for engineering, and produces documents that describe obvious expectations instead of real operating practices.
I’m trying to understand whether this is a common, costly problem or just something I’m seeing in a narrow slice of organizations.
For those who have worked with NIST CSF, 800-53, 800-171, SSDF, or similar frameworks: have you seen this policy-to-engineering translation gap, and does it create enough recurring pain to be worth solving?