Most defenses are built for machines – firewalls, MFA, SIEM rules, WAFs. But the part that keeps getting popped isn’t the box, it’s the person. Social engineering works because it aims at human defaults: we trust what looks familiar, we react to urgency, we don’t want to get in trouble, and we like to help. If you understand those levers, you can build playbooks that look less like “generic phishing” and more like believable conversations.

This article is the practical follow-up to a “psychology of the breach” angle: not just why people click, but how to turn that into structured, testable social-engineering scenarios for pentests and awareness programs.

Why psychology matters more than the template

Most bad phishing fails because it looks like phishing – wrong tone, wrong timing, wrong channel. Real attackers don’t start with “Dear user.” They start with: who does this person report to, what tools do they use every day, what are they scared of right now (payroll, VPN, layoffs, compliance), and who they are willing to answer fast.

So: the message is the last step. The real work is mapping the target’s context.

The 3 classic levers: motivation, fear, urgency

You can design 80% of social-engineering content around these three.

1. Motivation (reward, belonging, usefulness)

   • “We’re giving early access to the new HR portal.”

   • “We need your input for the Q1 roadmap.”

   • “Your team was picked to test the new VPN client.”

   • Works best in internal, collaborative cultures.

2. Fear (loss, non-compliance, “you’ll break it”)

   • “Your account will be disabled in 24h unless you update SSO settings.”

   • “Security found suspicious activity; confirm your identity.”

   • “Finance rejected your expense – see details.”

   • Works best in highly regulated environments.

1. Urgency (do it now, window is closing)

   • “Payroll closes in 30 minutes.”

   • “Customer is on the line, need invoice right now.”

   • “CISO asked for a list of admins before 16:00.”

   • Works best when tied to real company timelines.

Rule of thumb: pick один lever per message. Fear + reward + urgency in one email looks fake.

Building the playbook: from recon to message

A good social-engineering playbook for a pentest can be written as a pipeline:

1. Recon on people
   Job titles, teams, tools (Google Workspace / O365 / Jira / Slack / Teams), current projects, time zone. The goal: speak their language.

2. Pick a believable actor (pretext)
   IT helpdesk, HR, Finance, PMO, security, external vendor, or “your manager.” Use the one they already interact with.

3. Pick a believable task
   Reset MFA, review document, sign policy, confirm device, update ticket, join a call.

4. Pick a channel
   Email is the default, but chat (Slack/Teams), calendar invites, and even “we just called you” combos are much more effective.

5. Define the success metric
   Click? Credential submission? MFA fatigue success? Reply? File opened? For pentest reporting you need a clear “attack succeeded when …”.

6. Add safety rails
   No real exfiltration, no real money moves, clear banner or time-bounded domain, agreed user list.

Email patterns that actually get responses

Below are structures, not copy/paste spam. Swap in your org names, tools, and deadlines.

1. Security follow-up pattern

Subject: Action required: confirm your sign-in

Hi <firstname>,
we detected a sign-in to your <tool> account from a new location.
To keep your access active, please confirm this activity in the security panel:
<link>
If you don’t confirm it today, the account may be temporarily locked.

Why it works: fear + mild urgency; aligns with real messages many SaaS tools send.

2. Internal tools roll-out

Subject: Quick check: new VPN profile for your team

Hey,
IT is moving Sales/CS to the new VPN profile. It takes ~30 seconds.

1. Open the page

2. Download the profile

3. Click “Apply”
If you’re traveling today, do it now so you don’t lose access

Why it works: motivation (“everyone’s moving”), plus relevance to role.

3. Finance / payroll nudge

Subject: Expense report issue - needs update

Hi,
your expense report for March can’t be processed because of a missing field.
Please review the details here: <link>
If this isn’t fixed today, it will move to the next payroll batch.

Why it works: urgency tied to money.

Chat / messenger attacks (the 2025 reality)

People are getting better at spotting bad emails. They are not yet good at spotting bad Slack/Teams messages, especially from “IT” or “Security” accounts.

Example flow:

1. “Hi, we’re rolling out phishing-resistant MFA today. Are you at your laptop?”

2. (User says yes.)

3. “Great, open <link to controlled page>. I’ll see the status on my side.”

It feels like help, not like an attack. You can make it stronger by referencing real internal channels:

• “Same as the VPN update from last Friday.”

• “This is part of the Q3 security OKRs.”

• “You’re in the pilot group, so thank you for doing it early.”

Important: for pentests, you tell the client what persona you will use in chat and exactly what the page will collect.

Measuring success (without being evil)

For reporting and for training users, define success levels upfront:

1. Engagement: user replied / clicked / followed the chat instructions.

2. Disclosure: user typed credentials / token / code.

3. Privilege: user’s account had access to something sensitive.

4. Lateral movement potential: from this account you can reach Jira/CRM/SharePoint/Git.

You don’t have to actually take the data – you just show that the user was willing to give it. That’s enough to prove the human control failed.

Staying inside the rules

Because this is social engineering, you have to show the customer (or your internal security lead):

• which users you targeted;

• what exact content you sent;

• what you logged;

• how you will clean it up afterward;

• and that you didn’t go after personal/health/financial data unless they explicitly allowed it.

That makes the exercise reproducible and defensible.

Turning it into awareness, not blame

The best outcome isn’t “we tricked 40%.” The best outcome is: now we know exactly which narratives work on our people, so we can add them to training and to detections.

• If “security follow-up” worked → add lookalike-domain checks and DMARC enforcement.

• If “chat from IT” worked → add a rule: IT never sends auth links in chat; always via service desk.

• If “finance/payout” worked → add a second-person approval for anything with money.

Social engineering should leave people with a clear rule, not with shame.

Recap you can paste into your playbook

• Start from context, not from the template.

• Use one lever per message (motivation, fear, or urgency).

• Pick the actor your target already trusts.

• Define success metrics before sending anything.

• Keep everything logged and show it to the customer.

• Turn the successful lures into awareness material.

That’s how you go from “we sent some phishing” to “we understand how people in our company get tricked – and we closed those gaps.”