How a social engineering test is scoped: pretext, channels and rules of engagement

Why social engineering scope is not like network scope

A network penetration test has a clear perimeter: an IP range, a list of hostnames, a set of services. Social engineering testing has a behavioral perimeter, and it is harder to draw. The asset being tested is human behavior under a constructed scenario. The scope document has to answer questions that never arise in infrastructure work: who can be contacted, by which channel, posing as whom, and asking for what.

Getting the scope wrong produces one of two failure modes. A test that is too narrow proves only that a small population can be phished, not that the organization has a detection or training problem. A test that runs wider than the organization was prepared for generates complaints, HR involvement, or legal questions about impersonation and data handling. Neither result serves the purpose of a social engineering engagement. Treat scoping as the most important phase of the work, not a formality to clear before the active test begins.

Objectives, authorization tier, channel mix and rules of engagement are agreed and signed before any pretext runs. NIST SP 800-115 treats social engineering testing as a distinct technical category within a broader security assessment, with its own documentation and authorization requirements. The engagement lifecycle below shows what happens before, during and after the active test.

Target population and authorization tier

The first question is who can be targeted. It is almost never everyone. Most organizations have staff in roles where a surprise scenario would be inappropriate during a test period, staff who are already aware of the exercise and should be excluded from the live population, and staff who are contractors, secondees or agency workers whose testing requires separate authorization from their employing entity.

Authorization follows the population. The executive sponsor must sit at or above the level of the people being tested. A CISO can authorize testing of operational staff. Testing the leadership team requires sign-off from a tier above, typically a board audit or risk committee. A successful test against a senior account can capture a credential with broad organizational access. Testing staff at a third-party supplier requires that supplier's own authorization, signed by someone with authority over their workforce.

A red team engagement and a social engineering test share this authorization logic. A red team handles a broad authorization tier more comfortably because it targets systems rather than named individuals. When testing targets people directly, the population list and the authorization chain must be explicit in the scope document, not implied by a general full-scope clause.

Channel selection and what each requires in the authorization

The channel determines the authorization, the rules of engagement and the detection surface. Email phishing is the most common and the most straightforward to authorize. The scope document names the sending domain or pattern, the payload type (a link to a clone page, a macro document, or a credential harvest form) and the campaign window. It must also state what happens to any credential captured. A credential taken against a live authentication system is a live credential, even during a test.

Voice pretexting has different requirements. Caller ID spoofing to impersonate an internal helpdesk or an external supplier is technically straightforward but legally more complex in many jurisdictions. The scope document must address whether calls are recorded, whether single-party consent applies, and which roles can be impersonated by name. An operator posing as a generic IT helpdesk is not the same as one claiming to be the named CFO. The second requires explicit authorization for that specific impersonation.

Physical pretexting brings the facilities and security leadership into the authorization chain. A test of tailgating controls or pretext entry requires part of the physical security team to be either informed (when testing staff behavior at entry points) or kept uninformed under a higher authorization tier (when also testing whether the security team detects the intrusion). These are different tests and need different authorization documents, because what the operator can do differs in each case.

Building the pretext: scenario, lure and requested action

A pretext has three parts: the scenario (the role the operator plays and the context that makes it plausible), the lure (the reason the target acts) and the requested action (the specific thing that marks a successful test response, whether a click, a credential disclosure, a door swipe or a document handover). All three are documented in the scope before the test runs, because they determine what the test can and cannot measure. MITRE ATT&CK classifies phishing as technique T1566, with sub-techniques covering attachment, link and service-based delivery, each mapping to a distinct pretext type.

A scenario built from a real supplier relationship or public organizational data is more effective than a generic IT-reset email, but also harder to authorize. Using a real brand name in test materials requires explicit authorization for that brand to appear. Impersonating a real executive by name requires their individual consent unless the authorization tier explicitly includes them within scope. The scope document names which brands and which roles can appear in pretexts, and the operator works within that list.

Pretext sophistication affects what the test measures and how the findings read. A tailored spear phishing campaign will produce a higher response rate than a generic credential-reset message. Both are valid tests of different things. The scope document records the authorized level of sophistication so findings can be read against the right baseline. The technique described in Phishing without a fake login page: OAuth device code abuse sits at the sophisticated end: it asks the target only to enter a code, which makes the lure harder to recognize as a phishing attempt and tests a different detection control than a clone page does.

Rules of engagement: what the document must contain

The rules of engagement document is the legal and operational boundary of the test. It is a signed agreement between the operator and the client that defines what is authorized and where that authorization ends. A penetration test carries an RoE too, but a social engineering RoE has elements a network assessment does not need, because the subjects of the test are people rather than systems.

The RoE must name the safe word: the signal from any tested staff member or from the client that pauses the test immediately. It must define what the operator does if a target escalates to law enforcement or HR. The test stops, the operator identifies themselves using the authorization letter they carry, and the client is notified. Any credential captured during the test is recorded in the evidence log and reported to the client within a defined period for invalidation. Retaining a credential beyond that period is not covered by the authorization.

The debrief terms belong in the RoE too: who is informed of the results, when, and what is disclosed to staff who were tested. A purple teaming exercise or an assumed breach engagement is disclosed fully to the defending team as part of the design. A social engineering test is often run without advance disclosure to the tested population. That means the debrief is the moment those staff first learn they were tested, and the findings report has to serve both the security function and the people managers who will deliver the feedback.

Social engineering testing in the UAE: Abu Dhabi, Dubai and the authorization chain

Organizations in the UAE operate under several regulatory frameworks that address social engineering as part of a broader requirement for security testing. The CBUAE requires banks and financial institutions to test the human layer of their controls as part of cyber resilience programmes. This aligns with the regulatory picture described in UAE rules that apply to social engineering testing, the first article in this cluster.

Dubai government entities and their direct suppliers work within DESC cybersecurity standards that include requirements for staff security awareness testing. For organizations in Abu Dhabi's healthcare sector, ADHICS names human-factor controls as part of a layered security posture. Federal entities and organizations within TDRA's mandate are subject to the UAE Information Assurance Regulation, which sets security testing requirements at a federal level across both emirates.

The free zone structure raises a scoping issue that applies throughout Dubai and Abu Dhabi. A parent entity in a mainland jurisdiction and a subsidiary in DIFC, ADGM or Dubai Silicon Oasis may sit under different regulatory frameworks, both of which name testing. An engagement that tests staff across the group needs authorization documents that address both populations separately. Authorization from the mainland entity does not automatically cover staff employed by and governed through the free zone subsidiary.

Authorization letters carry particular weight in the UAE context because the scenarios in a social engineering test can intersect with provisions of the UAE Cybercrime Law. The letter should name the issuing entity, the engagement scope and the authorization holder, and the operator should carry it during any physical pretexting scenario. Every UAE social engineering scope document should include a properly formed authorization letter as a stated deliverable, not something to be drafted on the day the test begins.

Frequently asked questions