A Reddit thread on the topic of social engineering in penetration testing contains a comment that cuts to the central tension: "Most organisations run phishing simulations and call it social engineering testing. What they're actually running is awareness training with a performance metric."
The distinction matters more than vendors who sell phishing simulation platforms would prefer to acknowledge. Social engineering penetration testing and phishing simulation training are related but serve different purposes, produce different evidence, and answer different security questions. Conflating the two leads to security programs that measure click rates without ever testing whether the human attack surface could produce a real breach.
This guide covers what social engineering penetration testing actually is, how it differs from awareness training, what the methodology covers, the ethical and consent framework that makes or breaks a social engineering engagement, and what the results should be used for.
Social engineering penetration testing is a structured attempt to breach an organisation's security controls by manipulating people rather than exploiting technical vulnerabilities. The tester uses deception, impersonation, and psychological techniques to extract credentials, gain physical access, induce wire transfers, or achieve whatever specific objective is defined in the rules of engagement.
The goal is to test whether the combination of human decision-making and security controls would allow an attacker to achieve a defined objective through social manipulation. It is a security test, not a training exercise. The metric is whether the objective was achieved, not how many people clicked a link.
This is the debate that the Reddit thread and the 2017 practitioner essay that still ranks in this SERP both engage with. It is worth addressing directly because it determines what engagement type an organisation should commission.
Phishing simulation training sends simulated phishing emails to employees, tracks who clicks, who enters credentials, and who reports the email. It is used to measure employee susceptibility to phishing, identify individuals who need additional security awareness training, and demonstrate improvement in susceptibility rates over time. It is a training and measurement tool. It is valuable. It is not penetration testing.
Social engineering penetration testing tests whether an attacker using social manipulation could achieve a specific objective: access to the building, credentials that allow access to sensitive systems, a successful wire transfer, installation of malware on a workstation. It tests the system of controls around the human attack surface: not just whether people click links, but whether the entire response system (people, processes, and technology) would contain or detect a sustained social engineering attack.
An organisation can have excellent phishing simulation metrics (low click rates, high reporting rates) and still fail a social engineering penetration test because the test reveals controls that do not exist: a receptionist who will walk anyone through a door if they present a convincing cover story, a help desk that resets passwords over the phone without adequate verification, a finance team whose wire transfer process does not require secondary verification for above-threshold amounts.
Social engineering testing covers the human and process controls that technical testing cannot reach:
Email phishing: Targeted phishing (spear phishing) using intelligence gathered about the target organisation and specific individuals. Highly targeted phishing designed to impersonate a specific known individual (CEO fraud, BEC) to induce wire transfers or credential disclosure.
Vishing (voice phishing): Phone-based social engineering impersonating IT support, bank fraud departments, regulatory agencies, or vendors. Testing whether authentication procedures on inbound calls are enforced, whether help desk staff can be manipulated into resetting credentials, and whether executive assistants can be manipulated into scheduling calls or disclosing information.
Smishing (SMS phishing): Text-based social engineering impersonating banks, delivery services, or internal systems. Testing whether employees follow links in unsolicited SMS messages and enter credentials on attacker-controlled pages.
Physical intrusion: Tailgating through secure access points, impersonating vendors, service personnel, or new employees to gain physical access to the facility. Testing whether physical security controls (access card requirements, visitor escort policies, challenged entry) hold under realistic pretexting.
Pretexting and impersonation: Multi-stage social engineering combining phone, email, and in-person interactions to build a believable cover story and achieve a sustained objective. The most complex and realistic social engineering test type, and the one most likely to reveal systemic control failures.
Social engineering penetration testing is the discipline within penetration testing where the ethics and consent requirements are most consequential. Getting this wrong can damage careers, damage organisational trust, and in some jurisdictions, create legal liability regardless of the organisational authorisation.
Organisation-level authorisation is required but not sufficient. A CISO signing off on a social engineering engagement gives the tester legal protection for conducting the test. It does not address what happens to the individuals targeted. A phishing simulation that captures a specific employee's real credentials is capturing real data. A pretexting call that manipulates an employee into disclosing confidential information is doing that to a real person who was not told they were in a test.
Scope definition is an ethical obligation. The engagement scope should define specifically what objectives are authorised, what techniques are permitted, what individuals or groups are in scope, and what the immediate halt conditions are. An engagement that permits "any technique to achieve access" creates unpredictable situations that can affect people in ways not anticipated when the authorisation was signed.
The "name and shame" problem. Social engineering test results should not be used to discipline or publicly identify employees who were successfully manipulated. This is both an ethical position and a practical one: social engineering testing that employees perceive as an attempt to catch them out rather than improve organisational resilience creates the exact adversarial relationship between security teams and the rest of the organisation that security programs need to avoid.
Immediate notification after compromise. When an employee provides real credentials, clicks a link that would install malware in a real attack, or grants physical access, the tester should have a defined process for ending the specific employee interaction promptly and ensuring no real harm occurs. Credential capture must not result in actual credential exposure; physical access through tailgating should be flagged to the security team, not used to remain inside the facility for hours.
The penetration testing checklist before you start covers pre-engagement confirmation items in detail; social engineering engagements require every item on that checklist plus specific consent, immediate notification, and data handling procedures specific to the human element.
Phase 1: Intelligence gathering (OSINT)
Before any contact with the organisation, the tester gathers intelligence using only publicly available sources: LinkedIn profiles identifying employees and their roles, company website and social media revealing internal processes and systems, job postings revealing technology stack and organisational structure, previous data breaches revealing email formats and potentially recycled credentials, and public records revealing physical locations and facility information.
This phase produces the intelligence base that makes pretexting scenarios plausible. An IT support impersonation call that references the organisation's actual ticketing system name is more convincing than a generic "I'm from IT" call. Good social engineering attacks are built on good intelligence.
Phase 2: Pretext development
Based on the intelligence gathered, the tester develops specific cover scenarios appropriate to the engagement objectives: the vendor with a scheduled maintenance visit, the IT helpdesk caller following up on an open ticket, the new employee who lost their access card, the auditor reviewing system access controls. The pretext must be plausible given what the tester knows about the organisation.
Phase 3: Engagement execution
The specific techniques employed depend on the pretext and objectives defined in the rules of engagement. A physical intrusion test might involve arriving at the facility with a pretext, testing whether access card challenges are enforced, whether visitor escort policies apply, and whether challenges to unexpected visitors are made. A credential harvesting test might involve a targeted phishing email followed by a vishing call to complete the compromise.
The tester documents everything: timestamps, what was attempted, what worked, what failed, and what controls (or lack of controls) were demonstrated. This documentation becomes the finding evidence in the report.
Phase 4: Escalation and pivot (when authorised)
Depending on the engagement objectives, successful initial access may be followed by escalation: using harvested credentials to access systems, using physical access to install testing equipment, or using a compromised helpdesk relationship to escalate to higher-value targets. This is where social engineering testing intersects with technical penetration testing and is where red team exercises extend most fully.
Red team vs. penetration testing: what's the real difference covers the distinction between scoped social engineering testing and full red team exercises where social engineering is the initial access component of a sustained adversarial campaign.
The most common mistake in social engineering testing is using results as individual performance metrics rather than as system diagnostics. The correct frame: social engineering test results reveal failures in the organisation's security system, not failures of the individuals who were targeted.
What results reveal:
A successful phishing credential harvest reveals that: the email filtering system did not block the phishing email, the phishing page URL was not flagged by browser-based protection, the employee did not recognise the phishing indicators, and no secondary authentication factor prevented credential use. The finding is a system failure across multiple layers, not an employee failure.
A successful physical intrusion reveals that: the tailgating control at the access point is ineffective, the receptionist did not challenge unfamiliar visitors, the escort policy is not enforced, and internal challenges to unexpected personnel did not occur. The finding is a physical security process failure.
A successful vishing credential reset reveals that: the help desk authentication procedure is insufficient, the call screening process did not flag the request as suspicious, and the verification step was bypassed. The finding is a process control failure.
How to use results:
Fix the system controls that failed, not the individuals who encountered them. Retrain the help desk authentication procedure. Implement technology controls (hardware MFA, credential phishing-resistant authentication) that make credential harvesting less valuable even when employees are manipulated. Review and enforce the physical security escort policy.
Results should produce specific control improvements and be measured by whether those improvements hold in subsequent testing, not by whether click rates went up or down.
Social engineering testing is not explicitly required by most compliance frameworks, but it is increasingly considered part of thorough security testing evidence under frameworks that require testing of security controls.
SOC 2: While SOC 2 does not mandate social engineering testing, some auditors ask whether the organisation has tested the human controls around access management (does your help desk's credential reset process hold under a realistic attack?). Including a scoped social engineering assessment alongside technical penetration testing produces stronger SOC 2 CC6 evidence.
PCI DSS: PCI DSS does not require social engineering testing as part of Requirement 11.4. However, if social engineering is how a real attacker would reach the cardholder data environment, testing that pathway is relevant to the overall security of the CDE.
ISO 27001: Control 6.3 (security awareness, education, and training) and Control 8.7 (protection against malware) both relate to the human security layer. Social engineering testing produces evidence relevant to these controls.
**What is inside a VAPT report](https://www.10xpentest.com/blog/what-is-vapt-report-breakdown) covers how social engineering findings should be documented in the report: the same proof-of-objective standard applies: document exactly what pretext was used, what was achieved, what controls were bypassed, and what control improvements would prevent the same path.
Social engineering testing costs scale with the number of techniques employed, the geographic scope (physical testing requires travel), and the duration of the engagement.
Phishing-focused engagements (targeted spear phishing with simulated credential harvest and follow-up analysis) typically run $3,000 to $10,000 depending on the number of targets and sophistication of the phishing infrastructure.
Full social engineering assessments combining phishing, vishing, and physical intrusion testing run $8,000 to $30,000 or more depending on the number of locations and the duration of the physical intrusion component.
Red team exercises where social engineering is the initial access component alongside technical testing run $50,000 to $150,000+ for sustained campaigns.
How much does penetration testing cost? covers the full cost landscape for all testing types.
For penetration testing services in the US that include social engineering alongside technical testing, VAPT services, penetration testing in India, or technical application security testing as the continuous layer that complements periodic social engineering assessments, see pricing or get in touch to discuss how social engineering testing fits alongside your technical testing program.
Q1. What is social engineering penetration testing?
Social engineering penetration testing is a structured security test that attempts to achieve a defined objective by manipulating people rather than exploiting technical vulnerabilities. The tester uses deception, impersonation, and psychological techniques through email phishing, phone calls (vishing), text messages (smishing), or in-person physical intrusion to test whether human and process controls would allow an attacker to achieve the defined objective. Social engineering penetration testing differs from phishing simulation training in that it tests whether the complete system of controls around the human attack surface would contain a real attack, not just whether employees click links.
Q2. Is phishing simulation the same as social engineering penetration testing?
No. Phishing simulation training sends simulated phishing emails, tracks click and reporting rates, and is used for security awareness measurement and training. Social engineering penetration testing is a structured security test with defined objectives (credential harvest, physical access, wire transfer, credential reset through the help desk) that tests whether the organisation's complete system of controls around human attack vectors would prevent a real attacker from achieving those objectives. Good phishing simulation metrics do not mean good social engineering test outcomes, because the test covers controls that simulation training does not exercise.
Q3. What are the main types of social engineering attacks tested?
Social engineering penetration tests cover: phishing (targeted email attacks designed to harvest credentials or induce specific actions); vishing (phone-based social engineering targeting help desks, executives, or finance teams); smishing (SMS-based phishing); physical intrusion (tailgating, impersonation of vendors or service personnel to gain facility access); and pretexting (multi-channel sustained social engineering campaigns combining multiple techniques to achieve higher-value objectives). The appropriate technique mix depends on the engagement objectives and what attack vectors are most relevant to the organisation's actual threat model.
Q4. How should social engineering test results be used?
Social engineering test results should be used to identify and remediate system-level control failures, not to identify and discipline individuals who were successfully manipulated. Punishing or shaming employees caught by a social engineering test creates an adversarial relationship between the security team and the rest of the organisation, undermines the safety culture that good security programs require, and does not address the underlying control gaps. Results should drive specific improvements: stronger help desk authentication procedures, hardware MFA implementation, physical access policy enforcement, and technology controls that limit the damage when a social engineering attack succeeds at the human layer.
Q5. Do employees need to be told about social engineering testing?
Organisation leadership and the authorising security executive must know and explicitly authorise the engagement. Whether individual employees are informed varies by engagement type and organisational philosophy. Covert testing (employees not told) produces the most realistic results because employees behave normally rather than on heightened alert. Announced testing (employees told that testing will occur during a window) reduces the realistic failure rate but can still identify control gaps while avoiding some of the ethical concerns around covert deception. The engagement design should specify which approach is appropriate for the organisation's context, and in either case, employees who are successfully manipulated during the test should be notified and debriefed promptly rather than being left believing a real security incident occurred.
Cloud security assessments cover IAM configuration, network controls, storage access, workload security, and logging. This guide maps what each domain tests and what findings look like.
Tejas Dhokane Aug 26, 2026 
Penetration testing without a complete rules of engagement document is a legal and operational risk for both sides. This guide covers every clause and what goes wrong when it is missing.
Tejas Dhokane Aug 26, 2026 
Third-party risk assessment programmes use penetration testing evidence in two ways: requiring it from vendors, and producing it for customers. This guide covers both roles and how to evaluate vendor pentest reports.
Tejas Dhokane Aug 26, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
