Key takeaways
- A social engineering test is a professional engagement with authorisation, research-based pretexts and per-finding evidence. It is not a phishing simulation platform that counts clicks.
- The authorisation letter, signed before any test activity begins, is what separates a legal engagement from trespass and fraud.
- Proposals must be compared on equivalent scope. An email-only quote is not comparable to a multi-channel one.
- The report must map each successful attempt to the access it would have granted, not just report a click rate.
- A retest of the scenarios that succeeded is the step that confirms whether the remediation actually worked.
A simulation tool and a professional test are not the same thing
Automated phishing simulation platforms send templated lures to a staff list and count who clicked. They score awareness over time, which is useful for training programmes, but they do not tell you whether a determined attacker, given a well-researched pretext and several channels, could reach the people or systems that matter. That question requires a social engineering engagement run by testers who operate under a formal rules of engagement document.
The distinction shapes what you put to procurement. A simulation platform is software-as-a-service with a subscription fee. A professional test is a scoped engagement with a defined population, a written authorisation letter, and pretexts built against real public information about your organisation. NIST SP 800-115 classifies social engineering as an active test category precisely because passive measurement cannot determine whether a specific population is exploitable by a skilled attacker.
The clearest sign that a proposal is selling a simulation rather than a test is the absence of a rules of engagement document. If a vendor cannot tell you what the testers are authorised to do, who must be notified if an employee reports the attempt, and what happens if a physical access attempt triggers a real incident, you are not looking at a professional engagement.
What to settle before you contact a provider
Three things need an internal decision before you issue a brief. First, which populations are in scope: all staff, specific departments, executives or third-party contractors who have access to your systems. A test that covers everyone at the same depth is harder to act on than one targeting a specific high-value group. Second, which channels you want tested: email, voice calls, physical access attempts or a combination. Third, who inside your organisation must know the test is running. The tester needs at least one named contact who can call off a physical attempt if it escalates unexpectedly.
The authorisation letter is the document that makes the test legal. It names the testing firm, the authorised testers, the scope, the permitted channels, the start and end dates, and the point of contact with authority to abort. Without it, a physical attempt to enter your premises is trespass and a call impersonating your IT desk is a criminal matter under UAE law. If the vendor has not asked for one, or does not know what it must contain, that is a disqualifying gap. The article on scoping a social engineering test covers what a rules of engagement document needs to address in detail.
Before you sign
Define requirements
Populations, channels, authorisation contact
Evaluate proposals
Methodology, scope, pretext depth, reporting standard
Agree rules of engagement
Signed letter naming testers, channels and abort conditions
After you sign
Test execution
Pretexts run across agreed channels and targets
Report and evidence
Per-attempt log, access impact, technique mapping
Remediation and retest
Specific controls changed, succeeded scenarios retested
How to read a social engineering testing proposal
A professional proposal names the methodology for each channel included in the quoted price and describes the pretext development process. Pretext research is the time the tester spends mapping your organisation before the first lure is sent: public staff directories, job advertisements that reveal your technology stack, LinkedIn profiles showing team structures and role names. That time should be separately costed or explicitly included, because it is the difference between a credible, targeted attempt and a generic template.
Compare proposals on equivalent scope. A quote covering email phishing only is not comparable to one that includes voice calls and a physical access attempt. Ask each vendor to break out which channels are in the base price and which are additional. A lower total for a narrower scope is not a saving; it is a different engagement. MITRE ATT&CK maps phishing under Initial Access and voice-based pretexts under Spearphishing Voice, so the technique names a vendor uses should correspond to a real, documented method. The earlier article on OAuth device code phishing shows one example of how a modern phishing technique operates below the level most simulation platforms model.
Deliverable quality is difficult to judge from a description in a proposal. Ask the vendor to show you a redacted sample report from a comparable engagement. A vendor who declines, or who can show only a summary slide deck, is signalling the depth you will receive. The table below maps what a strong proposal includes against what to watch for.
| Proposal element | Strong proposal | Red flag |
|---|---|---|
| Methodology | Named technique per channel, pretext research costed or explicitly included | Industry-standard phishing simulation with no named technique or research process |
| Authorisation document | Rules of engagement template provided before work begins, signed letter required | Email approval or verbal confirmation treated as sufficient |
| Deliverables | Per-attempt evidence with access impact mapped, technique references included | Click rate summary with generic awareness training recommendations |
| Rules of engagement | Escalation path named, abort condition defined, point of contact with authority to stop named | No mention of what happens if a scenario triggers a real incident |
| Retest | Retesting of successful scenarios after remediation included or clearly priced | Not offered, or available at an additional unspecified cost only |
What the report has to contain
A social engineering report is evidence, not a score. For each successful attempt it should give you the pretext used, the channel, the target's role, what action the target took, and what access that action would have granted in a real incident. That last item is the one most reports omit: a credential collected from a finance system administrator is a different finding from the same credential collected from a visitor with no network access. The detection signals that confirm whether each attempt was flagged should also appear in the report, because a successful attempt that passed undetected is a combined failure of human and technical controls.
Remediation recommendations need to address the specific finding. If a physical access attempt succeeded because reception admitted someone presenting a fabricated visitor badge, the recommendation is a specific change to the visitor verification procedure. If a voice call succeeded because an employee read a one-time code to a caller claiming to be IT support, the fix is a verification protocol for that call type. Generic recommendations applied to a precise finding tell you the vendor has not thought carefully about what the result means for your environment.
The format matters as well. A report that maps each finding to a MITRE technique reference and includes reproducible steps for each scenario is far easier to take to an audit committee than a spreadsheet of percentages. Check whether the format meets what your governance or compliance function will accept before you sign. For a benchmark, see what a penetration test report must contain, which covers the evidence and finding structure a professional report requires.
Executive summary
Scope, channels, population count and overall risk finding
Per-attempt log
Pretext, channel, target role and action taken
Access impact analysis
What each success would have granted in a real incident
Technique mapping
MITRE ATT&CK reference per finding
Remediation by finding
Specific control change required, not awareness training
Comparing providers and making the final decision
Once proposals cover the same scope, the comparison points are pretext depth, channel coverage, reporting quality and post-engagement support. Pretext depth is the hardest to assess from a document alone: ask each vendor to describe, at a high level, how they would research your organisation before the first lure is sent. A vendor who describes a process that produces a generic lure is not delivering the same thing as one who builds a pretext from your actual public footprint: job adverts, staff directories, recent press releases, third-party supplier relationships. For a framework that applies to any professional security engagement, how to compare penetration testing proposals covers the evaluation method in more detail.
Post-engagement support covers whether the vendor will brief your security team on the findings, confirm that recommended controls have been put in place, and provide a retest on the scenarios that succeeded. A retest is not always included in the base price; confirm whether it is before you agree the contract. Some organisations also ask whether the findings can feed detection content development, connecting the social engineering result to a lasting improvement in monitoring capability. For organisations running a broader adversarial programme, a red team engagement often uses social engineering as an initial access path, and a vendor who has run a social engineering test against your organisation can use that knowledge directly in the red team's approach.
Pretext depth
Targeted depth test
Useful for a specific population, does not test cross-channel resilience
Full professional test
Research-based pretexts across email, voice and physical show true exploitability
Phishing simulation
Measures awareness, not exploitability. A click rate is not a finding.
Volume without depth
Multi-channel coverage built on generic lures produces noise, not intelligence.
Channel coverage
Buying a social engineering test in the UAE: regulatory context and procurement differences
Social engineering testing sits in a specific regulatory position in the UAE. The Central Bank of the UAE expects banks and financial institutions to test their human and process controls alongside their technical ones, and a social engineering engagement covering voice, physical access and email produces the kind of evidence a CBUAE examination will ask for. In Dubai, the Dubai Electronic Security Center governs government entities and their direct suppliers; its resilience requirements extend to the human attack surface. In Abu Dhabi, the ADHICS framework for healthcare organisations and the NESA-published UAE Information Assurance Standard place equivalent obligations on regulated entities. The article on UAE regulations that apply to social engineering testing maps these frameworks in detail.
From a procurement perspective, organisations buying in Abu Dhabi and in Dubai face a practical difference in vendor availability and legal chain. A vendor licensed and physically present in the UAE provides a cleaner authorisation path: the letter names a UAE-registered entity, the testers can present UAE-issued identification for physical access scenarios, and any incident arising during the test falls under UAE jurisdiction with a clear path to resolution. Ask any prospective vendor where their testers are based, whether the engagement letter will name a UAE-licensed company, and how they would handle an escalation under UAE law. These are not hypothetical questions; they are the ones your general counsel will ask before approving the authorisation letter.
Frequently asked questions
What is a social engineering test?
A social engineering test is a professional security engagement in which authorised testers attempt to gain access to people, information or physical premises by exploiting human behaviour rather than technical vulnerabilities. It covers channels including email, voice calls and physical access attempts, all conducted under a signed authorisation document. The objective is to identify which populations and processes are exploitable, not to measure how many people click a training exercise.
How does a social engineering test differ from a phishing simulation platform?
A phishing simulation platform sends templated lures to a staff list and measures who clicks, serving as a training measurement tool. A professional social engineering test uses research-based pretexts specific to your organisation, covers multiple channels, and produces per-finding evidence of what access each success would have granted. The two products serve different purposes and are not substitutes for each other.
What should a social engineering testing proposal include?
A strong proposal names the methodology for each channel in the price, describes the pretext research process, provides a rules of engagement template and specifies the report format with a sample. It should state the escalation and abort procedure, name a point of contact with authority to stop the test, and confirm whether retesting of successful scenarios is included or separately priced.
What does a social engineering test report need to contain?
The report should document each scenario attempted, including the pretext and channel, the target's role, the action taken and what access that action would have granted. Remediation recommendations should address the specific finding rather than defaulting to generic awareness training. The report should also note whether each successful attempt was flagged by security monitoring or passed undetected.
How long does a social engineering test take to run?
Duration depends on the number of channels, the size of the target population and the depth of pretext research needed. An email-only test targeting one department may run in a week. A multi-channel test covering email, voice and physical access across a larger group typically runs over two to three weeks, with pretext development preceding the active test period.
Who needs to authorise a social engineering test?
The authorisation letter should be signed by an officer of your organisation with authority over the assets and personnel in scope, typically a senior executive or company secretary. The letter must name the testing firm, the authorised testers, the permitted channels, the date range and the point of contact with authority to abort. No other form of agreement is sufficient to make the engagement legal.
How does the cost of a social engineering test vary?
Price varies with the number of channels, the size of the target population, the depth of pretext research required and whether physical access attempts are included. A clearly scoped brief that specifies which channels are needed makes quotes easier to compare. An engagement that includes physical access will cost more than an email-only test, and a test targeting a defined group will cost less than an all-staff exercise.
What is the difference between a social engineering test and a red team engagement?
A social engineering test focuses on the human and physical attack surface and tells you who can be manipulated and by which channel. A red team engagement uses social engineering as one of several possible initial access paths, then continues from that foothold toward a defined objective inside the environment. A social engineering test answers the human vulnerability question; a red team engagement answers whether the full chain from initial access to objective succeeds.
What happens after a social engineering test is completed?
The tester delivers a report documenting each attempt and its outcome. Your team then implements the specific remediation steps: procedure changes, verification protocols, access control updates. A retest on the scenarios that succeeded confirms whether the fixes hold under the same conditions. For findings that reveal systematic detection gaps, a follow-on purple team session can build the monitoring rules that would have caught the attempts.
How do I assess whether a social engineering vendor is qualified?
Ask for a redacted sample report from a comparable engagement, a description of their pretext research process and a reference to their stated methodology. Confirm that they can provide a formal authorisation document template, that their testers carry professional indemnity coverage for social engineering activities, and that their experience covers the specific channels in your scope. A vendor who cannot answer those questions clearly is not ready to run a professional engagement.
