The stage decides the strategy.
Every organization sits in one of three stages, and the stage determines nearly everything downstream. How security money gets spent. Where people and time go. What counts as enough. How much attention the board pays, and what they ask about when they pay it.
Security strategy is rarely chosen freely. It falls out of the stage the company is in.
The three are compliance-driven, risk-driven, and steady state. Most companies can tell you which security frameworks they hold. Very few can tell you which stage they’re in, and almost none can tell you which stage they should be in. That second gap is where security programs quietly go wrong.
Stage one: compliance-driven
Security exists to satisfy someone outside the company.
Every security dollar traces to an external obligation. An HHS penalty to avoid. PCI card brand fines. A SOC 2 or ISO certificate the market won’t buy without. A customer questionnaire that has to come back clean.
The bar for enough is the framework. Whatever earns and keeps the certificate gets done, and anything past that line hits a wall immediately. The board’s attention arrives at audit time and when a deal is blocked. Otherwise it’s absent.
This is the stage everyone criticizes. It’s also correct.
An early company is scrappy and wants every available dollar pointed at revenue, customers, and growth. Its risk landscape genuinely isn’t large enough to justify more. There aren’t enough records for a breach to matter much, and there isn’t enough brand for brand damage to register. The return on a dollar of growth spend beats the return on a dollar of security spend, and it isn’t close.
Pointing that money at growth instead is close to an arbitrage play. Calling it immature misreads what the company is doing, which is allocating scarce capital correctly.
The Phoenix Project. In the novel, John Pesche, the CISO, is consumed by a stack of SOX-404 findings while the company is dying around him. The rest of IT treats him as an annoyance. He isn’t wrong that the findings are real. He’s wrong about what they’re worth, because most of those controls weren’t protecting anything the business actually cared about. The financial risk was already handled somewhere else.
Security serves the business. When the business is fighting to survive, security that outruns it has stopped serving anything.
Stage two: risk-driven
There is finally something worth protecting.
This stage begins when the company has built enough to be worth defending. The board stops asking whether you’re certified and starts asking what happens if you get hit.
The unit of work becomes the material scenario. An extended outage that trips customer SLAs and brings clawbacks, discounts, or penalties. A breach above a specific record count, whether PII, PHI, or PCI. Disclosure of confidential customer data past some threshold, where one customer might not matter and fifty does.
Material means it moves revenue or the bottom line. Risks that are merely annoying don’t qualify and don’t get funded. That distinction is the whole stage.
The posture changes
Each material scenario gets a sufficiency threshold the executive team and the board agree to, then requirements written against it, then implementation. The standing goal is that risk scenarios may well occur, but none of them is ever allowed to become material.
Compliance drops to lights-on. Still done, still audited, no longer a differentiator, no longer setting the agenda. Spend is active and project-shaped. This is the build phase of a security program, and companies stay in it a good while.
There’s no clean exit. Stage two merges into stage three as the material scenarios get sufficiently mitigated.
Stage three: steady state
The work is holding the line and absorbing change.
The material scenarios are largely mitigated. What’s left is keeping them that way while the world moves.
Two clocks, running at different speeds
Requirements get confirmed quarterly or annually. Are the mitigations still in place, still working, still done correctly? Materiality itself gets re-tested on the business cycle, roughly every three years. What counted as material last year is almost always still material this year, because materiality changes on events rather than on the calendar.
What moves it: a new product, an acquisition, being acquired and inheriting new leadership and new priorities, a new market or office, or an entirely new class of threat. Frontier AI models are the current example.
Why the cadence differs
Organic growth has slowed by this stage. Growth comes more from acquisition, and it comes more slowly. The risk landscape shifts in surges instead of continuously. A program that re-litigates materiality every year is spending money to confirm what it already knew.
Spend buys a program that runs rather than a project that finishes. Ingest, adapt, manage, optimize, and around again. Steady state.
The three stages compared
| Compliance-driven | Risk-driven | Steady state | |
|---|---|---|---|
| What drives spend | An outside obligation. A regulator, a certificate, a customer. | Protecting what the company has built. | Holding the mitigations and absorbing change. |
| The bar for enough | The framework. Pass the audit. | A threshold per scenario, agreed by the executive team and the board. | Requirements still true. Materiality still current. |
| Board posture | Attention at audit time and when a deal is blocked. | Asking what happens if the company gets hit. | Reviewing on a cadence. |
| Shape of spend | Minimum to certify. Hard ceiling above the line. | Active and project-shaped. The build phase. | A program that runs. Cyclical. |
| Where it ends | No event. The company looks up and finds it’s late. | No exit. It merges into stage three. | It doesn’t. That’s the point. |
Almost nobody knows where they are compared to where they should be.
A compliance-driven program at forty people is a company making good decisions. The same program at $250 million in revenue is a company defending an asset base it built years ago with a budget it set before the asset base existed. The program didn’t fail. The company outgrew it, and nothing in the program was designed to notice.
There’s no trip-wire. There are symptoms.
Nothing announces the transition. Most companies look up one day and discover they’ve been somewhere else for a while. What follows is what that looks like from the inside.
The pen test stopped teaching you anything.
Compliance obliges a test. After a few years the findings stop changing and somebody says out loud that you haven’t learned anything new in a while. The usual response is to change pen testers, hoping different dice come up. But the scope is fixed and the objective is still compliance, so the results stay interesting without ever being meaningful. Swapping vendors is a stage problem being mistaken for a supplier problem.
The board asks something compliance can’t answer.
They want more than SOC 2, HITRUST, CMMC, no consent orders, and everything HIPAA asks for. They want to know what actually happens to this company if it gets breached. There is no certificate that answers that question.
A peer gets breached and it lands differently.
A comparable company ends up in the headlines and the room goes quiet in a way it didn’t use to. People start seeing themselves in the story instead of reading it as news. Of all the symptoms, this is the one that resonates deepest, and it’s usually the one that starts the conversation.
Compliance is a funding instrument, and that’s the trap.
Boards and executive teams fund objectives. They don’t fund initiative, and they don’t fund doing new things for the sake of doing new things.
Compliance frameworks make excellent objectives. They’re external, dated, unambiguous, and somebody else wrote the requirements. Nobody has to be talked into one.
Which means declaring yourself compliant removes the security leader’s standing to ask for anything. The reasonable next move, and one plenty of companies make, is to adopt another framework specifically to create a reason to fund more security. The certificate is the pretext. The budget is the point.
It works, and it’s also how a company spends another three years in stage one. The security leader owns this transition. If nobody makes it, the program stays on lights-on compliance until the company looks up and realizes it’s behind.
What to do about it
The question isn’t whether your program is good. It’s which company it was built for.
The honest test takes an afternoon. Name the scenarios that would genuinely hurt this business, at its current size, with its current customers and its current data. Rank them. Then ask whether your security program was built to prevent any of them, or built to pass an audit that predates them.
If it’s the second, you aren’t behind on maturity. You’re running a correct answer to a question the company stopped asking.
That test is where my work starts, and the output is the thing a stage two program is built on: the short list of what could actually hurt you, a written definition of good enough, and an order you can defend to a board.
If this sounds like your company, let’s connect.