Service 05
Security awareness
training
Training aimed at what each group is actually exposed to — and measured on whether behaviour changed, not on whether the module was completed.
In short
Security awareness training is the practice of preparing people to recognise and respond correctly to the attacks they are personally likely to face. It works when it is role-specific, recurring and safe to fail; it fails when it is an annual generic video whose only measurable output is a completion percentage.
Why most awareness training does not work
Three reasons, consistently. It is generic, so a finance clerk and a backend developer receive identical material about risks only one of them faces. It is annual, while the attacks it describes change monthly. And it is punitive, so when someone realises they have clicked something they should not have, the incentive is to stay quiet — which converts a five-minute problem into a five-week one.
The single most valuable behaviour any awareness programme can produce is fast reporting. Someone who clicks a phishing link and tells you within two minutes has given you a manageable incident. The same person, afraid of the consequences, gives you a breach discovered by a third party six weeks later.
What we typically deliver
Core awareness for all staff
Phishing and business email compromise, social engineering by phone and messaging, credential hygiene and password managers, multi-factor authentication and MFA fatigue attacks, safe handling of sensitive data, device and remote-working practice, and — given equal weight — exactly how and to whom to report a suspected incident.
Secure development training
For engineering teams: the OWASP Top 10 worked through against realistic code rather than slides, secure design and threat modelling, authentication and authorisation done properly, secrets management, dependency and supply chain risk, and how to read and act on a penetration test report. Where possible we build the material around findings from your own assessments, which lands considerably harder than a generic example.
Executive and board briefings
Senior staff face a different threat: they are targeted individually, they can authorise payments, and their approval carries weight that attackers borrow. Sessions cover impersonation and CEO fraud, the governance duties that now sit with management bodies under regimes such as NIS2, incident decision-making, and what questions a board should be asking about security that it probably is not.
Phishing simulation
Realistic, consented simulation campaigns that produce useful data — click rates, credential submission, and most importantly report rates over time. Run as measurement and coaching, not as a trap. Anyone who reports gets immediate positive feedback; anyone who clicks gets a short, non-punitive explanation of what they missed, at the moment they are most receptive to it.
Tabletop exercises
Scenario walkthroughs that put decision-makers through a realistic incident and expose the gaps that only appear under pressure: who authorises taking a system offline, who speaks to customers, who contacts the insurer, and what happens when the person named in the plan is on holiday. Closely related to the readiness work described under incident response.
How we measure it
Completion rates measure attendance, not learning. We track measures that correspond to real risk reduction:
- Report rate — the proportion of simulated attacks reported, and how quickly. This is the headline number, and the one that should be rising.
- Time to first report — how long between a campaign landing and the first person raising it. In a real incident, that interval is your head start.
- Repeat susceptibility — whether the same individuals or teams keep clicking, which identifies where coaching is needed rather than who to blame.
- Severity-weighted results — whether people are falling for crude attempts or only for well-crafted, targeted ones, which are two very different findings.
What you receive
A typical programme delivers the following. Content and cadence are set per audience rather than issued as one course to everyone.
- Live or recorded sessions tailored to each audience, delivered remotely or on site.
- Materials your organisation keeps and can reuse for new joiners.
- Simulation campaigns with reporting that distinguishes coaching needs from cultural problems.
- A programme plan setting out cadence over the year, so training is continuous rather than annual.
- Metrics suitable for evidencing awareness training obligations under ISO 27001, GDPR and similar regimes.
Questions we are asked
How often should security awareness training run?
Continuously, in small doses, rather than annually in one large one. A practical pattern is a substantive session at induction and once a year, short reinforcement quarterly, and phishing simulation on a rolling basis. Frequency matters more than duration: recognition of an attack pattern decays within months, and an annual session spends most of the year out of date.
Is phishing simulation fair to employees?
It is, provided it is run as measurement rather than entrapment. That means telling staff in advance that simulations happen as part of the programme, avoiding themes that exploit personal circumstances such as bonuses, redundancies or bereavement, never using results in disciplinary processes for ordinary mistakes, and giving immediate constructive feedback. Simulations designed to humiliate produce lower report rates, which is the opposite of the goal.
Does awareness training satisfy our compliance obligations?
It contributes to them. ISO 27001 requires awareness and competence, and expects evidence that it happened and was effective. GDPR expects staff handling personal data to be appropriately trained. PCI DSS requires security awareness training at least annually and on hire. Our programmes produce the attendance records and effectiveness metrics those regimes expect — but the point of the training is the behaviour change, and the evidence is a by-product.
Our developers say generic training wastes their time. Are they right?
Largely, yes. Telling an engineering team not to reuse passwords is not a good use of their attention. Developer training should be about the decisions they make in code and design — authorisation logic, input handling, dependency risk, secrets management, threat modelling — and it works best when it is built around real findings from your own applications. That is a different course from the one the rest of the organisation needs, which is why we do not deliver one course to everyone.
Can you train a distributed or multilingual workforce?
Sessions are delivered remotely as standard, which suits distributed teams, and are also available on site where an organisation prefers it. Delivery is in English. For a workforce that needs material in other languages, we will say so plainly during scoping rather than delivering training people cannot fully follow — comprehension is the entire mechanism by which this service works.
Next step
Talk to a security consultant
Tell us what you are building, defending or certifying. We will tell you plainly what we would test first, what it takes, and whether you need us at all.