Phishing-resistant verification for Slovak SMEs

Three in four employees in the EU encountered suspicious emails, messages or links at work, according to a Eurobarometer published by the European Commission on 30 September 2026. Phishing was reported by 39%, while 15% encountered AI-generated scams. The practical lesson for a Slovak SME is not that every colleague must become a forensic analyst. It is that a sensitive business decision must not depend on whether one person can spot a convincing fake under time pressure.

Modern deception can borrow a supplier's tone, refer to a real project, reproduce an executive's voice or arrive inside a genuine account that has been compromised. Visual polish is therefore weak evidence. The safer question is not “Does this message look real?” but “What independent evidence do we require before this particular action is allowed?”

Why awareness alone is not enough

Awareness training remains useful: people should recognise urgency, unexpected links, changed payment details and requests for secrecy. But a well-designed attacker deliberately creates plausible context. A rushed colleague may also misjudge a legitimate request. If the control depends only on individual suspicion, performance will vary with workload, confidence and hierarchy.

Eurostat reports that 22% of EU businesses experienced an ICT security incident in 2024; Slovakia was among the countries with the lowest reported share, at 12%. That figure describes reported business experience in the survey, not immunity. The same Eurostat publication says only around 60% of EU businesses informed staff about ICT security obligations. A company therefore needs both informed people and a short process that is easy to follow on an ordinary busy day.

Identify the decisions that deserve verification

Do not slow every email. Start with actions where impersonation could create disproportionate damage:

adding or changing supplier bank details;
making an exceptional, urgent or split payment;
resetting a password or multi-factor authentication method;
granting administrator rights or access to a shared mailbox;
sending payroll, customer, contract or identity data;
opening an unexpected shared file that requires a new sign-in;
acting on a confidential request attributed to an owner or executive.

These triggers form the boundary of the verification system. Normal low-risk work stays fast. High-consequence changes receive a deliberate pause, an independent check and a small evidence trail.

Build a trusted route before an incident

A callback is useful only if the number is trustworthy. Do not call the number in the suspicious email, invoice or messaging profile. Maintain a compact directory of verified supplier and internal contacts using information confirmed during onboarding or a previous legitimate relationship. Restrict who may edit that directory and record when a sensitive contact detail changes.

For internal requests, use a known corporate number, an already established chat thread, an in-person check or a ticket created inside the company's normal system. For a supplier, use the number held in the approved vendor record or published on a known official website—not a contact supplied in the change request. The second channel does not need to be sophisticated; it needs to be independent.

Define what a valid confirmation sounds like

A vague callback can still fail. “Did you send something?” invites a quick yes and may refer to another message. The verifier should state the material action: “Please confirm that your company requested changing invoices from account ending 4821 to account ending 7394, effective today.” For access changes, name the account, permission and duration. For data disclosure, name the recipient and the dataset.

Avoid using personal facts, a voice or video appearance as the sole authenticator. Public information and AI-generated media can imitate familiarity. Confirmation is stronger when it uses a pre-established route, a second authorised person or a controlled system record.

Separate initiation from approval

In a very small company, perfect separation of duties may be unrealistic. A proportionate version still helps: the person entering new bank details should not be the only person approving the first payment; an administrator should not approve an MFA reset solely from the requester's new telephone number; an executive request above an agreed threshold should receive a second check even when the owner appears to be asking.

Set thresholds that match the business. A second approval may apply to all bank-detail changes, while unusual payments may use a monetary threshold. Some actions—such as creating a new global administrator—deserve verification regardless of value. Write the thresholds down so that staff do not have to negotiate them during an urgent request.

Support the workflow with technical controls

Process controls should sit beside basic technical measures. Use multi-factor authentication, preferably phishing-resistant methods where supported; keep privileged accounts separate from everyday email; limit administrator rights; filter malicious mail; apply updates; and maintain recoverable backups. Configure domain protection and monitoring appropriate to the mail service. None of these controls makes people infallible, but each reduces the attacker's available path or limits the consequence of one mistake.

ENISA's current threat work warns that interconnected dependencies widen the attack surface and that AI is increasingly relevant to malicious operations. That is another reason to favour controls based on authority, independent channels and limited privileges instead of relying on grammar, logos or an apparently familiar voice.

Make reporting quick and blame-free

A colleague who clicks and reports immediately may protect the company. A colleague who hides the event because the reporting route is unclear cannot. Provide one visible way to report a suspicious message or possible mistake. Ask people not to continue the conversation, not to delete the original, and not to experiment with the link. The response owner can then preserve evidence, secure the affected account, review related rules and decide whether external support or formal reporting is required.

Record near misses as well as confirmed incidents. A blocked bank-detail change shows which supplier record, approval limit or contact route needs improvement. The objective is not a leaderboard of who spotted the most phishing. It is a process that learns before money or data leave the company.

A practical 30-day implementation

Week 1—Map: list the five to ten actions where false authority could create the largest loss. Name the current initiator, approver and trusted record.
Week 2—Design: define verification triggers, independent channels, approval thresholds, escalation contacts and the minimum evidence to retain.
Week 3—Practise: rehearse three realistic scenarios: changed supplier account, urgent executive payment and MFA reset. Correct friction and ambiguity.
Week 4—Embed: place the rule in the payment, access and data-handling checklists; brief new starters and review the first real uses.

Measure whether the control is usable

Track a small set of operational signals: the share of defined high-risk changes that received independent confirmation, time required for a normal verification, number of exceptions, near misses reported and outdated contacts discovered. A control that is constantly bypassed may be too vague, too slow or unsupported by management. Improve the route without weakening the decision boundary.

The strongest result is not zero suspicious messages. It is a company where a convincing message cannot quietly become an irreversible action. That is achievable without a large security department: define the sensitive decisions, verify through a route established in advance, separate authority where practical and make early reporting safe.

For support with practical digital workflows, access controls and business-safe automation, see our Technology services.

Sources and further reading

Facts, figures and current context were checked against the following official European and Slovak sources on 11 October 2026. The verification model, decision triggers, 30-day implementation plan, practical recommendations, conclusions and wording are original editorial work by Merkle s. r. o.

The Eurobarometer figures describe employees' reported encounters and perceptions; the Eurostat indicator describes enterprises reporting specified ICT incidents. Neither statistic predicts the risk of an individual company. This article provides general operational guidance and does not replace a tailored cybersecurity assessment, incident-response service or legal advice.