According to the Verizon 2026 Data Breach Investigations Report, the human element was present in 62% of breaches, up from 60% the year before. Social Engineering was the third most common breach pattern, representing 16% of all breaches. Pretexting, an attack in which a trusted relationship is built through a concocted scenario, reached 6% of all breaches and has become a more common initial access vector for ransomware and extortion attacks. The report also states that in phishing simulations, the median rate of successful click rates in mobile-centric vectors, such as voice and text messaging, is 40% higher than via email.
That last finding matters for anyone who measures staff resilience through email phishing alone. A programme that sends a monthly email lure and reports a click rate is measuring one channel, and by Verizon's data not the most successful one. The attacks that have produced some of the most damaging recent breaches arrive by phone, by message, and sometimes in person, and they depend on a person being helpful at the wrong moment.
A second finding deserves equal weight. In a randomized trial covering more than 19,500 employees at UC San Diego Health, researchers sent ten phishing campaigns over eight months and found that embedded phishing training reduced the likelihood of clicking by only about 2%, with no significant relationship between completing annual training and avoiding the lure. Simulation, in other words, is a measurement instrument. It is not a cure, and an organization that treats a falling click rate as proof of safety is reading the instrument wrongly.
Talk to Our Security Experts →
Social engineering testing, done well, answers a different set of questions. Would a caller get a password reset from the help desk? Would a stranger walk past reception and reach a server room? When one employee does click, how quickly does someone else notice, report, and contain it, and would multi-factor authentication have stopped the attacker anyway? This guide covers what social engineering testing includes, why email-only simulation understates risk, what the research says about measuring people fairly, how an assessment is structured, why authorization is the foundation of physical testing, how Indian law and the DPDP Act shape the work, and which metrics show real resilience. It is written for CISOs, security awareness owners, facilities and HR leaders, and the legal teams who must sign off on testing that involves employees.
What Social Engineering Testing Covers
Social engineering testing is the authorized simulation of manipulation attacks against an organization's people and processes, run to find out whether controls hold when a person is the target. It spans several channels, each with its own objectives and controls.
| Channel | What is simulated | What it measures | Controls it exercises |
|---|---|---|---|
| Email phishing | Lures that try to obtain credentials or prompt an action, sent within agreed limits | Clicks, credential submissions, and reports | Email filtering, multi-factor authentication, the reporting button, SOC triage |
| Smishing and messaging | Lures delivered by text or messaging apps | The same measures on mobile devices | Mobile device controls, reporting routes for non-email lures |
| Vishing and pretexting | Calls to staff or the help desk using a believable scenario | Whether information is disclosed or an action is taken | Identity verification procedures, callback rules, escalation |
| Physical intrusion | Attempts to enter premises or reach defined areas without authorization | Whether people and controls stop or challenge an unauthorized person | Access control, visitor management, guard response, a culture of challenging |
| Multi-stage scenarios | A chain of the above toward a single objective | Detection and response across teams | Coordination between security, help desk, facilities, and HR |
The channels are tested together because attackers move between them. Verizon describes pretexting as frequently carried out by voice but also seen over email and text messaging, and a scenario that starts with a message and ends with a call exercises the organization's seams, not only its individual defenses.
Why Email-Only Simulation Understates the Risk
The DBIR draws a distinction that testing programmes should adopt. Phishing, as it defines the term, is an asynchronous social action: a message arrives and the recipient decides what to do. Pretexting is synchronous. An attacker is on the other end of a call, text conversation, or email thread, adapting in real time to convince the person to do something or disclose something they should not.
| Aspect | Phishing | Pretexting |
|---|---|---|
| Timing | Asynchronous: the target decides alone, later | Synchronous: the attacker responds to the target's hesitation |
| Typical channel | Email, text | Voice, text, email threads |
| What stops it | Filtering, authentication, user suspicion, reporting | Verification procedures, scripted refusals, escalation rules |
| What a test should examine | Click and report behavior, filter coverage, response speed | Whether help desk and support staff follow verification steps under pressure |
Verizon makes a point that is easy to miss. Training IT help desks and customer support agents not to be helpful when someone is trying to manipulate them is not as simple as checking whether an email looks suspicious. Pretexting needs business-specific rules aligned with each area of the organization, such as what a help desk agent may reset, for whom, and after what verification. A test of that process produces findings an email campaign never will.
What the Research Says About Measuring People
Two bodies of research should shape how results are collected and read.
The UC San Diego Health study found that lure choice mattered more than training. Click rates varied from 1.8% for one lure to 30.8% for another, a spread far larger than the roughly 2% effect of embedded training. Seventy-five percent of users spent a minute or less on the embedded training page, and a third closed it immediately. In the first month, about 10% of employees clicked a link; by the eighth month, more than half had clicked at least once.
The second is the NIST Phish Scale, developed in 2019 to rate how hard a phishing message is to detect. It combines two components: the observable cues in a message, and its premise alignment, meaning how relevant the scenario is to the target audience. The output is a detection difficulty rating that gives context to click rates. A 2025 reproduction across 12,511 participants found that the Phish Scale predicted behavior, with click rates rising from 7.0% for easy lures to 15.0% for hard ones, and that training interventions showed no significant main effect on click or reporting rates.
Three practices follow. A click rate should never be compared across campaigns without accounting for lure difficulty. Staff should not be ranked or shamed by a number that depends so heavily on how the test was written. And the programme should invest in controls that work when a person fails, since the evidence that training alone changes behavior is weak.
Metrics That Show Resilience
| Metric | What it indicates | Caution |
|---|---|---|
| Click rate | Susceptibility to one specific lure | Depends heavily on lure difficulty, so compare only like with like |
| Credential submission rate | Closer to real harm than a click | Needs careful handling to avoid collecting real passwords |
| Report rate | Whether staff alert the organization | Verizon advises making it as painless as possible for people to notify the organization |
| Time to first report | How quickly a human signal reaches the SOC | Depends on a clear, well-known reporting route |
| Time to containment | Whether the organization acted after the report | Tests process, not people |
| Help desk verification outcomes | Whether pretexting attempts were stopped | Requires pre-agreed rules for what counts as a failure |
| Repeat clickers | Where targeted support may help | Should lead to support, never punishment |
How a Social Engineering Assessment Runs
The structure below reflects common practice and the research above. Individual engagements adapt it to the organization.
| Step | What happens | What it produces |
|---|---|---|
| 1. Objectives and scope | Agree which channels, which business areas, and which outcomes matter | A written scope and a short list of objectives |
| 2. Authorization and rules of engagement | Obtain legal and executive sign-off, name a trusted contact, define stop conditions, data handling, and off-limits themes | A signed authorization and a rules-of-engagement document |
| 3. Reconnaissance within scope | Gather only the public information the scope permits | A target picture and candidate scenarios |
| 4. Scenario design | Build pretexts grounded in the business and rate lure difficulty, for example with the Phish Scale | Scenarios that are realistic and comparable |
| 5. Execution | Run the scenarios across the agreed channels with live monitoring and the ability to halt | Evidence of what staff and controls did |
| 6. Evidence capture | Record outcomes in a way that protects individuals and preserves facts | A defensible record |
| 7. Debrief and reporting | Present findings by objective, control, and process, with individual results restricted | A report leadership, HR, and security can use |
| 8. Remediation and retest | Fix the process and control gaps, then repeat the scenarios | Confirmation that fixes work |
Two design details deserve emphasis. First, the trusted contact, sometimes called a white cell, is a small group who know the test is running and can stop it. It also prevents a simulation from being handled as a real incident. Under the CERT-In Directions of 28 April 2022, identity theft, spoofing, and phishing attacks are among the incident types to be reported to CERT-In within six hours of noticing, so an organization needs a way to distinguish a sanctioned simulation from a real campaign without tipping off the people being tested. Second, the debrief should concentrate on process and controls. A finding that a help desk agent reset a password without verification is a procedure gap to fix, not a person to punish.
Physical Intrusion Testing: Authorization Comes First
Physical testing examines whether people and controls stop an unauthorized person from reaching defined areas. Scope typically covers entry points, reception and visitor handling, restricted areas such as server rooms and wiring closets, and after-hours conditions. The objective is evidence of what an intruder could reach, gathered without damaging property or endangering anyone.
The 2019 case of two Coalfire testers in Iowa is the standard cautionary example. Hired by the Iowa Judicial Branch to test court facilities, they were arrested at the Dallas County Courthouse on 11 September 2019 and charged, and the charges were later dropped. The state's court administration acknowledged that it and the contractor had different interpretations of the scope of the agreement. The county, which had reportedly not been told in advance, disputed that the state could authorize entry to a county-owned building. The lesson is not that physical testing is unsafe. It is that authorization has to come from whoever actually controls each site, and the scope has to be unambiguous about places and hours.
In India the stakes are of the same kind. Entering premises without authority can implicate criminal trespass and house-trespass under Section 329 of the Bharatiya Nyaya Sanhita, 2023, and impersonation to gain access can implicate cheating by personation under Section 319. Digital impersonation raises Sections 66C and 66D of the Information Technology Act, 2000. Written authorization is therefore the foundation of the engagement, and many Indian offices sit in shared buildings or IT parks where the tenant does not control the lobby, the lifts, or the guard force.
| Authorization element | Why it matters |
|---|---|
| Signed approval from the party that controls each site | The client may not control the building, the lobby, or the security contractor |
| Written scope of sites, dates, hours, and permitted methods | Ambiguity about scope is what failed in Iowa |
| Named testers carrying proof of identity and the authorization | Lets a challenged tester show who is responsible |
| A trusted contact reachable at all hours | Allows deconfliction with guards or police |
| Pre-agreed stop conditions | Protects safety and ends the test if circumstances change |
| A decision on whether and whom to notify | Balances test realism against the risk of an arrest |
| Firm limits: no damage, no force, no interference with life-safety systems, no entry to personal spaces | Keeps the exercise ethical and lawful |
Ethics and Employee Data
A phishing simulation processes personal data: names, work emails, and behavior such as clicks, submissions, and reports. Section 7(i) of the DPDP Act, 2023 recognizes processing for the purposes of employment, or related to safeguarding the employer from loss or liability, as a legitimate use that does not require consent. This is a ground for processing, not an exemption from the Act. The Data Fiduciary duties in Section 8, including reasonable security safeguards and erasure once the purpose is served, still apply. The Act’s notice requirement covers only consent-based processing, but telling staff in policy that simulations occur remains good practice. The Act's core obligations take effect in May 2027, and Rule 6 of the DPDP Rules 2025 sets minimum safeguards for the data a programme holds. Qualified legal advice should confirm how the clause applies to a specific programme.
Practical choices reduce risk. Report results at group level where possible, and restrict individual results to those who need them. Set a short retention period for raw data, subject to any period the DPDP Rules require. Tell staff in policy that simulations occur, without announcing individual campaigns. Agree off-limits themes in advance, such as pretexts built on bereavement, medical conditions, or job losses, since distress caused by a test erodes the trust the programme depends on. Never collect real passwords.
Where Indian Requirements Point
Several existing requirements touch this work. The CERT-In Directions make phishing and identity theft reportable, which gives the reporting path a regulatory weight beyond good practice. For organizations certified to ISO/IEC 27001:2022, controls on information security awareness and training (A.6.3), physical entry (A.7.2), and information security event reporting (A.6.8) are natural places to hold testing evidence. And under Sections 8(4) and 8(5) of the DPDP Act and Rule 6(1)(g) of the DPDP Rules 2025, which take effect in May 2027, data fiduciaries must adopt technical and organisational measures alongside reasonable security safeguards, so records. showing that staff and procedures were tested and gaps fixed are useful evidence.
What Skipping Social Engineering Testing Costs
| Gap | Consequence |
|---|---|
| Awareness measured by training completion alone | No evidence of behavior, and the UC San Diego study found completion did not predict outcomes |
| Email-only simulation | Voice, text, and physical weaknesses go unseen, though Verizon reports higher simulated click rates on mobile-centric vectors |
| No test of help desk verification | Pretexting succeeds through helpfulness, a weakness no email campaign reveals |
| Click-rate scoreboards | A punitive culture lowers reporting, which is the signal the SOC needs |
| No physical testing | Tailgating, visitor handling, and unattended-area weaknesses stay hidden |
| Unclear authorization | Legal exposure for testers and the client, as the Iowa case showed |
| No measure of containment | Reports are filed but nobody confirms the credential was reset or the message removed |
A Maturity Model for Social Engineering Resilience
Level 1: Annual awareness training runs, completion is tracked, and no simulation is performed ↓ Level 2: Periodic email phishing simulation reports click rates ↓ Level 3: Multi-channel simulation, covering email, messaging, and voice, uses difficulty-rated lures and tracks report rates ↓ Level 4: Pretexting and physical scenarios are tested under documented authorization, and controls such as help desk verification, multi-factor authentication, and visitor management are tested, not only people ↓ Level 5: Objective-based scenarios tied to current threat intelligence run continuously, metrics cover time to report and time to containment, and findings feed controls, culture, and purple team work
The step from Level 2 to Level 3 matters most, because it replaces a single number with a picture of how the organization behaves across channels.
A Readiness Playbook
- Decide the objectives first. Credential theft, help desk takeover, and physical access are different goals with different tests.
- Get legal, HR, and executive sign-off in writing before any employee is tested.
- Name a trusted contact and agree stop conditions, so a simulation can be halted and never mistaken for a real incident.
- Rate every lure for difficulty so results can be compared across campaigns.
- Build a reporting route that is easy and well known, and measure it as carefully as clicks.
- Test the help desk and support teams with pretexting scenarios, using verification rules agreed beforehand.
- Include physical testing only with site-level authorization from whoever controls each location.
- Fix the control gaps found, then retest, and report trends to leadership without naming individuals.
Common Mistakes and Edge Cases
Treating a click rate as a score of people. It reflects the lure as much as the person, and it falls and rises with test design.
Punishing clickers. Fear reduces reporting, and reporting is the capability the organization most needs.
Testing only email. Voice and text are where Verizon's simulated click rates run higher.
Authorizing physical testing through the wrong party. The Iowa case turned on who could authorize entry to which building.
Using distressing pretexts. Themes built on illness, bereavement, or layoffs damage trust and add little insight.
Running a test with no way to halt it. A trusted contact and stop conditions are basic safeguards.
Collecting more data than needed. Raw results with names are sensitive and should be minimized and retained briefly.
When to Use What: A Few Decision Points
Announced versus unannounced tests. An announced test, where leadership knows the window, is a sensible start for organizations new to simulation. Unannounced tests give a more realistic reading of behavior and need the strongest authorization and a trusted contact.
In-house versus external testers. Internal teams know the organization and its tools. An external team adds independence, outside experience, and credibility with auditors, and it is usually better placed to run voice and physical scenarios where staff may recognize colleagues.
A simulation platform versus bespoke scenarios. A platform is efficient for recurring email campaigns and reporting. Pretexting and physical work need scenarios written for the organization.
Frequency. Email simulation can run regularly. Voice, pretexting, and physical assessments are usually periodic, tied to changes such as new premises, a new help desk provider, or a reorganization.
Including physical testing. It is most valuable where premises hold sensitive systems or data, and it requires the most careful authorization.
How SecNinjaz Fits Into This
Social Engineering sits within SecNinjaz's Cybersecurity practice alongside Penetration Testing, Red Teaming, Purple Teaming, Vulnerability Assessment, Breach and Attack Simulation, and AI SOC Automation. SecNinjaz's social engineering assessments cover phishing simulations, vishing, and physical intrusion testing, and the results can be carried into a red team engagement or a purple team exercise so that detection and response are tested alongside the people.
The governance side connects to SecNinjaz's GRC and DPDP practice, including Regulatory Compliance and Audit and Gap Assessment, which help map testing evidence to ISO/IEC 27001 controls and to DPDP safeguard duties. SecNinjaz holds ISO/IEC 27001:2022 and ISO/IEC 27701:2025, which matter here because the results of a social engineering test, including who failed what and where physical controls are weak, are sensitive and need disciplined handling. For organizations that want evidence of how their people and processes behave under pressure, that combination of realistic testing and careful governance is the pairing worth looking for, whether the organization works with SecNinjaz or anyone else.
Talk to Our Security Experts →
Frequently Asked Questions
What is social engineering testing?
Social engineering testing is the authorized simulation of manipulation attacks, such as phishing, vishing, pretexting, and physical intrusion, to find out whether an organization's people and processes hold up when a person is the target. It measures behavior and controls together, including whether staff report suspicious contact and whether the organization contains the result.
What is the difference between phishing simulation and vishing or pretexting tests?
Phishing is asynchronous: a message arrives and the recipient decides alone. Vishing and pretexting are synchronous: an attacker speaks with the target and adapts in real time. Verizon's 2026 DBIR notes that the countermeasures differ, and that protecting help desks and support teams needs business-specific verification rules, not just email awareness.
Does phishing awareness training reduce clicks?
The evidence is modest. A randomized trial of more than 19,500 employees at UC San Diego Health found embedded phishing training reduced the likelihood of clicking by about 2%, with no significant relationship between completing annual training and avoiding phishing. Controls that work when a person clicks, such as multi-factor authentication and easy reporting, therefore matter alongside training.
What metrics should a phishing simulation report?
Click rate alone is a weak measure because it depends on how hard the lure is. Better programmes report credential submission rate, report rate, time to first report, time to containment, and a difficulty rating for each lure, such as one based on the NIST Phish Scale. Repeat clickers should lead to support, not punishment.
Is physical penetration testing legal in India?
It is lawful when properly authorized in writing by whoever controls each site, with clear scope, named testers, and stop conditions. Without authority, entry can implicate criminal trespass under Section 329 of the Bharatiya Nyaya Sanhita, and impersonation can implicate cheating by personation under Section 319. Shared buildings need approval from the landlord or facility management as well as the tenant.
How does the DPDP Act affect phishing simulations?
Simulations process employee data such as names, emails, and behavior. Section 7(i) of the DPDP Act recognizes processing for employment purposes or for safeguarding the employer from loss or liability as a legitimate use. Security safeguards and erasure duties still apply once the Act’s core obligations take effect in May 2027, and telling staff in policy that simulations occur is good practice. Minimizing and restricting individual results, and confirming the position with legal advice, reduces risk.
Should employees be told about a simulation in advance?
Staff should be told in policy that simulations occur, but individual campaigns are normally unannounced, since advance notice removes the realism being measured. A small trusted group should know the schedule so the test can be halted and is not handled as a real incident, which matters because real phishing is reportable to CERT-In within six hours.
Where should an organization start with social engineering testing?
Start by deciding the objectives and getting written legal, HR, and executive sign-off. Name a trusted contact and stop conditions, rate lures for difficulty, build an easy reporting route, and test the help desk with agreed verification rules. Add physical testing only with site-level authorization, then fix the gaps found and retest.
