Services

CMMI

CMMI started as a software engineering process model, but the underlying idea — that an organization's processes move through identifiable levels of maturity, from ad hoc and reactive to measured and continuously improving — applies just as well to a security program as it does to a development team. I use it here in that second sense: not CMMI as a software certification, but as a lens for assessing how mature your security operations actually are.

Most security programs I see sit somewhere between "reactive" and "defined" — there are policies on paper, some processes exist, but a lot of what actually happens day to day depends on who's in the room that week rather than a documented, repeatable process. That's not a criticism; it's just where most organizations are, and it's useful to actually name it rather than assume you're further along than you are.

What maturity actually buys you

A more mature security process means incident response doesn't depend on one specific person being available, vulnerability management happens on a schedule instead of in bursts after something scary gets reported, and you can actually measure whether changes you make are improving things, instead of just assuming they are.

How I'd use this with you

I'd assess where your core security processes actually sit on a maturity curve — not as an abstract exercise, but against the processes that matter most to you: vulnerability management, incident response, change control, access reviews. Then it's about picking one or two to deliberately mature first, rather than trying to professionalize everything simultaneously, which tends to stall out.

If you want an honest read on how mature your security processes actually are — not how mature the policy documents claim they are — let's talk.