Company data rarely leaks through the website. It leaves through the mailbox, the phone and an account in someone else's system. What to do first.

Company data rarely leaks through the website. It leaves through the mailbox, the phone, and an account in someone else's system — through the things nobody treats as infrastructure, because nobody ever bought them as infrastructure.
This article is about that layer. Access to the site itself — dashboard accounts, roles, plugins — is a separate conversation and a separate set of habits.
What you will find here. The protection you are already using and probably do not know about — together with what it structurally cannot do, which matters more than what it can. An inventory of the places your company's data actually sits. One reflex worth teaching the team instead of a course in spotting phishing. What to do with data you should have stopped holding years ago. Four moves after somebody clicks. And a boundary: what in all this belongs to a lawyer rather than to us.
It is worth starting with the part of this subject that changes its proportions, because almost nobody counts it as protection at all.

The protection already working, and what it cannot stop
Own analysis
Three filtering layers stand between a fraudulent message and the person it was written for, and nobody in your company set any of them up.
The browser and the operating system check addresses against a reputation list. When an employee clicks a link to a page already known to be fraudulent, the browser will very often refuse to open it and show a warning instead. This is not a product anyone in your company chose; it ships switched on, and the list behind it is maintained centrally and updated continuously.
The mail provider filters before delivery. A substantial part of what is sent to your company never reaches anyone's inbox, and a further part lands in a folder nobody reads. This is the layer most people mean when they say "we don't really get much of that" — the correct reading of which is that a lot of it is being stopped somewhere, not that little is being sent.
Network operators block at the level of the connection. In Poland, CERT Polska maintains the Warning List (Lista Ostrzeżeń), a register of malicious domains that internet providers and mobile operators download and block inside their own networks. In 2025 almost 245 thousand domains were added to it, it was downloaded close to 1.3 billion times, and that translated into about 141.1 million blocked visits to dangerous sites. The same route is used for filtering fraudulent text messages. From your side this is invisible: the page simply does not open, or the message never arrives.
Two things follow from this for a small company, and both are practical.
You are on the protected side without knowing it. A large share of the attempts that could have reached your employees never gets to them, because it was stopped at the operator, at the provider, or in the browser. That is not a reason for calm — it is a reason to know the layer exists and what keeps it working.
You can feed it, and that is the cheapest thing in this entire article. Every one of those layers is built from reports. Browsers carry a "report a phishing site" option in the menu. Mail clients have a "report phishing" button next to "mark as spam", and the difference between them is not cosmetic: spam goes to a folder, a phishing report goes to the provider's analysis. In Poland that is CERT Polska: a suspicious text message forwarded to 8080 costs as much as one text message, and a suspicious page reported through the form at incydent.cert.pl takes a minute. A single report gets an address onto a list that then blocks the next attempts at everyone else at once.
This is the rare case where reporting your own incident genuinely protects someone else — and it is worth saying that out loud to the team, because it changes the framing from "it's embarrassing that I clicked" to "I report it so that the next person doesn't".
It is equally worth knowing what this protection does not do, so that nobody builds a false sense of safety on it. Addresses land on the lists after analysis, and fraudsters use them briefly and at scale — so the first hours of a campaign always get through, and the first hours are when most of it is sent. Network-level blocking works only where the provider implemented it; a message opened on a private phone, on somebody else's Wi-Fi, may never meet it. And finally: none of it works on an attachment, or on a payment request sent from the real, compromised mailbox of a company you work with — because in that case no address involved is malicious, no reputation list has anything to flag, and every technical check the message passes through is passed honestly. That is exactly the scenario the section on verification through a second channel answers, and it is the reason that section exists.
Before you secure anything, it is worth knowing what you are looking for. Almost every time, more places turn up than anyone remembered.
The mailbox. The most important place, and the most casually treated. It holds form submissions, quotes, client details, invoices, and very often also password resets for every other system you use. Whoever holds the mailbox holds the rest.
The shared drive and the desktop. Contracts, price lists, customer databases in spreadsheets. Usually with no control at all over who can reach what, because "everyone sees everything anyway".
Phones. Private ones, with company mail on them, with no screen lock or with a four-digit code. A phone left on a train is a company mailbox in somebody else's hands.
Accounts in other people's systems. Invoicing, CRM, the bank, the hosting panel, social media, mailing tools. Each with its own password, or — more often — with the same one.
Channels that look to nobody like a system. The messaging group where scans of ID documents get passed around. The photograph of a signed contract sitting in a phone's camera roll. These are real storage locations and the hardest ones to clean up, precisely because nobody filed them as storage.
In practice: write this out on a single sheet of paper. One column for the place, one for who has access, one for the question of what happens if a stranger gets in. It is an hour of work, and it is the only part of this article that nobody can do for you — because only you know where the files actually end up.
Two things usually surface during this exercise that nobody planned for. The first: accounts belonging to people who no longer work here, still active in half the systems, because the departure was handled by taking back a laptop. The second: one account used by several people — for invoicing, for the bank, for social media — which can be taken away from nobody in particular and which makes it impossible to establish who did what. Both are fixable on the same day the list is written, and both cost nothing but a decision.
The standard advice is "train the team to recognise phishing". It is weak advice, because it teaches people to compare what they see against examples, and campaigns change faster than any course can be updated. What works better is a single reflex that does not depend on how the message looks:
If a message asks for an action — a login, a payment, a change of bank account — confirm it through a different channel than the one it arrived on.
It came by email from the managing director — call the managing director. It came by text from a courier — go to the courier's site by typing the address yourself. It came from a supplier with a new account number — call the number you have from the contract, not the one in that message.
Confirm through a different channel than the request came in
Digital Vantage, own diagram
The reflex also works when the message is flawless — and increasingly it is, because writing correct, idiomatic text in any language stopped being a barrier. It no longer matters much whether your team can spot a fake; what matters is whether they verify through a channel the attacker does not control.
Two additions that cost nothing:
Set a rule for changes of bank account. This is the single most expensive scenario in a small company: a genuine-looking invoice with a substituted account number. The rule is "a change of account number is always confirmed by phone", and it has to apply even when the request appears to come from someone well known.
Tell the team that reporting a mistake carries no consequences. The greatest loss is not caused by the click; it is caused by the two hours of silence afterwards, because somebody was afraid to say it. That is the only "security policy" a small company genuinely needs, and it fits into one sentence said out loud.
It is also worth naming the scenario that gets past every technical rule: a message from the real, compromised mailbox of a company you work with. The address is right, the thread history is right, the tone is right — because it is being written by somebody who has been reading that correspondence. Nothing in the message looks suspicious except one thing: a request to change an account number, or to make an urgent payment. The industry name for this is business email compromise, and the reason it works is that there is nothing to spot. Which is exactly why the rule is about the action being requested, not about how the message looks.
The most effective way to secure data is not to have it — and this is the only item in this article that reduces risk permanently rather than until the next incident.
Alongside the inventory from the section above, it is worth asking a second question at each place: is this still needed for anything?
Scans of identity documents. Sent once, for one transaction, sitting in the mailbox for three years. There is no reason for them to be there, and in a mailbox takeover they are the most damaging part of the loss — to the people whose documents they are, which is a category of harm you cannot compensate with an apology.
Form submissions from years ago. They sit in the mailbox because nobody ever deletes anything. Each one is a name, an email address and a message somebody entrusted to you in the course of asking a single question.
Spreadsheet databases on the drive. An export pulled out of a system for one campaign, which then stayed on the desktop. This is the most common source of company data circulating in parallel to the system that was supposed to hold it — and the copy nobody thinks to delete when a record is deleted in the system itself.
Copies on private devices. A file sent to a private mailbox "to work on at home" outlives the project it belonged to by years.
In practice: one afternoon spent deleting what has no purpose, and the habit of deleting exports once they have been used. It sounds modest next to two-factor authentication and a password manager, and it reduces the one quantity you have complete control over: how much there is to lose.
Briefly, because securing the website dashboard itself is a separate article.
Uniqueness beats complexity. A complicated password reused across three services is weaker than a simple one used once. Mass attacks do not guess — they replay pairs of credentials taken from other companies' breaches, and they do it at a rate no human process competes with.
Two-factor authentication where the resets arrive. If you are going to switch on a second factor in exactly one place, make it the mailbox — because everything else can be recovered through it.
The mailbox — the key to every other account
Digital Vantage, own diagram
A password manager is a tool, not a topic. It solves the problem of "you cannot invent and remember forty different passwords", and that is the whole of its role. The versions built into browsers are enough for a small company, as long as the browser account itself has a second factor — otherwise you have moved every password into one basket with no lock on it.
Shared accounts are a separate problem. One invoicing password for three people means that when one of them leaves, it has to be changed for all three — and usually nobody does. If the system allows separate accounts, it is worth using them, even when they cost more per user.
A private phone with company mail on it is the norm in most small companies, and there is no point fighting it. There is a point in treating it as what it is.
A screen lock is the minimum, and a four-digit code is not one. A phone left on a restaurant table or lost on a train is a company mailbox in somebody else's hands — and with it, the password resets for everything else.
Remote wipe has to be switched on before it is needed. In both common mobile systems it is a built-in, free feature, and it only works if it was enabled in advance. Five minutes per device.
Decide what happens when an employee leaves. It is not about the laptop; it is about access: signing company mail out of their private phone, removing their accounts in external systems, changing shared passwords. The list from the earlier section is exactly the list you work through.
Public networks and working from a café are a smaller problem than they used to be — connections to mail and to business systems are encrypted by default now. The real problem is the screen visible to the person at the next table, and the phone left unlocked on it, not the network.
Honestly: almost everything in this article is free and takes one afternoon. It is worth saying plainly, because the security services market sells the opposite impression.
For nothing: the list of places, a second factor on logins, signing out old accounts, switching on remote wipe, the rule about verifying through a second channel, reporting suspicious messages.
For very little: a password manager in its team version, separate accounts instead of shared ones in systems that charge per user.
Reasonably worth paying for in a larger team: training with a simulated campaign — but only once the above is done, because training people while accounts are shared and no second factor exists teaches caution in a place that has no lock on it anyway.
Not worth buying: "company protection" packages that do not say plainly what they monitor and who receives the alert. The control question is the same as it is for a website — will this service telephone a named person, or will it generate a report in a panel nobody opens?
We do not quote figures in this section, and that is deliberate. What the paid items cost depends on the size of the team and on which tools you already pay for, and the only honest number is the one on the quote in front of you. A figure carried over from somewhere else would read as a benchmark while being a guess.

Somebody clicked — five moves, and the first four are timed
Digital Vantage — from incident work
The order matters, because the first two things lose their value with every minute that passes.
Change the password — from a different device. If the machine where the click happened is running something that records the keyboard, a new password typed on it goes to the same place as the old one.
Sign out all sessions. Changing a password does not evict someone who is already signed in. The option is usually called "sign out of all devices" and lives in the account's security settings.
Check the mail forwarding rules. This is the step almost everybody skips, and the only one that keeps working after the password is changed. An attacker sets a rule copying mail to an outside address precisely so that they can keep reading it once they lose access. The rules are in the mailbox settings, under filters or forwarding.
Warn the team and your business contacts. Messages go out of a compromised mailbox to your customers — and it is those, rather than the incident itself, that do the most reputational damage.
Only now establish what it was and who clicked. Not because it does not matter, but because before the four steps above, it stops nothing.
If what became available to a stranger included personal data — of customers, employees or contacts — there is an obligation on top that no technical action removes. Under the GDPR, a breach is not only a leak: accidental loss of personal data and loss of access to it count too, and the clock runs 72 hours from the moment you become aware, not from the moment you understand the cause. In Poland the notification goes to the President of the Personal Data Protection Office (Prezes UODO). We cover the notification duty and what it requires separately.
"We are too small for anyone to be interested in us." Campaigns that reach small companies do not pick their targets — they are addressed from lists, and nobody checks a company's size before sending. The messages that are targeted are aimed at a role, not at a size: whoever pays the invoices, whoever has the bank access. That role exists in a three-person company exactly as it does in a three-hundred-person one, and in the three-person company it is usually held by someone with four other jobs.
"We have antivirus." Antivirus software will not stop a situation in which somebody voluntarily types a password into a page that looks genuine. And that is the dominant scenario — the data leaves through a form, not through a file.
"That's a job for the IT person." Half of this list is decisions, not configuration: who has access to what, what happens when an employee leaves, whether a change of bank account requires a phone call. An IT person can implement those decisions but cannot make them for you — because they do not know who you trust.
"We'll have everyone sign a security policy." A document nobody reads changes nothing. In a team of a few people, one sentence said out loud — "reporting a mistake carries no consequences" — works better than twenty pages appended to a contract.
The list from the first section is a one-off. Four things, though, are worth reviewing on a cycle, because they go stale on their own.
A quarter of an hour, once every three months. The only item that needs a calendar entry is the first; the rest happen in passing, once somebody knows where to look.
One thing is worth saying at the end, because it follows from the whole list and is rarely said out loud: none of these steps requires understanding how an attack works. You do not need to know the difference between phishing and smishing, or what session hijacking looks like. You need to know where the data sits, who can get to it, and what to do in the first ten minutes. That is organisational knowledge, not technical knowledge — which is why the owner of a company is better placed here than an outside IT contractor who does not know who trusts whom, or who works with whom.
The shortest summary: start with the mailbox and with one sheet of paper listing the places. Everything else — the second factor, unique passwords, the reflex of verifying through a second channel — arranges itself around those two, and costs nothing but an afternoon.
In an audit we go through the mailbox, the access rights and the accounts in outside systems — including the ones nobody in the company remembers any more.
In Poland 97% of recorded incidents are fraud and only 0.3% break-ins. So this section starts with the list of accounts, not the firewall.
91% of WordPress vulnerabilities sit in plugins; six were found in the core. And 46% had no fix on disclosure day, which changes what a routine is for.
Phishing is 30% of incidents registered in Poland, break-ins through code 0.3% (CERT Polska 2025). Securing a website is access control, not plugins.
On a website, the GDPR duty to inform is the privacy policy. What must be in it, what is padding, and why cookies sit on a separate legal basis.
A free certificate is enough almost every time. When you need a wildcard, why the EV bar disappeared, and what Chrome changes in October 2026.
A WordPress backup nobody has restored is a feeling, not a safeguard. Four layers, three storage locations, and why losing access is a GDPR breach.
Table of Contents · 11 sections · 12 minutes read
Rate this article
Back to the guide: Websites — a guide to the whole section

SMS marketing for online stores: GDPR and ePrivacy consent, what a campaign costs in PLN, and the Gmail, Yahoo and Outlook rules for email.

Meta Ads for online stores: Shops availability, the product catalogue, Advantage+ shopping, dynamic retargeting, and Pixel plus Conversions API.

An ecommerce SEO audit runs mostly on free Google reports: indexing, Core Web Vitals, rich results, duplicates and Merchant Center data.

Google Merchant Center: site verification, product data, shipping and landing page rules, disapprovals, and Shopify, WooCommerce and IdoSell integrations.

API explained with NBP, KSeF and VIES as examples: REST API, webhooks, OpenAPI, API keys and integration security for business.

Multi-tenant SaaS: single tenant vs multi-tenant, the silo/pool/bridge models, Row Level Security, GDPR and choosing a model for an MVP.

Cloud computing by the NIST definition: five traits, IaaS, PaaS and SaaS, public, private and hybrid cloud, and how Polish businesses actually use the cloud.

When a free booking calendar is enough, what an online booking system must handle and when a custom module pays off. Vendor prices and our estimate.

What a CRM is, when a spreadsheet is enough, what the system must do, how to square a customer database with the GDPR and how to choose one.