Social Engineering and Physical Penetration Testing Guide: Scoping, Safety and Reporting

Social engineering and physical penetration tests target people and buildings rather than code, so a badly run test can harm employees, break the law or put testers in a police cell, while a well run one exposes the processes attackers actually exploit. Recent intrusions such as the help desk calls behind the MGM Resorts and Co-op attacks show why boards want these processes tested. This guide is for the people who commission and own such tests: CISOs, security assurance leads, HR and legal partners, and facilities managers. It covers authorisation and legal limits, privacy under UK GDPR and EU GDPR, employee welfare, physical safety, scoping, AI voice and video scenarios, and reporting that fixes processes instead of blaming staff. It does not contain pretext scripts or bypass techniques, which belong with the qualified testers you engage.

Key takeaways

• Authorisation must come from whoever actually controls the target: the building owner, the landlord, the outsourced help desk provider and every supplier in scope, not just the person who signed the purchase order.
• Test processes, not people: a finding is "the reset process accepted unverified identity", never "Jane in the service desk failed".
• Privacy law applies to testing: collecting staff data, recording calls or filming premises is processing personal data and needs a lawful basis, a privacy assessment and a retention limit.
• Safety outranks realism: stop conditions, a reachable control contact and a way to prove authorisation instantly protect testers, staff and the public.
• Measure reporting, not just failure: the number and speed of staff reports tells you more about resilience than the number of people who were deceived.

What these tests cover and where they sit

Social engineering testing assesses whether processes and controls resist manipulation by email, phone, messaging, video or in person. Physical testing assesses whether controls on sites, rooms and equipment prevent unauthorised entry and access to devices or networks. Both are usually commissioned as part of a wider penetration test or red team exercise, so read this alongside the Penetration Testing Guide and the Red Teaming Guide.

All IDs are from ATT&CK v20. CISA's advisory on Scattered Spider (AA23-320A) describes help desk impersonation to reset passwords and MFA, SIM swapping and MFA fatigue, which makes these scenarios the priority for most organisations.

Authorisation and legal protection

Physical and social engineering testers do things that would be offences without permission: entering premises, deceiving staff, accessing systems. In September 2019 two Coalfire testers were arrested inside the Dallas County Courthouse in Iowa while testing for the State of Iowa; they were charged with felony burglary and held for about 24 hours before the charges were later dismissed. The case is widely cited as a warning about unclear authority over the target building.

• Authorisation letter: signed by someone with authority over each target, naming the testers, the sites and addresses, the dates and hours, the permitted activities, and two 24-hour emergency contacts who will answer and can confirm the engagement. Testers carry it at all times, with photo ID.
• Who must sign: confirm ownership and control of every site. Shared buildings, landlords, managed security guarding, co-location providers and outsourced help desks usually need their own written consent. If a third party cannot be told, take it out of scope.
• Contract terms: scope, rules of engagement, data handling, liability, insurance, confidentiality and destruction of collected data at the end. The Red Team Rules of Engagement Template gives a structure.
• Police and guarding: decide with legal counsel whether local police or the guarding contractor are told in advance. If not, the emergency contact process is what keeps a confrontation from escalating.
• Testers' standing: use qualified providers. For UK government bodies the NCSC recommends CHECK-scheme companies for penetration testing; see the Penetration Testing Provider Buyer's Guide.

Privacy and employee data: UK GDPR and EU GDPR limits

Testing collects personal data: staff names and roles, call recordings, CCTV or body camera footage, simulation click logs and sometimes credentials. Treat the test as a processing activity.

The ICO notes that its monitoring workers guidance is under review following the Data (Use and Access) Act, so confirm the current version with your data protection officer before each programme. See the GDPR Compliance Guide for Security Teams and the Privacy by Design Guide for Engineering Teams.

Ethics and employee welfare

The NCSC phishing guidance is blunt: no one can be expected to spot every phishing email, blaming users for clicking does not work, and simulations can erode trust so that staff stop reporting. It advises checking with HR before running simulations because they carry legal risk. Its cyber security culture principles put building safety, trust and processes that encourage openness at the centre. Apply the same thinking to every social engineering test.

• Exclude harmful lures: no pretexts about pay, bonuses, redundancy, health, bereavement, disciplinary action or emergencies involving family. They cause real distress and damage trust in genuine messages.
• Protect vulnerable situations: exclude staff on leave, under investigation or with known welfare concerns, as agreed confidentially with HR.
• No consequences for individuals: agree in writing that test results will not be used for performance management or discipline. Repeated failure points to training or process design.
• Debrief kindly: where staff were deceived in person or by phone, a short, supportive explanation soon after the test reduces embarrassment and teaches more than a report.
• Involve representatives: where there are unions or works councils, brief them on the programme (not the dates).
• Synthetic media consent: cloning an executive's voice or likeness for a test needs that person's explicit written agreement, secure handling of the model and recordings, and deletion afterwards.

See the Security Awareness and Human Risk Management Guide for how results feed training.

Safety and stop conditions for physical testing

• Risk assessment: a site-specific safety assessment covering working at height, restricted plant rooms, laboratories, data hall fire suppression, lone working and travel. Operational technology areas and building management systems usually need extra controls or exclusion; see the Building Management System Security Guide.
• No-go list: safety-critical areas, areas with armed or specialist security, patient or child care areas, and anything where an interrupted process could harm someone.
• Stop conditions: any challenge by police, any sign of distress in a member of staff or the public, any risk to safety, discovery of a real crime or a real intruder, or accidental impact on a live system. On a stop, testers identify themselves, show the letter and call the control contact.
• No force and no damage: agree in writing that testers will not cause damage, use force, or carry anything that could be mistaken for a weapon, and define how planted devices are tracked and recovered.
• Control team: a small group (sometimes called the white team or control team, as in TIBER-EU) who know the test is live, can stop it and can vouch for testers at any hour.

Scoping the engagement

The NCSC penetration testing guidance asks for a scoping document covering technical boundaries, test types, effort, timeframes, compliance obligations and reporting requirements, a technical point of contact available at short notice, and a decision by the risk owner when testers find something out of scope. For people and premises add these decisions.

1. Objectives: state the questions, for example "can a caller get an MFA reset for a privileged account without strong verification?" or "can an unescorted visitor reach the network room?".
2. Targets: processes and functions (service desk, reception, finance approvals, mailroom) rather than named individuals. If individuals must be targeted, record why and get HR and DPO sign-off.
3. Methods allowed and excluded: channels (email, phone, SMS, messaging apps, video, in person), whether real credentials may be captured or only the act of submission recorded, whether accounts may be logged into, and whether devices may be planted.
4. Reset safety: for help desk tests, use pre-agreed test accounts or require that any real reset is reported immediately and reversed under control team supervision.
5. Third parties: outsourced help desks, guarding contractors and landlords, with their written consent or exclusion.
6. Timing and duration: avoid peak operations, incidents in progress and sensitive dates.
7. Data handling: what is collected, where it is stored, who sees it and when it is deleted.
8. Rollback: how planted devices, test accounts, cloned voices and captured credentials are removed or reset at the end, with evidence.

See the Penetration Test Scoping Checklist.

Choosing the right exercise

Small organisations usually get more from a structured walk-through of their reset and visitor processes and a modest phishing programme than from a covert physical test. Large organisations with many sites and outsourced services need a rolling programme with a standing authorisation framework, a control team and annual legal review.

AI-enabled social engineering scenarios

The FBI warned in May 2025 that attackers had been sending text messages and AI-generated voice messages that impersonated senior US officials, and advised verifying identity through a separately known channel. The Arup deepfake fraud shows the same risk on a video call. Testing here should focus on whether processes require out-of-band verification for payments, access grants and resets, not on whether staff can detect synthetic media by ear or eye. Agree the consent and data handling points above before any voice or likeness is cloned. See the Deepfake and AI Impersonation Guide and the Vishing and Smishing Guide.

Where identity fits

The most damaging social engineering targets identity recovery. In the MGM Resorts breach, attackers claimed that a call to the IT help desk impersonating an employee led to Okta and Azure administrator access; MGM estimated an impact of about $100 million on adjusted property EBITDAR. In the Co-op cyber attack, reporting describes attackers posing as IT or help desk staff to get a password reset, and Co-op later confirmed that data on all 6.5 million members had been taken. The controls to test are verification strength for resets of privileged and executive accounts, phishing-resistant MFA (FIDO2/WebAuthn or PKI, as CISA recommends), and whether service accounts and admin consoles can be reached with a reset human credential. See the Account Recovery and Help Desk Security Guide and the Phishing-Resistant MFA Guide.

Reporting without blaming staff

• Write findings against controls: each finding names the process, the control that failed or was missing, the evidence, the risk rating and the fix. The NCSC asks for issues, risk ratings and remediation for each finding, using HIGH, MEDIUM, LOW or INFORMATIONAL.
• Anonymise by default: the main report uses roles or functions, not names. Keep any identifying evidence in a restricted annex with its own deletion date.
• Report positives: record who challenged, reported or refused, and how quickly the security team responded. These are the behaviours you want to reinforce.
• Separate detection findings: did reception, guarding, the SOC or the service desk escalate? Detection gaps go to the blue team, not to front-line staff.
• Track to closure: feed fixes into the risk register and retest, which is the NIST CSF 2.0 outcome ID.IM-02 (improvements identified from security tests and exercises).

Detection and measurement

During a live test, the control team should watch service desk ticket logs, identity provider reset and MFA registration events, physical access control system logs and visitor records, so that any real-world impact is caught and reversed quickly.

Common failure patterns

• Authorisation from the wrong person: a client contact without authority over the building or the outsourced service signs the letter, and testers face arrest or a contract dispute.
• Naming and shaming: results shared with line managers or used in appraisals, after which reporting rates fall and staff hide mistakes.
• Cruel lures: pay rise or redundancy pretexts that make headlines internally and undermine trust in real HR messages.
• Uncontrolled real resets: a successful help desk test leaves a real account reset, a real MFA device enrolled or a planted device unrecovered.
• Data hoarding: recordings and staff dossiers kept indefinitely on a tester's laptop, creating a privacy breach waiting to happen.
• Testing detection by people only: concluding "staff need more training" when the real fix is stronger verification or phishing-resistant MFA, as the help desk incidents above show.

Framework mapping

Practitioner checklist

• Confirm who owns and controls every site and outsourced service in scope, and get each signature.
• Issue an authorisation letter with named testers, sites, dates, activities and two 24-hour contacts who will answer.
• Complete a legitimate interests assessment and, where recording or covert observation is involved, a DPIA with the DPO.
• Agree with HR the excluded lures, excluded staff and a written no-discipline commitment.
• Complete a site safety assessment, a no-go list and stop conditions, and brief the control team.
• Use test accounts or controlled reversal for help desk scenarios, and track every planted device.
• Get explicit written consent before cloning any voice or likeness, and set a deletion date.
• Require reports written against processes and controls, with identifying evidence in a restricted annex.
• Measure report rates and response times alongside failures, and retest fixes.
• Delete recordings and collected personal data on report acceptance, with confirmation from the provider.

Standards and references

• NCSC: Penetration testing
• NCSC: Phishing attacks: defending your organisation
• NCSC: Cyber security culture principles
• ICO: Data protection and monitoring workers
• NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
• CISA and FBI: Scattered Spider advisory AA23-320A
• European Central Bank: TIBER-EU framework
• Infosecurity Magazine: Case dropped against Coalfire pen testers accused of burglary

Related NHI Mgmt Group resources: Red Teaming Guide · Penetration Testing Guide · Phishing Simulation Programme Guide · Account Recovery and Help Desk Security Guide · OSINT and Reconnaissance Guide