We use cookies to understand how the site is used and to improve your experience. Privacy policy

    Skip to main content

    Social Engineering Testing

    Authorised, scenario-based testing of how your people, processes and premises hold up against an attacker who never touches an exploit.

    Most intrusions start with a person: a convincing call to the service desk, an email from a supplier that looks right, a visitor who follows an employee through a door. Technical controls assume the human layer holds. Social engineering testing checks that assumption with the same preparation an attacker would invest, under written authorisation and strict rules of engagement, and reports what happened as a measured outcome, not as a verdict on individuals. You learn which pretexts work, which processes stop them, whether anyone reports them, and what to change.

    What is social engineering testing?

    Social engineering testing is a controlled, authorised attempt to obtain access, information or an action from your organisation by manipulating people rather than systems. It begins with an open-source intelligence (OSINT) phase to learn how your organisation presents itself, who works where, which suppliers and tools it uses and what a believable pretext looks like. It then runs agreed scenarios: telephone pretexting (vishing), including AI voice cloning of a known executive where in scope, targeted spear phishing, multi-factor authentication fatigue prompts, impersonation of IT or the helpdesk to obtain a password reset or a remote session, and physical scenarios such as tailgating, badge cloning or placing a rogue device. Every scenario has a defined objective, a stop condition and a named contact on your side who can halt it at any moment.

    Key Capabilities

    OSINT and Pretext Development

    Public footprint, staff and supplier mapping, leaked credentials, building and badge intelligence, and the pretexts an attacker would build from them (MITRE ATT&CK T1589 to T1598).

    Vishing and Deepfake Voice

    Telephone pretexting against staff, the service desk and finance, including authorised AI voice cloning of an executive to test payment and access approvals.

    Spear Phishing and MFA Fatigue

    Hand-built, targeted emails and messages to specific roles, credential harvesting with safe capture, and push-notification fatigue against MFA-protected accounts (T1566, T1621).

    Physical Intrusion

    Tailgating, lock and door-control weaknesses, badge cloning, after-hours access, unattended workstations and the placement of drop devices or rogue network implants (T1200).

    Helpdesk and IT Impersonation

    Password resets, MFA re-enrolment, remote-support sessions and account unlocks requested under a false identity, testing verification procedures end to end.

    Authorisation, Ethics and Reporting

    Written authorisation from an officer with authority, rules of engagement, data handling agreed in advance, and reporting at process level with no individual named without consent.

    Who needs social engineering testing?

    Organisations whose last phishing campaign scored well and want to know whether a determined, prepared attacker gets further; finance and treasury teams exposed to CEO fraud and invoice redirection; operators of physical sites with sensitive areas such as data centres, laboratories, hospitals and production plants; service desks that reset passwords and MFA for thousands of users; and entities under NIS2 or DORA that must demonstrate their people and processes are tested, not only their systems. If one phone call could move money or open a door, this is the test that shows whether it would.

    How a Social Engineering Test Works

    01

    Objectives, Legal Basis and Rules of Engagement

    We define what success means (a credential, a payment approval, a door), agree exclusions, obtain written authorisation and align with legal, HR and the works council where required.

    02

    OSINT and Scenario Design

    Open-source reconnaissance maps people, processes, suppliers and premises; scenarios are written, risk-assessed and approved by your named contact before any contact is made.

    03

    Remote Scenarios

    Vishing, spear phishing, MFA fatigue and helpdesk impersonation are executed against the agreed targets, with every interaction logged and a stop condition in place.

    04

    On-Site Scenarios

    Where in scope, testers attempt physical entry, badge cloning and device placement, carrying a letter of authorisation and an escalation number for your security staff.

    05

    Detection and Response Check

    We record who reported what, how soon, and whether your processes (verification, escalation, incident response) triggered as designed.

    06

    Report, Debrief and Awareness Follow-Up

    Measured outcomes per scenario, root causes at process level, prioritised fixes, a debrief with leadership and material for your awareness programme.

    How We Work

    Scenario design and execution by experienced testers, led by Michael van Mameren, under written authorisation and rules of engagement agreed with your security, legal and HR leads. Under Dutch law, unauthorised access to systems is a criminal offence (computervredebreuk, Article 138ab of the Dutch Criminal Code) and unauthorised entry into business premises is likewise punishable, so the authorisation letter, the named contact and the stop conditions are not formalities but the legal basis of the test. We handle any captured credential or personal data under a pre-agreed protocol, never use real malware, and report at the level of process and control. Individuals are not named in the report; the goal is a stronger organisation, not a disciplinary file.

    What you receive

    Written scope, rules of engagement and an authorisation letter for signature
    OSINT report: what an attacker can learn about your organisation and people from public sources
    Scenario-by-scenario outcomes: objective, approach, result, detection and response timing
    Root causes at process and control level with prioritised remediation
    Debrief for leadership and anonymised material for your awareness programme
    Retest of selected scenarios after remediation, with a dated verification appendix

    Social Engineering Testing FAQ

    The questions security, HR and legal leaders ask us before authorising a social engineering engagement, answered straight.

    What is social engineering testing?

    Social engineering testing is an authorised simulation of attacks that target people and processes rather than software: phone pretexting, targeted phishing, MFA fatigue, impersonation of IT or suppliers, and physical entry attempts. It follows an OSINT phase, runs agreed scenarios against defined objectives, and reports measured outcomes at process level. It answers the question a phishing click rate cannot: whether a prepared attacker would actually get in.

    How is this different from a phishing simulation?

    A phishing simulation sends a templated campaign to a broad group and measures click and report rates over time; it is a training and measurement instrument and we offer it as a separate service. Social engineering testing is targeted and multi-channel: a handful of carefully built scenarios against specific roles, by phone, email, message and in person, with a concrete objective such as a password reset or a payment approval. One measures awareness across the workforce; the other tests whether your processes stop a determined attacker.

    How does it differ from red teaming?

    Red teaming is an objective-driven simulation of a full attack chain, in which social engineering is one possible entry vector alongside technical exploitation, and the goal is to test detection and response end to end. Social engineering testing isolates the human and process layer so it can be examined in depth and reported on its own. Many clients run it standalone first and include the successful scenarios in a later red team engagement.

    Is social engineering testing legal in the Netherlands?

    Yes, with written authorisation. Unauthorised access to a computer system is a criminal offence under Article 138ab of the Dutch Criminal Code (computervredebreuk), and unauthorised entry into premises is punishable as well, so the test must be commissioned in writing by someone with authority to consent on behalf of the organisation. Processing of personal data during the test needs a legal basis under the GDPR, usually legitimate interest with a documented assessment, and where the test could be regarded as monitoring employees the works council may have a say under the Dutch Works Councils Act. We prepare this paperwork with you before testing starts.

    Will employees who fall for a scenario be named?

    No. Reports describe scenarios, outcomes and the process or control that failed, not the individual who was deceived. Where a client wants to follow up with a specific team, we do so in a debrief framed as learning, never as discipline. A blame culture reduces reporting, and reporting is the control that catches real attacks; we design the engagement to strengthen it.

    Do you use deepfakes and AI voice cloning?

    Where it is in scope and explicitly authorised, yes. Executive voice cloning is now a realistic fraud technique and we test whether a cloned voice combined with a plausible pretext can obtain a payment approval or an access change. The cloned individual consents in writing, the recordings are destroyed after the engagement, and the scenario is designed to test the verification process, not to embarrass anyone.

    How much does a social engineering test cost?

    Every engagement is quoted on scope; there is no fixed price list. The drivers are the number and type of scenarios, whether on-site work and travel are involved, the depth of the OSINT phase, the number of target roles and locations, and whether a retest and awareness debrief are included. After a scoping call you receive a written proposal within a few working days with the day count and the named lead tester.

    Ready to test the human layer?

    Realistic scenarios, written authorisation, measured outcomes and a report that improves processes rather than assigning blame.