In September 2013, Target confirmed that its systems were certified as compliant with PCI DSS standards. Eleven weeks later, attackers walked out with 40 million credit card numbers and the personal information of 70 million customers.
Target’s CFO John Mulligan told the Senate Judiciary Committee that the company had passed its PCI inspection shortly before the breach, and that they had a sophisticated anti-fraud system the attackers were nonetheless able to penetrate. The breach eventually cost the company over $200 million in settlements and remediation. None of that was recoverable because they passed a compliance audit.
An audit tells you whether your controls existed at a point in time, but that scope has limits, and it doesn’t say much about whether those controls are holding up on any given Tuesday. Target’s story is a useful illustration of the gap between those two things.
What Compliance Actually Measures
Compliance frameworks like PCI DSS, ISO 27001, SOC 2, and HIPAA are genuinely valuable. They establish baselines, force documentation, create accountability, and give organizations a structured way to demonstrate that they take security seriously. For regulated industries, they’re not optional, and for very good reason.
What they can’t do is account for everything. The SANS Institute’s case study on the breach noted that PCI compliance alone is not a risk management strategy, because it only covers assets related to payment card processes, and the assets posing the greatest risk to an organization can easily fall outside that scope.
In Target’s case, the entry point was a third-party HVAC vendor with credentials to Target’s network. That vendor wasn’t within the PCI scope. The malware that scraped payment card data in memory, before encryption could kick in, exploited a gap the standard hadn’t explicitly addressed. The controls that would have stopped it existed in theory, but alerts went ignored and automated responses had been disabled.

The Snapshot Problem
PCI certifications are, by design, snapshots rather than guarantees. A company can pass its annual audit and fall out of compliance within weeks as systems change, new access points are created, and configurations drift.
This isn’t a failure of compliance frameworks so much as a failure of how organizations treat them. When a certification becomes the goal rather than the baseline, the effort gets concentrated around audit preparation rather than ongoing security practice. Controls get implemented to satisfy requirements, then quietly degrade once the auditor has left.
Where the Gaps Show Up
There are a few specific areas where the distance between “compliant” and “secure” tends to widen.
- Access control in practice vs. on paper. Compliance frameworks require documented access controls and policies around privileged accounts, but they can’t always verify whether those controls are enforced consistently at the endpoint level. An organization can document a least privilege policy, earn certification for it, and still have hundreds of users running as local administrators because nobody enforced the revocation. Actually removing permanent admin rights, enforcing just-in-time elevation, and maintaining a full audit trail is what closes that gap, and it’s what Admin By Request’s EPM solution is built to do.
- Third-party and vendor access. Most frameworks include requirements around third-party risk, but they can’t fully account for the sprawl of vendor access in modern organizations. Contractors, support staff, and software vendors all need some level of access, and managing that consistently is harder than a checklist makes it look. Persistent vendor connections, shared credentials, and access that outlasts the contract are common findings in post-breach investigations, and they were central to what happened at Target.
- Monitoring and response. A compliance requirement to have logging and monitoring in place doesn’t mean those logs are being reviewed, or that the team has capacity to act on alerts. Target had FireEye deployed, received alerts, and hadn’t acted on them. The tool was compliant. The process wasn’t. This is a common pattern: organizations invest in monitoring to satisfy a requirement, then don’t build the workflows around it to make it useful. Logging without review is just storage, and alerts without a response process are noise.

Getting More Out of Compliance
None of this means compliance is a waste of time or money. For organizations handling sensitive data or operating in regulated industries, it’s a minimum threshold, and meeting it matters. Certifications reduce risk, satisfy auditors and customers, and force a level of documentation that most organizations benefit from having.
The problem is treating the threshold as the destination. The frameworks that work best are the ones organizations internalize rather than just satisfy, where the controls required for certification are actually maintained, tested, and extended to cover what the standard doesn’t explicitly require.
Practically, that means enforcing access controls continuously rather than reviewing them once a year. It means including assets outside your compliance scope in your security program, because attackers will find them regardless. It means making sure the tools you’ve deployed for compliance purposes are actually configured to do something when they detect a problem.
If you want to see how Admin By Request’s EPM solution handles the privileged access side of that equation, you can sign up for our free plan and get full access for up to 25 endpoints, or book a demo if you’d rather see it in action first.

