Pretexting

A pretext has three engineered components: an identity (auditor, new colleague, supplier's support engineer, police officer), a scenario that explains why the request is being made now, and supporting detail that makes both credible - internal jargon, correct names from the org chart, ticket or case numbers, an invoice reference, a spoofed caller ID or a plausible email thread. The detail comes from reconnaissance: company websites, LinkedIn, job adverts that reveal internal systems, public registers such as the Danish CVR, earlier data leaks and, often, a first low-stakes call whose only purpose is to harvest vocabulary for the second. Chaining small, individually harmless disclosures into one high-value request is the signature technique.

The legal history explains the term's era. The US Gramm-Leach-Bliley Act of 1999 (section 521, 15 U.S.C. § 6821) prohibited obtaining customer information from financial institutions under false pretences. In 2006 it emerged that investigators hired by Hewlett-Packard's board to trace a press leak had impersonated directors and journalists to obtain their phone records; the scandal led directly to the Telephone Records and Privacy Protection Act of 2006. In current threat reporting the Verizon DBIR uses pretexting as a VERIS social-engineering action, and most incidents it records under that label are business email compromise.

Pretexting differs from spear phishing in its unit of attack. Spear phishing is typically a single crafted message with a payload or link; pretexting is an interactive role that adapts to the victim's questions and can run across calls, mails and even physical visits. It also often has no technical payload at all: the output is information or an action performed by the victim, such as a password reset, an MFA device re-registration, a payroll change or a disclosed customer list. Help desks are the classic target because their job is to be helpful to people who have lost access.

Controls are therefore procedural. Identity verification must use something the pretexter cannot research or control: a call-back to the number in the directory or HR system, manager approval through a separate channel, or verification in person or via a strong digital identity. Help-desk scripts should forbid bypassing verification under time pressure or authority claims. Disclosure rules should classify information so that staff know what may be shared with an unverified caller. Where personal data is handed to a pretexter, it is an unauthorised disclosure and thus a personal data breach under GDPR Art. 4(12), with the notification duties of Art. 33.