What Eight PCI Audits Taught Me About Real Security vs. Checkbox Security

This entry is part 1 of 14 in the series Technology

TL;DR

I led cybersecurity at a major national retailer for twenty years. Once PCI DSS applied, we passed every audit we faced. Now I ghostwrite books for the security leaders who do this work. Here is what nobody tells you: passing an audit and being secure are two different things. An audit is a snapshot. Security is a habit. Most breaches happen at companies that passed their last audit clean. The checkbox tells you that you met a standard on one day. It says nothing about the other 364. Real security is the boring work you do when no auditor is watching, plus a good auditor who cares about intent and the user training nobody thinks to fund.

For twenty years I ran technology infrastructure and security for a national retailer with hundreds of stores and billions in revenue. When PCI DSS came into effect and applied to us, compliance became part of that job. We passed every audit we faced, year after year. These days I ghostwrite books for CISOs and security founders, so I spend a lot of time getting this exact knowledge out of people’s heads and onto the page. Which means I know the process from the inside, and I know the thing the process does not want you to say out loud.

Passing a PCI audit does not mean you are secure. It means you were compliant on the day someone checked.

Passing a security audit doesn’t mean you’re secure. It means you were compliant on the day someone checked.
Share on X

Those are not the same thing, and the gap between them is where companies get breached. The audit is a photograph. Security is a film. A photograph of a tidy room tells you nothing about whether the room is tidy tomorrow.

What a PCI audit actually checks

PCI DSS is the standard that applies to any business handling credit card data. It exists because payment data is valuable and businesses kept losing it. The standard lays out requirements. Encrypt cardholder data. Restrict who can access it. Maintain firewalls. Patch your systems. Log activity. Test your defenses. The list is long and it is reasonable. Getting those requirements written down in a way people actually follow is its own discipline, which I get into in good security policy names names.

An audit checks whether you meet those requirements at the moment of the audit. An assessor reviews your systems, your policies, and your evidence. If everything lines up, you pass. You get your attestation. You move on.

Here is the part that matters. The assessor is checking a state, not a behavior. They confirm the firewall rules are correct today. They cannot confirm that someone will not change those rules next Tuesday because a vendor asked them to and it seemed harmless. They verify the systems are patched today. They cannot verify you will keep patching them once the audit pressure is off.

The auditor who taught me how audits really work

I got lucky early. Our auditor was a man named Steve Levinson, and he was the best kind of auditor there is. He later wrote the foreword to one of my books, which tells you something about how that relationship went. But what made him good is worth explaining, because it changed how I understood the entire process.

Steve understood something most people miss about PCI. You cannot actually conform to the letter of the standard. Not fully. The standard is enormous, it is written to cover every possible business, and if you tried to satisfy every literal clause exactly as written, you would never finish. A real company with real systems and a real deadline cannot do it.

So Steve focused on the intent of the standard instead of the letter. He looked at each control and asked what it was actually trying to protect against, then judged whether we were achieving that protection, even if our method did not match the literal text. That distinction, between documenting real protection and just satisfying a checklist, is the whole subject of my piece on documenting security policies and procedures, and the regulatory documents that drive them. This did not make the audit easier, exactly. It made it possible. It reduced an impossible checklist down to a subset we could actually confront and finish in the time we had.

A great auditor doesn’t enforce the letter of the standard. Nobody can meet that. They enforce the intent, which turns an impossible checklist into something you can actually do.
Share on X

The thing Steve was truly good at was communicating. He would sit down and talk to you. He took the time to understand exactly what was going on with a control, what our systems actually did, and what genuinely needed to be fixed versus what merely looked wrong on paper. He was not there to catch us. He was there to understand us and help us get to real security.

That is the lesson I wish someone had given me before my first audit. A good auditor is not your adversary. They are the most useful security consultant you will get all year, and they are sitting right across the table telling you exactly where your gaps are. The companies that treat the auditor as an enemy to be fooled are throwing away the best free advice in the building.

The first audit is brutal, and then it is not

I will be honest about the first one. It was tough. We had never been audited before, so we walked in with a long list of things that were not right, and we had no idea how many until Steve found them. That first pass turned up a lot to fix. It was a big jump from where we were to where the standard needed us to be, and there is no way to make that first jump small.

If you are facing your first audit, expect that. You will have more findings than you think. That is normal, and it is not a sign you failed. It is a sign you had never been measured before.

What surprised me is how much easier it got. Each year after that first one, the audit got smoother. We knew what was coming. We had built better infrastructure, partly in response to what the earlier audits taught us. The findings shrank because we had already fixed the structural problems and built habits that kept them fixed. By the later years, the audit was almost routine, because the security work was already done before the assessor arrived. The first audit is a wall. After that, you are just maintaining.

The companies that get breached passed their audits

Look at the big retail breaches of the last fifteen years. Almost every one of those companies was PCI compliant. They had the attestation. They passed the audit. And the attackers still walked out with millions of card numbers.

This is not because the standard is worthless. The standard is fine. The problem is that compliance is a floor, and a lot of companies treat it as a ceiling. They do the minimum to pass, they file the paperwork, and they go back to their actual jobs. The security posture decays the moment the auditor leaves the building.

Most companies treat security compliance as a ceiling. It’s a floor. The minimum. The point where real work starts, not ends.
Share on X

An attacker does not care that you passed an audit in March. They care whether the door is open in September. And doors that were locked in March drift open all the time, because systems change, people leave, vendors get added, and the careful configuration that passed the audit quietly rots.

The thing that mattered most was not technical at all

Here is what surprised me most over twenty years of this. The single highest-value security work we did was not a firewall rule or an encryption standard. It was training the users.

The end users were the people who actually let attackers in, and almost never on purpose. Someone would get an email, the email would look fine, they would innocently click the link, and just like that we would have ransomware spreading through the environment. It was not malice and it was not stupidity. It was an ordinary person doing what the email asked, because that is what helpful people do.

So we trained them, hard. Not a once-a-year video nobody watches. Real, repeated training about what a bad link looks like, what a phishing email feels like, why the urgent request from the boss might not be from the boss. We taught people to pause and feel the small wrongness before they clicked. That whole problem, the people who can be talked into opening a door no firewall guards, is what I cover in the human layer is where security actually breaks.

This matters for PCI specifically because the standard can make you focus entirely on systems and configurations, the technical controls an assessor can verify. Meanwhile the actual breach is going to come through a person clicking a link, which no firewall rule prevents. The companies that pass the audit on paper and skip the user training are securing the walls while leaving the front door propped open. The human layer is where the real attacks land, and it is the part the checklist barely touches.

You can pass every technical control in PCI and still get breached, because the attack comes through an employee clicking a link. Train your people or none of the rest matters.
Share on X

Real security is the boring work nobody audits

The stuff that actually keeps you secure is unglamorous and continuous. It is patching servers on a schedule and not skipping the ones that are inconvenient to reboot. It is reviewing who has access and pulling it the day someone changes roles, not six months later. It is watching your own logs and noticing when something looks wrong. It is training your people, again and again, because they are the real perimeter.

None of that shows up cleanly on an audit. An auditor can confirm you have a patching policy. They cannot easily confirm you actually follow it every week when nobody is looking. The gap between the policy on paper and the behavior in practice is the whole ballgame, and it is invisible to a snapshot.

The companies that stay secure are the ones where security is a habit baked into daily operations. The patching happens because that is just how the team works. The access reviews happen because someone owns them and does them. The logs get watched because watching them is part of somebody’s actual job. I go deeper on that unglamorous daily grind in the boring security work that actually keeps you safe. The audit, when it comes, is just confirmation of something that was already true.

This is also the kind of distinction that separates a security book worth reading from one that just repeats the standard. When I work with a security leader on their book, the real material is never the framework everybody already knows. It is the hard-won judgment about what actually protects an organization versus what just passes the audit. That judgment is what readers cannot get anywhere else.

Why this matters even if you never touch a credit card

PCI is the example because I lived it, but the lesson is bigger than payment data. The same habits-not-snapshots principle applies right down to your own machines, which I wrote up in home computer security. Any security framework works the same way. SOC 2, HIPAA, ISO 27001, whatever applies to your business. They all certify a state at a point in time. They all create the same temptation to do the minimum, pass, and relax.

And they all share the same trap. The certificate on the wall makes everyone feel safe. Leadership sees the attestation and assumes the problem is handled. Budget for security gets harder to justify, because did we not just pass the audit? The very thing that proves you met the standard becomes the reason you stop trying.

The certificate on the wall makes everyone feel safe. That feeling is exactly how companies stop doing the work that keeps them safe.
Share on X

The certificate is not the security. The certificate is a receipt for one day of security. What protects you is whether the work behind it keeps happening after the assessor goes home.

What I tell people who are dreading their first audit

If you are facing your first PCI audit and you are scared of it, here is the honest advice. Relax, and just get through it. I mean that practically, not as a platitude.

Work with your auditor. Do not try to cover things up, and do not fluff over the parts you know are weak. The auditor already knows what weak looks like, and the moment you start hiding things, you turn the one person who can help you into someone who has to dig. Your auditor does not want you to fail. Genuinely. A good one wants you to succeed, and they will work with you to get there if you let them. So let them. Show them the real state of things, ask what actually needs fixing, and fix it.

That is the whole secret, and it is not technical. The companies that struggle with audits are the ones that treat them as a confrontation. The companies that breeze through are the ones that treat the auditor as a partner. Bring them in, be honest, do the work they point you to, and you will pass. Not by gaming the standard, but by actually getting closer to secure, which was the point the whole time.

Do not aim to pass the audit. Aim to build the security, work openly with the person checking it, and let passing be the side effect. Companies that chase the audit do a frantic cleanup in the weeks before, pass, and then slide back. Companies that build real operations find the audit almost boring, because nothing special has to happen. The assessor shows up and everything is already the way it should be.

Eight clean audits taught me that the audit was never the point. The point was everything that happened in between, and the auditor was there to help me see it.

Frequently Asked Questions

Does passing a PCI audit mean my business is secure?

No. Passing an audit means you met the standard on the day you were assessed. Security is continuous, and an audit is a snapshot. Most companies that suffer card breaches were PCI compliant at the time. The audit confirms a state, not the ongoing behavior that actually protects you.

What is PCI DSS in plain terms?

PCI DSS is the security standard that applies to any business handling credit card data. It sets requirements like encrypting cardholder data, restricting access, maintaining firewalls, patching systems, logging activity, and testing defenses. It exists because payment data is valuable and businesses kept losing it.

How should I approach my first PCI audit?

Relax and get through it, and work with your auditor instead of against them. Do not cover things up or fluff over weak spots, because your auditor already knows what weak looks like and wants you to succeed. Expect the first audit to turn up a lot of findings, since you have never been measured before. It gets much easier in later years.

Should I try to meet the exact letter of the PCI standard?

You cannot, fully, and a good auditor knows it. The standard is too large to satisfy literally clause by clause. The best auditors focus on the intent of each control, what it is actually trying to protect against, which reduces an impossible checklist to a subset you can actually achieve. Aim for the protection the control intends, not the literal wording.

What is the most overlooked part of PCI security?

User training. The end users are the ones who let attackers in, almost always by innocently clicking a bad link that delivers ransomware. You can pass every technical control and still get breached through a person. Repeated, real training on phishing and suspicious links protects the front door that no firewall rule covers.

Why do companies that pass audits still get breached?

Because compliance is a floor and many companies treat it as a ceiling. They do the minimum to pass, file the paperwork, and let the security posture decay once the pressure is off. Systems change, people leave, and the careful configuration that passed quietly drifts out of shape. An attacker only needs the door open on one day, not audit day.

Do you ghostwrite books on cybersecurity?

Yes. I ghostwrite books for CISOs, security founders, and technical executives who want their hard-won judgment on the record, accurately and in their own voice. I ran enterprise security for two decades and was technical editor on Cyberheist for KnowBe4, so the engagement is not spent explaining the basics. You can see how I work with cybersecurity leaders on my cybersecurity ghostwriting page.


📝 Disclaimer

The views and opinions expressed in this blog post are solely those of Richard Lowe and are based on personal experience and research. This content is for informational purposes only and should not be construed as professional legal, financial, accounting, or business advice. Always consult with qualified professionals before making important business or legal decisions. Richard Lowe is not a lawyer, accountant, or licensed professional advisor, and this content does not establish any professional relationship.

Leave a Reply

Your email address will not be published. Required fields are marked *