Social engineering scope, consent and staff welfare

What should be out of scope from the start?

Anything whose effect on the individual outlasts the test. Pretexts touching employment security, pay, health, immigration status or family safety belong in that category, as do threats of any kind, impersonation of regulators or law enforcement, and pretexts that would require a member of staff to breach a professional duty. Also out: personal devices and personal accounts, home addresses, and family members, none of which your organisation can consent on behalf of.

Two more exclusions are practical rather than ethical. Do not test named individuals who have raised a concern or are subject to an ongoing process, because the exercise will be read as retaliation. And exclude anyone whose momentary distraction has physical consequences, which in some organisations means clinical staff, drivers and control room operators during operating hours.

One exclusion gets forgotten: the pretext that works by making someone break a rule they are right to follow. Asking a member of staff to bypass a payment control or hand over a credential tests whether they will comply under pressure, and if they do, the finding is about the control rather than the person. Design pretexts that test a process, and most of the welfare question resolves itself.

Write the exclusions into the rules of engagement as a list rather than a principle. A principle gets interpreted by whoever is writing the pretext at eleven at night; a list does not.

Who consents, and to what?

The organisation consents, and the individuals deliberately do not know, which is the design and also the source of every difficulty. The employer authorises testing of its own processes and its own staff acting in their working capacity. It cannot authorise testing of anyone's private life, and its ability to authorise covert observation of employees at all varies by jurisdiction.

That variation matters more than teams expect. In parts of Europe, employee monitoring engages data protection obligations and may require prior consultation with a works council or employee representative body before it begins, and doing it afterwards does not cure the problem. Elsewhere the position is looser. The narrow questions to put to counsel and to human resources are: may we test staff covertly, must anyone be informed or consulted first, what personal data may the testers process, and how long may it be kept.

Decide who inside the organisation knows. Human resources and the head of the affected function usually need to be told even when the wider team is not, because they will field the first complaint and can stop a genuine welfare problem escalating. Adding them to the small group of insiders costs a little secrecy and buys a great deal of institutional cover.

One practical rule reduces most of the risk: results are reported in aggregate and no individual is named. Put that in writing before the engagement, tell staff afterwards that it was the rule, and refuse requests to identify who clicked. An organisation that names people once will not get a genuine report of the next real phishing email.

Which techniques carry which risks?

The techniques differ enormously in what they teach and what they cost in trust. The last column is the control that makes each one defensible, and a technique without its control should not run.

How do you protect staff during and after?

Decide the aftercare before the first email goes out. Report in aggregate, brief the affected teams once the engagement ends, and lead the briefing with the pretext itself so people understand it was designed to work. The message that matters is that anyone who reported it did the right thing and anyone who did not was not the point of the exercise.

Never allow results to feed a disciplinary process, and say so publicly. The moment clicking becomes a performance matter, reporting stops, because reporting is an admission. Organisations with high reporting rates have almost always made reporting consequence-free and easy, and they have usually thanked people by name for reports that turned out to be tests.

Measure the right thing while you are at it. The proportion of people who clicked is the number everyone reports and the least useful one available, because it moves with the quality of the pretext. Reporting rate, time to first report, and whether that report reached someone who acted on it describe a capability you can improve, and they are the numbers a genuine phishing email will test next week.

Have a named person, ideally outside the security team, who staff can complain to about the exercise. Complaints are useful data: they identify pretexts that crossed a line you had not thought to exclude, and they arrive early enough to change the next engagement. Also brief the service desk manager and reception supervisor before physical or telephone testing, so the individual on the receiving end has support in the room.

What does a service desk test reveal that phishing does not?

Whether your account recovery process can be talked through by a stranger, which is the path an intruder is most likely to use and the one least likely to have been tested. Phishing tests the population. A pretext call tests one procedure, performed by a small team under time pressure, and the failure mode is procedural rather than human: the verification steps are ambiguous, or they can be satisfied with information available on a company website and a professional network profile.

The valuable variant targets credential and multi-factor resets. Ask the tester to attempt a factor reset for an account they do not control, using publicly available details plus a plausible urgency, and record exactly which verification step stopped them or failed to. Repeat it for a privileged account, because the procedure is often the same one and it should not be.

The fix is usually structural and cheap. Verification that requires something the caller cannot research, a second channel confirmation to a known device, mandatory manager approval for privileged resets, and a rule that urgency never removes a step. Test it again a month after changing it, because reset procedures drift back towards whatever is fastest for the customer on the phone.

What has to be written down before you start?

Six things, and they belong in the rules of engagement rather than the proposal. The list of excluded pretexts. The list of excluded individuals and roles, with the reason. That reporting is aggregate and individuals will not be named. Who may be impersonated, including whether internal executives and named suppliers are permitted. Whether calls or physical entry may be recorded, which is jurisdictional and sometimes requires notice to the other party. And the retention and deletion schedule for anything collected, including credentials captured on a phishing page.

Synthetic voice and video deserve an explicit clause because the capability is now cheap and the question will come up. If you decide to include it, restrict it to a specific process rather than a specific person, tell the recipient afterwards in person rather than in a report, and consider whether a tabletop exercise on payment authorisation would answer the same question without the distress. In most cases it will.

Finally, agree what happens if someone does something genuinely wrong during the exercise, for example moving money or handing over a customer database. That is an incident, not a finding, and the plan for it needs to exist in advance rather than being improvised while a member of staff is upset and a supplier is waiting for instructions.