Social Engineering Testing: What It Involves and When You Need It

‍​​‌‌​‌​​‌‌​​‌‌‌​‌‌‌​‌‌​‌​‌​‌‌​‌‌‌​‌​‌‌‌​‌​​‌​​​​‌‌​‌​​‌​​​​​​‌​‌‍Social engineering testing checks whether your people would fall for the same tricks that real attackers use: phishing emails, pretexted phone calls, and physical access attempts. It targets the gap between your technical controls and human behaviour. 85% of businesses identifying breaches in 2025 experienced phishing (Cyber Security Breaches Survey). Your firewall won't stop an employee handing over credentials to someone who sounds like IT support.

What does social engineering testing actually cover?

Social engineering testing goes beyond sending a few test phishing emails. Here's what a proper engagement covers: multiple attack channels that real attackers use, often in combination.

Email phishing

The tester sends carefully crafted phishing emails to agreed target groups. These aren't the obvious scam emails with broken English and Nigerian prince stories. They're realistic emails that mimic legitimate business communications: an invoice from a known supplier, a password reset notification from a service your organisation actually uses, or a message from a senior manager asking for something urgent. Honestly, the good ones are indistinguishable from genuine emails.

The test measures who clicks, who enters credentials, who downloads attachments, and (just as usefully) who reports the email.

Phone-based pretexting (vishing)

The tester calls staff members and uses a prepared scenario to try to extract information or get them to take an action. Common scenarios include impersonating IT support to get a password reset, impersonating a supplier to change bank details for an upcoming payment, or impersonating a senior manager to bypass a process.

Vishing tests are uncomfortable for organisations because the results are often stark. I've run these calls where I got credentials within three minutes, and the person on the other end genuinely wanted to help me, and that is the whole problem. People are trained to be helpful on the phone, and that is exactly the instinct a skilled pretexting call exploits. The tester sounds legitimate, asks reasonable questions, builds rapport before making the actual request.

Physical access testing

This is where social engineering testing crosses into red team territory. The tester tries to gain physical access to your premises: tailgating through a secure door behind an employee, presenting a fake ID at reception, or accessing a server room that should be locked.

Physical security testing is a separate scope from a standard pen test. Whether it's a Manchester warehouse or a Leeds office block, the rules are different: separate engagement terms, different insurance, explicit permission to be on-site. It isn't always included in a standard social engineering engagement, but for organisations with physical premises that matter (data centres, labs, secure offices), it tests something that no remote assessment can.

USB drop testing

The tester leaves USB devices in common areas (car parks, break rooms, meeting rooms) to see if anyone plugs them into a company machine. The USB devices are harmless but track whether they were connected and to which machine. (as noted in the February 2023 remediation review).

This vector is less common than it was five years ago, and many organisations now disable USB ports as a policy. But where it is relevant, it tests a specific human behaviour that technical controls alone cannot always prevent.

Pretexting through third parties

This is a more sophisticated variant that targets the relationships between your organisation and its suppliers, partners, or service providers. The tester contacts your organisation posing as someone from a company you actually work with. They have done enough research to know who your suppliers are, who your account manager is, and what services they provide.

The test checks whether your staff verify identity before acting on requests. When someone calling from your "IT support company" asks for remote access to a workstation, does the employee verify the request through an independent channel, or do they grant access because the caller knew the right names and the right details? The answer is almost always the latter.

How is this different from a standard pen test?

A standard penetration test focuses on technical vulnerabilities: network configuration, software patches, authentication mechanisms, application security. The tester works with your systems and their configurations. Social engineering testing is the opposite of that. It focuses on human behaviour: how people respond to requests, whether they follow security procedures under pressure, where the organisation's culture creates exploitable gaps. The tester works with your people and their habits.

Test Type	What It Targets	Skills Required	Typical Duration
Network pen test	Systems, servers, configuration	Technical exploitation	3-10 days
Web app pen test	Application code and logic	Application security	2-5 days
Social engineering	Human behaviour and processes	Psychological techniques, pretexting	2-5 days
Red team exercise	All of the above combined	Technical + social engineering + physical	2-4 weeks

A red team exercise combines technical exploitation with social engineering and physical testing to simulate a realistic multi-vector attack. It's the most thorough type of assessment, but it's also the most expensive and most disruptive. Most organisations start with targeted social engineering testing and progress to red teaming when their technical controls are mature.

What do you typically find?

The same patterns come up again and again.

Phishing click rates are higher than expected. Leadership teams are often shocked. Organisations that haven't run simulations before typically see 20-30% of staff clicking on a well-crafted phishing email. That drops after training and regular simulations, but the first baseline test is almost always a surprise.

Phone-based attacks succeed more often than email. People are more cautious about emails because they've been told to watch for phishing. They're less cautious on the phone because vishing awareness training is rare. A confident caller who knows the organisation's structure and uses the right names can extract a worried employee's credentials in under five minutes.

Physical access controls depend on culture, not technology. The door might require a pass, but if the culture is to hold it open for the person behind you, the pass doesn't matter. Physical access testing reveals whether the technical controls are supported by the behaviours they rely on.

Reporting is low. This one leaves security teams genuinely frustrated. Even well-run organisations with a documented "report suspicious activity" policy see actual reporting rates under 10% during tests. Staff don't recognise the attack, don't know how to report it, or don't believe their report will be acted on. Often all three factors apply at once.

Authority overrides procedure. When the test scenario involves someone senior (real or impersonated), people skip the checks they'd normally follow. An email from the "CEO" asking for something urgent gets acted on without verification. Nobody wants to question the boss. That's the mechanism behind business email compromise, and it works because organisational hierarchy is stronger than security policy in most workplace cultures.

Technical staff are not immune. IT teams sometimes assume they'd never fall for social engineering because they understand the technology. In practice, they just get targeted with different pretexts: a vendor calling about a critical patch, a security researcher reporting a vulnerability, a colleague from another office asking for help with a system they both manage. I've seen sysadmins fall for a well-timed "urgent patch" call that any non-technical employee would have ignored. The attacks are tailored to what IT staff find plausible, and the click rates are not much lower than the rest of the organisation.

When do you need social engineering testing?

You need it if:

• You want to measure your organisation's real-world vulnerability to phishing and pretexting
• A standard or framework requires it (some insurance policies, some contracts, PCI DSS)
• Your technical controls are mature and you want to test the human element
• You've had a security incident that involved a human being manipulated
• You're building a case for investing in security awareness training and need baseline data

If you are earlier in your security journey and have not yet sorted the five Cyber Essentials controls, start there. Social engineering testing is most valuable when your technical foundations are in place and you want to assess what falls through the gaps.

How much does it cost

Social engineering testing is priced by the number of days and the scope of the engagement. A phishing-only campaign against a specific department might take one to two days. A thorough engagement covering phishing, vishing, and physical access testing across multiple sites runs longer.

The cost is comparable to a pen test of similar duration. For a targeted engagement covering a London headquarters or a multi-site operation across Birmingham and Leeds, expect £1,500 to £5,000. The preparation is different from a pen test, though. The tester spends time researching your organisation, building realistic pretexts, crafting scenarios that mirror genuine threats. That reconnaissance phase is where the quality of the test lives or dies.

A phishing email that took five minutes to write will be obvious. A phishing email that references a real project your team is working on, sent from a domain that looks like your actual supplier's domain, is a different test entirely.

Some organisations combine social engineering testing with their annual pen test, running the technical and human elements together. This gives a more complete picture of the organisation's security posture and is often more cost-effective than two separate engagements.

What should the rules of engagement cover?

Social engineering testing needs tighter rules of engagement than a standard pen test. You're testing real people, not just systems.

Who is being tested? Agree which departments or individuals are in scope. Testing the entire organisation is expensive. A targeted test of high-risk groups (finance, reception, executive assistants, IT helpdesk) often delivers better insight for less cost.

What scenarios are permitted? The tester should propose realistic scenarios based on your threat model. You approve the scenarios before testing starts. No scenario should cause genuine distress or put anyone at risk.

How are individuals treated? Results should be reported by department or role, not by named individual. The purpose is to identify systemic weaknesses, not to single out specific people. If someone falls for a test, that's a training opportunity, not a disciplinary matter.

Who knows about the test? A small number of people need to know (usually the person who commissioned it and one IT contact for emergency purposes). The wider the knowledge, the less realistic the results.

What does the report look like?

The social engineering test report includes:

• Scenarios used with detailed descriptions of each approach
• Success and failure rates broken down by channel (email, phone, physical)
• Specific findings showing which techniques worked and which didn't
• Cultural observations about organisational habits that create risk
• Recommendations for training, process changes, and awareness improvements
• Comparison data if this isn't the first test, showing improvement trends

What actually matters is that the recommendations are practical. "Train your staff on phishing" is not useful. "Run monthly phishing simulations targeting the finance team with invoice-themed scenarios, and provide immediate click-through education" gives your team something to act on.

What happens after the test

Bottom line: the test results are a starting point, not a conclusion. The value is in what you do with them.

Most organisations respond by implementing or improving a security awareness training programme. Regular phishing simulations with immediate feedback, role-specific training for high-risk departments, clear reporting channels for suspicious activity.

Process changes matter as much as training. If the vishing test succeeded because there is no callback verification procedure for password resets, the fix is not just training. The fix is implementing a procedure where the helpdesk calls the user back on a known number before processing any credential change.

Physical security findings often require both technical and cultural changes. If the tailgating test succeeded, you might need turnstiles or mantrap doors for the technical fix (£2,000 to £8,000 depending on the site), but you also need a culture where challenging someone who follows you through a door is normal and expected rather than rude.

Run the test again in six to twelve months and compare the results. If click rates dropped and reporting rates went up, the training and process changes are working. If the numbers haven't changed, something in your approach needs to change. The training isn't reaching people, the processes aren't being followed, or the cultural shift hasn't happened.

The goal is not a perfect score on every test. People will always be vulnerable to well-crafted social engineering. The goal is to reduce the success rate enough that an attacker has to work much harder, and to increase the reporting rate enough that your security team gets early warning when an attack is in progress. A single reported phishing email can prevent a £50,000 business email compromise, and that is the return on investment.

---

---

Related articles

• Security Awareness Training: What Actually Changes Behaviour
• Can AI Actually Do a Pen Test?
• Infrastructure Pen Testing: What We Actually Test

netsec-canary-fc1256a7e305.