Compliance is not Security

I have been doing tech and cyber for over fifteen years. Military, government, small companies, Fortune 100 enterprises. Different industries, different stacks, different threat models, different cultures. If you do this work long enough across enough environments, you start to notice patterns in what separates the organizations that are actually secure from the ones that just look like it on paper.

The clearest pattern I have noticed is this: the organizations that are actually secure understand that being compliant and being secure are not the same thing. The organizations that struggle do not.

I have spent a long time trying to get people to see that distinction. This post is another attempt.

What Compliance Frameworks Actually Are

In the military and government, the relevant artifacts are Security Technical Implementation Guides, more commonly called STIGs. They are checklists. Configure this setting this way. Disable this service. Apply this patch. They are procedural by design, and they exist for good reasons. A standardized baseline means an inspector can walk into any unit anywhere in the world and grade them against the same yardstick. That has real value.

In the private sector, the landscape is broader. CIS Benchmarks are probably the closest direct analog to STIGs at the configuration level. On top of that, depending on the industry, organizations are working against NIST CSF, ISO 27001, SOC 2, PCI DSS, HIPAA, or some combination of all of the above. For my fellow CISSP holders out there, this is the alphabet soup the Common Body of Knowledge spent a lot of time helping us memorize. Different frameworks, similar spirit. Prescriptive baselines, governance scaffolding, audit-ready paperwork, all designed to give you a defensible starting position.

These frameworks are useful. I am not going to tell you they are not. They are also widely misunderstood by the people who are supposed to be using them.

The mistake is treating the framework as the destination instead of the starting point. STIGs and CIS Benchmarks are the headline of the article, not the article. They are the starting line, not the finish line. Adhering to them does not make you secure. Adhering to them makes you compliant, and it gives you the baseline level of security a reasonable organization should be expected to have. That is a floor. It is not a ceiling, and it should not be where the work stops.

The Fitness Analogy

The way I think about this is the same way I think about fitness standards in the Marine Corps.

There is a minimum. Every Marine has to meet it. The minimum exists because below a certain level of physical conditioning, you are a liability in a fight, and the institution has a responsibility to make sure people who pin on the uniform are at least at the baseline.

But nobody wants the person next to them in combat to be the Marine who just barely makes minimum standards. Everybody wants the Marine who dominates the test, the one for whom the fitness test is the easiest workout of their week. That Marine is the one you can count on when things go sideways. The Marine who barely passed is the one you are nervous about.

Security works the same way. The compliance framework is the minimum standard. You should meet it. Below the minimum you are a liability. But the organizations whose security I would actually trust in a fight are the ones for whom the compliance framework is the easiest part of their week. Compliance is the warm-up. The real work is everything they do on top of it.

Counting Reps

I lived this principle on the fitness side, and it earned me a particular reputation. People did not like pairing up with me for the test, because I held them to the standard.

On pull-ups, I climbed up on the bar and looked across to make sure the chin actually cleared. I did that for two reasons. The obvious one is that I wanted the count to be accurate. The less obvious one is that from the ground, the angle can make a legitimate rep look like it did not quite get there, and I did not want to miss reps somebody had actually earned. Both directions of error mattered to me.

Crunches were the same. If you did not get to the top of the rep, it did not count. If you did eighty out of a hundred, you got eighty. There was no buddy hookup version of the number.

I was never a great runner. I worked on it all the time, and the run was always my weakest event. You cannot fake a run time. The clock is the clock. So I made sure my other events were the strongest they could be, because the math of the test is unforgiving, and any points I lost on the run had to come back somewhere else. I trained around my weakness instead of negotiating around it.

Senior Marines came to me to count their reps, including people who outranked me. They came to me knowing that I would give them their honest number, not a polite one, and they trusted the result more because of it. I never told anyone they had done something they had not done. I also never failed to count something they had earned. That was the deal, and I think people respected the consistency, even the ones who did not love the experience in the moment.

For a stretch of my time in, I was a cybersecurity inspector for the Commanding General’s Readiness Inspection. The job put me on the road visiting units and grading their compliance with Marine Corps cybersecurity policy. I took the same posture I took at the fitness test. The standard was the standard, and I gave units the score they had actually earned, not the score they would have liked.

That did not always make me popular when I walked in. It is not designed to. An inspector who hands out perfect scores to keep the relationship pleasant is not doing the unit any favors. The findings are how the unit knows what to work on. If I papered over the gaps, the gaps were still there, and the next inspector or the next adversary would find them anyway. Better the unit hear it from me, in writing, with time to fix it.

What I noticed over time was that the units took the honest scoring seriously, and so did their commanders. Nobody enjoyed the visit in the moment. But after the dust settled, the commanders knew the report was a real picture of where they stood, and the unit knew that the work they did to close findings actually mattered. The next inspection cycle would tell the truth about whether they had moved. That is what makes an inspection useful. The honest version produces better units. The polite version produces better paperwork.

You want a better fitness score, work harder. You want a better rifle score, shoot better. The way to score higher is to be better, not to negotiate the count.

Security is the same. You want to be more secure, do more security work. Not better-looking compliance documentation. Not a tighter cover story. Actual security work. The standard exists for a reason. The way to get past the standard is to do the work.

The Private Sector Failure Mode

In the private sector, the failure mode is treating security as a checklist that exists to satisfy a legal or contractual obligation.

The incentives in the private sector point the right direction in theory. A breach has real consequences. Monetary damage. Reputational harm. Customer loss. People get fired. Reporting requirements get triggered. Lawyers get involved. Boards get nervous. None of those things are good for the company, and all of them create pressure that, in a well-run organization, gets translated into actual security investment.

In practice, what often happens instead is that the pressure gets translated into compliance investment. The company makes sure it can demonstrate that the appropriate boxes were checked at the appropriate times. The annual penetration test gets scheduled because the framework says so, not because anyone is trying to learn something from it. The security awareness training gets rolled out because the auditor will ask. The findings get tracked in a spreadsheet that satisfies the regulator and gets filed away after the audit.

No customer who has just had their data stolen is going to take comfort in a press release that says the company was fully compliant with all applicable regulations. That sentence does not produce the outcome anyone actually wants. But a lot of companies operate as if it does, because compliance is measurable and security is hard, and the more effort security takes, the less appetite there is to do it.

The companies that get this right are the ones who treat the compliance work as the bare minimum and use the budget and political capital it gives them to fund the work that actually matters. The companies that get it wrong are the ones who treat the compliance work as the whole job.

The Military and Government Failure Mode

The military and government failure mode looks different on the surface, but it has the same root cause.

The surface symptom is laziness wrapped in compliance language. The deeper problem is the absence of consequence and accountability when security fails. Those two things together produce a culture in which the path of least resistance is to check the box and move on, because no one is going to get held responsible if it turns out the box-checking was not enough.

Federal workers have a lot of protections, and those protections are there for legitimate reasons. They are also extremely effective at making it hard to fire someone, including in cases where firing someone would be the right call. If a federal employee causes a breach through negligence or worse, the realistic outcome in many cases is not termination. It is a reassignment, or a stern letter, or nothing at all. The signal that sends through the rest of the workforce is exactly the signal you would expect.

The military has its own version of this. The version I have seen most often is the practice of pushing blame as far down the chain as it will go. When something goes wrong, the people who get held responsible are usually not the planners or the leaders who set the conditions for failure. The senior people have careers. Senior careers are expensive to damage. The junior person who actually executed the failing task is a different equation. They are new. They have less to lose. Their career is, in a cold accounting sense, expendable. They get burned, they cannot reenlist, and the institution moves on. Meanwhile the people whose decisions actually produced the failure walk away clean.

That is not leadership. That is the opposite of leadership. Real leadership is the willingness to take the hit when your team’s failure traces back to your decisions, and to protect the people below you who were doing what you told them to do. I have seen that done well in the Marine Corps, and I have seen it done badly, and the units where it was done well were also, not coincidentally, the units that took security seriously.

The other piece of the military and government picture is the cover. When a private company has a breach, they have to report it. They have to tell the regulator. In many cases they have to tell their customers. The public consequence is part of the incentive structure.

When the government or military has a security failure, in a lot of cases the failure itself is classified, and the response is to put a wrapper around it and stop talking about it. Sometimes that wrapper is warranted. Sometimes it is genuinely the right call. But the broader effect is that the institution gets to avoid the public consequence private companies cannot avoid, and the internal pressure to actually fix the problem is weaker as a result. A Plan of Action and Milestones gets drafted. The POA&M gets briefed up. Everyone in the room knows it is unlikely to ever get implemented, because implementation is work, and the people responsible for making the work happen have other priorities. The document satisfies the process. The process moves on. The vulnerability remains.

I am not arguing for the public flogging of every government cyber incident. I am arguing that the absence of a real consequence loop has predictable downstream effects on culture, and culture is what determines whether the network is actually secure or only appears to be.

What Actually Makes a Network Secure

Vulnerability scans do not make a network secure. They make it scanned. STIGs do not make a network secure. They make it compliant.

The things that make a network secure are not on any framework’s checklist, but they are the same things every time.

People who take their jobs seriously. Not the job description. The job. The thing they are actually responsible for, regardless of what the position write-up says.

Leaders who have bought in, and who are willing to spend the resources, the political capital, and the personal time that real security requires. The presence or absence of that leadership buy-in is, in my experience, the single biggest predictor of whether an organization is secure or just compliant.

Every user practicing the cyber hygiene the organization expects of them, because the human surface is still the largest attack surface, and culture is the only thing that closes it.

Administrators and security professionals putting in the actual effort. Maintenance. Configuration drift. Patch hygiene. Identity management. Detection engineering. The unglamorous, sustained work that does not photograph well in a briefing slide but that is the actual product of a security program.

None of these things are easy. All of them are work. That is the part nobody wants to hear. Security is effort, sustained over time, applied across every layer of the organization, by people who care. There is no checklist that replaces it and there is no framework that simulates it.

Compliance is not security. It is the floor. Build the floor, but then keep building everything else.