Social Engineering & Persuasion

A phishing simulation is only useful if it’s convincing. A message nobody falls for measures nothing; a message everyone falls for teaches nothing if it’s a cheap trick. This guide explains why people click — the persuasion principles real attackers exploit — and how to apply them in PhishSpot to build simulations that produce honest results and, crucially, a teachable moment.

This is written for security and awareness teams running authorized simulations against their own organization. The goal is never to embarrass employees — it’s to find and close the gaps before a real attacker does. Keep Designing Effective Campaigns open alongside this: that guide covers the mechanics, this one covers the psychology.

32.1 Why people click

Falling for phishing is rarely about intelligence. Attackers succeed by triggering fast, automatic decisions — exploiting how busy people process a flood of email on autopilot. The same six principles of influence (popularized by Robert Cialdini) underpin almost every effective phish:

Principle	The lever	Example pretext
Authority	We comply with figures of power	”Message from the CEO,” “IT Security policy update”
Urgency / scarcity	A deadline short-circuits scrutiny	”Your account will be locked in 24 hours”
Social proof	We follow what others do	”12 colleagues have already completed this”
Reciprocity	We return favors	”Here’s your bonus statement — confirm to receive it”
Fear	Threat narrows attention	”Suspicious login detected on your account”
Curiosity	An open loop demands closing	”A document was shared with you”

Each maps cleanly onto pretexts you can build in PhishSpot. The most effective simulations combine one dominant principle with strong realism — stacking three or four makes a message read as a scam.

32.2 Designing a believable pretext

A pretext is the story the email tells. Believability comes from consistency, not cleverness:

Plausible context. The message should fit something the recipient actually expects — an invoice for someone in Finance, a shared file for a collaborator, a password-expiry notice that mirrors your real IT process.
Coherent sender. The display name, address, and domain must match the story (see §30.5). A “Microsoft” email from an unrelated domain trains the wrong lesson.
Right tone and branding. Match the voice and visual style of whatever you’re impersonating. A corporate IT notice is terse and formal; a consumer brand is friendly. Use the email HTML techniques to reproduce a brand’s look convincingly.
A single, clear call to action. Real phishing asks for one thing. Multiple asks dilute urgency and raise suspicion.
Just enough personalization. Use {{first_name}} and role data so it feels addressed to the person — but don’t over-personalize in a way a real external attacker couldn’t (that tests a different threat model; see §32.3).

32.3 Targeting and difficulty

Not every recipient should get the same email. Tailoring the pretext to the audience both improves realism and teaches you where the real risk sits.

Role / department awareness. Use contact data ({{department}}, {{position}}) to choose pretexts that fit: invoice and payment lures for Finance, credential-reset lures for IT-heavy teams, benefits and HR notices for everyone, “executive request” lures for assistants and finance approvers (the classic Business Email Compromise vector). Segment recipients into Groups and run targeted campaigns.
Generic vs. spear. A broad, lightly personalized lure (“your mailbox is full”) models commodity phishing. A spear-phishing simulation references a real project, vendor, or person — much harder to spot, and the right test for high-value targets. Decide deliberately which threat model you’re measuring.
Difficulty laddering. Over a program, escalate. Start with easy, obvious lures to set a baseline and build the reporting habit; progress to subtler, well-branded, context-aware messages. A repeated easy test inflates your numbers without improving resilience.

32.4 The red flags you’re planting

Every simulated phish should contain the teachable signals you want employees to learn to spot. Design them in on purpose, then map results back to them:

Mismatched / look-alike sender domain (micros0ft-support.com).
Urgency and threats (“act now or lose access”).
Generic greeting — which is exactly why you control it: send some recipients a {{first_name}} version and some a generic one, and compare. If personalization sharply raises your click rate, that’s a finding worth teaching.
Unexpected attachment or link, hover-mismatch between link text and destination.
Requests for credentials or payment that bypass normal process.

When you debrief (via the course or awareness page), point employees at the specific flags that message contained. Concrete beats abstract: “this email asked you to log in via a link with a misspelled domain” lands better than “be careful online.”

32.5 Localization and culture

A translated phish is a weak phish. Idiom, formality, and local business norms all signal authenticity:

Polish recipients respond to copy written in natural Polish, with the right register and local references — not machine-translated English. PhishSpot’s curated Polish templates are written by a Polish-speaking team for this reason, not auto-translated (see Phishing Templates).
Localize the pretext, not just the language: the brands, banks, courier services, and government bodies impersonated should be the ones your recipients actually use.
For multinational audiences, segment by language/region and run parallel localized campaigns rather than one lowest-common-denominator email.

32.6 Learning from the results

Persuasion is a hypothesis; the Reports & Analytics funnel is the test. Read results as signal, not a scoreboard:

Compare click vs. submit rates — many people click out of curiosity but stop at handing over credentials. The gap tells you where awareness is holding.
Break results down by department/group to find concentrated risk, not just an org-wide average.
Watch the trend over time across a program — resilience improving campaign over campaign is the real success metric, not a single low rate.
Track reporting, not just clicking — an employee who reports the simulation is the win condition. See Reported Messages.

32.7 Ethics and program hygiene

The line between a useful simulation and a harmful one is the care you take. A program that humiliates people destroys trust and drives under-reporting — the opposite of what you want.

Stay in scope and authorized. Simulate only against your own organization, with leadership and (where required) works-council/HR sign-off. This is security awareness training, not an attack.
Avoid cruel pretexts. Don’t dangle bonuses, raises, layoffs, COVID/medical results, or anything that exploits genuine personal anxiety. Realistic ≠ heartless; these themes cause real distress and backlash and have made headlines for the wrong reasons.
Train, don’t shame. Make the end action a constructive moment — a short course or a reassuring “this was a simulation, here’s what to watch for” — never a public list of who failed.
Reinforce reporting. Reward the behavior you want: praise people who report, make reporting easy (see the Outlook Add-in), and treat a click as a coaching opportunity, not a mark against someone.
Protect the data. Reconsider capturing real passwords (see §30.3); often recording that someone submitted is enough to drive training without storing sensitive values.

Run this way, a simulation does what it’s meant to: it turns a moment of “I almost fell for that” into a durable habit of caution — and gives you the data to prove the program is working.