Compliant and Breached: Why Passing an Audit Doesn’t Mean You’re Secure

Compliant and Breached: Why Passing an Audit Doesn’t Mean You’re Secure

SERIES: “The Death of Compliance Theater” — Part 1 of 3

In 2013, Target passed its PCI-DSS assessment. The retailer was, on paper, compliant with the payment card industry’s security standard, the same standard designed specifically to prevent exactly the kind of attack that hit it a few months later, when attackers used stolen vendor credentials to reach point-of-sale systems and walk away with 40 million card numbers.

The certificate wasn’t fraudulent. The assessment wasn’t fabricated. Target had genuinely done the things PCI-DSS asked of it, at the moment someone checked. That’s precisely the problem this series is about.
More than a decade later, that gap hasn’t closed. If anything, it has widened: infrastructure now changes in hours, cloud resources appear and disappear in minutes, and identities multiply faster than any access review can track, while the audits meant to prove all of it is under control still happen, for most organizations, once a year.

Quick answer: A compliance audit measures whether specific controls were configured correctly at a specific point in time, usually verified through screenshots, policy documents, and sampled evidence gathered over a few weeks once a year. It does not measure whether those controls are actually working right now, whether they’ve drifted since the assessment, or whether an attacker has already found the gap between “documented” and “enforced.” Organizations can be fully, honestly compliant and still be actively compromised, because compliance and security are answering two different questions.

The number that should worry every CISO more than their next audit

According to research from Swimlane, which surveyed 500 IT and cybersecurity decision-makers at enterprise companies across the US and UK, 71% of organizations could fail a cyber audit. Only 29% say their compliance programs consistently meet internal and external standards, meaning for most organizations, “compliant” is closer to a temporary state achieved right before the auditor arrives than a durable condition of the environment.

It’s worth reading that number carefully. These aren’t small businesses without a compliance function. They’re enterprises with at least 1,000 employees, dedicated GRC teams, established frameworks, and audit histories. The program holds together for the assessment window, then quietly drifts until the next one.

That gap matters because of what happens on the other side of a breach. IBM’s 2025 Cost of a Data Breach Report puts the average breach at $4.44 million, with organizations taking a mean of 241 days to identify and contain an incident, the fastest that figure has been in nine years, and still the better part of a year. A lot can happen inside an environment in 241 days while everyone involved believes, correctly, that the last audit went fine. An attacker who gets in shortly after an annual assessment could plausibly operate until well past the halfway point to the next one, and every report produced in that time would still say the controls were in place.

Two different jobs, one shared vocabulary

The core issue isn’t that audits are worthless or that compliance teams aren’t doing their jobs. It’s that compliance and security operations were built to answer genuinely different questions, and the industry has spent two decades letting the language blur together until people started treating one as a proxy for the other.

Security operations asks: are we compromised right now? It runs on live telemetry, authentication logs, network flows, endpoint activity, cloud events, updated continuously, because the threat it’s watching for doesn’t wait for a review cycle.

Compliance, as it’s traditionally practiced, asks: did we configure this control correctly, as of the last time someone checked? It runs on retrospective evidence, a screenshot from last quarter, a signed policy document, a sample of logs pulled for the auditor, because that’s what a point-in-time audit methodology was built to produce.

Both questions matter. Regulators, customers, and insurers rightly expect proof that controls exist. The trouble starts when an organization answers the second one and assumes it has also answered the first.

When a passing grade and a live compromise coexist

Here’s the specific failure pattern worth naming directly: a compliance tool queries your cloud provider’s API and confirms multi-factor authentication is enabled for every IAM user. Green checkmark. Auditor satisfied.

What that check can’t see is whether, an hour ago, an attacker used an adversary-in-the-middle phishing kit to steal an already-authenticated session token, bypassing the need to trigger MFA at all, because the session was already established. The configuration is compliant. The environment may not be secure. Those are not contradictory facts; they’re two separate measurements that happen to be pointing at the same control.

The same pattern repeats across almost every control family. A firewall rule set passes review, but an over-permissive exception added last month was never re-assessed. Logging is enabled on every server, but nobody notices that one critical system stopped forwarding logs three weeks ago. Access reviews are signed off each quarter, but a departed contractor’s service account stays active between them. In every case, the paperwork is accurate as of the day it was produced. The risk lives in the days after.

This is also why so much compliance work has a seasonal, panicked quality to it. Swimlane’s research found that 92% of organizations depend on three or more separate tools just to collect audit evidence, only 39% of that evidence-gathering process is automated, and 54% of organizations spend more than five hours a week on manual compliance work, hours that mostly show up in a concentrated scramble before a renewal date rather than spread evenly across the year. Sixty-two percent describe their own evidence-gathering process as at least occasionally error-prone, and 90% worry that poor collaboration between GRC and security teams is undermining audit preparation. None of this reflects a lack of effort. It reflects a methodology built around annual snapshots being asked to answer a question that only continuous observation can actually answer.

What this means heading into the rest of this series

None of this is an argument against frameworks, auditors, or the discipline of compliance itself, organizations genuinely need all three. It’s an argument that the mechanism most companies use to achieve and prove compliance hasn’t kept pace with how fast environments actually change, or with how fast an attacker can exploit the gap between what a policy says and what a system is actually doing.

The answer the rest of this series builds toward is continuous compliance: verifying controls all the time using live operational data, instead of proving them once a year with screenshots. The most direct way to get there is to generate compliance evidence from the same security telemetry that already detects attacks, so the question “are we compliant?” and the question “are we compromised?” finally draw on the same source.

In Part 2 of this series, we look at why the last decade’s wave of “modern GRC automation” platforms, the tools that turned an eight-month manual audit into a four-week dashboard, solved the mechanics of compliance without solving the underlying problem, and why a growing number of compliance teams report being busier than ever despite all that new automation.

And in Part 3, we look at a different approach: how Seceon aiCompliance CMX360 treats compliance evidence as something generated automatically by the security operations already running in an environment, rather than as a separate exercise bolted on alongside it.

Frequently asked questions

Compliance verifies that required controls were configured correctly at the time of an assessment. Security verifies, continuously, whether an organization is being attacked or is already compromised. An organization can be compliant and insecure at the same time if its controls have drifted or are being bypassed.

Yes, and it happens regularly. Certifications verify controls at a point in time; they don't continuously confirm those controls still work or stop active attack techniques. Target was certified PCI-DSS compliant in September 2013, weeks before its breach.

Point-in-time compliance proves controls with evidence gathered during a fixed audit window, such as screenshots, policy documents, and log samples. It describes the environment on the day the evidence was collected, not today.

Swimlane found that 92% of organizations use three or more tools to collect audit evidence, only 39% of the process is automated, and 54% spend more than five hours a week on manual compliance work. That pushes most of the effort into a concentrated scramble before each audit.

IBM's 2025 Cost of a Data Breach Report found a global average cost of $4.44 million and a mean of 241 days to identify and contain a breach, the fastest in nine years but still nearly eight months.

Generate compliance evidence from live security operations data instead of periodic snapshots, and map that evidence to every framework you report against. Seceon aiCompliance CMX360 does this by turning detections and responses from the Seceon OTM platform into evidence across 40+ frameworks.

This is Part 1 of a 3-part series on continuous compliance and security assurance. Continue to Part 2: The GRC Automation Trap.

Sources

Footer-for-Blogs-3

Categories

Seceon Inc