Company data security — start with the mailbox, not with the website

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.

The protection that already runs and costs you nothing

It is worth starting with the part of this subject that changes its proportions, because almost nobody counts it as protection at all.

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. Across Europe, national computer security incident response teams maintain lists of malicious domains and pass them to internet providers and mobile operators, who block them inside their own networks. 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. Every country in Europe has a national incident response team that takes reports from the public, and finding its current reporting page 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.

Where your company's data actually lives

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.

One reflex instead of a course in spotting phishing

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.

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.

What to do with data you should not be holding

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.

Passwords: what actually changes the outcome

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.

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.

Devices nobody thinks of as company devices

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.

What it costs

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.

When somebody has already clicked

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. We cover the notification duty and what it requires separately.

The four sentences we hear most often

"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.

What to check once a quarter

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.

• Accounts of people who have left — in the mail system, in external systems, and on the private phones that company mail was never signed out of.
• Forwarding rules in the mailboxes. Not only after an incident: this is a check that takes a minute per mailbox and catches the one trace that keeps working after a password change.
• Where the resets arrive. The address a system sends recovery links to is sometimes a mailbox created during setup years ago that nobody has opened since.
• Whether the second factor is still tied to the right device. After a phone is replaced it sometimes stays on the old one — in which case, when it is needed, it will neither work nor warn you.

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.

What this article does not settle

• Legal obligations after an incident — notifications, risk assessment, informing the people affected. That is a separate subject, and in anything doubtful it is a lawyer, not us.
• Access to the website itself — dashboard accounts, roles, plugins: how to secure a website.
• Backups — separately, including the part where losing access is itself a breach.
• The choice of specific tools and suppliers. They change faster than an article can be kept current, and the right choice depends on what you already use.
• Internal policies and regulations. In a company of a few people, a spoken rule confirmed by a phone call works better than a document nobody read.

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.