Your security program probably looks great on paper. Policies documented. Framework mapped. Maybe a maturity assessment showing you’re “Level 2” across most domains with a roadmap to “Level 3.”

Attackers don’t care about your maturity level.

I worked with a fintech company last year that had passed their SOC 2 audit with flying colors. Comprehensive policies, documented procedures, evidence of control operation. Three months later, an attacker got in through a contractor’s reused password and moved laterally to their production database. The maturity model hadn’t asked about contractor credential hygiene.

At Adversis, we’ve built security programs for dozens of organizations. What follows isn’t another framework—it’s structured prioritization based on what actually stops breaches.

Start With What Will Kill You

Most security programs begin with a framework and work through it sequentially. Control 1, then Control 2, then Control 3. Orderly. Comprehensive. Wrong.

Frameworks are designed to cover everything, but threats aren’t evenly distributed across controls. A mid-market healthcare company we worked with spent their first security budget on data classification and information governance—important eventually, but not when they had no endpoint detection and domain admin credentials in a shared spreadsheet.

We start differently. What would actually destroy this specific business? Not “data breach” generically, but the concrete scenario that ends you. The answer is often surprising. One biotech client assumed it was patient data, but their real existential risk was theft of research IP that would crater their acquisition value.

Work backwards from destruction. What attack paths lead there? What controls block those paths? That’s your priority list.

The Layers: Structured Prioritization

I won’t pretend this is a revolutionary framework. It’s prioritization with guardrails to prevent teams from jumping to the interesting stuff before the boring stuff is solid.

Layer 1: Commodity Attack Defense

Stop the opportunistic attacks first. If automated scanners and script kiddies can pop you, nothing else matters.

This means endpoint detection that catches real payloads (test it—most out-of-box configurations miss basic tools), MFA on critical systems, patching that happens in days rather than months, and actual credential hygiene.

MFA deserves a reality check here. “Enable MFA everywhere” is easy to say and genuinely hard to do. Service accounts, legacy applications, third-party integrations, that one system from 2012 that nobody knows who owns—these break or can’t support modern authentication. Plan for a phased rollout with exception tracking. Don’t pretend you’ll flip a switch.

Layer 1 isn’t glamorous. But ninety percent of breaches I’ve investigated died here when these controls worked.

Layer 2: Targeted Attack Survival

Once commodity defense is solid—actually solid, not “we bought the tools”—focus on surviving determined attackers.

The goal isn’t stopping every sophisticated attack. It’s containment before business impact. This layer gets into network segmentation, detection of post-exploitation behavior, identity architecture that frustrates lateral movement, backup restoration that you’ve actually tested, and incident response capability (internal or retained).

Layer 2 also includes your supply chain. For most organizations, third-party risk now exceeds internal risk. Your pristine security program means nothing if an attacker pivots through your marketing automation vendor. Build vendor security assessment into procurement, monitor third-party access, and know what blast radius each integration creates.

Layer 3: Continuous Improvement

Red teams, threat hunting, architecture reviews, control validation—the activities that security teams find interesting. Important, but only after Layers 1 and 2 are genuinely solid.

I regularly see companies running red team exercises against environments where basic credential hygiene isn’t solved. The red team finds the obvious stuff, generates a report, and nothing changes because the remediation capacity is already overloaded with Layer 1 gaps.

Measure Outcomes, Not Activity

Most security metrics are vanity metrics. “Vulnerabilities remediated” means nothing if you’re closing lows while criticals age. “Training completion rate” has zero correlation with phishing resistance. “Mean time to detect” is noise if you’re detecting noise.

Useful metrics tie to outcomes. Here’s how we actually measure one of them:

Coverage: Pick a control—say, EDR. Export your asset inventory. Export your EDR deployment list. Compare. The percentage of assets with working EDR agents is your coverage. Do this monthly. Trend it. Fight about it when it drops.

That’s not sophisticated, but it’s real. Most organizations can’t tell you their actual EDR coverage within 20 percentage points.

For detection efficacy, run atomic tests. Not annual pentests—automated, repeatable simulations of specific techniques. Track what percentage get caught and at what stage. This tells you if your detection actually works.

A Word on Maturity Models

Maturity models aren’t useless. If you’re in a regulated industry or facing customer security questionnaires, you probably need one. They provide common language and benchmarking.

Use maturity models for compliance and stakeholder communication. Use capability questions for actual security decisions.

Capability questions have binary answers: Can we detect Kerberoasting? Can we restore this system from backup within four hours? Can we revoke a compromised credential in under fifteen minutes?

You can do it or you can’t. No hiding behind “partially implemented.”

Getting Executive Support

Technical controls require executive backing, and “security is important” speeches don’t count. Specific air cover for specific decisions is what matters.

Two tactics that work:

First, connect security decisions to business outcomes the executive already cares about. Don’t pitch “we need EDR for threat detection.” Pitch “this protects the platform availability that enterprise customers require.” Same control, different frame.

Second, bring executives into tabletop exercises. Not as observers—as participants making decisions under pressure. When a CEO has personally navigated a simulated ransomware scenario, budget conversations change.

One Controversial Take

Most security teams should run fewer tools, not more.

The instinct is to add. New threat? New tool. Compliance requirement? New tool. Vendor pitch? New tool.

Every tool adds integration complexity, maintenance burden, and alert fatigue. I’ve seen five-person security teams running thirty-plus security products, spending all their time managing tools rather than managing security.

If you can’t staff a tool properly—configure it correctly, tune the alerts, act on findings—it’s making you less secure, not more. It’s creating blind spots disguised as coverage.

Consolidate ruthlessly. Depth beats breadth.

Starting Tomorrow

If you’re building from scratch, here’s your first week, tied back to Layer 1:

1. Identify your three business-critical systems (the ones where compromise means game over)
2. Verify MFA is enabled and enforced on all three—actually verify, don’t assume
3. Confirm you have visibility into authentication logs for those systems
4. Document who has admin access and whether it’s justified
5. Attempt one backup restoration and document what breaks

Not comprehensive. Not glamorous. But you’ll know more about your real security posture after this than most maturity assessments would tell you.

Build iteratively from there, always asking: does this address how we’d actually get hurt?