Skip to main content
Security Best Practices

Why Good Staff Bypass Security Rules — and How to Fix It

Almost no one breaks a security rule to cause harm. They break it because the rule costs them something and appears to protect nothing. Here is why sensible people work around your controls, and how to design controls they keep.

Fraud Defence First
28 July 2026
7 min read

Almost every business we assess has a security policy. Far fewer have staff who follow it on a busy Friday. That gap is where most real-world compliance failures live — not in the firewall, not in the payment gateway, but in the moment a well-meaning member of staff decides that the official way is going to take too long. It is tempting to file this under carelessness and schedule more training. That diagnosis is usually wrong, and it is why the same workarounds come back a month later. This article looks at why sensible, loyal people bypass security rules, and what to change so they stop needing to. For the wider picture of what PCI DSS expects of you, start with our complete PCI DSS compliance guide.

What does bypassing a control actually look like?

Rarely anything dramatic. The behaviours that undermine card data security are mundane, quick and almost always well-intentioned — someone trying to serve a customer faster or finish a job before closing. In a typical UK small business they look like this:

  • Writing a customer's card number on a pad 'just until the terminal is free', then binning the note at the end of the day.
  • Sharing one login for the till, the booking system or the payment portal because setting up individual accounts was never finished.
  • Propping open the back office door during a delivery, in the room where the terminal and the router live.
  • Emailing a spreadsheet of order details to a personal address to finish the reconciliation at home.
  • Leaving remote access switched on after the IT visit, because turning it off means phoning someone next time.
  • Clicking 'remind me later' on an update prompt for three weeks because the restart always lands mid-service.
  • Telling a caller who claims to be from the bank exactly what they ask, because they sounded like they already knew.

None of these is sabotage. Every one of them is a rational response to a rule that costs the person something now and protects something they cannot see. That is the pattern worth understanding, because it tells you what to fix.

Reason 1: nobody explained what the rule protects

Most security training explains what staff must do. Much less of it explains what happens if they do not — in terms that connect to their own working life. 'Do not write card numbers down' is an instruction. 'A written card number is the one piece of paper in this building that can cost us the ability to take payments at all' is a reason. People follow reasons far more reliably than instructions, because a reason survives situations the instruction never anticipated.

The tell is when staff can recite the rule but cannot say what it is for. Ask three people why the card machine is inspected each week. If the answer is 'because it is on the checklist', the control is being performed rather than understood — and performed controls quietly stop happening the first week someone is off sick.

Reason 2: the secure route costs more than the job rewards

Staff are measured on serving customers, closing sales and getting home on time. They are not measured on compliance. When the secure route adds ninety seconds to a task performed forty times a day, the arithmetic does the deciding — and it decides against you. This is not a character flaw. It is what happens when you ask someone to pay a personal cost, repeatedly, for a benefit that lands somewhere else entirely.

The practical fix is almost never 'try harder'. It is to reduce the cost. A password manager removes the reason to reuse one password everywhere. A second terminal at the busy end of the counter removes the reason to write numbers down. Individual logins that take five seconds remove the reason to share one. Every workaround you find is a piece of free product feedback about which control is priced too high.

Reason 3: the control does not fit the real work

Sometimes compliance is impossible as designed, so staff invent something workable. The classic version is a policy written for how the business was supposed to operate rather than how it does: a rule that card details are never taken over the phone, in a business that plainly takes phone bookings every day. Faced with a rule that cannot be followed and a customer waiting, staff will do the job and quietly drop the rule.

When you find a control everyone ignores, the honest question is whether the control or the process is wrong. If phone payments are genuinely part of your business, the answer is not a sterner policy — it is a compliant way to take them, which is a solved problem. Our guide to PCI compliance for phone payments covers what that looks like in practice.

Reason 4: the shortcut is invisible, and nothing bad happens

Security has a miserable feedback loop. Do the right thing and nothing happens. Do the wrong thing and — almost always — nothing happens either. A shortcut that has worked five hundred times feels proven, and the five hundred and first time is indistinguishable from the rest right up until it is not. Worse, the shortcut usually spreads: a new starter learns the workaround from a colleague rather than the handbook, and within a year it is simply how the job is done.

This is the strongest argument for the boring controls — logging, individual accounts, periodic checks. Their value is not that they stop the shortcut. It is that they make it visible while it is still cheap to correct.

Reason 5: the policy describes a business you no longer are

Policies age badly. The document was written when you had one terminal, no online ordering and nobody working from home. Since then you have added a booking system, a tablet on the floor and a supplier with remote access. Staff notice the mismatch long before management does, and a policy that is visibly out of date loses authority over the parts that are still correct. PCI DSS anticipates exactly this: your scope, your policy and your risk assessment are meant to be reviewed at least every twelve months and whenever the environment changes. Our PCI DSS compliance checklist is a practical way to run that review.

How do you find the workarounds already happening?

You cannot fix what nobody will tell you about, and nobody volunteers a workaround to someone who might treat it as a disciplinary matter. The businesses that get this right ask in a way that makes honesty safe:

  • Ask 'what slows you down?' rather than 'are you following the policy?'. The first question gets answered honestly; the second gets answered correctly.
  • Watch a shift rather than reading the procedure. The gap between the two is your risk register.
  • Make it explicit that reporting a workaround — or a mistake, or a suspected phishing click — carries no blame. A member of staff who hides a click for four hours is far more expensive than one who reports it in four minutes.
  • Check the leavers list against the accounts list. Dormant accounts belonging to people who left are one of the most common findings in any assessment.
  • Ask new starters after a month what they were told informally. They have not yet learned to stop noticing.

How do you design controls people do not need to dodge?

  • Make the secure path the fast path. If the compliant way is also the quickest way, adherence stops depending on goodwill.
  • Cut the number of rules until every remaining one is defensible. Ten rules people follow beat forty they skim.
  • Give each control an owner and a moment — 'the duty manager inspects the terminals at Monday open' beats 'terminals are inspected periodically'.
  • Automate what you can. Updates that install overnight, accounts that expire on the leaving date and alerts that fire on their own do not depend on anyone remembering.
  • Train in short, frequent, specific doses rather than an annual slide deck, and cover the threats staff actually meet — phishing emails, callers impersonating the bank, someone in a hi-vis asking to swap a terminal.
  • Close the loop publicly. When someone reports a suspicious email, say so and thank them. Visible reporting is what turns a policy into a culture.

What does PCI DSS actually require here?

This is not only good management — a fair slice of it is written into the standard. Requirement 12 expects a documented security policy that is reviewed at least once every twelve months and updated when the environment changes, with information security responsibilities defined for all personnel and understood by them. Requirement 12.6 expects a security awareness programme delivered on hire and at least annually, explicitly covering phishing, social engineering and the acceptable use of end-user technologies. Requirement 12.10 expects an incident response plan and staff who have been trained on their part in it. Our guide to training staff to spot card fraud covers what that programme should contain — these controls fail precisely because they are about people rather than equipment.

The card-handling side has a people requirement too. If you take payments face to face, Requirement 9 asks you to keep an inventory of your card terminals, inspect them for tampering and train the staff who work near them to spot interference and to verify anyone claiming to be there to service a device. A terminal swap performed by a confident stranger in the right jacket is a real attack, and the only control standing in its way is a member of staff who feels entitled to ask for identification.

Key takeaways

  • Staff bypass controls because the secure route costs them time and appears to protect nothing — not because they are careless.
  • Every workaround you discover is feedback that a control is priced too high or does not fit the real job.
  • Rules people can explain survive; rules people merely recite stop happening the first busy week.
  • Make reporting mistakes and shortcuts blameless, or you will simply stop hearing about them.
  • PCI DSS Requirements 9, 12.6 and 12.10 turn much of this into an explicit obligation: trained staff, a current policy, and an incident plan people have actually rehearsed.

If you would rather not work out which of these obligations apply to your setup, that is what we do. Fraud Defence First's fully managed PCI compliance service maps how card data really moves through your business, completes the right questionnaire with you and files it with your acquirer — a flat £100 + VAT a year, including the policy and training questions people find hardest to answer honestly.

Need Expert PCI Compliance Help?

Our PCI compliance specialists are here to guide your business through the certification process. Get personalised advice and ensure your business stays compliant.

28/07/2026
7 min

Training Staff to Spot Card Fraud: What PCI DSS Actually Requires

Your staff are the control that runs when every other control has already been passed. Here is what PCI DSS requires you to train them on, what card fraud looks like from behind the counter, and how to evidence the training when your acquirer asks.

Read Article
28/07/2026
7 min

Why Phishing Still Works — and How to Be a Harder Target

Phishing is the most common way UK businesses get attacked, and the messages stopped being obvious years ago. Here is why it keeps working, what it looks like now, and the handful of controls that actually reduce the risk.

Read Article
28/07/2026
7 min

Physical Security for Card Data: Terminals, Paper and Premises

Encryption does not help if someone can walk up to the terminal. Here is what PCI DSS Requirement 9 expects of a UK business — device inventories, tamper checks, paper handling and who gets into the back office.

Read Article