Pretexting

Pretexting uses a believable story, role, or situation to make a social engineering request appear legitimate. The pretext supplies the interaction’s context: who the requester claims to be, why contact is occurring, and why the requested action appears reasonable.

Effective pretexts often resemble ordinary business activity. Familiar names, internal terminology, project references, or process knowledge can make the interaction consistent with the target’s expectations before identity or authority has been independently established.

Social expectations may strengthen the effect. Helpfulness, deference to authority, urgency, or concern about obstructing legitimate work can reduce scrutiny and make an exception feel proportionate to the situation.

How it appears

Pretexting can be adapted to different roles, processes, organisations, and communication channels. The surface story may change from an account issue to a supplier follow-up or access request, while the underlying structure remains similar.

A pretext usually establishes a claimed identity and a reason for the interaction before moving to the action sought. The developed versions add contextual detail and a ready explanation for why an expected process cannot be followed this time, such as a portal outage that makes the normal channel unavailable. The exception is framed as a practical accommodation rather than a departure from control.

Indicators

Pretexting often contains inconsistencies between the claimed identity, the story, and the process the request would normally follow. The pretext may remain plausible even where those details do not align.

Indicator	What to look for
Story inconsistency	The explanation changes when questioned, contains unnecessary complexity, or conflicts with known circumstances.
Role and knowledge mismatch	The requester lacks information expected for the claimed role or asks for details that should already be available to that role.
Unverified identity or authority	Identity, role, contact details, authority, or reason for contact cannot be confirmed independently.
Exception dependence	The request relies on a workaround, one-off exception, unavailable system, or claimed approval outside the normal process.
Verification resistance	Independent confirmation is discouraged or redirected to contact details, links, forms, or instructions supplied by the requester.
Channel mismatch	Contact arrives through a personal account, unexpected call, social media message, or unapproved platform without a clear operational reason.
Isolation from normal functions	Managers, service records, security, finance, procurement, or another expected function are deliberately kept outside the interaction.
Missing expected record	The request has no corresponding ticket, approval, booking, transaction, or system record where one would normally exist.