A social engineering drill, usually a simulated phishing email, sends a realistic message and observes whether staff click the link, enter credentials, or report it. It measures behaviour, which neither lectures nor quizzes can.
Because a drill touches mail infrastructure, employee trust and personal data, the planning matters more than the sending. Here is how to run one from start to finish.
Who needs to run social engineering drills?
Some public-sector bodies and regulated organisations are required to run them periodically. Many private companies start because of customer security requirements, ISO 27001 audits, or a phishing incident of their own.
Required or not, if your staff read email, approve payments or manage accounts every day, a drill is the most direct way to measure real risk.
Four things to settle before the drill
Skip these and your data will be wrong, or worse, you will create a dispute.
- Get written authorization: management approves scope, timing and audience, and HR and legal are informed in advance.
- Use a dedicated drill sending domain: never send drills from your corporate or product domain, which risks its reputation and lets staff spot the drill from the URL.
- Have IT allowlist the sender: otherwise the mail filter blocks the message, and you end up measuring the filter rather than people.
- Choose the landing page: show a teaching page on click; if you measure credential entry, the fake login page must record only that something was submitted and never store what was typed.
Design scenarios by department, not one generic email
A generic "you have won a prize" email is easy to spot and measures little. Real attacks target roles: finance gets "supplier bank details changed", HR gets "candidate CV attached", IT gets "your VPN account will be disabled".
Department-specific (spear-phishing) scenarios reveal each team's real weak spots and make remediation more targeted. The sender display name can imitate an internal team, but avoid impersonating a specific real person unless they have agreed to it.
Which metrics matter? Not just click rate
Drill reports often give a single click rate. What is useful is the whole funnel, and whether things improved.
- Click rate: the share who clicked the link, the main behaviour metric.
- Submission rate: the share who went on to enter credentials, a higher risk than clicking.
- Report rate: the share who reported the email to IT, a positive metric you want to rise.
- Open rate is indicative only: mail privacy features and security scanners load content automatically, so opens are inflated and should not drive risk scoring.
- Remediation completion and repeat clickers: did those who clicked finish remedial training, and who clicks across multiple drills.
The five most common mistakes
- Sending drills from the real corporate domain, getting it flagged by mail providers.
- A fake login page that actually keeps employee passwords, creating a new security and privacy risk.
- Publishing the list of who clicked or punishing them, so people stop reporting, which is worse than clicking.
- Sending one generic email that produces a nice number but measures no real risk.
- No remediation afterwards, just a click-rate report, so the next result is the same.
Build it yourself, use a global platform, or a localized service?
Typical options are self-hosting an open-source tool, an international awareness platform such as KnowBe4, or the attack simulation included in some higher-tier Microsoft 365 licences. Points worth comparing:
- Localized scenarios: content in your staff's language and the scams common in your market.
- Drill and training joined up: whether a click automatically assigns remedial training, and whether results flow into training records and audit reports instead of living in two separate systems.
- Sending infrastructure: whether a dedicated drill domain and sender setup is provided, isolated from your corporate mail reputation.
- Managed service: whether someone can design scenarios and run the sending if you lack the staff.
The full flow
A complete social engineering drill breaks down into six steps:
-
1
Get authorization and inform stakeholders
Management approves scope and timing in writing; HR, legal and IT are informed, and the purpose is framed as learning rather than punishment.
-
2
Prepare the sending environment
Use a dedicated drill domain and sender account, have IT allowlist it, and send a test to yourself first.
-
3
Design scenarios per department
Finance, HR, IT and sales each get role-relevant scenarios; decide between a teaching page and a fake login page.
-
4
Send and observe
Send in batches rather than all at once, and record clicks, submissions and reports.
-
5
Remediate those who clicked
Staff who clicked or submitted are routed to remedial training and a test, and the record is updated on completion.
-
6
Report and schedule the next drill
Compile the funnel, department risk and remediation completion as audit evidence, and schedule the next drill to track improvement.
Run drills and remediation with LabLearn
LabLearn's phishing simulation supports email and Slack, a dedicated drill sending domain, and department-specific scenarios; the fake login page records only that a submission happened and stores nothing that was typed. Staff who click are automatically assigned remedial training, and drill and remediation results go straight into the ISO audit report, with no reconciling two systems. If you lack the staff, we can help design scenarios and run the drill for you.
FAQ
Should we tell employees before a drill?+
Announce that the company runs periodic social engineering drills, without revealing timing or content. That respects staff while still measuring real behaviour.
How often should we run drills?+
Commonly at least once or twice a year, quarterly for higher-risk teams, using repeated results to track improvement.
Should employees who click be disciplined?+
Not recommended. Discipline discourages reporting and increases risk. Assign remedial training automatically and follow up on repeat clickers instead.
Will the drill collect real employee passwords?+
It should not. The fake login page only needs to record that something was submitted; no typed username or password should ever be stored.
What if our mail system blocks the drill emails?+
Have IT allowlist the drill sender first; otherwise you are measuring the filter, not employee behaviour.