What a Forgotten 1972 Growth Model Tells Us About Cybersecurity That CMM Never Could
The thunderheads of the afternoon storms are exploding out of the swamp we call Florida, and I can hear, likely over twenty miles off, the early booms of the ox carts of thunder rolling across the sky. I am sitting here with a Blue Moon, from a glass, thank you, sketching out an idea I pulled from the dustbins of the past. I like doing digital archeology, because in this business it is about the last thing anyone will bother to do. In graduate school I was told more times than I can count that nothing in my citations could be older than five years or I was not taking the work seriously. The joke turned out to be on them. Today I am panning one framework that has been around longer than most junior SOC analysts, and reviving, like some kind of technology necromancer, another one from back when I was young and computers were the size of rooms. The beer is cold. The clouds are starting to strobe. You can feel the change coming in your bones. Even cybersecurity can change.
I have a question, and I am going to ask it twice, once now and once at the end. Where are you in this? And when I lay out the crises that follow, have you lived through these, or others I have not thought to name?
The old machine nobody runs anymore
In 1972 a management professor named Larry Greiner published an article in the Harvard Business Review called “Evolution and Revolution as Organizations Grow.” He revisited it in 1998 and added a sixth phase. The piece is a classic in the strict sense, meaning everyone cites it and almost no one reads it, and the part they cite is the wrong part. People remember Greiner for his stages. Creativity, then direction, then delegation, then coordination, then collaboration. They turn him into a ladder, a set of rungs you climb, and in doing that they throw away the only idea in the paper that matters.
Greiner’s real claim is not that organizations pass through stages. Everybody has stages. His claim is about the engine. You do not advance because you decided to advance. You advance because whatever you are doing right now works, and it keeps working, right up until its own success creates a problem it cannot solve. That problem is the crisis. The crisis is what forces the change. As Greiner put it, managers get to watch a major solution in one period turn into a major problem in the next (Greiner 1998). You do not graduate by getting better at the thing you are already good at. You graduate when the thing you are good at stops being enough, and the failure shoves you into a new way of working.
Every calm stretch of growth ends in a specific, named crisis, and the crisis is always the child of the growth that came before it. The informal, everybody-knows-everything energy of a startup works until there are too many people to run by hallway conversation, and that is the crisis of leadership. You solve it by bringing in real management and real structure, and that structure works until the people running the functions know more than the center does and the center becomes a bottleneck, which is the crisis of autonomy. And so on up the line, each solution laying the seed of the next failure (Greiner 1972).
That last part is the whole reason I dragged this old machine out of the barn. The founder of the model, revising his own work twenty six years later, drew a sixth phase and did not name its crisis. He left the box empty (Greiner 1998; Young 2016). The man who built the thing admitted the last crisis was unknown. I find that honest, and I find it useful, and I will come back to that empty box.
The ruler (measurement stick, not despot) we mistook for an engine
Now the framework I am here to pan, and I want to be precise about the panning, because I have friends at the institution that built it and because being sloppy here would be both unfair and lazy. In 1986 Watts Humphrey left IBM and joined the Software Engineering Institute at Carnegie Mellon. The Air Force had a problem. The Department of Defense was buying software from contractors and had no reliable way to judge, before writing the check, whether a given contractor could actually deliver. Projects ran late, budgets blew up, code shipped broken. Humphrey was asked to build an instrument the government could use to assess a contractor’s process capability, and by September of 1987 he had the preliminary maturity questionnaire in hand (SEI 2001; CIO Wiki). By 1993 the SEI had formalized it as the Capability Maturity Model, five levels running from initial chaos up to optimizing (Paulk et al. 1993).
That origin tells you exactly what CMM is for. CMM was born as a procurement screen. It was an instrument for a buyer to rank suppliers at a single moment in time. Is this vendor a level 2 or a level 3, and therefore do I trust them with this contract. That is a measurement problem, and CMM is a fine answer to it. It measures. It compares. It gives you a defensible, repeatable snapshot.
What is never claimed for it is that it explains motion. It has no theory of why an organization moves from one level to the next. It has no crisis engine. It is a ruler, and a good one, and somewhere along the way we took that ruler and draped it over a completely different problem, the problem of how a security program actually matures over time, which is not a measurement problem at all. It is a problem about force and failure and change.
This is where the security industry went wrong, and I say this as someone who has sat through more maturity assessments than I care to admit. We adopted the ruler as if it were an engine. C2M2, the NIST CSF tiers, BSIMM, the CMMC apparatus that now governs whether shops like mine can even bid on defense work, all of it inherits the CMM shape, and the shape counts upward. You get scored, you get a heat map, the heat map becomes the deliverable, and the score stands in for a diagnosis it was never designed to provide. The model tells you your height. It says nothing about what makes you grow, and worse, the ladder framing quietly lies to you about the driver. A ladder implies the thing moving you up is ambition. Climb, better yourself, reach the next rung. But that is not what moves a security program at all. What moves a security program is trauma. You get hit, and the pain forces the change. The ruler cannot see that, because a ruler only knows where you are standing, not what is about to knock you off your feet.
None of that is a knock on Humphrey or the people at the SEI who still do serious work. They built exactly what the Air Force asked for. The error is ours, the practitioners who took a comparison tool and pretended it was a map of growth.
Where security refuses to behave
Greiner’s engine goes into the security program and runs, but in two places security flatly refuses to behave the way Greiner’s companies do. A model you cannot break is a model you do not actually understand, and I should name the places my extension strains before someone reads the strain as me misreading the original.
The first difference is where the crisis comes from. Greiner’s crises are internal. His companies grow, add people, and the coordination burden they created for themselves becomes the thing that breaks them. The crisis is a byproduct of their own success, generated from inside. Security is not like that. Our crises come mostly from outside, from an adversary who gets a vote. Which means a security program can be forced into a phase transition before it is anywhere near ready, by an attacker who does not know or care that you have not finished the previous phase. A company never has to face the red tape crisis until it is big enough to generate red tape. But a small, half-built shop can absolutely get taken apart by a nation-state actor tomorrow morning. The adversary gets a vote and sets the tempo, not your growth rate. The clean, sequential march that the firms he studied get to walk becomes violent and out of order the moment a human enemy is the one deciding when your quiet time ends.
The second difference is that in Greiner, each crisis is resolved by a structural change and then the old structure is genuinely superseded. Phase two’s directive management gets replaced by phase three’s delegation. The old way goes away. In security, the earlier phases never end.
You do not finish hygiene and move on like you washed your car on Sunday. You are still patching and still running multifactor in year ten while you also run the SOC and the analytics (measurement of everything). The phases stack, they do not swap. Which means your real maturity is not which phase you are in. It is how many phases you are sustaining at once without letting any of them rot like roadkill in the Florida sun. A shop with a shiny machine-learning detection stack and lapsed patching is not advanced. It is a phase-one failure wearing a phase-four costume.
Both of those are the reason the borrowed model we call a machine because it does work has to be modified before it fits, and they are also what makes the security version more dangerous than the original.
The engine, running hotter
You start with hygiene. Patching, multifactor, asset inventory, configuration management, access control. This is prevention, and it is static. You are building walls and trusting the walls to hold. And hygiene works for a good long while, and yes it genuinely works. Right up until you get hit hard by a new emergent threat you haven’t seen. The breach is the crisis. It is the precise moment prevention proves it cannot solve the problem in front of it, because prevention assumes you can keep everyone out, and the breach is standing proof that you cannot. That is not a maturity score ticking up a notch. That is Greiner’s revolution, the hard punctuation between one era and the next.
What the breach forces is not more of the same. A breach or major incident forces a different philosophy. Usually hiring a new CISO even though the old one could have told you what to do and might have a year ago. There is a reason I drink bourbon.
You stop assuming the walls hold and you start assuming compromise is inevitable and you had better be able to see it when it happens. That is detection. SIEM, logging, a SOC, incident response, the whole apparatus of knowing when someone is inside. It requires a different mindset, different tooling, a different team with different skills. Likely a run to HR for additional people and different knowledge, skills and abilities. And you could not have stood it up on day one even if some consultant had told you to, because you did not yet have the telemetry, the tuned baselines, or the organizational scar tissue to know what you were even looking for. The previous phase is what produced the raw material this phase runs on. Skip hygiene and your SIEM drowns in noise from problems you should have fixed at the root.
Then detection capability matures, and it too works until it breaks. Lots of companies start out just detecting everything and actioning very little. You have to build capability. You have the SOC, you have the correlation rules, and you get hit again, but differently this time.
We all know when something unique not just a zero day but an actor with a different skill set. It is something the signatures never caught, something slow and quiet that looked like normal traffic. That is the next crisis, and notice it is a crisis of your detection model specifically, the same way Greiner’s crisis of autonomy is a crisis of the very centralization that the prior phase installed. You can’t get here unless you’ve done the other stuff. Rule-based, known-bad detection cannot catch the unknown-bad. So now, and only now, you reach for behavioral analytics, anomaly detection, the machine-learning tier everyone wants to buy on day one.
And you cannot buy it on day one. Not because someone forbids it, but because the machine needs exactly what the earlier phases produce. Clean data. Established baselines. I can tell you sitting here in the heat of Florida it is hot but if I tell you it’s 90f and 95% humidity I’ve measured it and know just why the beer is sweating as much as I am. An analyst team that knows normal well enough to tell the model when it is wrong. Drop machine learning onto a shop with no hygiene and no tuned detection and you have built an extraordinarily expensive random-alert generator, and you have taught your people to ignore it inside a month.
Every arrow in that progression everybody cites is a crisis. Prevention gives way to detection because of the breach. Detection gives way to active and behavioral defense because of the miss. Active defense gives way to analytics because of the novel, low-signal attack that slips the net. Nobody moved up because they read a maturity model and wanted a bigger number. They moved because they got hurt in a way the current stage could not prevent, and the hurt forced the restructure. Most of the cybersecurity community spend so much time eating their own they never realize you grow stronger from living through the crises. Companies are organic that way. That is Greiner, and it is a far truer account of how these programs actually grow than any capability ladder.
There is a small live example of the whole idea sitting inside a document most of us cite without thinking. The current NIST digital identity guidance tells you to stop forcing periodic password rotation. People love to wave this around as license to kill their rotation policy. The actual section says two things in the same breath. It says verifiers should not require memorized secrets to be changed on a schedule, and it says verifiers shall force a change when there is evidence of compromise (NIST SP 800-63B, section 5.1.1.2). That swap trades a blind, calendar-driven ritual for an evidence-driven one. And you can only run the evidence-driven version if you have built the machinery to have evidence, meaning breach screening, monitoring, the ability to detect that a credential was compromised. The guidance is not saying rotation is dumb in a vacuum. It is assuming you did the other work. Drop rotation without the detection to replace it and you have not matured past the control, you have simply removed it and put nothing in its place. That is the skip-a-phase failure in miniature, proven with the field’s own flagship advice. Worth noting too that some regimes, PCI-DSS and certain federal contracts among them, still mandate the old rotation anyway, doctrine outliving the reason it existed.
The clay dries in the sunshine
The danger is not being at a low level. The danger is being comfortable at whatever level you reached. A CISO who sleeps good at night is nearing retirement whether he wants to or not. Between the crises there is a quiet stretch, and the quiet stretch is not rest. It is the period during which you are manufacturing your next failure, one comfortable budget cycle at a time.
Here is how a bad day happens. A program takes the resolution that got it through the last fight, the budget it fought for, the way of working it settled into, the concept of operations it wrote down, and it lets all three cure into something rigid. The clay sets Maybe I should think of this as concrete? And the setting is the vulnerability, because a fixed concept of operations is calibrated to the last adversary, never the next one. Your concept of operations and standard operating procedures are your baseline. A good CISO is going to bring a vision of the future and be able to talk about it without straining too early.
Those three things harden for three different reasons, which is why the problem is so stubborn. We see this again and again and I imagine I’m not alone. The budget hardens because it got fought for and nobody wants to reopen a settled fight. What you want to change the rules again? The way of working hardens because people build their competence and their identity around it and asking them to change it feels like telling them they were doing it wrong all along. Think about how human resources thinks about job description, labor organizations think about duties, and how employees define themselves. I can hear the concrete drying from here. Ooops I mean clay. The concept of operations hardens because it is written down, it is the official version, and written things pick up the authority of having been decided. Heck, we get audited on policies and passed on them even though they might be completely divorced from reality. Three kinds of stickiness, all pulling toward stasis, all of them perfectly adaptive right up until the environment moves under them.
Then the adversary lights it all on fire. Not breaks it, not beats the control. The adversary lights it up like Florida man with a roman candle and can of gasoline, the way fire takes a thing that has dried out and stopped bending and vaporizes it into ash and shattered careers. A living program does not burn when it gets hit, it bends and self-extinguishes whether it is stop drop and roll, or jump in the swamp with the swamp puppies. It is the cured clay that cracks and the dried-out idea that catches. The attacker is not defeating your defense so much as exploiting the fact that your defense stopped moving. Those are different claims. The first says go buy a better wall. The second says the wall was never the point, the point was whether you were still adapting when they arrived, and you were not, because you spent the sunshine hardening instead of staying wet.
This is why the advanced shop is not safe. It is the opposite. The advanced shop with everything has more to ossify. More budget locked into settled lines, more entrenched process, a more elaborate concept of operations to defend. Its clay is thicker. That is how outfits with big teams and impressive tooling get torn open by adversaries who were simply more current than they were. Their sophistication turned to sediment while the sky was clear.
If you know your Boyd, you already hear it. Yep I am using a fighter pilots words once again. The program that hardens its concept of operations has stopped cycling. It has locked its orientation to the last engagement, and it is now fighting inside a picture of the threat that the threat itself has already left behind. The enemy who is still adapting is turning inside a defender who quit turning, and the breach is just the moment that lag becomes visible. Think about how we see adversaries use the same low level failures that should never have been useable in a certified organization. So the real maturity signal is not which tools you have reached. It is your refractory period, how long you stay hardened after a win before something forces you to move again. The mature program rewets its own clay on purpose. It reopens the settled budget and interrogates the settled concept of operations before an adversary shows up to do it for free.
The second climb, the one that actually stops you
Everything above is the technical story, and if that were the whole story then maturing a program would just be a matter of engineering. It is not, and any working CISO knows it is not, because there is a second climb running right alongside the first one, and the second climb is usually where you die. On a hill. With a bunch of other CISOs. And your two years of tenure in the company.
Think about what each technical crisis demands of you organizationally. The breach that pushes you from prevention to detection also pushes you to go ask leadership for real money and to go ask IT for log access and endpoint agents on systems they own and do not want you touching. You cannot build the SOC without winning that fight. The move from detection to active response means you are now taking actions that interrupt the business, isolating hosts, killing sessions, blocking things in the middle of the workday, and if you do not have the relationships and the pre-agreed authority to do that, the business overrides you every single time and your active defense is theater. The analytics tier needs data from every corner of an organization that has no reason to hand it to you unless you have spent years earning the standing to ask.
So the technical curve and the political curve are the same mountain. That’s on fire. Every technical transition has a matching organizational one, and the organizational one is almost always the real barrier. This is the leadership crisis Greiner named, made concrete for our world. The founding CISO builds hygiene on force of personality and relationships, and that works, exactly the way Greiner’s founder-driven first phase works, right up until the program has to institutionalize. I’ve been exactly here a few times and have the scars to prove it. Budget lines instead of favors. Service agreements with IT instead of hallway deals. Delegated authority to act during an incident instead of the CISO personally calling the CIO at midnight. That is the leadership crisis, the moment personality-driven security has to become structure-driven security or it caps out for good. Most programs die right there. Not for lack of tooling. Because they never made the relationships load-bearing instead of personal.
The second climb towards the oxygen-thinning air has its own weather, its own way of drying out in the sun, and it shows up as three things people say to you when you ask for what the next phase needs. I have heard all three more times than I can count, and they are not three versions of one no. They are three structurally different refusals, and each one defeats a different weapon in your kit.
The first is the sunshine refusal. No breach, no budget. A good CISO bringing a program along asks for more, and the company looks out the window at the current weather and says no, it is clear out. This is roofing logic, and it is exactly backward. A roof is a thing you build when it is sunny, because you obviously cannot shingle in a downpour. I have a whole metaphor about blue tarps, hurricanes and cyber incident response but I won’t bore you. The company is pricing risk off today’s weather and treating the absence of a breach as evidence of safety, when the absence of a breach is just the absence of a breach and carries no information about the monsoon. The rain is coming. I cannot tell you the day. That missing date is precisely why the argument loses in the room, because I cannot produce one and they read no date as no threat. This refusal defeats your urgency. You sound like you are crying wolf. Most CISOs seem to move on after fighting this for a few board report cycles.
Here is rapid diagnostic for an incoming CISO before you blame your predecessor. How many board reports asked for funding and went unfunded before the dastardly dude you followed moved on. If the number is three, tag you’re it, and good luck.
The second is subtler, and people misread it as the same no said louder. Somebody somewhere in the c-suite or board says something about funding like If we gave you every dollar in the company we could not run the business, and you still could not tell us we are secure. This one is dangerous because it starts from something true. There is no dollar figure that buys done. Any CISO who promises secure is lying. But leadership have taken that truth and drawn exactly the wrong conclusion from it, that because there is no finish line the race is not worth running. You do not insure a house because insurance stops it burning. You insure it because it changes what the fire costs you. Leadership is demanding a guarantee and rejecting the work for offering only loss reduction, which is like refusing a seatbelt because it cannot promise you will survive the crash. The seatbelt was never selling survival. It was selling a better spread of outcomes. This refusal defeats your competence. It concedes you are good and says it does not matter, so being right buys you nothing.
The third “No” is the quietest and the most lethal, and it is not even a no. Have you ever heard, “Let us put that in the parking lot with the other ideas, and we will circle back when the synergy is right.” A no is a decision, and a decision you can argue with, escalate, revisit. This is a refusal wearing the mask of a maybe, and it strips you of the one thing a hard no would leave you, something to push against. The parking lot is where ideas go to die precisely because nothing in it was ever killed. It was tabled, and tabled things have no owner, no date, no forcing function, so they rot by neglect while everyone keeps deniability that they were ever turned down. Synergy is the perfect word for the condition that never arrives, because it is undefined on purpose. There is no test for whether it is right, so there is no moment the item is allowed to come back. This refusal defeats your standing to even be answered. There is nobody across the table.
Security is change. Change is hard. It’s easier to say no than admit growth is going to require blood and treasure. Line these versions of no up and they are not random. They are an escalation in how sophisticated the organization’s immune response to security has become. We do not believe you. Then, we believe you and we do not care. Then, we will not dignify the question with a decision. Here is the cruel part, that progression runs inversely to how much the organization seems to understand security. The sunshine shop is naive and at least leaves points arguable. The futility shop sounds informed and is unreachable by evidence. The parking-lot shop is procedurally mature. It has evolved a way to metabolize every security concern into permanent non-action while looking entirely reasonable in the minutes. The organization got more sophisticated and used the sophistication to build better-disguised refusals.
Notice too that each refusal hardens one of the three dimensions of clay from the last section. The sunshine no hardens the budget. A CISO shop runs on cash and bourbon. The futility no hardens the concept of operations, because it is a settled belief about what security can and cannot deliver, and settled beliefs are doctrine. For some reason I think when I hear this one of tinker bell sprinkling fairy dust in the execs coffee mugs. The parking-lot no hardens the way of working, because the tabling ritual is a process doing exactly what an ossified process does, protecting the organization from having to change. I have a graphic somewhere with a CISO a dozen knives in his back. That’s this version of no. Three refusals, three dimensions, all curing while the sky stays clear.
This all tells you what the CISO’s real job is across these phases, and it is not technical. The job at its heart is arson prevention on your own program, and specifically it is learning to answer each refusal in its own language. Let’s be honest you do not beat the sunshine no with more alarm. What you do is beat it by pricing the roof against the monsoon in dollars they already understand, expected loss, not maybe-someday. You do not beat the futility no with a better security argument. What you have to do is beat it by killing the guarantee frame outright and replacing it with risk reduction they would accept anywhere else in the business, the way they already think about insurance and redundancy and hedging. Of course you do not beat the parking lot with patience, because patience is what it eats alive like the swamp puppies eat fried chicken. No I don’t feed them. How you beat it is by refusing the maybe and forcing a real decision, making them say no on the record so it becomes a thing with an owner and a date you can reload against, instead of a ghost in a lot. Getting that answer is critical and I have seen boards that can wiggle out of that trap more ways than an invasive python at the round up. A CISO who brings urgency to a futility no, or evidence to a parking-lot no, has brought the wrong weapon to the wrong fight and will lose while being completely right on the merits. Being right was never the bottleneck. Being right in the language the refusal is written in, that is the bottleneck, and almost nobody teaches it.
The empty box
Back to the sixth phase. Greiner drew it and left the crisis blank. He did not know what came after collaboration, and rather than invent something he left the box empty and said so. When you admit you don’t know you make something bigger than you had with all the answers.
I think he had the right posture to end on, because I do not think the three refusals I just described are the complete set. They are the three I have hit most often, standing in front of the people who hold the money, at so many consultancies’, at the Corps and Harley and BCBSMA and at UKG and now here. I suspect there is a fourth that lives at the very top of the curve, and it does not sound like a no at all. It sounds like a yes. I think it is. the enthusiastic yes that funds you fully and then quietly strips your authority to act, security as a well-paid ornament, a line item that proves the company is serious right up until the ornament is asked to actually stop the business from doing something profitable and stupid. I have seen the ghost of it and can perceive it. I just have not mapped it the way I have mapped the other three. Maybe you have.
So here is the question I told you about at the start. Where are you in this? Are you still building walls in the sunshine, or did you already take the hit that taught you to watch? Have you made your relationships load-bearing, or are they still favors that leave with you when you go? Which refusal did you get the last time you asked for what the next phase needed, and did you answer it in its own language or bring the wrong weapon?
And the empty box is yours as much as mine. I have named the crises I have lived. If you have hit one I did not name, the fourth refusal or the fifth, the crisis after collaboration that even Greiner left blank, then you know something the model does not yet contain, and I would genuinely like to hear it.
The clouds have stopped strobing and opened up. The rain finally came. I still could not have told you the day.
Works Cited
Greiner, Larry E. 1972. “Evolution and Revolution as Organizations Grow.” Harvard Business Review 50, no. 4: 37 to 46.
Greiner, Larry E. 1998. “Evolution and Revolution as Organizations Grow.” Harvard Business Review 76, no. 3: 55 to 68. Reprint of the 1972 article with the author’s commentary adding a sixth phase, whose terminal crisis is deliberately left unnamed.
Humphrey, Watts S. 1989. Managing the Software Process. Reading, MA: Addison-Wesley. The first full formulation of the process maturity framework underlying CMM.
National Institute of Standards and Technology. Digital Identity Guidelines: Authentication and Lifecycle Management. NIST Special Publication 800-63B. Section 5.1.1.2 on memorized secrets establishes that verifiers should not require periodic rotation and shall force a change on evidence of compromise. Available at nvlpubs.nist.gov.
Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. 1993. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24. Pittsburgh: Software Engineering Institute, Carnegie Mellon University.
Software Engineering Institute. 2001. People Capability Maturity Model, Version 2. Pittsburgh: Carnegie Mellon University. Documents Humphrey’s 1986 arrival at the SEI, the Air Force request, and the September 1987 preliminary maturity questionnaire.
Young, Sam. 2016. “Greiner’s Organizational Growth Model.” Note observing that the sixth phase added in 1998 carries no named crisis. samyoung.co.nz.
About the Author
