Why Mature Security Programs Are Built on Operating Models, Not Projects
The assessment report comes back, and it’s solid work. Hundreds of findings, ranked by severity. Leadership funds a remediation sprint, engineering works through the top of the list in six weeks, and the next board update finally has a chart heading in the right direction.
Six months later, the next assessment looks a lot like the first one. Some of the old findings are back. New ones have turned up on systems that didn’t exist during the sprint. The sprint team has moved on to other priorities, and nobody can say for sure which of the original decisions still apply.
No one dropped the ball: every project delivered what it said it would. What the program lacked was a way to make the same good decisions next month without a sprint forcing the issue. Building that ability is what security maturity actually requires.
02 Five Capabilities That Separate Mature Programs
Why Point-in-Time Improvements Fade
Assessments, remediation sprints, and transformation initiatives share a shape: a fixed scope, a temporary team, and an end date. That’s what makes them easy to fund, and it’s also why their gains don’t last.
Each project brings exposure down. Then it ends, and the environment keeps moving. New systems come online, old findings return, and the decisions behind the last sprint leave with the team that made them. These are the breakdowns that keep risk reduction from repeating, and exposure creeps back toward where it started until the next project knocks it down again.
Over time, that pattern looks like a sawtooth. Each improvement is real, but none of it builds on the last. A mature program works differently: it keeps figuring out what matters, deciding what to do about it, getting it done, and confirming it worked, so each cycle starts from where the previous one ended instead of from scratch.
The short version: a project gets you an improvement. An operating model gets you the ability to keep improving, without a new mandate every time.
Five Capabilities That Separate Mature Programs
The programs that break out of that sawtooth aren’t working harder during sprints. What they do differently happens in between. Each of the five capabilities below marks a point where immature and mature programs split. The immature program does the work once.
The mature program has built it into how the organization runs, with clear inputs, named owners, and a cadence that doesn’t depend on someone launching a new initiative.
“Mature companies have the right processes. The problem is the right processes are not useful if nobody's following the process, right? So they think they're mature, but the process is there, but nobody's doing it, right?”
Capability One: Continuous Scoping and Discovery
A project scopes once. The scope gets set at kickoff, discovery builds an inventory, and the team works from that picture until the project closes. The picture starts aging the day it’s drawn.
Business change is what ages it: an acquisition, a new product line, a vendor integration, a team spinning up its own cloud account. None of those wait for the next assessment, and each one changes what the program should be protecting. Mature programs treat scope as something that moves with the business, not a decision made once at the start.
Scopes once, at the start of an assessment, and works from that inventory until the next one. Anything launched in between, whether it's a new cloud account, an acquisition, or a new product, goes unwatched and piles up exposure nobody is tracking.
Revisits scope whenever the business changes and runs discovery continuously. New assets enter the process as they appear, and anything found without a known owner or purpose gets treated as a finding in its own right.
Tie re-scoping to business events, not the calendar. An acquisition, launch, or new vendor should trigger a scope review on its own, and new assets should enter discovery as they appear instead of waiting for the next assessment.
“So when it comes to the bigger question, what are the assets that we do have? What are the assets that we don't have? That's the question I've been asking recently. Like, show me what we see, but show me what I don't see.”
Ricoh DanielsonEnterprise CISO, CorroHealthSee it in the transcript at 2:54 · From Discovery to Risk Reduction: Operationalizing CTEM →
Capability Two: Repeatable Risk Decisions
Every exposure ends in a decision: fix it now, fix it later, put a compensating control in place, or accept the risk. In a project, those calls get made by whoever is in the room, and the reasoning rarely outlives the sprint.
That works until someone has to make the same call again. A new analyst, an auditor, or the next sprint team can see what was decided but not why, so the decision either starts from scratch or gets copied without the context behind it. The specific criteria that move an exposure up or down the list matter less here than whether they’re written down and applied the same way every time.
Prioritizes in a meeting. The ranking is often sound, but the criteria live in people's heads, so the decision can't be reproduced, audited, or revisited when conditions change. Accepted risks quietly fall out of view.
Documents the criteria and the reasoning behind each call, applies them the same way every cycle, and revisits them as threat activity and business priorities shift. Risk acceptances expire and come back for review instead of disappearing.
Make every decision reproducible. If a new analyst can't reach the same call from the same inputs, or an auditor can't see why it was made, the decision belongs to a person, not the program.
Capability Three: Coordinated Remediation Ownership
Sprints work partly because they borrow authority: an executive sponsor, a dedicated team, and a hard deadline make it obvious who’s doing what. Once the sprint ends, that authority goes back where it came from, and remediation goes back to competing with everything else on engineering’s plate.
Mature programs replace borrowed authority with standing arrangements that hold after the sprint team disbands. The questions that stall remediation, like whose problem it is and when it gets done, get settled once instead of renegotiated with every ticket.
Assigns ownership one finding at a time, after prioritization is done. Work lands in a shared queue that belongs to everyone and so belongs to no one, and every request to engineering gets negotiated from scratch.
Treats ownership as a standing part of the environment. Every asset maps to an accountable team, capacity for exposure work is agreed on in advance, and security coordinates across owners who are already expecting the work.
Reserve capacity, don't request it. A fixed share of each team's sprint or change window set aside for exposure work keeps remediation moving without an executive mandate behind every ticket.
“My focus is: How do we execute? How do we execute in a way that sets the business up for success? I don't do that on my own. I do that in concert with cyber, with infrastructure, with risk.”
Ken LawrenceCOO, Lighthouse Credit UnionSee it in the transcript at 3:59 · From Protecting the Business to Running It →
Capability Four: Verification and Root-Cause Elimination
A fix made during a project gets checked once, if it gets checked at all. The more useful question is whether it’s still fixed three months later. A patch applied to a running instance disappears at the next autoscaling event, and an infrastructure-as-code template keeps redeploying the misconfiguration someone just fixed by hand.
The mature approach checks the fix, then keeps checking on later cycles. When the same finding shows up across dozens of assets, it looks upstream for the image, template, or process that keeps producing it.
Counts closures and fixes individual instances: this server, this storage bucket, this overprivileged role. When a fix doesn't survive the next deployment or image rebuild, the finding reappears and gets treated as brand-new work.
Confirms that each fix held, then checks again on a later cycle. Recurring findings get grouped by cause and traced back to the base image, template, default permission, or process that produced them, so the fix happens once, at the source.
Fix the source, then keep checking. Re-confirm fixes on later cycles, and when a finding keeps coming back, fix the image, template, or default that produces it so new assets start out clean.
Capability Five: Measuring Improvement Over Time
A project gets measured once, at the end: did it finish, and did the numbers go down? That tells you whether the project worked. It can’t tell you whether the program is improving, because improvement only shows up as a trend, and a trend needs the same things measured the same way, cycle after cycle.
The question worth answering is whether the organization is harder to attack than it was a year ago, and whether the process that got it there is getting faster and more reliable. When a trend stalls, a mature program treats that as a reason to adjust the operating model, not just to push harder.
Measures each project on its own terms: whether the sprint finished and how much it closed. The measures change from one initiative to the next, so there's no baseline to compare against, and team-by-team scorecards tend to turn into blame.
Tracks trends only a continuous operation can produce: exposure on critical business services over time, time from discovery to confirmed resolution, recurrence rates, and the share of decisions made within agreed timelines. Metrics are shared across owners, and the model itself gets adjusted when they stall.
Keep the measures fixed and watch the trend. Pick a small set of outcome measures for your critical services, track them the same way every cycle, and treat a stalled trend as the cue to change the model.
Maturity Is What Happens Between Projects
Projects still matter. Assessments show what’s missing, and a focused sprint can clear an inherited backlog. But the improvement only lasts if something keeps the work going after the sprint team moves on.
That’s the real test of maturity. If your last sprint team left tomorrow and their gains would still hold a year from now, the capability belongs to the program. If not, it belonged to the project.
TrollEye is built for the first kind. As a CTEM platform backed by services, it runs exposure management as one continuous cycle, so each assessment starts from a lower baseline than the last.
Make Your Next Assessment Better Than Your Last.
See how TrollEye centralizes exposure management, validates what's actually exploitable and reachable, and fixes root causes, cycle after cycle.
Frequently Asked Questions
Do mature programs stop running assessments and remediation sprints?+
No. Assessments remain valuable as an independent check on whether the operating model is seeing what it should, and sprints are useful for clearing an inherited backlog. The difference is that in a mature program, both feed the model. Assessment findings become inputs to continuous processes rather than a one-time list.
Where should a project-driven program start?+
Usually with ownership and verification, even though scoping comes first in the CTEM cycle. Mapping assets to accountable teams removes the most common source of delay, and confirming fixes reveals which improvements are not holding. Both cost little compared with new tooling, and both make every later capability easier to build.
How long before improvement becomes measurable?+
Process measures, such as time from discovery to an assigned owner or the share of fixes that hold on re-test, can move within a few cycles. Exposure trends on critical services take longer, because they need several quarters of consistent measurement before the direction is meaningful.
How do you show leadership that maturity is improving?+
Show the same measures across several cycles instead of a single snapshot. Exposure on critical business services, recurrence rates, and time to confirmed resolution, tracked consistently over time, show whether improvements are holding, which one quarter's numbers can't.
Is security maturity a tooling question?+
Tooling can enforce and scale an operating model, but it cannot supply one. The characteristics that separate mature programs, including defined decisions, standing ownership, verification, and root-cause focus, are choices about how the organization works. The right tools make those choices easier to sustain.
