PenTesting Company

Social engineering testing

Social Engineering Tests - Protect Your Organization

Many security incidents start with people, not software. A social engineering test measures how your organization responds when someone tries to trick staff into giving up access or information, and it shows you where to strengthen training and controls.

What is social engineering testing?

Social engineering is an umbrella term for attacks that target people rather than hardware or software. Instead of breaking a system directly, an attacker convinces someone to open a door for them, by clicking a link, sharing a password, approving a request, or handing over information they should not.

Social engineering testing is an authorized, scoped exercise that measures how your people and processes respond when someone tries to trick them into giving up access or information. Testers run scenarios agreed with your organization, such as a phishing email or a phone call with a believable pretext, and note how each one was handled and which controls helped. You get a report on patterns and process gaps, with practical guidance for training, procedures, and technical controls, without blame.

Phishing email

What it measures
Whether people open the message, click, enter details on a landing page, or report it, how quickly the first report reaches the security team, and whether email filtering and the report button help.
When to choose it
You want to see how staff handle the kind of message they are most likely to receive, for example after awareness training or a change to email controls.

Phone pretexting (vishing)

What it measures
Whether staff, such as the help desk, follow their own identity verification steps when a caller uses a believable pretext, what information is shared, and whether the call is escalated.
When to choose it
Your help desk, front desk, or support team can reset passwords, grant access, or share account details over the phone.

Physical scenarios, where in scope

What it measures
Whether someone without authorization can gain access to an agreed location or device, and whether staff challenge or report them.
When to choose it
Your offices or sites hold equipment, records, or network access that matters, and you want to check how access controls and staff respond in person. Physical scenarios are included only when agreed in scope.
Plan a social engineering test

Not sure which scenarios fit? Tell us about your organization and we will help you choose.

Laptop, desktop, and mobile devices used during application testing

What a good report includes

Results you can act on, without blame.

  • Which scenarios were attempted and how they were handled.
  • Business impact described in plain language.
  • Severity rated with a documented, consistent method.
  • Practical guidance for training, process, and technical controls.
  • A readout to walk through the findings with your team.

How we run it

Every engagement follows the same structure, so your team knows what will happen, who is involved, and when testing stops.

  • Planning and rules of engagement: we agree the goals, channels, target groups, exclusions, testing window, and named contacts with your organization in writing before any testing begins.
  • Pretext design: each scenario and pretext is approved in scope. We avoid pretexts that touch pay, layoffs, health, or personal emergencies unless the organization agrees otherwise in the scope.
  • Controlled run: scenarios run only in the agreed window, with stop conditions agreed in advance, such as a named contact asking us to pause or a critical-severity issue that needs immediate attention.
  • Measurement: we track the measures agreed for each scenario, such as reports, clicks, submissions, and whether verification steps were followed, along with how quickly the organization responded.
  • Reporting without blame: results focus on processes, controls, and patterns rather than individuals, with practical guidance for training, procedures, and technical controls.

Our process

  1. 1

    Scope and rules of engagement

    We agree on the scenarios, the targets, and the boundaries before any testing begins.

  2. 2

    Controlled testing

    We run the agreed scenarios in a controlled way and record how they are handled.

  3. 3

    Reporting

    You receive findings with what happened, the impact, severity, and practical guidance.

  4. 4

    Readout

    We walk through the results with your team and answer questions. Retest terms set in the statement of work.

Scoping checklist

These questions define coverage so both sides know what is included. This is about clarity, not a checklist for choosing a vendor.

  • Which scenarios and channels are in scope, such as phishing email, phone calls, or physical access.
  • Who may be targeted and any people or groups that are off limits.
  • What is explicitly out of scope.
  • Rules of engagement and the conditions that stop a test.
  • Who to contact if we confirm a critical-severity issue mid-engagement.

Social engineering testing works best alongside technical testing. If you are also looking at your systems, see our network penetration testing and web application security testing services.

What a social engineering test looks like: a worked example

This is an illustrative scenario, not a real client or case study. The organization and results are hypothetical and are here to show how an engagement runs.

Imagine an organization with an office, remote staff, and an IT help desk. It asks for a phishing email test and a phone pretext test against the help desk.

1. Agreed scope and rules of engagement

  • Channels: one phishing email scenario sent to an agreed group of employees, and phone calls to the help desk using an agreed pretext.
  • Off limits: anyone the organization asks us to exclude. We also avoid pretexts that touch pay, layoffs, health, or personal emergencies unless the organization agrees otherwise in the scope.
  • Data handling: we align on how submitted credentials are treated, for example recording that a submission happened without keeping the password.
  • Timing and stop conditions: the testing window, and the conditions that pause or end the test.
  • Contacts: a small number of people who know about the test, and a person to reach if we confirm a critical-severity issue mid-engagement.

2. What is measured

  • Phishing: who opened the message, who clicked, who submitted details on the landing page, and who reported it through the organization's reporting route.
  • Timing: how long it took for the first report to reach the security team, and what happened next.
  • Phone: whether the help desk followed its own identity verification steps, what information was shared, and whether the call was escalated.
  • Controls: whether email filtering, the report button, and call procedures helped or were bypassed.

3. What the report shows

The report describes what was attempted, how each scenario was handled, and what it means for the business, without blame. Hypothetical examples of what it might record:

  • High: A caller with a plausible story was given a password reset after providing only a name and an employee ID, and the verification step in the help desk procedure was skipped.
  • Medium: Some recipients entered details on the landing page, and the first report to the security team arrived well after the first click.
  • Low: The email filter flagged the first message, and a reworded version was delivered, which shows where the filter rules could be tuned.

4. How awareness follow-up works

At the readout we go through the results with security, IT, and the help desk lead. Follow-up is built around what was observed: for example, a short refresher on the verification steps for the help desk, a reminder of how to report a suspicious message, and changes to the call procedure or email controls.

Whether training material is part of the engagement is agreed in scope.

Retest terms set in the statement of work.

A social engineering test is not a compliance certification. It shows how your people and processes responded to the scenarios that were agreed.

What is included

Beyond the testing itself, you get the deliverables your team needs to prioritize and fix what we find.

  • Scoped social engineering testing of the phishing, vishing, and physical scenarios we agree are in scope.
  • A written report with steps to reproduce, business impact, severity, and remediation guidance.
  • A readout after delivery to walk through findings and answer questions.
  • Retest terms set in the statement of work.

Frequently asked questions

Short answers to common questions about scoping a social engineering test.

Do employees know about the test?

A few named contacts at your organization know about the test, agreed in scope. They can answer questions during testing, pause the test if needed, and be reached if we confirm a critical-severity issue. Keeping the group small lets the results show how people respond day to day.

Is social engineering testing legal?

We test only with written authorization and an agreed scope that sets out the scenarios, targets, exclusions, and timing. For physical scenarios, that authorization has to come from whoever controls each location, such as the building owner or landlord as well as the tenant. Many organizations have their own legal or HR advisors review the scope before testing begins.

What happens to credentials people submit?

How submitted credentials are handled is agreed in scope before testing begins. For example, the test can record that a submission happened without keeping the password.

Will people be named in the report?

Results focus on processes, controls, and patterns rather than individuals. How individual results are handled, and who can see them, is agreed with your organization in scope.

How often should we test?

It depends on your organization's risk and goals, and on changes such as new staff, new procedures, or recent training. We can help you align a testing schedule with those goals during scoping.

Is a social engineering test a compliance certification?

No. A social engineering test is not a compliance certification. It shows how your people and processes responded to the scenarios that were agreed, and it can be one input to a broader security program.

Scope a social engineering test

Tell us what you want to test and we will follow up with next steps.