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.
Social engineering
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
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.
Findings may lead to training, technical changes or better incident handling. We agree the scope of that work separately.
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 certificateWe do not send messages or start calls before the rules are approved. Campaign timing and intensity reflect the way your business works.
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.
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.
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.
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.
Practical scope
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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