For an authorized social-engineering test, which pretext is acceptable?

Social engineering is powerful precisely because it manipulates people, which is why it demands the tightest ethical guardrails of any pentest discipline. A signed engagement authorizes a test — it does not authorize cruelty.

Why a plausible, agreed, non-harmful pretext is correct

The right pretext is realistic enough to measure the human attack surface but harmless to the person: a generic IT password reset, a routine vendor follow-up, a benign delivery notification — and, crucially, one that is pre-agreed in the rules of engagement. Keeping pretexts within documented bounds means the client consents to the methods, targets aren't traumatized, and you stay on the right side of the law. The aim is to learn how the organization responds, not to break individual employees.

Why the other options are wrong

• Impersonating a named employee's sick child. This weaponizes a real person's family and exploits a genuine emotional pressure point. It causes real distress and damages trust in the security team long after the test ends.
• Threatening the target with being fired. Coercion isn't social engineering — it's intimidation. It harms the employee, isn't representative of typical attacker leverage you'd want to measure ethically, and can create HR and legal liability.
• Pretending to be law enforcement. Impersonating police or government officials is a serious offense in many jurisdictions and is generally not something a client can lawfully authorize. It also induces fear that crosses the ethical line.

What an interviewer is probing

They want to see that you understand consent and harm minimization apply to the humans in scope, not just systems. A strong candidate proposes effective pretexts while naming the bright lines — no authorities, no threats, no exploiting medical or family emergencies — and insists those limits live in the rules of engagement.