Social Engineering Penetration Testing Explained

Social engineering penetration testing is an authorized assessment of how well your people, processes and supporting controls resist manipulation. Testers run realistic but controlled phishing, phone (vishing), text message and, when approved, physical scenarios, then measure who reported the attempt, how quickly the security team responded and which business processes let the attempt succeed. A well-run test needs written approval from leadership, legal and HR, strict limits on the pretexts used and anonymized reporting. Its purpose is to fix verification steps and technical controls, not to single out the employees who clicked.

What Is Social Engineering Penetration Testing?

NIST's Technical Guide to Information Security Testing and Assessment, SP 800-115, describes social engineering as an attempt to trick someone into revealing information, such as a password, that can be used to attack systems. NIST lists it as a validation technique that tests "the human element and user awareness of security" and can reveal weaknesses such as failing to follow standard procedures. The same section adds a rule that still defines good practice: results should be used to improve the security of the organization and not to single out individuals.

A social engineering penetration test (also called a social engineering assessment or social engineering test) applies that idea in a scoped engagement. It answers practical questions:

• Do email, phone and messaging controls stop or flag a convincing lure before it reaches people?
• When a lure gets through, do employees recognize it and report it, and how fast?
• Do help desk, finance and reception staff follow verification procedures under pressure?
• When someone does click or share a credential, do multifactor authentication, monitoring and the security operations center (SOC) contain the damage?

The threat is real and persistent. The 2026 Verizon Data Breach Investigations Report found a non-malicious human element in 62% of breaches, named social engineering the third most common breach pattern at 16% of breaches, and reported that pretexting reached 6% of all breaches. For the full threat data, see our roundups of social engineering attack statistics, phishing statistics, vishing statistics and smishing statistics. This guide focuses on how to test your exposure safely and fairly.

Social Engineering Penetration Test vs Phishing Simulation vs Red Team

Three activities are often confused. They overlap in technique but answer different questions.

A recurring phishing program builds habits. A social engineering penetration test is an independent check that also covers the channels and processes a phishing platform does not reach, such as the help desk's password reset procedure or the front desk's visitor checks. In a red team, social engineering is usually just the entry point to a larger objective; our guide to what red teaming is explains how those campaigns work.

Types of Social Engineering Penetration Tests

Most engagements combine two or three of the test types below. Choose them by your real exposure: a company whose help desk resets passwords by phone needs a vishing test more than a USB drop.

Email phishing assessment

An email phishing assessment, often called a phishing simulation test, sends controlled lures to an agreed population and records what happens next. Testers describe lures by theme and difficulty, such as a document-sharing notice, a policy update or a delivery problem, and agree each theme with the control group before sending. A well-designed assessment also checks the defenders: how long it takes for the first report, whether the SOC pulls the remaining messages and whether anyone who entered a credential is contacted.

MITRE ATT&CK tracks the attacker side of this activity as Phishing (T1566) and, for information gathering, Phishing for Information (T1598). Mapping your test to those techniques makes results comparable with threat intelligence and with later red team work. For QR-code lures, our explainer on QR quishing covers why they slip past link scanning.

Vishing and help desk tests

Voice tests check whether staff follow procedure when a caller sounds confident and urgent. The most valuable target is usually the IT help desk, because a password or multifactor reset given to the wrong person can hand over an account. ATT&CK added Spearphishing Voice (T1566.004) in 2023, and the 2026 DBIR notes that attackers impersonating help desk agents or users who need a password reset have had "moderate levels of success."

A good vishing test is scored against the written procedure, not against an agent's personality. If the procedure allows a reset after a caller gives a name and an employee ID, the finding belongs to the procedure. Pair this test with phishing-resistant authentication work; our article on MFA fatigue attacks shows how attackers combine calls with push-notification abuse.

Smishing and QR phishing tests

Text-message and QR-code lures reach people on phones, where corporate email filtering and link rewriting often do not apply. The 2026 DBIR reports that in phishing simulations the median click rate for phone-centric vectors such as voice and text is about 2%, compared with 1.4% for email, a 40% relative increase. Verizon warns that the phone-centric sample is small, so treat the gap as a signal to test mobile channels, not as a precise benchmark.

Physical penetration testing

Physical penetration testing checks whether someone without authorization can enter offices, data rooms or other restricted areas by tailgating, impersonating a contractor or visitor, or exploiting weak badge and reception processes. It carries the highest legal and personal-safety risk of any social engineering test, so it has its own section below.

Baiting tests

Baiting tests leave removable media or other "found" items in common areas to see whether employees plug them in or hand them to IT. The device should do nothing except record that it was connected, so no data leaves a workstation and no code runs beyond that harmless signal. The most useful metric is how many devices were turned in or reported, not how many were connected.

Rules of Engagement: Approval, Consent and Pretext Limits

Social engineering tests target people, so the rules of engagement (ROE) must protect them as well as the organization. The UK National Cyber Security Centre's phishing guidance warns that phishing simulations "can also create legal risk" and can erode trust between employees and security. Written approvals and firm limits are what keep a test from causing that harm.

Who must approve the test

Consent without spoiling the test

Individual employees are not told the date or theme of a test, or the measurement would be meaningless. Consent therefore works at two levels. The organization consents through the signed ROE, and employees are informed in advance, through policy and onboarding, that the company runs security exercises, including simulated phishing and calls, and that results are used to improve processes rather than to punish individuals. That general notice is what makes later testing fair.

Phone recording needs separate care. US federal law allows recording when one party to the call consents (18 U.S.C. 2511), but some states require every party's consent, and other countries have their own rules. Unless legal review approves recording, testers should take notes rather than record. Synthetic voices need the same caution: in 2024 the FCC ruled that AI-generated voices count as "artificial" under the Telephone Consumer Protection Act. Do not clone or imitate a real executive's voice without that person's written consent and legal sign-off.

Pretexts that should stay off limits

A pretext is the story a tester uses. Some stories cause real distress or legal exposure, and they teach nothing a gentler scenario would not. Exclude these in the ROE:

• Pay, bonuses, layoffs, disciplinary action or benefits changes that are not real
• Health, medical results, pregnancy, family emergencies or bereavement
• Disasters, violence, active threats or law enforcement impersonation
• Real charities, unions, government agencies or third-party brands without their permission
• Employees' personal accounts, personal phones, home addresses or family members, unless explicitly approved
• Any pretext that requires lying about a real, named colleague in a way that could damage their reputation

The control group should approve every scenario by theme and difficulty before launch. Testers should be able to show that each pretext maps to a threat the organization actually faces, such as invoice fraud or help desk impersonation, rather than to whatever produces the highest click rate.

How a Social Engineering Engagement Runs

Most engagements follow six steps. The detail varies by channel, but the order rarely changes.

1. Scoping. Agree objectives, channels, population, exclusions and the ROE. Our guide to penetration testing scope covers how to write a scope that both sides can test against.
2. Open-source research within limits. Testers review what the organization publishes about itself, such as role titles, email formats, office locations and vendors, to build realistic scenarios. Research stays on business information and avoids employees' private lives.
3. Scenario approval. The control group approves each scenario by theme, difficulty and channel. A difficulty rating, such as the NIST Phish Scale, is recorded before launch so results can be interpreted later.
4. Execution and monitoring. Testers run the scenarios within the agreed window while the control group watches for real incidents and deconflicts SOC escalations.
5. Immediate care. People who interacted with a lure see a short, respectful explanation, and anyone who reported it gets thanks. Credentials entered are invalidated or reset as agreed.
6. Reporting, debrief and retest. Findings go to process owners, fixes are agreed and a retest checks that they work.

Metrics: Click, Report and Credential-Entry Rates

Phishing and other social engineering tests produce numbers that are easy to misread. NIST's Phish Scale User Guide (TN 2276) defines click rate as the number of people who clicked a simulated link or attachment out of everyone who received it, and reporting rate as the number who reported it out of everyone who received it. NIST also notes that these rates "do not provide a complete picture" of phishing risk on their own.

What the research says about these numbers

Lure difficulty dominates click rates. In a study of more than 19,500 employees at UC San Diego Health, published at IEEE Security and Privacy 2025, average failure rates for ten simulated lures ranged from 1.82% for the easiest to 30.80% for the hardest. Over eight months, 56% of employees clicked at least one simulated link. The same organization, same people, same month can produce a "good" or "bad" click rate depending on which lure was sent.

Training moves reporting more than clicking. The UCSD researchers found no significant relationship between recent annual awareness training and failing a simulation, and an average absolute difference of only 1.7% between employees who received embedded training and those who did not.

An earlier ETH Zurich study of more than 14,000 employees over 15 months found that embedded training "does not make employees more resilient to phishing," while warnings on suspicious emails helped and employee reports proved a practical way to detect campaigns quickly. Verizon's 2025 DBIR, drawing on data from more than 7,000 organizations, found that users with training in the previous 30 days reported simulated phishing at about 21%, against a base rate of 5%, while the effect on clicking was much smaller.

Typical numbers are low, but they are not zero. The 2026 DBIR puts the median email phishing simulation click rate at 1.4%, and that median hides wide variation between lures and audiences. The NIST Phish Scale exists for this reason: it rates how hard a lure is to detect, and NIST notes that lures rated very difficult "might understandably result in high click rates," while a high click rate on an easy lure may point to a training need.

A worked example (illustrative)

The numbers below are illustrative, not data from a real engagement. A company sends one approved lure to 1,000 employees:

• 120 click the link, a click rate of 12%.
• 35 enter credentials, a credential-entry rate of 3.5%, and a click-to-credential conversion of 29% (35 ÷ 120).
• 180 report the email, a report rate of 18%, and the first report arrives 6 minutes after delivery.
• The SOC removes the remaining copies 40 minutes after the first report.

Read well, this result is encouraging. More people reported the lure than clicked it, and the first warning came within minutes. The priorities are to cut the 40-minute containment time, to make sure phishing-resistant MFA would block the 35 submitted credentials, and to find out why the landing page did not trigger browser or password manager warnings. None of those fixes involves naming the 35 people.

Five rules for reading results without blaming staff

1. Record lure difficulty first. Report every rate next to the lure's difficulty rating and theme. A high click rate on a very difficult lure is expected, while a high click rate on an easy one points to a training or tooling gap.
2. Lead with reporting. Make report rate, time to first report and time to containment the headline metrics. NCSC warns that if you appear to value the absence of reported problems, you encourage people to stay quiet.
3. Aggregate and protect. Present results by team, role or location with a minimum group size, and keep individual data with the control group. NCSC states that punishing people for clicking on simulated emails "starts to resemble entrapment."
4. Trace each failure to a control. For every successful attempt, ask which filter, verification step or technical control should have stopped it, and assign the fix to that control's owner.
5. Compare like with like. Compare trends only across lures of similar difficulty and channel. A falling click rate after switching to easier lures is not progress.

Physical Penetration Testing Safety

Physical testing puts testers in front of employees, guards and sometimes police. The best-known warning is the 2019 case in which two Coalfire testers were arrested on September 11, 2019, at the Dallas County courthouse in Iowa during a physical test commissioned by Iowa's State Court Administration. As Krebs on Security reported, some buildings in scope belonged to the state and others to the county, a distinction that had not been resolved before testing. The testers were charged with burglary-related offenses, the charges were later reduced to trespass, and prosecutors dropped them on January 30, 2020. The lesson is that a contract is only as good as the signer's authority over the property.

Use this checklist before any physical test:

• Confirm property authority. Verify who owns or leases each building, and get signatures from every owner, landlord or facilities provider whose permission is needed.
• Carry an authorization letter. Each tester carries a signed letter describing the engagement, the dates and hours, the addresses in scope and at least two control-group contacts who answer around the clock.
• Decide on law enforcement and security notice. Agree in advance whether guards, building security or local police are told, and how a confrontation will be verified quickly.
• Set entry limits. No forced entry, lock damage, climbing, alarm or fire-safety tampering, or entry into hazardous areas unless explicitly approved with the right safety controls.
• Stop on confrontation. If challenged by a guard or police officer, the tester stops, stays calm, identifies themselves and calls the control group. Testers never run, hide or resist.
• Work in pairs and in agreed hours. Use a two-person team where possible, with one person able to call for help, and avoid out-of-hours entry unless the property owner has approved it in writing.
• Protect staff. Do not test anyone in a way that could feel threatening, and end any interaction where an employee becomes distressed.
• Collect proof, not property. Prove access with photos of agreed markers or placement of a harmless token, never by removing equipment or documents.

Reporting and Training Follow-Up

The report is where a social engineering test either improves processes or just embarrasses people. NIST SP 800-115 recommends a detailed report that identifies both successful and unsuccessful tactics, so the organization can tailor its awareness program. A strong report contains:

• an executive summary tied to the objectives and the threats they represent;
• each scenario by theme, channel and difficulty, with aggregate results and timelines;
• what worked well, including fast reports and staff who followed verification procedures;
• each failure traced to a process or control, with evidence and a fix;
• a retest plan and the metrics that will show whether fixes work.

Our penetration testing report guide covers severity, evidence and structure in more depth.

For finance teams, our business email compromise statistics show how payment-change fraud plays out.

Training follow-up should be short, specific and respectful. Thank reporters first. Offer people who fell for a lure a brief explanation of the cue they could have noticed, without public lists or manager escalations. Then retest the processes, not the individuals, after the fixes are in place. If attackers use phishing as an entry point in a real incident, your incident response plan should already describe how reports reach responders.

Is Social Engineering Testing Worth It?

Some security leaders argue that social engineering testing only proves what everyone knows, that some people will click, while hurting trust. The criticism is fair when tests are run as gotcha exercises or reported with names. The UCSD and ETH results also show that punishing or retraining clickers changes little.

The value comes from changing the question. Instead of asking whether employees can be fooled, a good test asks whether the organization's processes and controls still hold when someone is fooled, and whether staff report quickly enough for the SOC to act. Tested that way, social engineering findings lead to concrete fixes: stronger help desk verification, phishing-resistant MFA, faster mailbox purges and better visitor controls. If your organization cannot yet act on findings like these, start with the technical basics and an internal reporting program, then commission an independent test.

Frequently Asked Questions

What is social engineering testing?

Social engineering testing is an authorized exercise that uses controlled phishing, phone, text, physical or baiting scenarios to measure how well people, processes and supporting controls resist manipulation. It reports results in aggregate and focuses on fixing processes and controls.

Is social engineering penetration testing legal?

Yes, when it is authorized in writing by someone with authority over every system, site and population in scope, and when it respects employment, privacy, telecom and recording laws in each jurisdiction. Legal and HR review before testing is the norm, and physical tests need confirmed property authority.

Should employees be told about a phishing test in advance?

They should know in general, through policy and onboarding, that the organization runs security exercises and that results are not used for punishment. They should not be told the date or theme of a specific test, because that would make the results meaningless.

What is a good phishing simulation click rate?

There is no universal target, because click rates depend mostly on lure difficulty. The 2026 Verizon DBIR reports a median email simulation click rate of 1.4%, while a large university health system study saw rates from 1.82% to 30.80% across different lures. Track click rate alongside difficulty and focus on report rate and response time.

How often should you run a social engineering penetration test?

Many organizations run an independent test once a year and after major changes to help desk, finance or access procedures, while an internal phishing program runs more often. The right cadence depends on risk, regulatory expectations and how quickly you can fix findings.

Does PCI DSS require social engineering testing?

PCI DSS v4.0.1 Requirement 12.6.3.1 requires security awareness training to cover phishing and related attacks and social engineering, as published in the PCI SSC document library. That is a training requirement, not a mandate for a social engineering penetration test, although a test can provide useful evidence that training and controls work.

What is the difference between a vishing test and a phishing test?

A phishing test uses email to measure clicks, credential entry and reporting. A vishing test uses phone calls to check whether staff, especially help desk and finance teams, follow identity verification procedures before resetting access, sharing data or changing payment details.

Next Step: Test the Processes Attackers Target First

A social engineering penetration test is worth running when it is approved by legal and HR, limited to fair pretexts, measured with report rates and lure difficulty, and followed by fixes to verification steps and technical controls. Start by listing the processes an attacker would most like to manipulate, such as password resets, payment changes and visitor entry, and test those first.

DeepStrike's penetration testing services include social engineering assessments that simulate real-world attacks such as phishing, calling and baiting. For objective-based campaigns where phishing and pretexting are the entry point, see our red teaming services. To discuss scope and rules of engagement, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• NIST TN 2276: NIST Phish Scale User Guide (November 2023), PDF
• NIST: NIST Phish Scale User Guide publication page
• Verizon 2026 Data Breach Investigations Report
• Verizon 2025 Data Breach Investigations Report
• Ho et al., Understanding the Efficacy of Phishing Training in Practice (IEEE S&P 2025), UC San Diego
• Lain, Kostiainen and Čapkun, Phishing in Organizations: Findings from a Large-Scale and Long-Term Study (IEEE S&P 2022), arXiv
• UK National Cyber Security Centre: Phishing attacks, defending your organisation
• MITRE ATT&CK: Phishing (T1566)
• MITRE ATT&CK: Spearphishing Voice (T1566.004)
• MITRE ATT&CK: Phishing for Information (T1598)
• 18 U.S.C. 2511, Legal Information Institute, Cornell Law School
• FCC: AI-generated voices in robocalls ruled artificial under the TCPA (February 2024)
• Krebs on Security: Iowa prosecutors drop charges against men hired to test their security (January 2020)
• PCI Security Standards Council: Document Library (PCI DSS v4.0.1)