Why passing a compliance checklist doesn't mean you're secure

Your password policy says 14 characters and multi-factor authentication (MFA). Go check how many accounts actually follow it.

That's the compliance vs. security problem in two sentences. I've walked into plenty of businesses with a binder that would make any auditor smile, and a network that would make any attacker smile wider.

This is called checkbox compliance. It's documentation built to pass the audit, not to stop the attack. Writing a policy is easier than enforcing one, so the implementation needs to be checked alongside the documentation.

What's the difference between compliance and security?

Compliance means meeting a defined standard, such as HIPAA, NIST, CMMC, PCI DSS, or an examiner's checklist, and proving it at a point in time. Security means actually reducing the risk of a breach, continuously. They overlap, but compliance is the minimum, and the minimum is what attackers plan around.

Quick decoder. HIPAA is the Health Insurance Portability and Accountability Act. NIST is the National Institute of Standards and Technology. CMMC is the Cybersecurity Maturity Model Certification. PCI DSS is the Payment Card Industry Data Security Standard.

Compliance and security aren't opposites. Good frameworks give you a common language and a minimum bar. They also give you a reason to finally write things down.

The problem is stopping at the paperwork. A framework tells you what good looks like. It doesn't make your laptops look like that.

Even the framework authors agree. The NIST Cybersecurity Framework (CSF) 2.0 added a Govern function, and its policy category says cybersecurity policy should be "established, communicated, and enforced." Writing the policy is only part of that requirement.

Why do compliant companies still get breached?

Compliant companies get breached because their policies aren't enforced by technology, exceptions never expire, accounts are shared, networks are flat, and a full year passes between checks. The audit reviewed the policy, but nobody checked the laptop. Attackers don't care what the binder says; they care what the system allows.

Here are five ways compliance and security drift apart.

1. Written but not enforced. The policy requires MFA, but nothing in the system blocks a sign-in without it.
2. Exceptions that become permanent. Someone gets a "temporary" exemption for a deadline. Nobody sets an end date, so it never ends.
3. Point-in-time testing. An audit is a snapshot. Your environment changes every day after the photo is taken.
4. Scope games. Whatever gets declared out of scope for the audit tends to get ignored. Attackers don't respect your scope boundary.
5. Shared and orphaned accounts. A shared login can't be traced to one person. An orphaned account, one that belongs to someone who left, is an open door nobody's watching.

Heartland Payment Systems is a public example. Contemporaneous reporting quoted Heartland's president confirming that a qualified assessor had found the company PCI compliant in April 2008. Heartland later reported malicious software compromising data crossing its network.

The Justice Department alleged SQL-injection attacks and the theft of more than 130 million card numbers across a scheme involving Heartland and other companies, rather than attributing that total to Heartland alone. Heartland disclosed its breach in January 2009.

The breach illustrates the limits of point-in-time verification. Controls need to remain effective between audits.

What does an enforced policy actually look like?

An enforced policy is applied by technology to every device and account automatically, so violations are blocked or flagged instead of trusted. Think MFA required by conditional access, disk encryption pushed by device management, USB storage blocked, and patches applied on a schedule. If a person has to remember it, it isn't enforced.

The written vs. enforced framework

Read that table left to right and you'll see the whole argument. A written policy states the requirement. An enforced policy applies it through a technical control.

The idea behind the right-hand column is policy as configuration. Every sentence in your policy maps to a setting in your systems, and the setting itself becomes the proof.

Here's how that works in practice.

• Conditional access checks every sign-in against your rules and blocks the ones that fail. Those rules can require MFA and a managed device, or an approved location.
• Intune / MDM holds every device to a configuration baseline. This can require encryption and a firewall, with a current operating system. Devices that fall out of line lose access.
• Role-based access control (RBAC) grants access by job role, so least privilege (only what that role needs) is the default, not a favor.
• Network segmentation splits the network into zones, so one compromised laptop can't reach everything.

Configuration also catches compliance drift, the slow slide between what the policy says and how systems are actually set up. When settings are monitored, drift shows up as an alert, not an audit finding.

We took this approach in case HS-1108, where controls were enforced on every device rather than written down. Over nine months, the defense supplier moved CUI into a government-tenant Microsoft 365 environment and automated evidence collection. The published case records 110 NIST 800-171 controls implemented and same-day new-hire setup.

What happened when a regulated lender moved from written policy to enforced policy?

A regional financial services firm (case HS-0731) had shared logins, a flat network, and an exam coming up with old findings still open. Headway gave everyone individual least-privilege access, segmented the network, and automated the documentation. The firm went into its exam with every prior finding closed and zero shared logins left.

Case HS-0731. Regional financial services firm

Situation. Shared logins, a flat network (one where every device can reach every other device), and an upcoming exam with prior findings still open.

What we changed. Individual, least-privilege access for every user. A segmented network. Automated documentation.

Result. 100% of prior findings closed. 0 shared logins. 11-month engagement.

The work focused on enforcement rather than expanding the documentation alone.

Individual accounts made every action traceable to a person. Segmentation limited how far any problem could spread. Automated documentation meant the evidence already existed before the examiner asked for it.

In case HS-0731, implementing the controls helped the firm close its prior exam findings.

How do you close the gap between compliance and security?

To close the gap, list every written policy, map each one to a technical control, enforce it through configuration, monitor for drift continuously, collect evidence automatically, and review exceptions every quarter. Done right, the audit becomes a report you print, not a project you scramble through.

1. List every written policy. Every requirement your frameworks, examiners, contracts, and insurer expect you to meet.
2. Map each one to a technical control. Administrative controls, including policies and procedures as well as training, say what should happen. Technical controls (settings and tools) make it happen. Every administrative control needs a technical partner wherever one is possible.
3. Enforce it through configuration. Push the setting to every device and account. If it can't be enforced automatically, document why and who owns it.
4. Monitor for drift continuously. Alerts should fire when a device or account falls out of line, not 11 months later.
5. Collect evidence automatically. Reports and logs should be generated on a schedule, along with configuration exports. That's what compliance automation is actually for.
6. Review exceptions every quarter. Every exception gets an owner and an expiration date. Record its reason as well. No exception lives forever.

This is what continuous compliance means. You're not preparing for the audit. You're always ready for it.

It's also why we tie this work to our operations reporting and quarterly business reviews (QBRs). The evidence should show up in front of you every quarter, not only when an examiner asks.

If you're working toward CMMC specifically, our guide to CMMC and NIST 800-171 for small businesses walks through the requirements and where to start.

Frequently asked questions

Closing the gap between compliance and security

Compliance isn't the enemy. Stopping at compliance is.

Check whether system configuration continues to enforce your requirements at 2 a.m. on a Saturday, outside normal business hours.

Written policies and technical controls need to match.

Put your written policies into practice.

Jim Knotts is Managing Partner at Headway Strategy.