Reading security compliance training with a sceptical eye

"Security compliance training" is doing two entirely different jobs in one phrase, and confusing them is why so much of it is a waste of an hour.

The first job is evidence. Somebody outside your business (an insurer, a customer's procurement team, an auditor, a contract), wants proof that your staff were trained. The deliverable is a record.

The second job is behavior. You want the person in accounts to phone the supplier before changing bank details, and the person in the warehouse to report a strange message instead of quietly deleting it. The deliverable is a changed habit.

A program designed for the first job produces completion certificates and no behavior change. A program designed for the second may produce no paperwork at all. You need both, but you have to design for them separately and stop pretending one delivers the other.

What to take away

What training can realistically change

Be honest about the mechanism. Training does not make people better at detecting deception; that skill degrades with fatigue, workload, and the sheer plausibility of a well-made message. Any program sold on the promise that your staff will reliably spot everything is selling something that does not exist.

For example, treat a pitch such as “our course will make every employee spot every phishing email” as a claim to test, not proof; ask what behavior it changes and what evidence supports that result.

What training does well is install specific, rehearsed responses to recognizable situations. That is a much narrower claim, and a much more useful one.

Realistic goals are five specific habits:

Five habits. That is a realistic curriculum for a small business, and it maps onto the controls described in phishing defense.

Design rules that make a difference

Short and frequent beats long and annual. Ten minutes at a monthly team meeting on one specific thing outperforms a ninety-minute annual module that everyone clicks through at speed.

Use your own situations. Generic material about a fictional corporation lands nowhere. Discussing an actual near-miss from your own business, anonymized if necessary, is the version people remember, because they recognize the supplier and the invoice.

Train the response, not the detection. Rather than "how would you spot this", ask "what do you do when you are not sure". The second question has an answer everyone can execute.

Make the safe action the easy one. A report button in the mail client beats an address to remember. A password manager with everyone's logins already loaded beats a policy about password length. Most training failures are actually friction failures.

Train the specific role. Whoever handles payments needs the payment verification rule drilled until it is reflexive. Whoever administers systems needs to know what an unexpected consent prompt means. Everyone else needs the reporting route and not much more.

Include the owner. Training that senior people are excused from teaches everyone exactly how seriously to take it, and senior people are the ones being impersonated.

Simulated phishing, done in a way that helps

Simulations are useful and easy to run badly. The difference is what you measure and what happens afterwards.

Measure the reporting rate as the primary number. Click rate tells you about the difficulty of the message you sent, which you controlled. Reporting rate tells you whether your detection-by-humans channel works, which is the thing you are actually trying to build. A team where many people reported quickly is in good shape even if some clicked.

Treat a click as a system finding, not a personal failure.

Follow up privately with a short explanation: what to look for and what to do next time. Skip the scoreboard.

Publishing names or attaching consequences turns your reporting channel into one where people hide things. You paid to become less safe.

Do not use themes that cause real harm. Fake bonus announcements, fake redundancy notices, and fake HR investigations produce genuine distress and lasting resentment, and the lesson people take away is about the employer rather than about security.

Tell staff that simulations happen, as a standing fact, without announcing dates. Consent to the practice is compatible with a valid test.

Run them at a modest, regular cadence, and watch the trend in reporting rate rather than any single result.

The compliance half: find out what actually applies to you

Honest position: no one can tell from a distance which rules bind your business. Obligations depend on your industry, where you operate, where your customers are, what data you hold, and what you signed.

Start by checking named requirements, not assuming every small business has the same obligations: PCI DSS applies to payment-card environments; HIPAA covers covered entities and business associates; and the FTC Safeguards Rule covers certain financial institutions under FTC jurisdiction. Also check the breach-notification statutes of relevant U.S. states. Depending on whose personal data you process and where, the GDPR or California Consumer Privacy Act (CCPA) may apply. Customers may require ISO/IEC 27001 certification, a SOC 2 report, or alignment with the NIST Cybersecurity Framework (NIST CSF); these are not interchangeable with laws. Confirm which requirements apply, what training evidence is required, and any notification deadlines in the applicable rules and contracts.

Anyone who states them as universal facts is guessing. Acting on a guess leaves businesses with expensive controls they did not need and missing controls they do.

Ask each of these, in writing, and keep the answers. Ask them to cite the specific law, standard, or contract clause, say what training evidence they accept (such as dated attendance or completion records and course materials), and identify any applicable deadlines. No single record or certificate satisfies every requirement.

For a readable working checklist, put the questions to your legal adviser, the regulator administering any applicable rule, your insurer, and the customer whose contract sets security terms. Ask each to identify the specific requirement and the evidence it accepts; do not assume one party's answer applies to another.

The insurance and customer questions are the ones small businesses skip, and they are frequently the most binding in practice. A cyber policy may require particular controls as a condition of cover; a large customer's contract may require notification within a stated period. Those obligations arrive quietly in documents you have already signed.

The records that make all of this easy

There is no universal evidence packet: ask the insurer, customer, auditor, or regulator what it accepts. As a practical working file, keep dated attendance or completion records and the course materials used; the current curriculum and its review date; simulation results and follow-up; restore-test evidence; and notes from incident-plan rehearsals. These records make it easier to answer questions, but they do not guarantee that a particular regime's requirements are met.

That last point is worth sitting with. Policies get copied from templates because they look like the deliverable. But the document is not the control, and a policy that describes an imaginary business is a liability in exactly the circumstances where you would want it to help.

Measuring whether any of this worked

Completion percentages measure attendance. Use them for the evidence job and ignore them for everything else.

Measure reporting speed: how many people reported the last simulated message, and how quickly? To check whether payment verification is actually happening, ask the finance team when they last called a supplier back.

Also measure how long it took to report the most recent genuine suspicious message and whether anyone has been made uncomfortable for reporting something. That last one is qualitative, and it is the leading indicator for everything else.

The United States Federal Trade Commission publishes general data security guidance for businesses that is free to read and reasonable as orientation. It does not establish what your business is required to do, which remains a question for your own legal advisers, your regulator, and your contracts.

Common questions

How often should we actually run something?

Ten minutes a month beats anything annual, and the annual module is worth keeping only where somebody outside the business insists on a quantity. What matters is the recurrence, not the total hours.

Who should own it in a business with no security person?

Whoever already runs recurring internal things: an office manager, a practice manager, the person who chases timesheets. An hour a month is the real requirement, and the material can be bought or borrowed.

Does a certificate satisfy an insurer or a customer?

Ask them, in writing, what evidence they accept, and produce exactly that. Guessing is how a business buys a platform to satisfy a requirement a dated attendance record would have met.

What about contractors and part-time staff?

They get the same reporting route and the same rules from the first day. Build the list from who holds access rather than from who is on payroll, which is the same list the reviews in identity and access work from.

Nobody reports anything. Is that a good sign?

No. It usually means the route has friction or somebody was once made to feel foolish, and both are worth more attention than any module. The verification rule that protects the money is the one in business email compromise, and it works because people have practiced it aloud rather than because they read about it.

Where can we get material without writing it ourselves?

The Cybersecurity and Infrastructure Security Agency's Secure Our World resources are written for general audiences and cover the everyone-gets-this half of a program. Keep the other half specific to your own near misses, which is the part people remember.