Social Engineering Testing: Why Phishing Tests Are Not Enough

Annual phishing simulations have become a compliance ritual for many organisations. Employees receive a simulated phishing email, click rates are measured, those who click complete online training, and the result is logged as evidence of a functioning security awareness programme. This is not social engineering testing. It is one data point from one channel, and treating it as a comprehensive assessment produces a dangerously incomplete picture of how susceptible an organisation is to human-targeted attacks.

Real social engineering attacks use whatever channel works. Attackers call help desks, impersonate executives, build rapport over weeks of LinkedIn contact before making a request, walk into offices with a confident manner and a plausible pretext, and send targeted messages crafted around information scraped from public sources. An organisation that has drilled its employees to identify generic phishing emails but has never tested its front desk procedures, its help desk verification processes, or its physical access controls has a gap it does not know about.

What a Phishing-Only Programme Misses

Email phishing simulations typically use generic lures: fake IT notifications, HR announcements, or parcel delivery alerts. Employees who have seen enough of these learn to spot them. What they do not train for is a targeted message that references a real project, a real colleague's name, or a real business process they are involved in. Spear phishing, which is targeted email attack based on reconnaissance, has a substantially different success rate from commodity phishing and is not well-tested by the annual bulk simulation.

Vishing, which is voice phishing via phone or messaging, is an entirely separate attack vector that most phishing programmes do not touch. Attackers calling the help desk and requesting a password reset, calling a finance team member and impersonating the CFO requesting an urgent transfer, or calling an employee and establishing a rapport relationship before a later social engineering approach: these scenarios exploit different human vulnerabilities than email-based attacks and require separate testing to assess and address.

Physical Pretext Testing

Physical pretext testing assesses whether an attacker can gain unauthorised physical access to facilities by presenting a believable cover story. Scenarios include impersonating a contractor, presenting as a delivery driver, tailgating an employee through an access-controlled entry point, or presenting a plausible credential to a reception desk. In our experience testing Australian organisations, physical access controls that appear sound on paper consistently produce surprising results under realistic testing conditions.

Physical access matters because it changes what an attacker can do next. An attacker inside a building can plug a device into a network port, access an unlocked workstation, photograph documents left on desks, and identify physical infrastructure that is not visible from outside the perimeter. An attacker who gains physical access to a server room changes the threat model entirely. Testing whether physical controls hold under a realistic approach reveals gaps that security camera footage and access logs will never show.

Building a Complete Social Engineering Test Programme

A complete social engineering testing programme assesses each attack channel with specific scenarios drawn from real-world threat intelligence. Email phishing covers both bulk and targeted approaches. Vishing scenarios test help desk verification procedures, executive impersonation responses, and how employees handle unusual requests from unfamiliar callers. Physical testing covers entry points, visitor procedures, tailgating controls, and clean desk and screen lock compliance. Each channel requires a different scenario design and different measurement criteria.

Pretext quality matters as much as technical execution. A social engineering test where the scenario is obviously artificial produces artificially bad results. Pretexts should be drawn from realistic situations: a new IT services contractor, a building maintenance visit, a call from the organisation's outsourced payroll provider. The tester's job is to create conditions as close to a real attack as the client's authorisation allows. Findings from a realistic scenario are far more useful for driving behavioural change than results from an exercise employees recognise as a test.

Using Results to Drive Genuine Improvement

Click rates from phishing simulations are a vanity metric if they are not connected to specific programme improvements. The useful output from a social engineering test programme is an understanding of which channels are most susceptible, which pretext categories are most effective, which teams or roles are consistently targeted and most vulnerable, and whether the verification and escalation procedures employees are supposed to follow are being followed in practice.

That output drives specific improvements: procedure changes for help desk verification, physical visitor management updates, targeted training for high-risk roles, and changes to how unusual requests are escalated. These are real programme improvements that reduce susceptibility. Monitoring completion rates for generic awareness training is not a substitute for measuring how the organisation actually behaves when tested under realistic conditions.

• Test email, voice, and physical channels as separate activities with separate scenario design.
• Include targeted spear phishing scenarios, not just bulk simulation.
• Test help desk verification procedures explicitly.
• Run physical pretext scenarios against all significant facility entry points.
• Connect test results to specific programme improvements, not just retraining completion.

To discuss social engineering testing across your organisation, contact Cyberlinx at info@cyberlinx.com.au.