Protect Maturity Assessment: Where Most Programs Fall Short
Most Protect functions look solid on paper and fail in practice. How to test real control maturity, rank the gaps and take them to your board.
Loading...
Most Protect functions look solid on paper and fail in practice. How to test real control maturity, rank the gaps and take them to your board.
What AI-driven security solutions really do: alert triage, behavior-based detection, risk ranking and automated response, and how to test the AI claims.
Most security programs have a Protect function that looks solid on paper. You have endpoint controls, network segmentation, identity governance and a data classification policy someone wrote three years ago, your last audit came back clean, and your board thinks you're in good shape. Then a tabletop exercise or a real incident shows that half your controls are ceremonial, your segmentation has exceptions that swallowed the rule, and your access review is a quarterly ritual nobody believes in.
That gap between documented controls and what happens in operation is what a Protect maturity assessment is for. It isn't a compliance exercise, and it isn't a vendor-sponsored benchmark that happens to show you need more products. It's a structured look at whether your controls reduce risk under real conditions, or only reduce audit findings under ideal ones.
I wrote this for security leaders who inherited a program, who are getting ready for a board risk conversation, or who need to justify budget to a CFO asking what last year's security spend bought. The Protect function is where most of your budget goes, so it deserves more than a checkbox review.
Browse the Full Cybersecurity Market. Every Category.
Every category on CybersecTools, from AI Security and Cloud Security to Threat Intelligence and Offensive Security. Filter by use case, industry, or company size.
In NIST CSF 2.0 the Protect function covers identity management, authentication and access control, awareness and training, data security, platform security, and technology infrastructure resilience. That is a wide surface, and most programs have something in every category, so whether a control exists is rarely the question. What you need to know is whether it works, whether it holds up under pressure, and whether anyone would notice if it stopped.
Control reliability is the metric most maturity models leave out. A control that works 95% of the time sounds fine until you do the math across 200 controls, which leaves about 10 broken at any given moment. Your maturity score reflects how your controls were designed, while your real risk depends on how reliably they run.
The other problem is gaps that hide in the seams between teams. Your endpoint people own EDR, your network people own segmentation and your IAM people own access governance, but nobody owns the places where those meet. That is where attackers live.
The same four patterns keep showing up, and they are program design failures more than technology failures:
Each of these needs a different fix. Ceremonial controls need process redesign, drift needs continuous validation, coverage illusions need an accurate asset inventory, and ownership gaps need named accountability. A single maturity score won't tell you which of the four you have.
A useful Protect assessment ends with a ranked list of control gaps, each with its business impact attached. A 40-page report that sits in a SharePoint folder doesn't count. I'd run it in three phases.
Phase 1: Control inventory and ownership (2 to 3 weeks). List every control in your Protect function. For each one, write down what it covers, who owns it day to day, when it was last validated and what failure looks like. This phase alone surfaces ownership gaps most programs have never admitted to.
Phase 2: Reliability testing (3 to 4 weeks). Don't rely on vendor dashboards or compliance reports to tell you a control works. Run targeted tests instead: purple team exercises for your highest-value controls, configuration audits against your documented baselines, and spot checks on access review outputs to see whether they match who is employed and in what role today.
Phase 3: Rank the gaps by business impact (1 to 2 weeks). Map each gap to a business risk rather than a compliance requirement. A gap in privileged access controls on your ERP system is a financial integrity risk, and a gap in endpoint controls on developer machines is an IP theft risk. Rank by what exploitation would cost the business rather than by the severity score in your scanner.
Identity is the new perimeter, and you've heard that many times. The trouble is that most programs bought identity products without building identity governance around them. The products give you the ability to manage access, while governance is the process that makes sure that ability is used correctly and consistently.
The most common identity gap in Protect assessments is orphaned access. Employees change roles, contractors finish their engagements and acquisitions bring in new groups of users, and every one of those transitions leaves access behind that should have been removed. An orphaned access audit almost always finds accounts whose access no longer matches the person's role or employment status, which is why identity governance belongs near the top of the assessment.
The second most common gap is privileged access sprawl: local admin rights granted for a one-time project and never revoked, service accounts with domain admin rights because that was easier than scoping them, and break-glass accounts nobody monitors. These are the real paths that ransomware operators and insiders use, so test them first.
Compare Security Program solutions side by side
Features, integrations, NIST coverage and deployment for every Security Program solution we list, in one table.
Most organizations have a data classification policy, but fewer have a data classification program. The difference is whether anyone classifies data, whether systems enforce the labels, and whether the labels stay current as data moves between environments.
A realistic data security assessment asks three questions most policies can't answer. Where is your sensitive data right now, including shadow copies and backups? Who accessed it in the last 90 days, and was that access appropriate? And if your DLP product were switched off tomorrow, how long would it take you to notice?
Cloud adoption has made this harder. Data that used to sit on file shares now lives in SharePoint, S3 buckets, Snowflake and a dozen SaaS applications, each with different native controls. If your DLP policy was written in 2021 for a different architecture and you haven't updated it for your current cloud footprint, your maturity score is measuring a program that no longer matches your environment. Data security posture management products exist for exactly this mapping problem.
Maturity models give you a scoring framework, but they don't stop you from fooling yourself. The usual way security leaders do that is by scoring controls on design rather than on how they run, so a policy document ends up scoring the same as an enforced technical control.
So score each control on two dimensions, design maturity and operational reliability. A control can be well designed and badly run, and it can also run reliably while covering the wrong scope.
| Score | Design maturity | Operational reliability |
|---|---|---|
| 1 | No control exists | Control fails regularly or is untested |
| 2 | Policy exists, no enforcement | Control works in ideal conditions only |
| 3 | Technical control deployed | Control works consistently, with some gaps |
| 4 | Control with monitoring | Control validated, exceptions managed |
| 5 | Automated, continuously validated | Control degrades gracefully, metrics tracked |
A control that scores 4 on design and 2 on reliability is a risk, because it looks good in your documentation and fails in practice. Those are the controls behind post-mortems that start with "we had a control for this".
Your board doesn't care about your maturity score. It cares about what happens to the business if your controls fail, so your job is to connect control gaps to outcomes they already worry about: revenue disruption, regulatory exposure, reputational damage and M&A risk.
What works best is a risk scenario tied to one specific gap. Compare "our privileged access controls are at maturity level 2" with something like this example: "We have 47 service accounts with excessive privileges. If one is compromised, an attacker has a path to our ERP system, and a ransomware event on the ERP would cost an estimated $2 to 4 million in recovery and disruption based on our last business impact analysis." The first is a status report, and the second starts a budget conversation.
When you present Protect gaps to a board or audit committee, lead with the two or three that carry the most business risk. Show the current state, the target state, the cost to close each gap and the risk reduction you expect, and keep it to one page. If the board asks for more detail, they're engaged, which is a good problem to have.
A point-in-time assessment is better than nothing, but a continuous program is what manages risk. The difference is whether you have ongoing ways to catch a control wearing down before it fails.
Three mechanisms work at most team sizes and budgets. First, automated configuration monitoring against your documented baselines, which cloud security posture management and endpoint configuration management products give you for drift. Second, a quarterly validation calendar that rotates targeted tests through your highest-risk controls, so you test what matters most each quarter instead of repeating the full assessment. Third, an ownership model where every control has a named owner who gets a monthly reliability metric and answers for the exceptions. Continuous controls monitoring products can carry part of that load.
The aim is to see a control wearing down before it becomes a gap, and to handle gaps as routine operations rather than as a crisis. Programs that do this well spend less time in incident response and more time on deliberate improvement, which is the real return on a mature Protect function.
Check a vendor before you sign
Mandos tracks funding, acquisitions, hiring and news for security companies. Look up any vendor on your shortlist before the renewal.
A Protect maturity assessment is only useful if it produces decisions. A score without a ranked action plan is a status report, and a gap list without business impact won't survive a budget conversation.
The programs that improve over time treat Protect maturity as an operating discipline rather than a yearly exercise. They validate controls continuously, give every gap an owner and explain risk in terms executives can act on. It's unglamorous work, and it's what separates programs that look mature from the ones that are.
An internal assessment costs mostly staff time. External assessments from credible firms are priced by scope and company size, so get quotes from two or three. Internal reviews give you operational detail, but they tend to miss the gaps your people have learned to live with. A mix works best: gather the data internally and bring in outside validation for your highest-risk areas.
I'd plan for 12 to 18 months for a focused program with enough budget and executive support. It depends a lot on which controls lag. Identity and access gaps can close faster with the right products and process changes, while data security gaps in complex cloud environments take longer because they need technical fixes and behaviour change across the company. Programs that try to improve everything at once usually improve nothing.
Scope it tightly. A full assessment of every control in every environment is a project of several months that competes with operational work, so start with the highest-risk areas: privileged access, endpoint protection and security for your most sensitive data. A focused 6-week assessment of those three gives you more to act on than a broad 6-month review, and you can use the results to justify the people or products you need for the rest.
Lead with business risk and leave the control scores in the appendix. Pick two or three gaps that connect to risks the board already cares about, such as regulatory fines, operational disruption or reputational damage. For each one, show the current exposure, the cost to close it and the risk reduction you expect, all on one page with a clear ask.
Ask them to show coverage against your environment rather than a generic capability matrix. Any vendor can claim to handle privileged access or data security, but what matters is whether the product covers your cloud environments, your legacy systems and your real user population. Require a proof of concept on your own data before any significant commitment, and add the integration, tuning and staff hours that vendor cost calculators tend to leave out.
Use compliance frameworks as a floor. SOC 2 and ISO 27001 give you a useful baseline of controls and produce audit evidence with real business value. They are designed to be reachable by a wide range of organizations, though, so meeting them doesn't mean you're well protected. Run your assessment against your own threat model and then map the results to your compliance requirements, and compliance follows from the real security work.
Written by Nika (Nikoloz) Kokhreidze, from my own work running security programs and buying security products. Category and glossary links point to the CybersecTools catalog of 9,168 security products. Read the methodology for how we review products.