Death by a 1000 Frameworks

Somewhere along the way, cybersecurity turned into a certification arms race.

SOC 2. ISO 27001. HITRUST. NIST. CIS. PCI DSS. CMMC. HIPAA. GDPR. The list keeps growing, and so does the pressure to add another certification to the website.

Certifications have value. They can provide independent validation that an organization has established certain controls and is meeting defined requirements. Customers want assurance; regulators have expectations, and audits serve an important purpose.

But at some point, we should ask a simple question:

Sometimes it does. Sometimes it doesn’t.

When Compliance Becomes the Work

A company gets one certification. Then a customer asks for another. Then another customer requires a different framework.

Before long, security teams are maintaining multiple frameworks that often address many of the same fundamental capabilities: monitoring, identity protection, logging, incident response, vulnerability management, and access controls.

From one framework to another, the terminology changes, the control numbers change, but the actual security outcomes often don’t.

That’s where frameworks can actually start working against us, despite the best intentions. Teams spend more time mapping controls, collecting evidence, and answering questionnaires and potentially less time improving the security capabilities those controls are supposed to represent.

Teams can often get wrapped up in meeting compliance needs, which continue to grow, without solving for the intent behind the control. With mounting and overlapping requirements, there is less time to focus and build intentional security programs that deliver the outcomes the frameworks are intended to solve.

When the Letter of the Control Misses the Outcome

Take, for instance, the requirement for complex passwords as part of an organization’s access controls. Why are complex passwords important? They help make brute-force attacks, dictionary attacks, and credential stuffing more time-consuming for the threat actor, raising the barrier to entry for successful malicious activity and increasing the chances that detections in place will alert teams to an attack before it succeeds.

But if an organization has single sign-on implemented across its SaaS applications, along with an MFA requirement, should the security team still spend equal effort mandating complex passwords for every downstream app and following legacy guidance to rotate those passwords every 90 days?

NIST itself moved away from mandatory periodic rotation in SP 800-63B because forced rotation tended to produce predictable patterns, such as incrementing a digit or swapping a symbol, rather than genuinely stronger credentials. In doing so, requiring credentials to rotate periodically could satisfy the letter of the control without delivering the security outcome it was meant to produce.

There’s a practical reality in the world of compliance: many frameworks mandate the literal control regardless of compensating measures, unless the framework has an explicit compensating-controls or risk-acceptance pathway.

As a result, even the most aware, intentional, and diligent security teams are somewhat hampered by the fact that reallocating effort away from legacy controls like rotation isn’t just an internal team decision. It typically requires building the case with an auditor or assessor and getting it documented as an accepted risk or compensating control, with leadership ownership.

That can easily be a heavier lift than it sounds, and it’s worth planning for rather than assuming it’s the way.

Where an MSP Fits

For organizations relying on an MSP or MDR provider, security shouldn’t become another compliance silo.

Your security provider should be helping you operate the capabilities that matter: detecting threats, monitoring identities and endpoints, investigating suspicious activity, and responding when something happens.

Those capabilities can then support multiple compliance requirements. MSPs should aim to follow this general rule of thumb as a best practice:

That’s a very different approach from building a separate security program every time another framework appears, which isn’t just inefficient, but in most cases unnecessary.

Not Every Company Needs Every Certification

Nothing drives this point home more than the uncertainty that has plagued U.S. federal compliance in recent years: shifting CMMC rulings on unstable timelines and revamped FedRAMP pathways that keep even seasoned compliance professionals second-guessing themselves.

It’s not just hard on MSPs; it’s hard on compliance professionals too. But for any organization, MSP or otherwise, remember this: there is nothing wrong with saying, “We don’t need that certification.”

A healthcare organization has different requirements from a defense contractor. A global enterprise has different needs from smaller businesses. One organization may benefit significantly from a certification while another may gain little from pursuing it.

At the end of the day, everything the business does is a business decision. It should be backed by sound business logic and weighed in accordance with company objectives, priorities, and constraints.

Build Security for the Outcome, Not the Badge

A guiding principle for any organization’s security team, MSPs included, ought to be this: don’t build security for the badge. Build the security program that makes the badge meaningful.

Frameworks aren’t the enemy. Certifications aren’t the enemy. More often than not, the problem is when the badge becomes the goal.

At Blackpoint, we’ll say it plainly: when a threat actor shows up, they don’t care how many certifications are on your website, whether you’re SOC 2 compliant, or whether you’ve automated your DSAR process. They care about one thing: whether you can see them, understand what they’re doing, and stop them before it matters.

That’s the outcome every framework in this article is ultimately trying to produce, and it’s the exact outcome Blackpoint’s Security Operations Center is built to deliver, 24/7/365.

See What That Looks Like in Practice

Explore how Blackpoint’s SOC operates and see the threat actors and techniques our teams are stopping in compliant, regulated, and well-managed environments through our Threat Intelligence and Research.

Explore the Blackpoint SOC →