[mc32]

Problem for companies is clients will ask for this or that certification (a due diligence checkbox they have little control over). Also unless you’re a big co., there is no way a service provider will let small co. customer interview the security and development teams and let you audit their security practices, etc. So at that point a known low bar is better than an unknown unset bar.

[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.