[tptacek]

That's true, but it's vitally important that companies satisfying "framework" requirements for sales enablement understand why they're doing it:

1. They should adopt frameworks only when there's certainty that the revenue coming in from the sales they enable justifies the expense of performing the framework.

2. They should minimize the scope of work they do to satisfy the framework, keeping a clear head about the fact that these are sales enablement tasks, not security program tasks.

3. They should design and execute a real security program independent of the frameworks, being careful not to let the real program get led around by the framework compliance tasks, which are unrelated to security.

The real danger with these frameworks is that people don't do (3), but rather use the framework as a runbook for building a security practice. That's a terrible idea with a terrible track record, because frameworks aren't designed to security your company, but rather to document what a consortium of IT security people, largely from huge companies with diffuse, unaccountable security teams, happen to be doing.

[0xmutt]

Absolutely nailed it with this take. This summarizes the sales enablement piece perfectly.

Unfortunately business benefit is easiest to quantify from a sales enablement perspective as opposed to a security program perspective. Agree wholeheartedly you need to do (3) to actually move the needle on security.