What You Hold, Where It Runs, and Who Is Asking

Almost every small business underestimates what data it holds, and the exercise of finding out is worth an afternoon because it changes several decisions at once.

Where it accumulates. The obvious systems: accounting, customer records, the website. Then email, which is usually the largest single store, containing years of correspondence with attachments nobody has looked at. Then personal devices, where files were saved to finish something at home. Then old systems still running because nobody switched them off. Cloud storage from a project three years ago. Spreadsheets exported once and never deleted. And backups of all of the above.

What is typically in there. Customer names and contact details. Payment information, sometimes including full card details that should never have been stored. Employee records including bank details, identity documents and health information. Applicant CVs from a hiring round in 2019. Supplier contracts. And correspondence containing far more about people's circumstances than anyone realises.

Why this matters practically rather than as an abstraction.

It determines your obligations. Data protection law applies according to what you process, and you cannot assess obligations you have not enumerated.

It determines your exposure. In an incident, the first question is what was taken, and a business that cannot answer spends days finding out while the notification clock runs.

And it identifies what to delete, which is the cheapest security control available. Data you no longer hold cannot be breached, cannot be published, and does not appear in a notification. Most small businesses could delete a substantial proportion of what they hold with no operational consequence whatsoever.

Retention is treated as an administrative matter and it is one of the highest-value security actions available to a small business, which is worth arguing explicitly.

The reasoning is simple. Every piece of data you hold is something that can be stolen, published, or subject to a notification obligation. Data you have deleted is none of those things, permanently, at no ongoing cost. No other control has that property: every other measure reduces probability, while deletion removes the exposure entirely.

And there is a legal dimension pointing the same way. Data protection regimes generally require that personal data is kept no longer than necessary for the purpose it was collected for. Indefinite retention is not a neutral default; it is a position that has to be justified.

What that looks like in practice for a small business, without becoming a records management project.

Decide a period for each category and write it down. Customer records for as long as the relationship plus whatever your tax and legal obligations require. Applicant data for a stated period after the role is filled, then deleted. Supplier records per contractual and accounting requirements. Marketing contacts until they are inactive for a defined period.

Then actually delete, which is the part that does not happen. A retention policy nobody executes is worse than none, because it documents that you knew.

The specific things worth deleting immediately. Old applicant CVs. Exported spreadsheets containing customer or staff data. Any stored payment card details, which should almost certainly not be held at all. Former employees' mailboxes beyond what you need. And project folders from finished work with clients who left years ago.

An afternoon of deletion reduces your worst-case incident more than most of what security vendors sell.

Small businesses generally cannot run device management, and staff use personal phones and sometimes personal computers. That is the reality to work with rather than to prohibit.

What actually matters, in order.

The device locks, with a passcode or biometric, and locks automatically. This is the single control that addresses the most common device incident, which is loss or theft rather than compromise.

Disk encryption is on. It is enabled by default on modern phones and available on every current computer operating system, and it converts a stolen laptop from a data breach into a lost asset.

Updates are automatic, which was already in the first lesson and applies to phones as much as computers.

Work accounts can be remotely signed out. Even without full device management, most business email and cloud platforms let an administrator revoke a device's sessions. Knowing how to do that, before you need to, is what makes a lost phone manageable.

And work data lives in work systems rather than on the device. If files stay in the cloud service and the device is only a window onto them, losing the device loses nothing.

That last point is the one that does most of the work, because it makes the device question largely irrelevant. A business whose data is in managed cloud services with multi-factor authentication is in a reasonable position regardless of what hardware people use.

What to avoid, specifically. Work email configured on a personal device with no passcode. Customer data downloaded to personal machines. Shared family computers used for business banking. And former staff who still have work accounts on their phones, which is the departure problem from lesson one wearing different clothes.

Mapping a small business's exposure by where data lives, because the answer usually surprises owners.

Email is almost always the largest concentration. Years of correspondence, attachments, customer details, invoices, personal information about staff, and the credentials for other services in the form of password reset capability. Compromise of email is frequently compromise of everything, because reset links go there.

Cloud business systems come next: accounting, customer records, file storage. Well protected by the provider, and the weak point is your account rather than their infrastructure, which is why authentication matters more than anything else you do here.

The website, which usually holds less than people fear unless it takes payments or stores accounts, and which is mostly a reputational and availability risk.

Devices, which matter mainly for what has been downloaded onto them rather than as targets in themselves.

And third parties, from lesson one, whose security is now yours.

The conclusion the diagram supports. Effort should follow concentration, and the concentration is in email and cloud accounts. Multi-factor authentication on those two is not a general good practice; it is the specific control protecting the specific place your risk actually lives.

Which is why the first lesson's ordering put it first, and why a business that has done only that is in materially better shape than one with a firewall and a shared password.

An increasingly common experience for small businesses: a larger customer sends a security questionnaire, and it asks about things you do not have.

Why it is happening. Large organisations are held responsible for their suppliers' security, so they push assessment down the chain. The questionnaire was designed for suppliers with security teams and it arrives unchanged at a business of nine people.

How to handle it well, because it is a commercial situation rather than a technical one.

Answer honestly. Claiming controls you do not have is a contractual misrepresentation, and it is the worst possible position if an incident later occurs. Insurers and customers both treat it seriously.

Answer proportionately. Where a question assumes an organisational structure you do not have, say what you actually do. We do not have a security operations centre; our systems are managed by a named provider and access is reviewed quarterly is a real answer and it is better than a blank.

Distinguish do not have from do not need. Some questions genuinely do not apply at your scale, and saying so with a reason reads as competence rather than as a gap.

Use it as a roadmap. The questionnaire is a list of what a customer with money at stake believes matters, which is the same argument as the insurance form from lesson two. The items you cannot answer are your priority list.

And negotiate where necessary. A customer who requires a certification you cannot justify may accept a written commitment, a specific set of controls, or a timeline. Most are more flexible than the form suggests, because they want to keep you as a supplier.

The strategic note. Being able to answer these credibly is becoming a commercial requirement rather than a security nicety, and small businesses that can answer will increasingly win work from those that cannot.

Any business taking payment has a specific obligation that owners frequently do not know applies to them.

The Payment Card Industry Data Security Standard applies to any organisation that stores, processes or transmits payment card data, with no small business exemption. What varies is how much is required, which depends on volume and on how you take payments.

The practical position that makes this manageable, and it is the whole of the advice for most small businesses.

Do not handle card data at all. Use a payment provider whose hosted checkout or payment terminal means the card details never touch your systems. Your obligations then fall to their simplest level, because there is nothing to protect.

What that means concretely. No card numbers written on order forms. No card details taken over the phone and noted on paper or in a spreadsheet. No card information stored in your customer records, your email, or your accounting system. And no card details emailed to you by customers, which happens routinely and should be met with a request to use the payment link instead.

That last one deserves attention. Customers will email card details unprompted. Those emails then sit in your mailbox, which lesson content above identified as your largest data concentration, and they are exactly what a compromised mailbox exposes. Delete them and tell the customer why.

Where you genuinely must handle card data, this needs specific advice rather than general guidance, because the requirements become substantial.

And the broader principle, which is the same as the deletion argument. The cheapest way to secure sensitive data is to arrange not to hold it. Payment processing is the clearest available case of that, and most small businesses can adopt it completely.

The departure process is where small businesses have the widest gap between what they intend and what happens, and it is entirely fixable with a list.

Why it goes wrong. In a small business, departures are personal and often awkward, the practical steps are nobody's defined job, and the person who knows which systems exist is frequently the one leaving. So access lingers, sometimes for years.

What that creates. A former employee with continued access to email, files, customer records or social accounts, whose own account security is now outside your control. This is a risk even where the departure was amicable, because their personal device gets sold, their password gets breached elsewhere, or their new employer's interests differ from yours.

The list, which should exist before it is needed.

Email account: access removed, and forwarding or delegation checked, since a forwarding rule survives a password change.

Every cloud system, individually. This is where the access list from lesson one pays for itself.

Shared accounts: passwords changed, because a shared credential is not revoked by removing a person.

Social and marketing accounts, where a departing administrator is a genuine and recurring problem.

Devices returned, and work accounts remotely signed out from any personal device.

Building access, keys and alarm codes.

And any access held with your suppliers or customers on your behalf.

One further point specific to small businesses. Where the departing person was the one who set everything up, capture what they know before they go: which systems exist, where accounts are held, what the recovery details are. That conversation is uncomfortable to have during a resignation and considerably worse to skip.

Everything across three lessons, as something a small business owner can act on.

You are attacked because you are reachable, not because you were chosen. Five things actually happen: account compromise, payment fraud, ransomware, ordinary data loss, website compromise.

Six controls address almost all of it. Multi-factor authentication on email first, then everything. Backups that are tested and unreachable from your normal credentials. Automatic updates. A payment verification rule with no exceptions for urgency. A password manager. Removing access when people leave.

Ransomware is the end of a process, not an event. Backups get destroyed before encryption, data is stolen before it, and the payment decision is settled months earlier by whether you can restore. Insurance is worth having mainly for access to specialists, and its application form is a free assessment.

Write the one page now: contacts, critical systems, where backups are, what personal data you hold, who decides, a holding statement, and how you run on paper for a day. Print it.

Know what data you hold, then delete what you do not need. Deletion is the only control that removes exposure entirely rather than reducing probability.

Arrange not to hold card data at all.

Your risk concentrates in email and cloud accounts, so that is where authentication effort belongs. Devices matter mostly for what has been downloaded onto them.

And answer customer security questionnaires honestly and proportionately, treating them as a roadmap rather than a threat.

The honest summary of all three lessons. None of this is technical, expensive, or difficult. It is a short list of unexciting things, most of which fit into a weekend, and the only reason it does not happen is that nothing forces it until something does.