Social engineering assessment: testing how people and processes respond
A social engineering assessment is an authorized test in which trained testers attempt to manipulate staff through phishing, vishing (voice phishing) or physical pretexting, so you can measure how people and processes respond when someone tries to deceive them. If a framework, a customer security review, an insurer or a due diligence request has asked for social engineering testing, the question to answer first is which human pathways matter most to your business, because the test is only useful when it targets those pathways. The risks it addresses are concrete: disclosure of credentials or multi-factor reset codes, help desk staff being persuaded to change access for an impostor, fraudulent payment or bank detail changes made by a convincing email or call, and unescorted access to offices, data centers or server rooms. The assessment is commissioned because these failures bypass technical controls entirely. A technical penetration test asks whether a system can be exploited. A social engineering assessment asks whether a person will hand over access that the system would otherwise protect.
The method has a solid basis. NIST SP 800-115 describes covert testing, carried out without the IT staff's knowledge but with upper management's permission, as a way to test technical controls, the staff's response to perceived incidents and policy knowledge. The same publication lists social engineering, such as posing as a help desk agent to request a password, among its target vulnerability validation techniques. That covert design is why written authorization matters: a named executive sponsor must approve the pretexts, the populations in scope, the stopping conditions and who inside the organization knows the test is running. Before commissioning, confirm with your sponsor and legal team which individuals are excluded, whether any third-party platforms or providers must be notified, and what happens if a tester reaches a sensitive record or a payment instruction. Also confirm your own hosting provider's rules, since cloud platforms can require advance notice of phishing simulations against hosted assets.
Ask any provider how they will protect the people involved. Good practice keeps individual results out of the final report, reports on patterns by team, process and control, and deletes captured data on an agreed schedule. Ask how the provider handles credentials or personal data that testers might encounter, whether they record calls and where those recordings are stored, and who can see raw results. The output should show which controls held, which failed, and which process steps (such as callback verification or dual approval for bank detail changes) need redesign, with training treated as one remedy among several. Finally, plan the follow-up now: the findings should feed a remediation plan and a retest, so the assessment becomes evidence of improvement rather than a single snapshot.
What a social engineering assessment can include
A social engineering assessment is shaped by a small set of choices: which channels are tested, which people and accounts are in play, and where the test stops. Each card below covers one of those choices and the checks a buyer should make before approving scope.
Email phishing campaigns
Simulated phishing emails test whether staff recognize lures, report suspicious messages and avoid entering credentials or opening attachments. Scope should name the mail platform, the sending domain and the lure themes, such as payroll, invoices or password resets. Confirm whether the campaign runs against your own mail tenant or a hosted service, because hosting providers set their own notice rules.
Voice and SMS pretexting
Vishing calls and smishing texts test help desk and service processes, such as identity verification before a password reset or an account change. The assessment should define which help desk lines, mobile numbers and call scripts are in scope, and what the tester may request. Agree in advance how a call ends if a staff member disputes the caller's identity.
Physical pretexting and tailgating
On-site tests check whether badge controls, visitor logs and reception procedures hold up when someone asks for entry or follows an employee through a door. Buyers should define which sites, floors and hours are covered, whether the tester may carry or present false credentials, and what counts as a stopping point. Confirm the facilities team and building management know the test is happening, and who handles any police or security call.
Population and role exclusions
Decide which groups are targeted, such as all staff, a business unit, executives or contractors, and which are excluded, such as employees in active HR cases, staff on leave or people in safety-critical roles. Exclusions should be written into the rules of engagement and checked against the target list before launch. Ask the provider how they handle a target who is identified outside the agreed population.
Accounts and systems that may be targeted
Specify which accounts, mailboxes, applications and data the tester may attempt to reach through a social engineering route, and which are off limits, such as executive mailboxes or payroll systems. Each target system should map to an owner who approves the test in writing. NIST SP 800-115 describes covert testing with management permission that stops at defined boundaries, such as a set level of access, and those boundaries belong in this list.
Cloud provider notice requirements
Simulated phishing against cloud-hosted assets can require advance notice to the provider. AWS requires a simulated events request at least 2 weeks in advance for simulated phishing campaigns against AWS-hosted assets, and Microsoft's rules of engagement prohibit phishing or social engineering of Microsoft employees. Check each provider's current rules before setting dates, and confirm that the lure infrastructure and sending domains do not breach them.
How the engagement runs, phase by phase
The sequence moves from written authorization to a report that improves controls and staff response without naming individuals. Each phase closes with a documented output that the sponsor approves before the next phase begins.
Agree scope, consent and emergency stop
The provider and a named executive sponsor agree the objectives, the target population, the channels in scope (email, phone, in person), and the systems and sites that are off limits. The sponsor signs an authorization letter that states who is permitted to run the test, which staff functions are covered, and how the test can be halted. An emergency stop contact is named, with a documented way to reach them at any hour. The step closes when the signed letter and the rules of engagement are on file with both parties. NIST SP 800-115 describes covert testing as performed without the IT staff's knowledge but with upper management's permission, and this agreement is what makes that permission explicit.
Research targets and build pretexts
Testers gather publicly available information about the organization, such as job titles, public-facing processes, supplier relationships and external communications, to design believable pretexts. The sponsor reviews the pretext categories before use, and the provider excludes anything that would touch personal data beyond what the objective requires, such as home addresses, family details or personal social media accounts. Pretexts that impersonate regulators, emergency services or specific named individuals are usually excluded unless the sponsor approves them in writing. The step closes with an approved pretext register that lists each scenario, its channel, and the controls it is meant to exercise.
Fix the testing window and control team
The sponsor and provider set the start and end of the active window, and a small control team inside the client knows the test is running. The control team holds the authority to pause activity and to confirm whether a given contact is an exercise. Where the test touches cloud-hosted email, telephony or other provider services, the provider's published testing rules apply, and some providers require advance notice of simulated campaigns. Ask the provider to confirm which notice periods apply to your hosting and communications platforms. The step closes with a window schedule and a control team roster confirmed in writing.
Run contacts within agreed limits
Testers execute the approved pretexts through the agreed channels and record each attempt in a log with timestamps, the function contacted, the outcome, and the controls observed. Activity stops at the defined boundaries, such as no collection of credentials beyond the stated proof point or no entry to restricted areas. Where a contact asks for something outside scope, testers end the contact and log it. The control team checks the log at intervals and can halt any pretext. The step closes when the window ends and the log is locked and countersigned by the provider and the control team.
Handle staff reports and live incidents
Staff who receive a suspicious contact are expected to report it through the normal channel, and the control team triages each report to decide whether it belongs to the exercise or to a real event. Reports that match an exercise are acknowledged with a neutral message, and the reporting staff member is thanked without being told the outcome of their colleagues. Reports that look genuine trigger the client's incident process, and the exercise pauses for that pretext. The step closes with a triage record for every report, showing whether it was an exercise contact, a genuine event, or a missed report that the team must review.
Debrief and protect individual data
After the window closes, the provider and control team hold a debrief to confirm facts in the log before any analysis is written. Individual names are removed from the working record, and results are aggregated by function, channel and control. The provider retains only the data needed for the report and deletes operational data on the schedule set in the authorization letter. The step closes with a confirmed fact base and a documented data handling record that the sponsor signs off.
Deliver the report and remediation plan
The provider writes a report that describes the objectives, the pretexts used by category, the controls that worked and those that failed, and the processes that slowed or stopped the response. Findings are tied to the controls they test and, where useful, to MITRE ATT&CK techniques so that detection engineers can act on them. The report includes recommendations ranked by effort and risk, and the sponsor agrees an owner and target date for each. The step closes when the sponsor accepts the report and the remediation plan, and the provider has confirmed what the report can and cannot be used to evidence for an auditor. Ask the provider to show a sample report before commissioning.
Weakness categories social engineering exposes
This table lists the weakness categories a social engineering assessment typically tests, what each looks like in a live organization, and why it matters. Read each row as a process to examine, not a person to judge, and use the right-hand column to decide which controls to validate first. The main takeaway is that most findings sit in process design, such as verification steps and escalation paths, rather than in individual judgment.
| Weakness category | What it looks like in this target | Why it matters |
|---|---|---|
| Help desk identity verification | Verification relies on details that are easy to find or obtain, or on a caller's stated urgency, rather than a fixed check against a trusted record. | Help desks can reset access for any caller, so a weak check can hand an outsider a legitimate account. |
| Credential or MFA reset requests | Requests to re-enroll a multi-factor device or reset a password can be approved without a second channel or a manager confirmation. | Resetting the second factor often defeats the protection MFA was meant to provide. |
| Payment and invoice change processes | Changes to supplier bank details or payment instructions can be accepted by email or phone without a call back to a number held on file. | Fraudulent payment redirection depends on this step, and losses can be hard to reverse once funds move. |
| Unverified callbacks | Staff return calls to numbers supplied in the request itself, or accept a callback number that the caller controls. | A callback that goes to the attacker defeats the verification it was meant to perform. |
| Badge and visitor controls | Tailgating through secured doors, visitors signed in without ID checks, or escorts who do not challenge unfamiliar people. | Physical access can expose workstations, network ports and paper records that bypass every digital control. |
| Reporting channels that are slow or unclear | Staff are unsure where to report a suspicious call or email, or reports sit in a mailbox with no triage owner or time target. | Late reporting lets an attack progress and gives the security team no chance to warn others. |
| Policy knowledge gaps | Staff know a rule exists but not how it applies to a specific request, such as whether urgency or seniority can override verification. | Policies that are not understood under pressure are not controls, and the gap usually shows up in the exact moment a request is convincing. |
How the assessment differs by channel and organization type
Email phishing is the most common channel because it reaches the most staff at the lowest operational cost. The assessment measures whether recipients open suspicious messages, follow links, enter credentials on a look-alike page, or report the message to the security team. Results show how well mail filtering, user awareness and the reporting path work together, which is the question most buyers actually need answered. Consent is usually set at the level of senior management, with the mail platform owner and the security operations lead informed so that filtering and alerting can be observed without tipping off the wider team.
- What is measured: click rates, credential submission, macro or attachment execution, and the speed and rate of user reporting.
- Consent and limits: written approval from an accountable executive, a defined list of target groups, and a rule that no real credentials are stored or reused.
- Safety constraints: landing pages must not capture passwords in plain text, and sending domains need to be registered and configured under the client's own control.
- Staff experience: staff receive an in-the-moment education page after a failed action, and no individual's name is shared outside the agreed reporting group.
- Platform checks: confirm with your mail provider whether simulated phishing must be pre-registered or whitelisted, and whether that notification is compatible with your mail security tooling.
Before approving a campaign, check how results will be reported and whether the data handling terms prevent individual results from reaching line managers.
Voice-based pretexting tests whether help desk and call-handling staff verify caller identity before resetting access, changing contact details or disclosing account information. It differs from email because the interaction is live, unscripted and emotionally pressured, so the assessment focuses on verification procedures and escalation paths rather than on a single click. The output is usually a set of observed decision points and the gaps in the procedure that allowed a request to proceed, which makes it especially useful for teams that run identity recovery workflows.
- What is measured: whether callers are challenged, which verification steps are skipped under pressure, and whether requests reach the correct approval queue.
- Consent and limits: agreed pretext categories, prohibited topics such as personal or medical information, and a hard stop if a caller becomes distressed.
- Safety constraints: tests should avoid recording personal data beyond what is needed for the report, and any call numbers used must be disclosed to the client in advance.
- Staff experience: frontline staff may feel tested personally, so debriefs should focus on process design and the support available to them.
- Telephony checks: confirm with your carrier and telephony provider whether outbound test calls require notification, and whether caller ID spoofing is permitted under local law.
Ask how the team will separate the observed procedural failure from any individual conduct in the final report.
Physical pretexting tests whether staff and processes stop an unauthorized person from entering a site, moving between zones or reaching equipment, using a believable reason to be there. It draws on NIST SP 800-115's inclusion of social engineering among validation techniques and on the facility penetration testing enhancement in SP 800-53 control CA-8, which the high baseline selects. Because people are physically present and the stakes include personal safety, this channel carries the strictest constraints and the most careful planning around emergency procedures.
- What is measured: badge challenge behavior, tailgating response, visitor logging, and whether sensitive areas such as server rooms are escorted.
- Consent and limits: signed authorization letters carried on the tester's person, named emergency contacts, and a defined list of permitted areas and times.
- Safety constraints: no entry into restricted zones that could trigger a life-safety response, no impersonation of police or emergency services, and no tests in occupied hazardous areas.
- Staff experience: receptionists and security guards may face real confrontation, so the team should know in advance that a test is in progress and how to escalate.
- Premises checks: confirm with landlords, building management and any shared tenants whether a test is permitted, since they may have their own rules.
Within the report, ask whether photographs or other evidence are retained and for how long, and who can access them.
Hybrid assessments combine a remote lure, such as a phone call or message, with an onsite step that relies on the information or trust gained. They are closer to how a determined adversary operates, because the remote contact is often used to prepare a physical approach. This design tests whether information leaks from one channel are recognized and whether teams across remote and physical controls share intelligence internally. The additional complexity means the scope, consent and stop conditions must cover both channels and the handover between them.
- What is measured: whether knowledge gained remotely is used onsite, whether onsite staff verify identity with the remote help desk, and whether the two response paths coordinate.
- Consent and limits: a single authorization that names every channel, plus a rule that any step can be halted by the client at any time.
- Safety constraints: the combined scenario needs a documented decision point where the tester withdraws if the situation escalates.
- Staff experience: staff may be tested twice in one engagement, so debriefs should explain how the two phases connected.
- Governance checks: confirm whether the control team will hold the full scenario record and whether it can pause the test without notice to the operational staff.
For a hybrid test, ask the provider to show how the stop and withdrawal rules work end to end before the test begins.
For banks, payment firms and other regulated entities in the EU, the Digital Operational Resilience Act (DORA) defines threat-led penetration testing (TLPT) as an intelligence-led red team test of critical live production systems, under Regulation (EU) 2022/2554, Article 3(17). Social engineering can be part of that testing, but it is a component of threat-led testing, not a substitute for it. Delegated Regulation (EU) 2025/1190 sets scenario, duration and tester requirements, so a phishing campaign alone does not meet TLPT obligations. Firms in other jurisdictions should check their supervisor's frameworks, such as TIBER-EU and CBEST, for how social engineering fits.
- Scope of the rule: TLPT applies to critical live production systems, so social engineering scenarios should be designed to reach them.
- Scenario count: the delegated regulation requires at least three TLPT scenarios, of which at most one may be non-threat-led.
- Testing period: active red team testing must run for at least 12 weeks with at least weekly progress reports.
- Tester expertise: the delegated regulation requires a red team manager with at least five years' experience and at least two testers with two years each.
- Supervisor alignment: confirm with your competent authority whether a social engineering module will count toward a TLPT requirement.
Before commissioning a channel test in a regulated firm, ask how it maps to the threat-led scenario set and who signs off on that mapping.
What drives the cost and duration of a social engineering assessment
This table lists each component that shapes the price and timeline of a phishing, vishing or pretexting assessment, who does that work, and whether it is paid once or recurs. Read it as a checklist for a written quote: the rows that expand fastest are the ones to tighten first in scoping.
| Cost component | Who does the work | Sizing driver and how to keep it down |
|---|---|---|
| Target populations | DeployOpen testers, with client HR and business owners approving the groups | Each separate group (for example, help desk, finance, executives) needs its own pretext and reporting cut. Keep to the groups that carry real access risk. |
| Channels (email, voice, in person) | Testers build and run each channel; client confirms which channels are permitted | Phishing, vishing and physical pretexting have different setup and safety controls. Adding a channel adds work even when the scenario is shared. |
| Physical sites | Testers scout and plan; client confirms site access and legal permissions | Each site adds travel, reconnaissance and local approval steps. Start with one site that represents the wider estate. |
| Pretext development | Testers design a believable scenario tied to the client's business | Bespoke pretexts for each population cost more than reusing a tested template. Ask whether scenarios will be reused across channels. |
| Research depth (open-source intelligence) | Testers gather publicly available information within agreed limits | Deeper research increases effort and privacy exposure. Agree the sources allowed and a cap on what is collected. |
| Number of scenarios | Testers build, run and log each scenario | Each additional scenario adds setup and analysis. Fewer, well-chosen scenarios often answer the control question more clearly. |
| Reporting depth | Testers write findings; client reviews against its own controls | Aggregate reporting by population is lighter than per-channel root-cause analysis. Ask what the report must answer for the auditor or board. |
| Retest and awareness follow-up (recurring) | Testers repeat selected scenarios; client or DeployOpen runs training | Retests and training are separate, optional items with their own timing. Request them as priced options so the base quote stays clear. |
| Data handling and cleanup | Testers handle captured data; client confirms retention rules | Strict retention, redaction and deletion steps add work but reduce risk. Confirm them in writing before the first send. |
Which frameworks expect social engineering testing
No single framework lists social engineering as a mandatory test for every organization, but several of them place it inside the penetration testing and threat-led work they do require. NIST SP 800-115, the technical guide to security testing and assessment, lists social engineering, such as posing as a help desk agent to request passwords, among the techniques used to validate target vulnerabilities. The PCI SSC *Penetration Testing Guidance* (v1.1, September 2017) treats social engineering as a component of penetration testing rather than a separate exercise. If your assessor works from either document, ask them in writing whether they expect a social engineering component, which people and channels it should cover, and whether it must sit inside the penetration test or can be a separate engagement. Threat-led frameworks go further, because they test people and processes as part of a realistic attack scenario. TIBER-EU and CBEST both build tests from threat intelligence about the adversaries that target the institution, and the scenarios can include manipulation of staff alongside technical attack paths. Under DORA, threat-led penetration testing (TLPT) for financial entities must use at least three scenarios, of which at most one may be non-threat-led, so a social engineering element is often one of several scenarios rather than a stand-alone test. Confirm with your supervisor or assessor which scenarios they will accept and whether they expect a people-focused scenario in the plan. General control frameworks are less specific. NIST SP 800-53 Rev. 5 control CA-8 (Penetration Testing) covers penetration testing in general, including independent teams, red team exercises and facility testing, and the high baseline in SP 800-53B selects it. CIS Controls v8.1 Safeguard 18.4 asks you to validate security measures after each penetration test and to adjust rulesets and capabilities where the test techniques went undetected. For social engineering, that means a finding about a failed help desk verification should lead to a control change and a re-test, not only a report. Ask your assessor to map each requirement to the test activity that satisfies it, so the evidence serves both the auditor and the remediation plan.
What you receive and whether it satisfies your auditor or customer
A social engineering report is built to be read by two audiences: the internal team that improves controls, and the auditor or customer who needs evidence that testing happened under agreed rules. The cards below explain each report component, how individuals are protected, and how follow-up work is measured.
Scope and consent record
The report opens with the written authorization, the named sponsor, the pretexts and channels approved, the populations included, and the limits that were agreed before testing began. Auditors check this section first because it shows the test was authorized and bounded. Confirm the record names who approved phishing, calls and any physical attempts, and when those approvals were signed.
Method summary and channels
This section describes each channel tested, such as email, telephone and on-site pretexting, along with the approach taken and the stop conditions that applied. It explains the social engineering method at the level a buyer needs without reproducing scripts or lures. Ask for a summary that maps each channel to the control objective it was meant to test.
Aggregate results by population
Results are reported as counts and rates for each department, site or role group, with small groups merged so that no one can be identified. This view shows where awareness or process gaps cluster, which is what a customer's security review usually asks for. Confirm the minimum group size used for aggregation before you accept the report.
Response timeline and escalation performance
The timeline records when each simulated attempt was sent or made, when it was reported, and how quickly the internal team escalated it. It separates detection by staff from detection by monitoring, which tells the team whether reporting paths work. Ask whether timestamps are shown for the control team's responses, since these are needed to judge escalation performance.
Anonymized findings and remediation priorities
Findings are written as control weaknesses, such as an unverified password reset request or a missing callback procedure, with no names attached. Each finding is ranked and linked to a remediation owner, so the output becomes a backlog for process and training teams. Check that the remediation plan states owners and target dates for each priority item.
Retest and awareness follow-up
A retest repeats the relevant scenarios after controls change, so the team can show whether the weakness is closed. Awareness follow-up can include targeted training or a later campaign for affected groups, which should be scoped and priced separately from the original test. Ask whether retests use the same scenario set for comparability, and how the results will appear in the next report.
How consent, personal data and staff welfare are protected
Every social engineering test starts with written authorization from senior management, and that authorization is the first thing a buyer should check. The document should name a sponsor who owns the test, an escalation contact who can stop it at any hour, and the exact channels, pretexts and locations in scope. NIST SP 800-115 describes covert testing as work done without the IT staff's knowledge but with upper management's permission, and that split is the model to follow: a small group knows the test is running, and the people being tested do not. Ask the provider to show how the sponsor's authority is recorded, who can change the scope in writing, and how a request to pause is carried out. Confirm also that a defined emergency stop exists, so that a test can be halted immediately if a participant reports distress, a live operational incident is in progress, or a pretext starts to touch a real third party. Data handling deserves the same precision as scope. A well-run engagement does not store real credentials, and any credential entered during a vishing or phishing exercise should be discarded without being logged or reused. Personal data captured during the test, such as names, phone numbers, recordings or screenshots, should be limited to what the findings require and deleted on a schedule agreed in advance. Reporting should use role or team level metrics rather than named individuals. Ask the provider to describe its evidence retention, encryption and access controls in writing. Because the test will process personal data about employees, the applicable data protection law in each jurisdiction where staff are contacted applies, including its rules on lawful basis, notice and retention. Confirm retention periods and any employee notice obligations with counsel before the work begins. Staff who are targeted need a plan too. Debriefs should be designed as learning sessions: individuals who fell for a pretext receive an explanation of what the attacker did and what the control should have caught, not a score or a disciplinary referral. The agreement should state that the exercise is not a basis for performance or disciplinary action, and that the organization will measure controls and processes rather than people. Identify, in advance, an internal contact who can answer questions from affected staff and a source of support if someone feels embarrassed or upset. Those decisions shape how much staff will trust the next exercise, and they determine whether the results lead to better processes or to quiet resentment.
What your team prepares before testing starts
This sequence gives the testing provider the authority, boundaries and contacts it needs to run a social engineering assessment safely, and gives your leadership a clear record of what was agreed before any message is sent or any call is made.
Confirm sponsor and written authorization
Your executive sponsor, typically someone with authority over the affected functions, signs an authorization letter that names the provider, the test types (phishing, vishing, physical pretexting or a combination), the testing window and the people who may approve changes to scope. Senior management permission is the baseline for covert work, as NIST SP 800-115 describes, so the letter should be signed before any planning begins. The step is done when the signed letter is on file with both parties and the sponsor's contact details are confirmed.
Build the in-scope population and exclusion list
Your team supplies a clean list of target groups, such as specific departments, roles or sites, and an explicit exclusion list covering executives, staff in regulated functions, employee representatives, or anyone whose participation would create unacceptable risk. Ask the provider to confirm which scope limits will apply to data collection, such as not capturing credentials or personal details. The list is complete when the provider reviews it and both parties sign off on the final population and exclusions.
Name incident handling and escalation contacts
Identify a small number of people who can recognize the test and stop it quickly, usually a security operations lead, a help desk manager and a legal or HR contact. Each contact receives a secure channel to the provider's test lead and a documented way to halt activity. The provider should explain how it will avoid the test being mistaken for a live attack by your security operations centre. The step is done when every contact has confirmed they can be reached during the window and knows how to call a stop.
Agree the cover story and its limits
If pretexting is in scope, your team and the provider agree on the cover stories the testers may use, the approved impersonations, and the topics that are off limits, such as payroll, health or disciplinary matters. Legal and HR review the scenarios against your employment and privacy obligations. Anything that would require real credentials, real payments or real personal data is removed. The step closes when the approved scenario library is written down and signed by the sponsor.
Set the change calendar and freeze windows
Your change manager shares planned releases, mail system maintenance, payroll runs, month-end close and other freeze periods so that the test does not coincide with activity that would make results misleading or create operational risk. Confirm whether a suspicious-email campaign would collide with a known security awareness campaign. The output is a dated test window and a list of blocked periods held by both the change manager and the provider.
Notify cloud providers where hosted assets are touched
If a phishing lure links to, or a pretext relies on, infrastructure hosted with a cloud provider, check that provider's penetration testing policy before scheduling. AWS, for example, requires a simulated events request at least two weeks in advance for simulated phishing campaigns against AWS-hosted assets, and Microsoft's rules of engagement prohibit phishing or social engineering of Microsoft employees. Your team confirms the requirement for each provider involved and the provider records the notification. The step is complete when each required notice is filed and the reference is stored with the authorization letter.
Agree how and to whom reports are delivered
Before testing begins, your sponsor and the provider decide who receives interim updates, the final summary report and any individual-level data, and how each is stored and deleted. Most organizations route aggregate results to leadership and control owners, and keep named results restricted to the smallest group needed for remediation. Agree the report format, the retention period set by your own policy, and whether the report will serve an auditor or a regulator. The step closes when a written reporting and data handling agreement is signed, which becomes the reference for the rest of the engagement.
What to check when choosing a provider for social engineering testing
A social engineering test puts staff, help desks and processes under real pressure, so the provider's judgment matters as much as its tooling. The cards below cover the team, the rules that protect people, the paperwork you receive and how changes are handled. Use them to compare proposals before you sign.
Team experience in social engineering
Ask who will run the pretexting calls, phishing lures and any on-site attempts, and how many years each person has done this work in environments like yours. Ask how the provider builds its threat intelligence for the pretexts, so that the scenarios reflect the actors you actually face. Request a description of the pretexts they have used, without client names, to judge creativity and restraint.
Threat-led testing background
If your organization is in scope for threat-led frameworks, the provider should show it can work within them. Under DORA, TLPT testers must have specific expertise in threat intelligence, penetration testing and red team testing. Ask how social engineering fits into a wider intelligence-led plan and who holds the threat intelligence role.
Consent and safeguarding practice
Ask how written authorization is obtained, who signs it and how the provider confirms the test is still permitted during execution. Ask what happens if a target is distressed, if a pretext touches a vulnerable person, or if a call reaches an emergency or medical line. The provider should have a stop procedure that your named contact can invoke at any time.
Data handling terms
Captured credentials, recordings, screenshots and personal data should be minimized, encrypted and deleted on a fixed schedule. Confirm where material is stored, who can access it, whether it leaves your jurisdiction, and how it is destroyed at closure. The contract should name these terms rather than refer to a general confidentiality clause.
Reporting samples and metrics
Request a redacted sample report before you commit. It should show how results are grouped by process and control rather than by named employee, and how it turns findings into remediation actions. Check whether the report includes the evidence your auditor or customer will ask for, and whether the provider can produce a debrief for your awareness team.
Accreditation and references
CREST is a not-for-profit company registered in the UK that accredits and certifies across disciplines, including security testing and red teaming. Check whether the firm and the individual testers hold current CREST credentials, and confirm the scope of each credential. Ask for references only where the client permits, and treat accreditation as a baseline rather than proof of quality for social engineering work.
Handling scope changes
Scope often shifts once a test begins, for example when a new system or site is added. Ask how changes are requested, approved in writing and reflected in the schedule and fee. Confirm that no new target, such as a third-party supplier or a cloud-hosted service, is contacted until the change is signed off.
Social engineering assessment questions buyers ask
Can we run a social engineering assessment in-house?
Yes, many organizations run phishing simulations with their own staff, but the harder parts are scoping, consent and reporting. An in-house team sees its own colleagues, so it may struggle to keep results away from individual performance reviews and to decide where the test should stop. Confirm who approves the test, who holds the raw results, and who can act on them. An outside team brings separation from internal politics and a documented method. Internal teams keep ownership of follow-up training and control changes, which is where most of the lasting value sits. Many buyers split the work: an external team designs and runs the pretexting, and internal staff handle the response and remediation.
What does a social engineering assessment cost, and what drives the price?
The price follows from the written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of channels tested (email, voice, in person), the number of target groups, the pretexts and research needed, whether the test includes physical entry to sites, and how much reporting and debrief work is required. Ask each provider to itemize these components: planning and rules of engagement, reconnaissance, campaign execution, data handling, reporting, and any retest. Expect one-time delivery costs for the first exercise. Recurring costs appear only if you buy repeat testing or a retainer. Ask whether the quote includes a control-focused debrief for leaders and technical teams, because that work is often where value is lost when it is left out.
How long does a social engineering assessment take, and what does it need from staff?
Duration depends on scope, the number of channels, and how long the pretexts need to run before a meaningful result. Planning includes agreeing rules of engagement, a named contact, an escalation path and a clear stop condition. Your staff need to be told only what is necessary: typically a small group of executives, the security operations lead and the people who will handle any incident triggered by the test. Help desk and front-line teams are often kept unaware so their responses are measured. Confirm with your provider how they will coordinate with your monitoring team and whether your email, telephony or physical security vendors need notice. If the test touches a cloud provider's systems, check that provider's testing rules and notice periods before scheduling.
Is a phishing simulation platform enough on its own?
A phishing platform measures click rates and report rates for one channel, which is useful but narrow. A social engineering assessment tests how people and processes respond to a live, adaptive approach across channels, including help desk password resets, vendor impersonation, voice pretexting and physical access. Platforms can run the campaigns, but they do not judge whether your identity verification, callback procedures or escalation paths would stop a determined attacker. Ask whether the provider will test those processes, not only the inbox. Good assessments also feed results into detection work, so the security team can confirm which emails, calls or logins were logged and alerted.
How do you protect individual staff from blame?
Start with the purpose: the assessment exists to find weak controls and process gaps, not to rank people. Agree in writing that results are reported in aggregate by team or control, that individual names are withheld from management and HR, and that no disciplinary action follows from a test outcome alone. Limit who can see raw data and define retention and deletion dates. Ask the provider how it handles personal data gathered during reconnaissance, such as social media research, and whether it minimizes collection. Give staff a clear, quick way to report suspicious contact, and recognize reports as good behavior. Debrief teams with the lessons, not the names. This approach also tends to keep staff cooperative in future exercises.
Does a social engineering assessment satisfy an auditor?
It can provide evidence for an assessment, but it does not replace an audit. Auditors and certification bodies decide whether a control is met, and DeployOpen prepares systems, controls and evidence for those assessments without issuing audit reports or certifications. Frameworks that include penetration testing expect testing to be authorized, scoped and reported. NIST SP 800-53 Rev. 5 control CA-8 covers penetration testing, and its enhancements mention red team exercises. For regulated financial entities, DORA's threat-led penetration testing requirements apply to a defined set of entities and carry specific tester and duration rules. Ask your auditor which evidence they expect before you commission the work, including the rules of engagement, the approval record and the remediation tracking.
How often should we repeat a social engineering assessment?
Repeat frequency depends on your risk profile, the rate of change in staffing and tooling, your regulatory obligations and the results of the last exercise. Most organizations repeat after remediation to confirm that changes worked, and after major changes to help desk procedures, identity systems or email platforms. Regulated entities may face their own cadence requirements, so confirm them with the regulator or your compliance lead. Plan the retest into the original scope so you know what will be measured again and how results will be compared. Retainers can cover recurring testing, but ask how the provider will avoid testing the same scenario so often that staff learn the test rather than the lesson.
How DeployOpen scopes, tests, reports and retests
DeployOpen agrees the scope of a social engineering assessment in writing before any test begins. The written scope names the channels in play (email, telephone, or on-site pretexting), the target groups or roles, the pretexts that are permitted, the systems and data that are off limits, and the stop conditions that end a test early, such as a request for credentials that cannot be validated or any sign of real-world harm. Consent is built into this step rather than added at the end. The sponsor, usually an executive with authority over the business areas involved, approves the scope, and the people who will run the engagement confirm their authority to act. Where a provider or a cloud host restricts social engineering against its own staff or hosted assets, the scope records those limits and the advance notice each one requires. Quotes follow from this written scope, so the reader should expect fees to move with the number of channels, sites, and target groups rather than with any fixed package.
Testing follows the planning and reporting approach of NIST SP 800-115, which lists social engineering among target vulnerability validation techniques and describes covert testing as work done without IT staff knowledge but with management's permission, usually bounded by defined limits. DeployOpen treats the sponsor's decision on what counts as a successful pretext as part of planning, and it records personal data handling rules before the first call or message is sent: what is captured, where it is stored, who can access it, and when it is deleted. Reports are written to serve two readers. The sponsor receives findings organized by process and control, such as help desk identity verification, callback procedures, and reporting paths for suspicious requests, with individuals anonymized unless the sponsor and the affected staff have agreed otherwise. Auditors and customers receive evidence of what was tested and how it was measured. DeployOpen prepares that evidence for assessments but does not issue audit reports or certifications; independent auditors and certification bodies do. Retesting checks whether the remediated controls hold, and ongoing testing can be placed under a retainer.
