Social Engineering
Attackers rarely start with technology; they start with a phone call, an email or a confident walk through reception. We run controlled, scenario-based attacks against your people and processes to find out what actually happens when someone plausible asks for something they should not have.
Who this is for
- You have invested in technical controls and want to know whether the human layer holds up
- Helpdesk, finance or reception teams handle requests that attackers love to imitate — password resets, payment changes, visitor access
- You need evidence to build the case for security-awareness investment
- A previous incident involved manipulation rather than malware, and you want to measure whether anything has changed
What we test
Coverage runs in depth, not breadth alone — each stage goes past where the one above it stops.
- Voice
Pretext phone calls
Impersonating IT support, suppliers or executives to request credentials, remote access or sensitive information — the channel with no spam filter in front of it.
- Email
Targeted, not templated
Bespoke scenarios against specific teams or roles, built from open-source research rather than a generic template library.
- Physical
Optional and bounded
Tailgating, visitor-pretext entry and seeded media drops, agreed and scoped in advance — where the engagement calls for it.
- Process
Whether the control survives contact
Verification steps for payments, resets and access requests: whether they exist, and whether they hold up against a persuasive caller under time pressure.
- Reporting
Who spotted it
Not just who was susceptible, but who recognised the attack, how quickly, and whether the report reached anyone who could act.
What you get
The package in three parts — what you read, what you act on, and what happens after.
What you read
What was attempted, and where you held.
- A scenario-by-scenario account of what we attempted, what worked, and where your processes held
- Susceptibility and reporting metrics you can baseline and measure against after training
What you act on
Process fixes alongside the human findings.
- Specific process recommendations — verification steps, escalation routes
- Blame-free findings framed to fund awareness training, never to name individuals
How it runs
How a simulation runs
Scoping & Rules of Engagement
Which hosts, people or systems are in play, at what intensity, in what window — plus your point of contact, the escalation route, and who holds the authority to stop it.
Reconnaissance & Scenario Build
Building the thing that will actually run: a pretext assembled from your own public footprint, an agent and scope for a ransomware run, or a load suite from your API collection.
Written Authorisation
Nothing executes until it is signed. Where a simulation touches your people or your availability, that authorisation is a separate document from the standard engagement terms.
Controlled Execution
The exercise runs inside the agreed window, watched by a named engineer, with the means to halt and reverse it immediately if you ask or if anyone becomes distressed.
Detection & Response Measurement
What your tooling saw, what your people did, and how long each took. This is the output that matters — the simulation itself is only the instrument for producing it.
Stand-down & Reporting
Everything is reversed and removed: files restored, assets deleted, campaigns closed, with the restoration reconciled. Then the annotated timeline, the findings and what to change.
This is our simulation sequence. The six-phase methodology CREST assessed governs our penetration testing, which is a different service.
Prerequisites
- A signed Laneden authorisation form from someone empowered to approve testing of staff and premises
- Agreed scenario boundaries, exclusions and a small circle of informed contacts
- An agreed escalation route in case an attempt is detected and reported to the police or building security
Frequently asked questions
Is it ethical to deceive our own staff?
Done properly, yes — and we insist on doing it properly. Scenarios are authorised in writing, individuals are never singled out in reporting, and results are framed as a test of process and training, not of people. The alternative is finding out from a real attacker.
Will staff who fall for a pretext get in trouble?
Not from us, and we strongly advise not from you. Reports present aggregate results and process gaps. Punishing individuals teaches people to hide incidents — the opposite of the reporting culture the exercise is meant to build.
How far will you actually go?
Exactly as far as the agreed scope. Boundaries — which pretexts, which sites, whether physical entry is attempted, what we do on success — are documented before we begin, and we carry authorisation letters on any physical work.
What if someone reports the attack while it is running?
That is a success, and we record it as one. Detection and reporting speed are core metrics; an organisation that spots and escalates our pretext quickly gets that credit prominently in the report.
Related services
Phishing Campaigns
One convincing email is still the most reliable way into most organisations.
Learn more →
Executive Threat Assessment
Senior leaders are targeted precisely because of who they are: their names authorise payments, their inboxes carry weight, and their personal lives leak online in ways corporate controls never touch.
Learn more →
Ready to test your defences?
Tell us about your social engineering requirement — we'll come back with a scoped proposal within two working days.
Free remediation retesting* to confirm your fixes (subject to assessment size).