What Does a Mature Security Program Actually Have?

Security maturity isn't the number of products you own, the size of your IT budget, or whether you've had a breach yet. Plenty of businesses with none of the right controls have never had a bad day, and plenty with all of them have.

A mature security program is one where every control is owned by a named person, documented, operating on a schedule, and provable to an outsider on demand. That last clause is the whole game. The measure of maturity is evidence, not intention.

It's an uncomfortable standard, because most businesses fail it on things they genuinely do.

What's the difference between having a control and having evidence?

A control is something you do. Evidence is something you can hand to somebody else.

You back up your data. Can you produce the log of the last full restore test? You have a password policy. Can you produce the document, dated, with a record of who acknowledged it? You review who has access to what. Can you produce the last review, with the names and the date?

If the answer to the second question is "well, we do it, we just don't write it down," you have a practice, not a control. It works right up until the moment somebody outside your company needs to be convinced - an auditor, an insurance underwriter, a customer's security team, or a regulator after an incident. At that moment, undocumented good behavior and no behavior look identical.

This is why I tell people to apply one rule when they assess themselves: only count something if you could show proof of it this week. Not "we could pull that together." Not "our IT guy would know." This week, from what already exists.

That rule cuts most self-assessments roughly in half, and the half it cuts is the useful half.

What are the actual categories a program has to cover?

Every serious framework organizes the same underlying work slightly differently, which is confusing until you notice they're all describing one thing.

NIST CSF 2.0 uses six functions - Govern, Identify, Protect, Detect, Respond, and Recover. The Govern function was added in 2.0, and its addition is the interesting part: the standards body decided that who decides, who owns it, and what's written down deserved equal billing with the technical work.

The FTC Safeguards Rule takes the legal route to the same place. 16 CFR 314.4 lists ten lettered requirements: a designated Qualified Individual, a written risk assessment, specified safeguards including encryption and multi-factor authentication, testing, personnel training, service provider oversight, program evaluation, a written incident response plan, an annual written report to the board, and FTC notification within 30 days of a breach affecting 500 or more consumers.

The HIPAA Security Rule does something structurally different that's worth understanding, because it's widely misread. Its implementation specifications come in two flavors: Required and Addressable. Under 45 CFR 164.308(a)(7), a data backup plan, a disaster recovery plan, and an emergency mode operation plan are Required. Testing and revising those plans is Addressable - meaning you assess whether it's reasonable and appropriate for you, and if you decide it isn't, you document why and implement an equivalent alternative. Addressable is not optional. It's optional-with-a-paper-trail, which for a small practice is often more work than just doing the thing.

Underneath the different vocabularies, four groups of work show up every time:

1. Govern. Who decides, who owns each control, what's written down, and how changes get approved. This is the group most small businesses have the least of and think about the least.
2. Manage risk. A current written list of what could actually hurt you, ranked. Access controls. Monitoring. Patching. Backups you've actually restored from. A tested plan for the bad day.
3. Comply. Mapping your controls to the frameworks that apply to you, collecting evidence as you work rather than reconstructing it under deadline, and being able to face an audit without a scramble.
4. Operate and defend. The day-to-day machinery - endpoint and identity protection, threat monitoring, hardening, remediation, and a scheduled review that keeps the whole thing current.

Why do businesses with good technology still fail assessments?

Because the technical layer is the layer that gets bought, and the other three are the layers that get skipped.

I see this pattern constantly. A business has EDR on every endpoint, MFA turned on, a decent firewall, and a backup running nightly. On paper that's a real security posture. Then the insurance application asks whether backups are restore-tested and nobody has ever restored one. The audit asks for the access review and there hasn't been one. The customer questionnaire asks who the accountable security owner is and the honest answer is "our managed services provider, sort of, we think."

The tools were never the problem. The tools are the easy part - you can buy them in an afternoon. What takes time is the governance around them: someone owning each one, a schedule they run on, and a record that proves they ran.

There's a second pattern worth naming. Businesses that score well on the technical items often score worst on evidence, because competence breeds confidence. If you know your backups work, you feel no urgency to test them. If you trust your team, you feel no need to document the access review. That instinct is reasonable and it is exactly what fails under external scrutiny, because scrutiny doesn't run on trust.

Which two controls get missed most often?

Change management and vendor oversight, and they get missed for the same reason: neither one is a product.

Change management means that changes to systems, software, and access are requested, approved, and recorded, so nothing important happens by accident. SOC 2 treats it as a core control, and auditors ask about it early because it's a reliable proxy for whether a program is real. In most small businesses the honest answer is that changes happen when someone decides they should, and the record is whatever's in a chat thread. That's not a scandal. It's just not a control, and the first time a change breaks something in a way that costs money, the absence of a record is what makes the postmortem impossible.

Vendor oversight means you know which third parties touch your systems and data, and someone reviews that access on a schedule. This one is nearly universal as a gap, and it's getting worse rather than better, because the number of SaaS tools a fifteen-person business uses keeps climbing. The FTC Safeguards Rule requires it at 314.4(f) - selection, contractual safeguards, and periodic reassessment. Most businesses can't produce a current list of who has access, let alone a reassessment.

Both are on the list because breaches keep coming through them. An unreviewed vendor connection and an unrecorded change are two of the quietest ways into an environment, and neither one shows up on a dashboard.

What does a self-assessment actually get you?

Not a grade. A work order.

The value of scoring yourself against a fixed list isn't the number at the end - it's that the unchecked items are specific. "We should improve our security" is not actionable. "We have never restored from a backup, nobody owns vendor oversight, and our incident response plan is a page in a binder from 2021" is three tasks with owners.

It also gives you something to hand to a decision-maker. A list of twenty-eight capabilities with eleven checked is a conversation about eleven specific things. A general sense of unease is a conversation about nothing, and it's the reason security budgets get deferred another quarter.

The honest limit of any self-assessment is that it's your view of your own program. Self-assessment tells you what you think you have. An independent review tells you what an auditor would find, which is reliably a shorter list. Both are useful; they answer different questions, and the second one is the one that holds up under pressure.