Scenario-Based People–Process–Technology Mapping for Social Engineering Awareness ^†

Abstract

Multi-channel social engineering attacks exploit individual decision-making while unfolding through organizational procedures and system interfaces. Prior work has examined user susceptibility, training, attack-channel evolution, and detection, but these strands are often weakly connected when interventions are designed or assessed. This paper presents a scenario-based People–Process–Technology (PPT) mapping model for multi-channel social engineering awareness. It uses a scenario as the starting point and links attack characteristics to weaknesses, intervention actions, and measurable criteria through an Identify–Model–Intervene–Evaluate–Adapt (IMIEA) cycle. A worked credential-harvesting use case illustrates the full cycle using one notional participant response, showing how an apparent internal IT password-reset message is mapped to PPT weaknesses, converted into expected secure actions, assessed through response measures, and used to derive adaptation actions. As a design artifact, the paper specifies mapping rules, secure-response measures, and evaluation logic for scenario-based assessment. The result is a structured basis for evaluating awareness as secure response quality across human-centered, organizational, and technology-supported dimensions.

1. Introduction

Social engineering remains a persistent cybersecurity challenge because attackers exploit the conditions under which people make security decisions. Phishing emails, SMS-based smishing, voice-based vishing, QR-code redirection, and AI-generated deception rely on more than delivery mechanisms; they use urgency, authority, familiarity, uncertainty, and contextual pressure to influence judgment [1,2,3,4]. Filtering, domain analysis, authentication controls, and machine-learning detection can reduce exposure, but they do not remove the need for users and organizations to interpret warnings, verify requests, and report suspicious activity [5,6]. Conversely, awareness training is limited when it is detached from organizational procedures and from the interfaces through which users encounter suspicious requests [7,8,9].

The scope of the paper is multi-channel social engineering, especially cases in which users receive deceptive requests through email, SMS, QR-code redirection, voice prompts, or similar digital interactions. It does not attempt to cover every form of social engineering, such as long-term impersonation, physical intrusion, or insider manipulation. This boundary allows the analysis to focus on situations where user interpretation, organizational response, and interface cues can be jointly represented and assessed.

The problem is sociotechnical rather than purely human or purely system-based. User susceptibility is shaped by cognitive and emotional factors, including self-efficacy, perceived severity, emotional manipulation, and message interpretation [10,11,12]. Yet these factors operate within organizational routines and interface contexts. A user may notice a suspicious cue but lack a clear reporting path; a warning may be accurate but difficult to interpret; or training advice may be remembered in abstract terms but fail to support action under pressure. The PPT perspective is useful because it connects these human, organizational, and technology-supported elements within one analytical structure [13].

The problem addressed in this paper is not simply that users fail to recognize deceptive messages. Multi-channel social engineering succeeds when manipulative cues, unclear response procedures, and ambiguous system signals converge in the same decision situation. Existing countermeasures often address these elements separately: training emphasizes recognition, procedures define reporting expectations, and detection tools generate warnings or alerts. What is missing is a structured method for translating scenario features into connected awareness content, organizational response actions, cue guidance, and measurable criteria.

This paper develops a scenario-based mapping approach for adaptive mitigation. Its design objectives are to connect human, organizational, and system-facing factors within one decision situation, translate threat patterns into intervention content, and make assessment observable through response measures. Secure response quality refers to more than correct message classification; it denotes whether a user detects a suspicious situation, verifies the request, reports or escalates where appropriate, avoids unsafe action, and calibrates confidence. The model uses an IMIEA cycle as an implementation structure, not as a new general theory of security behavior.

The contribution of this work is not the underlying PPT lens, originally introduced by Leavitt [13], but its scenario-based operationalization through the proposed PPT–IMIEA mapping model for multi-channel social engineering awareness. The paper makes three contributions. First, it defines a mapping model that connects attack features to People, Process, and Technology weaknesses. Second, it links this mapping to the IMIEA cycle so that each stage produces a concrete artifact, such as a threat-pattern inventory, weakness map, intervention package, assessment criteria, or adaptation action. Third, it specifies coding rules for evaluating secure response quality, including detection, reporting, verification, unsafe-action avoidance, and confidence calibration. The paper focuses on framework design and evaluation operationalization, providing the basis for subsequent empirical deployment.

The following sections develop this argument in three steps. First, the paper reviews prior work on human factors, emerging threats, and detection and assessment approaches. Second, it presents the PPT-based mapping model and uses a worked credential-harvesting case to show how scenario features become weaknesses, interventions, and measurable criteria. Third, it explains how these criteria support assessment and discusses the shift from message recognition toward secure response quality.

2. Related Work

Research on social engineering spans human susceptibility, training design, attack-channel evolution, automated detection, and scenario-based assessment. These areas offer important but often separate explanations of why attacks succeed and how they may be mitigated. Recent human-centric cybersecurity work also uses People–Process–Technology as a broad lens for integrating human, procedural, and system-level factors in security design [14]. This section organizes the literature into three strands that motivate the proposed model: human factors and behavioral interventions, emerging threats, and detection and assessment approaches.

2.1. Human Factors and Behavioral Interventions

Human-centered research shows that susceptibility to social engineering is not reducible to lack of knowledge. A systematic review of empirical studies highlights that many experiments only partially reproduce real attack conditions and that target context, cognitive processes, pretexts, and personalization are often insufficiently represented [10]. Emotional manipulation is also important because phishing messages use fear, urgency, empathy, or authority to trigger rapid responses, and affective cues can be associated with classification errors in simulated email environments [11]. Related work on self-efficacy, perceived severity, perceived susceptibility, and message appraisal further supports treating response behavior as context-sensitive rather than fixed [12].

Training research points toward adaptive and user-centered interventions. Phishing education can help users recognize suspicious messages, but its effectiveness depends on design, personalization, explanation, timing, and integration with organizational practice [7,8]. Security learning guidance likewise emphasizes planning, assessment, and improvement rather than one-off information delivery [9]. These studies explain why interventions must address decision conditions, not only knowledge deficits. However, they do not by themselves specify how user factors should be connected to reporting procedures and interface cues.

2.2. Emerging Social Engineering Threats

The threat landscape has expanded beyond conventional email phishing. SMS-based smishing creates specific user challenges because mobile messages are short, often lack rich contextual cues, and are processed quickly on personal devices; recent user-centered research shows that users may overestimate their reliance on sender information and that traditional phishing-susceptibility factors do not always predict secure behavior in SMS contexts [1]. Voice phishing uses conversational pressure and perceived legitimacy to influence users through voice communication [2], while QR-code phishing can hide the destination of a malicious link behind a visual code and shift interpretation to the scanning environment [3].

Generative AI further changes the scale and realism of deception by supporting realistic content creation, advanced targeting, personalization, and automated attack infrastructure [4]. These threats show that interventions cannot be designed around email-only cues. They also show the need to connect multi-channel attack characteristics to training, organizational response, and cue interpretation.

2.3. Detection Technologies and Assessment Approaches

Detection technologies remain essential in this defense context. Machine learning, deep learning, graph-based methods, and ensemble techniques are widely studied for phishing detection [5]. Explainable AI research also emphasizes that security tools should support human interpretation and trust calibration rather than operate as opaque automated systems [6]. These perspectives matter because warnings and alerts become part of the user’s decision environment. Automated detection cannot address all deceptive requests by itself. Some attacks succeed because they exploit organizational ambiguity, weak reporting habits, or uncertainty about how a request should be verified. Scenario-based phishing research has similarly shown that detecting a suspicious message and deciding what to do with it are distinct tasks [15]. Detection systems can reduce exposure, but their outputs still enter human and organizational decision contexts; they should therefore be treated as part of the decision environment rather than as a separate defense layer.

Taken together, existing work has strong accounts of user susceptibility, attack-channel evolution, detection methods, and scenario-based phishing behavior, but fewer models explain how these elements can be jointly translated into interventions and measurable response criteria. Large social-engineering assessment initiatives such as DOGANA have connected awareness, social-engineering vulnerability assessment, mitigation, and legal-compliance concerns at a program and tool-chain level [16]. Broader cybersecurity guidance and human-centric frameworks also support the integration of people, processes, and technologies in security practice [9,14]. The proposed model differs by beginning from scenario features and requiring each feature to be mapped to intervention content and response measures across People, Process, and Technology dimensions. The distinction is that PPT–IMIEA treats the scenario feature itself as the unit of analysis: each feature must be linked to a weakness, an intervention action, and an observable measure, rather than being treated only as training content, a detection target, or an evaluation stimulus.

3. Proposed PPT-Based Mapping Model

This section specifies the proposed mapping model and its IMIEA operational flow. The approach supports intervention design and assessment without isolating users, procedures, or tools. It asks how users interpret suspicious situations, how organizational procedures support or constrain action, and how systems present cues that can either assist or confuse decision-making. Figure 1 summarizes the flow.

Figure 1. PPT–IMIEA operational flow.

3.1. Framework Rationale

The proposed mapping method transforms multi-channel social engineering cases into interventions and assessment criteria. It addresses the gap between research strands that separately examine user susceptibility, organizational practices, and detection. Rather than treating these elements as independent components, the method uses a scenario as the starting point and links attack characteristics to PPT weaknesses, intervention actions, and observable measures.

The input is an example described by its channel, pretext, requested action, manipulation cues, and system cues. The output is a traceable map that identifies relevant People, Process, and Technology weaknesses, links them to intervention content, and defines assessment criteria. This structure addresses a limitation of isolated awareness approaches: training may focus on user knowledge, security systems on detection, and organizational procedures on compliance or reporting, while actual attacks unfold through the interaction of these elements.

The main advantages are traceability, integration, adaptability, and assessment alignment. Traceability links each measure back to a case feature and a mapped weakness. Integration means that training content, reporting and verification procedures, and cue interpretation are designed together rather than separately. Adaptability means that recurring weaknesses can be used to revise scenarios, training content, procedures, or guidance. Assessment alignment connects intervention design directly to observable measures instead of treating security learning as a general knowledge outcome.

An attack event can be understood as a sequence of sociotechnical interactions. An attacker selects a channel and pretext, the message reaches a user through an interface, the user interprets the request under cognitive and contextual pressure, and the organization may support, constrain, or fail to support verification, reporting, escalation, and recovery. Each stage contains People, Process, and Technology elements. For example, a phishing email may include an urgent tone that affects the People dimension, a request that bypasses normal approval procedures in the Process dimension, and a spoofed sender or misleading link in the Technology dimension.

3.2. Operational Mapping Procedure

The approach is applied through a structured procedure. First, an attack example is identified by channel, pretext, requested action, and delivery context. Second, its manipulation and system cues are extracted. Third, each cue is mapped to one or more People, Process, or Technology weaknesses, such as urgency pressure, unclear verification expectations, or ambiguous sender information. Fourth, the mapped weaknesses are translated into intervention content covering user interpretation, organizational action, and cue use. Fifth, response measures are assigned so that the same scenario can test whether the participant detects the threat, verifies the request, reports it, avoids unsafe action, and calibrates confidence.

The mapping follows three coding rules. A People code is assigned when a case feature targets perception, emotion, attention, confidence, self-efficacy, or decision pressure. A Process code is assigned when the feature requires reporting, verification, escalation, approval, policy interpretation, or use of an organizational routine. A Technology code is assigned when the feature depends on interface cues, sender or domain information, links, QR destinations, authentication prompts, caller information, warning messages, or security controls. A single feature may be mapped to multiple dimensions when it affects both interpretation and action; for example, an urgent credential request can create People-level pressure, Process-level verification bypass, and Technology-level sender or URL interpretation demands.

For empirical or expert application, each evaluation item should be documented using the same coding template: channel, pretext, requested action, manipulation cue, system cue, expected secure action, and mapped dimensions. Ambiguous mappings should be retained rather than forced into one category when the case feature affects more than one dimension. If the method is used in a study or expert review, independent coding and reconciliation can be used to assess whether the rules are applied consistently. The procedure is intended to produce traceable case-to-intervention and case-to-measure links, not only a descriptive taxonomy. The same logic can be applied across channels: QR-code cases emphasize hidden destination and mobile-browser cues, voice requests emphasize callback and escalation routines, and credential-reset emails combine urgency, process bypass, and sender or URL interpretation.

Adaptation is derived from patterns in the measures rather than from single errors. Persistent sender-domain errors would lead to revised cue examples, repeated failure to verify would lead to stronger process guidance, and overconfident incorrect classifications would lead to confidence-calibration content.

A complete implementation defines the number and expertise of coders, the case-generation procedure, the criteria used to determine expected secure actions, and the reconciliation method for disputed mappings. In empirical use, agreement between independent coders should be reported before the mapped items are used for assessment.

3.3. People, Process, and Technology Dimensions

The People dimension focuses on user awareness, self-efficacy, perceived susceptibility, perceived severity, emotional response, and confidence. Its goal is not to blame users, but to understand how decision-making is affected by manipulation, uncertainty, and context. Content in this dimension therefore includes not only examples of malicious messages, but also explanations of why particular tactics work and how users can slow down or verify requests under pressure. The Process dimension focuses on the organizational actions that make secure behavior possible. These include reporting channels, verification routines, escalation procedures, incident-response expectations, and the frequency and personalization of awareness interventions. A user who detects something suspicious still needs to know what to do next. The Process dimension connects awareness with organizational routines.

The Technology dimension focuses on the system cues and controls that shape user decisions. These include sender and domain indicators, URL previews, QR-code warnings, authentication prompts, filtering systems, and alert explanations. The framework treats these cues as part of the decision environment. Users are not expected to become analysts, but they need support in interpreting system signals and acting appropriately when uncertainty remains. The worked use case in Section 3.5 later shows how these dimensions apply to credential harvesting and how they translate into expected secure actions and observable measures.

3.4. The IMIEA Adaptive Cycle

The approach is structured through an Identify–Model–Intervene–Evaluate–Adapt cycle. IMIEA is used here as an artifact-producing implementation cycle rather than as a new theory or universal security lifecycle. It is appropriate in this context because attack patterns, user decision contexts, organizational procedures, and system cues change over time; a static awareness taxonomy cannot capture how assessment feedback should update future training and support.

Each stage produces a concrete artifact. Identify produces a threat-pattern inventory containing relevant channels, pretexts, requested actions, and manipulation cues. Model produces a weakness map that links each item to human susceptibility factors, process gaps, and cue-interpretation problems. Intervene produces an aligned package, such as manipulation-awareness content, reporting and verification guidance, and cue-interpretation examples. Evaluate produces measures, including detection, reporting, verification, unsafe-action avoidance, confidence calibration, and, where useful, an exploratory composite response measure. Adapt produces revisions to scenarios, training content, reporting procedures, and guidance. Because each stage has a named output, the same scenario can be traced from threat identification to intervention content, assessment criteria, and adaptation decisions.

3.5. Worked Credential-Harvesting Use Case

The following worked use case is an illustrative walkthrough using a hypothetical participant (P1) and is intended solely to demonstrate the operation of the proposed framework. It does not represent empirical data or validation. This worked use case illustrates the proposed structure from scenario identification to adaptation. In the Identify stage, the scenario is an email that appears to come from internal IT support and warns that the user’s account will expire within 30 min unless the password is reset through an embedded link. The pretext invokes authority through the IT identity, urgency through the short deadline, and fear through possible loss of access. The system cues include a suspicious sender domain, link text that appears to refer to an internal reset page, a destination URL that does not match the expected organizational domain, and an external login page that imitates the usual authentication interface.

In the Model stage, these elements are mapped to PPT weaknesses. The People dimension captures urgency, authority pressure, fear of account loss, and confidence under uncertainty. The Process dimension captures the attempt to bypass normal verification and reporting routes. The Technology dimension captures sender-domain inconsistency, URL mismatch, and the imitated login page. The Intervene stage then translates those weaknesses into content and procedures: users are taught to pause under pressure and question urgent credential requests; the organization defines how IT requests should be verified and reported; and cue guidance explains sender-domain checking, link inspection, and warning interpretation.

The expected secure action is not only to classify the email as suspicious. The participant is expected to avoid credential entry, verify the request through a trusted route, report or escalate the message where appropriate, interpret the sender and URL cues, and express confidence that matches the quality of the decision. To illustrate the Evaluate stage, the walkthrough uses a notional participant, P1, who classifies the email as suspicious and does not enter credentials, but also does not report the message or verify the request through the official IT channel. P1 notices that the sender domain looks unusual but does not identify the URL mismatch, and reports high confidence in the response. Figure 2 summarizes the resulting flow, with diagnostic interpretation included inside the Evaluate stage rather than represented as a separate IMIEA stage.

Figure 2. End-to-end credential-harvesting walkthrough. The diagnostic interpretation is performed within the Evaluate stage and does not represent an additional IMIEA stage.

Within the Evaluate stage, these responses produce the following diagnostic interpretation. Classification and unsafe-action avoidance are coded as present, while reporting and verification are coded as absent because the expected organizational actions were not performed. Cue interpretation is partial because the sender cue was noticed but the URL mismatch was missed. Confidence is not well calibrated because P1 reports high confidence despite an incomplete secure response. The resulting interpretation is therefore not a general awareness failure: it indicates adequate threat recognition, a Process weakness in reporting and verification, a Technology-related cue-interpretation gap, and a People-related confidence-calibration issue.

The Adapt stage uses this Evaluate-stage interpretation to revise the next intervention cycle. The Process component would strengthen reporting expectations and the official verification workflow for IT requests. The Technology component would add clearer URL and domain-inspection examples, especially for imitated login pages. The People component would add confidence-calibration content showing that correct classification alone is not sufficient when reporting, verification, or cue interpretation is incomplete.

4. Evaluation Operationalization

The worked case in Section 3.5 and the flow in Figure 2 show how a mapped scenario can be converted into intervention actions, coded responses, Evaluate-stage interpretation, and adaptation. Existing scenario-difficulty tools such as the NIST Phish Scale support phishing-awareness programs by rating phishing cues and user-context alignment; the proposed assessment is complementary because it focuses on secure-response quality after the scenario has been defined [17]. A future implementation can instantiate this logic through a background and perception questionnaire, followed by a scenario-based task containing legitimate and suspicious examples across email, SMS, QR-code redirection, and voice-related prompts. To support comparability, pre-test and post-test sets should be balanced by channel, pretext, requested action, manipulation cue, and system cue, rather than by reusing identical messages. After an integrated intervention, a post-test task can assess whether response quality changes across the same categories.

The evaluation uses dimension-aligned measures rather than a single aggregate score. People-related measures include recognition of manipulation cues, confidence, and calibration between confidence and correctness. Process-related measures include reporting, verification, and escalation choices. Technology-related measures include interpretation of sender, domain, URL, QR-code, warning, and authentication cues. In the illustrative P1 walkthrough, the positive classification and unsafe-action avoidance codes show threat recognition, while the zero reporting and verification codes identify a Process gap. The missed URL mismatch records a cue-interpretation gap, and high confidence despite incomplete action records a calibration problem.

The secure-response score is an exploratory composite built from four actions: correct classification, reporting, verification, and unsafe-action avoidance. For suspicious items, these actions can be coded as binary measures when they are expected by the item. For legitimate items, correct classification is coded separately, while unnecessary reporting, avoidance, or escalation can be treated as false-positive behavior depending on the item’s purpose. Response actions are item-specific rather than equally appropriate in every case. The exploratory composite may be calculated as an unweighted diagnostic summary when all component measures are applicable, but weighting or exclusion rules should be declared when items require different actions. Confidence calibration can be examined by comparing confidence ratings with classification correctness. The composite score supports comparison and diagnosis, not replacement of the component measures. It should therefore be reported alongside its components rather than used as the sole evidence of intervention effectiveness.

For example, consider a suspicious credential-harvesting item where the expected secure actions are classification, reporting, verification, and avoiding unsafe action. A participant who correctly classifies the message, reports it, verifies the request, and avoids entering credentials receives four positive component scores. If a legitimate item is presented, reporting is not considered a required secure action; therefore, the reporting component is marked as not applicable rather than incorrect, while unnecessary reporting may be recorded separately as a false-positive behavior. When a component cannot be assessed due to item design or missing participant data, it is excluded from the composite calculation and the denominator is adjusted accordingly. Tied cases or equal scores should be interpreted using the individual component measures rather than resolved through the composite alone.

This assessment design is part of the proposed artifact because it specifies how the mapping becomes measurable. The P1 walkthrough demonstrates this logic for one illustrative case only; empirical deployment is the next step and would require appropriate sampling, realistic examples, ethical safeguards, debriefing, and non-punitive procedures. Optional extensions could include simulated phishing campaigns or longitudinal follow-up when those safeguards are in place [9,18,19].

Future empirical deployment will require validation of both scenario construction and PPT mapping consistency. Scenarios should be generated using predefined criteria, including channel, pretext, requested action, manipulation cues, and system cues, and reviewed by cybersecurity and human-factor experts to ensure realism and relevance. The mapping procedure should be independently applied by multiple coders with relevant expertise, followed by reconciliation of disagreements. Inter-coder agreement can then be assessed using appropriate agreement statistics, such as Cohen’s kappa for two coders or Fleiss’ kappa for multiple coders, before the resulting mappings are used for participant evaluation.

5. Discussion

The end-to-end credential-harvesting walkthrough in Section 3.5 shows why assessment should move beyond the question of whether a user can identify a malicious message. In the illustrative execution, P1 recognized the email as suspicious and avoided credential entry, so a detection-only assessment would record partial success. The PPT-based assessment produces a more diagnostic interpretation: the absence of reporting and independent verification locates the remaining weakness in the Process dimension, the missed URL mismatch identifies a Technology-related cue gap, and high confidence despite incomplete action indicates a People-related calibration issue. The walkthrough therefore demonstrates the practical distinction between recognition alone and response quality across the whole decision situation.

This interpretation also shows how Adapt follows from the Evaluate stage. The framework does not simply conclude that the participant “failed” or that training was insufficient. It indicates which intervention components should be revised: reporting expectations and IT verification workflows for the Process gap, URL/domain examples for the Technology gap, and confidence-calibration content for the People gap. In this way, the proposed approach connects strands that are often studied separately by tracing a case from attack feature to mapped weakness, intervention action, observable measure, diagnosis, and adaptation decision.

For practitioners, the approach suggests that security learning programs should not be designed as isolated training events. They need to be connected to reporting processes, verification expectations, and the cues that users encounter in everyday work. For researchers, the mapping method provides a basis for scenario-based assessment in which detection, reporting, verification, confidence, and cue interpretation are measured together.

The approach is best interpreted as a design artifact rather than as evidence of intervention effectiveness. Its next evaluation step is empirical testing with appropriate samples, realistic examples, ethical safeguards, debriefing, and non-punitive procedures. It also depends on careful scenario construction and coding. Poorly designed items may measure familiarity with examples rather than resilience against deceptive requests, and a high composite score may reflect cautious behavior if false positives are not examined alongside suspicious-item performance. Similarly, some case features may map to all three dimensions, which makes transparent coding and reconciliation important. These limitations define the conditions under which the artifact should be evaluated and refined.

6. Conclusions

This paper presented a scenario-based People–Process–Technology mapping method for multi-channel social engineering awareness. The method defines a mapping procedure, an artifact-producing IMIEA cycle, scenario-based measures, and an end-to-end credential-harvesting walkthrough. The central argument is that security awareness should be evaluated not only as recognition of malicious content, but as secure response: detecting, verifying, reporting, avoiding unsafe action, and calibrating confidence within a supported organizational and technology-enabled environment. Future work will empirically examine whether integrated intervention content improves these measures across multiple social engineering examples.