Team taking part in a controlled social-engineering testing workshop and scenario debrief.

Social engineering

Social engineering tests

We assess how your business responds to controlled attempts to obtain data, money or access. We agree channels, scenarios and test boundaries, then review decisions, reporting and IT response. Findings guide improvements to controls and procedures, without blaming employees.

Trusted by

Companies and institutions that need stable IT.

  • AdAc
  • Baseline
  • BTW
  • Charlie
  • Dako
  • EVO
  • FTH
  • IFJ
  • MAEM
  • Banki Spółdzielcze BPS
  • PJG
  • Spinel Trade
  • Suder
  • Ziko Apteka
  • Aforti
  • Base Finance
  • CADM
  • Consol
  • Deka Trans
  • Ferro
  • GATE
  • Igoria Trade
  • Magnet Audit
  • Novacura
  • Przetargi
  • Streamsoft
  • VUMO
  • Audytplus
  • BKB Kancelaria Prawna
  • CBT
  • Contimax
  • ERBET
  • FOMACH
  • Geotermia Podhalańska
  • LATIS
  • Metgal
  • PIBR
  • Spontex
  • Super Krak
  • Wolimex

Assess decisions, not just clicks

A test is useful where a single request can trigger a payment, bank-account change, password reset, software installation or data disclosure. We tailor scope to your sector, processes and previous incidents, including remote and hybrid work and dealings with suppliers. Testing can cover selected roles, departments, sites or the whole organisation. We assess user behaviour alongside email controls, caller verification and the readiness of the helpdesk and security team.

Discuss a social engineering test

A facilitator and participants prepare scenarios, approvals and the debrief for a social engineering test during a controlled workshop.
Risk reduction Assess decisions, not just clicks

ISO 27001 · TÜV NORD Polska

Virtline's information security management system is certified by TÜV NORD Polska to PN-EN ISO/IEC 27001:2023-08. The published certificate states its scope and validity. The certificate covers Virtline's management system, not the compliance of the business being tested.

View Virtline's certificate

Discuss a social engineering test

How the test runs

We do not send messages or start calls before the rules are approved. Campaign timing and intensity reflect the way your business works.

01

Scope and approvals

With management or an authorised owner, we agree objectives, channels, groups, scenarios, exclusions, data handling and communication. We name an emergency contact and define when to stop or escalate the test.

02

Preparation

We review public information about the business within agreed privacy boundaries. We prepare scenarios, controlled landing pages and event measurement without collecting real passwords. We also agree what happens after a successful test interaction.

03

Controlled campaign

We carry out approved messages and calls, observing user, control and IT responses and checking how reports are routed. Unexpected effects on business operations are handled under the agreed stop and escalation rules.

04

Debrief and next steps

We deliver the report, discuss findings with management and IT, and prepare communication for teams without shaming individuals. We agree actions, responsibilities and how to compare results after improvements.

Discuss a social engineering test

Practical scope

What you receive

The report separates findings about people, controls and procedures. Results apply to the scenarios tested; they do not establish resistance to every form of fraud.

01 Management summary

Approved scope, authorisations, exclusions, campaign activity and key risks. We identify decisions for process owners and explain measurement limits instead of reducing the business assessment to a click rate.

02 Campaign results

Delivery, clicks, simulated credential-entry attempts, attachment handling, forwarded messages, reports and reporting time. Agreed breakdowns by role or group help identify recurring risks without publicly naming individuals.

03 IT response assessment

Security mailbox, reporting button, helpdesk, line managers and SOC. We describe report completeness, preserved material, assessment of suspicious activity, escalation time and feedback to users, alongside observations on filters, warnings and quarantine.

04 Improvement plan

Priorities for MFA, email, payment and supplier verification, access resets, incident reporting and crisis communication. We provide training topics, materials, checklists for high-risk roles and a repeat-test plan, separating urgent actions from longer-term work.

Discuss a social engineering test

Channels and scenarios

We select phishing emails, SMS messages (smishing), messaging apps, QR codes and phone calls (vishing). Scenarios may involve false invoices, attachments, invitations, Microsoft 365 alerts, shortened links, changes to account details or access resets. We assess impersonation of customers, suppliers, support staff, the helpdesk or internal teams, including requests for codes and repeated MFA approval prompts. Finance, HR, management, sales, customer service, reception, administrators and system owners need different scenarios. Selection reflects risk and previous training; not every campaign covers every channel. MFA scenarios require test accounts or an agreed simulation, without collecting employees’ real credentials.

Questions about social engineering tests

How are approvals and data protection handled?

+

A contract and scenario approval do not replace assessment against applicable law. Before launch, the business involves those responsible for legal and data-protection matters to establish the basis and conditions for processing. We agree necessary data, access to results, retention and anonymisation of summaries. We do not collect real passwords. Timing, information for employees and post-test communication are agreed with the business; we do not assume every test must be unannounced.

How does testing differ from training and SAT?

+

A test assesses agreed behaviours, channels and responses in specific scenarios. Training explains the rules and lets participants practise applying them; SAT combines repeated measurement, short modules and reinforcement. A campaign can be part of SAT or a separate check after an incident or training. A debrief and learning plan do not automatically include a full training programme.

How do you compare results and use the report?

+

We consider clicks alongside reports, reporting speed and response quality. Repeat campaigns account for comparability of groups and scenarios; an agreed programme review can also include training completion and incidents detected through user reports. Scope, approvals, findings and actions can support NIS2, ISO 27001, DORA, KSB 315 and customer audit reviews where relevant. They do not independently confirm compliance or demonstrate that every attempted fraud will be detected.

Can you help implement improvements?

+

Yes, under a separately agreed scope. We can help with MFA, payment and access-reset procedures, report handling, training and a repeat test. For email, we consider Microsoft 365 and Defender, filters, quarantine, and SPF, DKIM and DMARC: mechanisms for authenticating domains used in sending mail. They do not replace content analysis or user judgement. Changes reflect your environment, campaign findings and available features.

Discuss scenarios and limits

Describe user numbers, sector, roles, sites and current reporting channels. Identify the test objective, permitted channels and important exclusions. Do not send passwords or employee data; we will agree how to share necessary information before work begins.

Discuss a social engineering test