When do you get to be the difficult person who says no? That’s the question underneath this story.

I worked on ATM infrastructure at a major UK bank in the mid-2000s. The Payment Card Industry Data Security Standard — PCI-DSS — had teeth on the regulatory side. Compliance was the stated goal. But the distance between “we aim for compliance” and “we are actually compliant” was, in certain corners, quite considerable.

I was the person who kept pointing at that distance.

Not theatrically. More like: raising the same issues in writing, making sure they appeared in the same documents, not letting things get quietly resolved by being quietly ignored. Cardholder data storage. Key management. Logging. The controls that, if you don’t nail them, create exposure. And cost money and time to nail properly, which is why they get the side-eye.

Colleagues thought I was being over the top. “Gold-plating,” they said. The standard says X, we’re near enough, and your insistence on actually reaching X is slowing us down.

Here’s the systems thinking part: **there’s a difference between designing systems and accepting risk within systems.** If the requirement exists, it exists for a reason. That reason is a threat model. The attack surface doesn’t care that you nearly met the logging requirement. The attacker who finds unencrypted account data in a temp file doesn’t give partial credit for effort.

I didn’t forecast any specific incident. What I had was a simple model: if the control exists for a reason, you don’t implement it, and the reason later manifests, then the gap is not an administrative failure. It’s the reason the system failed. That model has held up.

The industry learned this the hard way, repeatedly. The big card breaches of the late 2000s and early 2010s — congressional testimony, nine-figure fines — had remarkable numbers of PCI requirements documented as gaps and left in place. Not because people were careless. Because fixing them cost something, and somewhere in a room, someone argued the risk was manageable.

It wasn’t.

But here’s what actually matters: I was the difficult person saying no. I understood why people wanted to move fast. I also understood why the controls existed. You can choose speed or safety as the primary optimisation. Both are legitimate. But you have to choose. You can’t have both, and you can’t pretend you’re choosing one while actually choosing the other.

The work we did mattered because ATMs handle real money for real people. Getting it right wasn’t pedantry. It was the job. I happened to be the one who thought the job meant what it said.

The question worth thinking about: when are you that person? When do your standards become the hill? How do you know the difference between being right and being inflexible?

I have worked with people since who were far more technically accomplished than me in various respects, who were nonetheless comfortable with “near enough.” I find it genuinely hard to understand. Not in a superior way — I’m sure there are entire dimensions of pragmatism I lack that allow normal humans to function in large organisations. But the specific comfort with leaving a known gap in a security control has always been opaque to me. The gap is right there. You can see it. Why would you leave it?

Anyway. I was right about PCI-DSS. Not in a triumphant way. Just in the basic way where the thing I said would matter did, in fact, matter, and the things that got waved through as acceptable risk occasionally weren’t. That’s all.

The industry learned. Slowly, expensively, and in some cases after considerable customer harm. But it learned. I suppose that counts.