Beyond compliance: Maturity models

A lot of organizations equate security with regulatory compliance–they figure out what the law requires them to do, then do precisely that.

Forward-thinking organizations don’t. They see security as a way to get and maintain a competitive advantage, and rather than measure themselves against regulations that are often nearly out of date by the time they’re approved, they measure themselves against a maturity model, which compares their practices with similar companies in similar lines of work so they can see how they measure up.

This makes sense, since a company that sells car parts has different requirements than a pharmacy chain. Advance Auto Parts and Auto Zone have a lot more in common with each other than with CVS.

And maturity models measure things that regulations don’t. Regulations just say patch your operating systems. But a maturity model will give you more credit if you slipstream your patches into your installation media so that a server hits the ground running completely up to date. And since it often takes less time to build a server than it does to patch it, you gain a competitive advantage too–building a server takes half the time, so you can do it more often if you need to. And sometimes there are advantages to having fresh servers, so if you can spin them fast, you solve problems.

Evaluating maturity models is messy work, so you generally bring in someone from the outside to do it, like Cigital. They send in a few people to interview everyone and take notes, then they spend a few hours arguing, then rack and stack you against similar companies and give you the results. The consultants are quick to emphasize your ranking isn’t really good or bad, and they emphasize it, but an observation I heard from Gene Kim recently seems relevant: The best are always getting better.

My corollary to that: If you’re not getting better, you might as well be getting worse.

Bringing in outsiders is probably the best way to get an honest ranking, but if you want to try self-assessment, the model the Department of Energy uses is free to download and use.

Organizations that want to be high achievers, even those who don’t face much in the way of regulatory compliance (such as private companies or not-for-profits), would do well to examine maturity models as a way to become more efficient, and then, once they’re headed in the right direction, keep themselves efficient and high performing. A government contractor seeking a competitive advantage would do well to add a bit of a maturity model into their mix too–that’s something most contractors aren’t doing, and, well, sometimes it shows.

The side effect is that when you’re following a maturity model, compliance is all but automatic. The reason is because compliance is a baseline, while maturity is a level or more above the baseline. The hardest part of compliance when you follow a maturity model is explaining to auditors–who are used to seeing the minimum–how you’re meeting each requirement by doing something better. For example, if the standard calls for 9-character passwords and you’re doing two-factor authentication, be prepared to spend some time explaining to the auditor that your two-factor authentication is better than the 9-character password.

But that’s the difference, come audit time. A mature organization isn’t scrambling to comply–the mature organization is spending time explaining excellence to someone used to seeing efforts that fall just short of mediocrity. Don’t get me wrong, that can be frustrating, but it’s a lot better than pulling long hours remediating findings under tight deadline.

If you found this post informative or helpful, please share it!