Most companies will fail these standards when their existing 'real' RISKs are correctly identified and mapped. This explains the difference between being 'compliant' and being 'secure'.
Increasingly, external regulatory bodies and laws require some level of proof that companies are implementing security controls.
To prevent unnecessary delays or fines, these requirements should be embedded in the process in the form of regular scans, embedded controls (e.g. in the default infrastructure), or in user stories.
For example, in DevOps environments all requirements related to OS hardening should be present in the default container. Development teams should not have to think about them.
