Social Engineering Testing

A social engineering test includes phishing, pretext calls, messaging over the platforms your staff already use, credential harvesting pages, and, by separate written agreement, physical access attempts and device drops. Which of these run against your organisation is agreed at scoping, and every scenario is approved by your white team before it is used.

Phishing and platform messaging

Targeted email, SMS and messages on work platforms, against an agreed population, using pretexts drawn from what an attacker could genuinely learn about you. A convincing sign-in page measures whether credentials are entered, and is invalidated at once.

Vishing and pretext calls

Calls in an IT or supplier scenario that test verification habits rather than gullibility. The question is whether the person asks who is calling and checks, not whether they are polite.

Physical access

Tailgating, reception pretexts, device placement and media left where it will be found. Physical work runs only with an authorisation letter carried by every operator and a named contact reachable throughout.

No, a social engineering test run by us never names the employees who clicked, called back or held the door, and we decline the engagement if that is a requirement. Results are delivered as rates, paths and process findings.

Naming individuals damages the reporting culture you depend on during a real incident. A person who has been on a league table learns to conceal the next mistake, and a suspicious message that is not reported is the one that succeeds.

Your white team sees aggregate results by population and by pretext. Staff hear in the debrief what happened and why it worked, never who fell for it. If a department is the finding, the finding is about its process, not its people.

During a social engineering test we never use pretexts built on bereavement, medical emergencies, redundancy, pay, immigration or visa status, or anything that targets a person's religion, nationality, health or family circumstance. These pretexts work, and that is exactly why they are excluded.

We do not impersonate a real named colleague without that person's own written consent, and we do not use a real bank's or regulator's identity, which is beyond any authorisation you can grant and in several cases unlawful.

We do not retain captured credentials, we do not name individuals in any deliverable, and we do not continue an approach after genuine distress. All of this sits in the rules of engagement before anything is sent, and it is the first thing you should ask any provider for.

No, credentials entered during a phishing simulation are not kept. Entry is recorded as a fact, the credential is discarded at once, and the harvesting page is taken down at the end of the window. The proof needed is that a credential was entered, not the credential itself.

Holding the credential would create a risk for you that the engagement was meant to reduce. It would also turn the test into something your staff could reasonably resent, since a password entered under a false story is still their password.

What the report records is the rate of entry, by population and by pretext, and how long it took for the first report to arrive. Whether the entered password was strong or reused is not examined, because the credential is gone.

Social engineering testing is a scoped engagement with bespoke pretexts that measures your response path, and a phishing awareness platform sends templates and gives you a click rate. They serve different purposes, and the platform is not a substitute for testing whether a report reaches anybody.

The click rate is the less useful number. Whether somebody reported the message, how long that took, and what happened to the report afterwards are the figures your incident response actually depends on, and a platform measures none of them.

Pretexts are drawn from open source research on your own organisation, so they resemble what an attacker who had done the same research would send. That is a different test from a generic parcel delivery template that most of your staff have seen before.

Yes, a physical social engineering assessment can be included, by explicit written agreement, with an authorisation letter carried by every operator and a named contact reachable at all times. We do not attempt physical entry without those in place, in any circumstances.

Physical work covers tailgating, reception pretexts, visitor handling, unattended workspaces and device placement. It measures the process around the door, not the guard on it, and the same no-names rule applies to whoever held it open.

Where the building is shared or leased, the authorisation needs to cover the premises as well as your organisation, and we raise that at scoping. Adding physical access also extends the engagement, mainly because of the reconnaissance and the additional authorisations.

A social engineering test covering phishing and vishing typically runs two to three weeks including the debrief. Adding physical access extends it, mainly because of the reconnaissance and the additional authorisations that entry attempts need.

Preparation takes a large share of that time: agreeing the safety and consent model, open source research, and pretext design and approval by your white team. Execution then runs at an agreed pace, because a burst of identical emails in one hour tests your mail filter rather than your people.

The measurement window stays open after the last approach is sent, because time to first report and what happened to that report are primary metrics and both need time to play out. The debrief follows once the numbers are settled.

If an employee becomes genuinely distressed during a social engineering test, that thread stops immediately and the white team is told, always, without needing to be asked. No result is worth causing real harm to somebody doing their job.

The pretext rules exist to make this rare. Stories that threaten a livelihood, a visa or a family are the ones that cause distress, and they are excluded before anything is sent. Every remaining scenario has been read by your white team with that risk in mind.

An engagement that produces a great click rate and a frightened workforce has failed. The debrief exists so that people who were approached hear what happened and why, and leave knowing the exercise was about the process.

The targets of a social engineering test are an agreed population, chosen with your white team at scoping, rather than the whole company by default. The population is usually defined by function, such as finance, reception, the service desk or a specific site, because the pretext that works against each is different.

Open source research then shows what an attacker could genuinely learn about those people from public sources: names, roles, suppliers, projects and the platforms they use. That picture is itself a finding, and it shapes which pretexts are proposed.

Individuals can be excluded for any reason, and the white team is asked at scoping whether anyone should be, such as people on leave or anyone in a difficult personal situation. Nobody is approached because of who they are, only because of what their role can do.

Social engineering testing is lawful in the UAE when it is authorised in writing by your organisation and stays inside what that authorisation can cover. The authorisation letter exists before anything is sent, names who signed it, and names who can stop the engagement instantly.

Some things sit beyond any authorisation you can grant. Impersonating a real bank or a regulator is one, which is why we never do it. Physical entry to premises you do not control is another, and shared buildings are raised at scoping.

Inside your organisation, the white team is the small group who know the test is running, approve every pretext, and can be reached at all times. Everyone else is unaware, because the point is to measure how people and process respond when nobody has been warned.

A social engineering test report contains rates and paths, never names. It is written so that staff can hear it in the debrief and so that a regulator can see what was measured and what changed as a result.

What is measured

Delivery, interaction, credential entry, report rate, time to first report, and what happened to that report. Each is broken down by population and by pretext, so you can see which story worked where.

What is reported

Why the pretext worked: the approval path, the shared mailbox, the supplier nobody verifies, the reporting button that reaches no one. Process findings carry an owner and a recommended change, in the same way a technical finding does.

What is never reported

Who clicked, who called back, who held the door, or any captured credential. The only figures are aggregates by population and pretext, and the debrief your staff hear is built from the same numbers.