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

You can buy a firewall. You can buy a compliant terminal. You cannot buy the thirty seconds in which a member of staff decides whether the man in the hi-vis jacket is really here to swap the card machine. Staff are the control that runs after every technical control has already been satisfied — and they are the control most businesses invest in last. PCI DSS treats training as a requirement rather than a nicety, and this article covers what it asks for, what fraud actually looks like from behind the counter, and how to keep evidence your acquirer will accept. If you are still getting the basics in place, our complete PCI DSS compliance guide sets out the wider picture first.

Why does training matter more than the technology?

Because attackers have noticed it is cheaper. Breaking modern payment encryption is hard work; persuading a busy person to read out a code, approve a refund or plug in a replacement terminal is not. The overwhelming majority of successful attacks on small businesses start with someone being helpful — answering a plausible email, trusting a caller who already knew the manager's name, letting a contractor into the back office because they were expected on Tuesday and it is Tuesday.

This is also the part of compliance that decays fastest. A firewall configured correctly stays configured. A team trained in March has, by November, gained two new starters who were never trained at all and lost the habit of asking awkward questions. Training is a maintenance task, not a project.

What does PCI DSS require you to train staff on?

Requirement 12.6 is the core of it. In plain terms, the standard expects you to run a security awareness programme, to review it at least once every twelve months and update it as threats change, and to train personnel when they join and at least once every twelve months thereafter. Three details are easy to miss. The training must use more than one method of communication, so an annual slide deck on its own does not satisfy it. Personnel must confirm, at least annually, that they have read and understood the security policy — an acknowledgement you need to be able to produce. And the content is not left entirely to you: the standard specifically requires coverage of phishing and related attacks and social engineering, and of the acceptable use of end-user technologies such as laptops, phones, removable media and remote access.

Two other requirements add obligations that are easy to miss. Requirement 12.10 expects an incident response plan and expects the people with a role in it to have been trained on that role — a plan nobody has rehearsed is not much of a plan. And if you take payments face to face, Requirement 9 asks you to train the staff who work near card terminals to spot tampering and substitution, to verify the identity of anyone claiming to be there to install, service or replace a device, and to report anything that looks wrong.

One caveat on scope, because it cuts both ways. The shorter questionnaires do not all ask about security awareness training — a fully outsourced e-commerce merchant, for instance, validates only a narrow slice of Requirement 12. That does not mean the obligation disappears; a requirement being absent from a form is a reporting decision by the card brands, not a statement that the risk does not apply to you. It does mean it is worth knowing which questions you will actually be asked before you build a programme around requirements you do not report against.

That last one is worth dwelling on, because it is the requirement that most often exposes a business with otherwise decent security. It sits alongside the practical premises controls covered in our guide to physical security for card data.

What does card fraud look like from behind the counter?

Training lands better when it describes situations staff recognise. These are the scenarios worth rehearsing by name:

• The unannounced engineer. Someone arrives to service, inspect or replace a terminal that nobody reported as faulty. The genuine version of this visit is always arranged in advance and the visitor can be verified with a phone call to a number you already hold — not the number on their paperwork.
• The swapped or tampered device. A terminal that looks slightly wrong: an unfamiliar serial number, a loose or mismatched casing, an extra cable, stickers or seals that do not match the others, or a device that has moved position overnight.
• The bank that phones you. A caller who knows your business name, your manager's name and possibly your last transaction, asking you to confirm details, move money, read out a code or run a test transaction. Real banks and real acquirers do not ask staff to do any of these on an inbound call.
• The urgent email from the boss. A request to change supplier bank details, buy gift cards or send a payment report, arriving when the named person is known to be away and pressing for speed and discretion.
• The refund that benefits a card you have never seen. Refund and cancellation fraud usually involves pushing money to a different card from the one that paid, and is often committed with a member of staff's cooperation rather than around them.
• The distraction pair. One customer occupies the person at the till while the other gets a moment alone with an unattended terminal, a card, or a screen left logged in.

What about phone and online payments?

Card-not-present channels have their own failure mode: staff writing card details down. It happens for entirely practical reasons — the line is bad, the system is slow, the customer is reading fast — and it converts a compliant process into a paper record of full card numbers sitting in a drawer. Train the specific behaviour, not the abstraction: card numbers are typed straight into the payment system and never onto a pad, a form, an email, a chat message or a CRM note. Our guide to PCI compliance for phone payments explains the compliant ways to take a card over the phone, including pause-and-resume recording and pay-by-link.

The security code on the back of the card deserves its own sentence in any training session, because the rule is absolute and frequently broken: it must never be stored after the payment is authorised. Not in a note, not in a booking record, not 'until the customer checks out'.

How often should you train, and what counts as evidence?

The floor is on hire and at least once every twelve months. The floor is also, in our experience, not enough on its own — an annual session is forgotten by spring. What works in a small business is a short refresher every month or quarter that covers one thing properly, plus the full session annually and whenever something changes: a new payment channel, a new till system, a new supplier with access.

Whatever you run, keep the paperwork, because 'we talk about it constantly' is not evidence. A simple record is enough for a self-assessment: the date, who attended, what was covered, and a signature or acknowledgement from each person. Keep the materials you used and the dates you reviewed and updated them. If you are ever asked to demonstrate compliance after an incident, this file is the difference between a business that trained its staff and a business that says it did.

What should the training actually contain?

• Why card data matters: what you hold, what it is worth, and what a breach would cost this business specifically.
• The card data rules in one breath: never write it down, never email it, never store the security code, never take a photo of a card.
• Phishing and social engineering, with real examples — ideally ones aimed at your own trade.
• Verifying visitors and callers, and the explicit permission to say 'I'll call you back on the number we hold'.
• Terminal checks: what your devices should look like, who is allowed to touch them, and what to do about anything unfamiliar.
• Passwords and multi-factor authentication: individual logins, no sharing, and what to do when a code arrives that nobody requested.
• Reporting: exactly who to tell, how fast, and a clear statement that reporting a mistake carries no blame.

What do you do when someone gets it wrong?

Treat the first report as a success, because it is. A member of staff who says 'I think I just clicked something' within two minutes has handed you the cheapest possible version of that incident; the same person, afraid of the consequences, hands you the most expensive one four hours later. Make the reporting route obvious and the response blameless, and make sure the person receiving the report knows what to do next. Since the click that starts all this is usually an email, it is worth pairing this training with our guide to why phishing still works.

Key takeaways

• PCI DSS Requirement 12.6 makes security awareness training a requirement: on hire, at least annually, and specifically covering phishing and social engineering.
• If you take payments face to face, Requirement 9 adds terminal tamper-awareness and visitor verification for the staff who work near your devices.
• Train the scenarios staff will actually meet — the unannounced engineer, the bank that phones you, the urgent email from the boss.
• Never write down card numbers and never store the security code after authorisation; these two rules prevent a large share of small-business incidents.
• Keep dated attendance records. Undocumented training does not exist as far as an assessment is concerned.

Not sure whether your current training would satisfy an assessment? That question is part of what we answer for every client. Fraud Defence First's fully managed PCI compliance service works through the policy, training and incident-response questions with you, completes the right questionnaire and files it with your acquirer — for a flat £100 + VAT a year.