Secure File Transfer for Small Business: A Practical Guide From Someone Who Builds This Stuff

You run a small business. You send contracts, tax documents, client records, payroll files. You do not have an IT department. And yet secure file transfer for small business is something you need to get right, because the cost of getting it wrong is not theoretical. The average breach costs a small business around $250,000, and roughly 60% of small businesses that suffer a major breach close within six months. This guide exists so you can make an informed decision about how you move sensitive files, without hiring a consultant and without wading through vendor marketing that blurs every distinction that actually matters.

Key Takeaways

• The single most important question when evaluating any file transfer tool: if the vendor gets breached, can they hand over your files? If yes, your encryption is decorative.
• "Encrypted in transit" (TLS) is table stakes. Every reputable service does it. It does not protect your files once they reach the server. You need to understand the difference between transit encryption, server-side encryption, and true end-to-end (zero-knowledge) encryption.
• Enterprise-grade managed secure file transfer platforms are not automatically safer. MOVEit, GoAnywhere, Cleo, and Accellion have all suffered mass breaches from ordinary bug classes like SQL injection. Bigger vendor does not mean smaller risk.
• The newest risk vector is not email or FTP. It is employees pasting sensitive files into AI tools with no security vetting. If your team uses generative AI, that is now part of your file transfer surface.
• A simple, low-cost approach (locally encrypted archive, expiring link, password sent via a separate channel) beats most "enterprise" solutions for a business with no IT staff, because it minimizes the number of parties who can access your data.

What Actually Makes a File Transfer Method "Secure"?

Vendors love the word "secure." It appears on every product page, usually next to a padlock icon. It means almost nothing without specifics. Here is what actually matters, broken into three layers that build on each other.

Layer 1: Encryption in Transit (TLS)

When you upload a file to a cloud service, TLS encrypts the connection between your browser and the server. Think of it as an armored truck: the package is safe during delivery. Every reputable cloud service uses TLS. If a service does not, walk away. But TLS alone does not protect your file once it arrives at the destination. The server decrypts it and can read the contents. Staff can open the package in the warehouse.

Layer 2: Encryption at Rest (Server-Side)

Most cloud storage providers encrypt your files on their storage drives. This protects against someone stealing a physical hard drive from a data center. The limitation: the provider holds the decryption keys. They can decrypt files for search indexing, malware scanning, legal compliance, or because an attacker compromised their infrastructure. Server-side encryption encrypts files using keys the provider manages, which means a breach of the provider is a breach of your data.

Layer 3: End-to-End (Zero-Knowledge) Encryption

With end-to-end encryption, the file is encrypted on your device before it ever leaves. The server stores ciphertext it cannot decrypt. The provider never holds the key. If they get subpoenaed, hacked, or simply curious, they cannot read your files. This is the only model where a vendor breach does not automatically become your breach. Not every service that claims "end-to-end encryption" actually delivers it. The test is simple: can the provider reset your password and still give you access to your files? If yes, they hold a key. It is not zero-knowledge.

Who Holds the Key? The One Question That Filters Everything

Forget certifications for a moment. Forget SOC 2 badges and ISO 27001 logos. Those are process audits. They tell you a company has documented procedures. They do not tell you whether the company can read your files.

Ask one question: if this vendor got breached tomorrow, could the attacker access my files in readable form?

If the vendor holds the decryption keys, the answer is yes. If the encryption happens on your device and the vendor never sees the key, the answer is no. That is the entire decision framework. Everything else is detail.

This does not mean certifications are worthless. SOC 2 Type II, for instance, means an independent auditor verified that security controls existed and operated effectively over a period of time. That matters for operational hygiene. But operational hygiene and cryptographic architecture are different things. A company can pass every audit and still store your files in a way that a single SQL injection can expose.

Why Do Managed Secure File Transfer Platforms Keep Getting Breached?

Managed secure file transfer (MFT) is a category of enterprise software designed for automated, auditable, high-volume file movement. Think scheduled batch transfers between business partners, regulatory file submissions, things like that. The tools in this category (MOVEit, GoAnywhere, Cleo Harmony, the former Accellion FTA) are widely deployed across government, healthcare, and finance.

They also keep getting breached. Repeatedly. By ordinary attack techniques.

The 2023 MOVEit breach compromised over 2,700 organizations and exposed the personal data of approximately 93.3 million individuals. The vulnerability was SQL injection, one of the oldest and most well-understood bug classes in software. The ransomware group CL0P exploited it to access sensitive databases across thousands of organizations that trusted the platform.

Then it happened again. On May 4, 2026, Progress disclosed a critical authentication bypass in MOVEit Automation affecting all versions prior to specific patched releases. The flaw allows unauthenticated remote attackers to bypass access controls entirely, no credentials or user interaction required. Three critical vulnerabilities in three years for a single platform. And scanning activity against MOVEit surged starting in late May 2025, with over 682 unique IP addresses probing MOVEit Transfer systems over a 90-day window. Attackers do not move on after each patch. They keep probing.

The recurring pattern across major MFT platforms is not due to exotic zero-day research. It traces back to SQL injection, insecure deserialization, and authentication flaws in the software itself. These tools become high-value targets precisely because they concentrate so many organizations' sensitive data in one place. A single vulnerability yields thousands of victims.

For a small business, the lesson is counterintuitive: a managed secure file transfer server that half the Fortune 500 uses is not automatically safer than a simpler tool where you control the keys. Concentration creates risk. Fewer moving parts, fewer third-party integrations, and keys you control is a more resilient posture than "trust the badge."

Do I Need a Secure File Transfer Server, or Is That Overkill?

Probably overkill. A dedicated secure file transfer server makes sense when you have automated, scheduled transfers between business systems (EDI with suppliers, regulatory submissions, nightly database syncs). If that describes your operation, you need MFT software and someone to maintain it.

If you are a 5-person accounting firm sending tax returns to clients, or a design studio delivering project files, or a law practice sharing contracts, you do not need a file transfer server. You need a tool that encrypts the file before it leaves your machine, generates a link that expires, and does not give the hosting provider access to the plaintext. The simpler the system, the fewer things can go wrong.

A reasonable minimum for any tool you pick:

• End-to-end encryption (the provider cannot decrypt your files)
• Expiring links (access revokes automatically after a set time or number of downloads)
• Multi-factor authentication on your account
• No requirement to create an account on the recipient's side

If the tool also offers password protection on individual transfers, that is a meaningful extra layer. If it offers audit logs showing who accessed what and when, useful for compliance. If it offers a 47-page admin console with LDAP integration and SFTP bridge configuration, you are buying a solution for a problem you do not have.

What About Email? Can I Just Send Encrypted Email?

You can. Most people will not. The friction is too high for recipients who are not technical.

S/MIME and PGP both provide genuine end-to-end email encryption. They also require the recipient to have a certificate or key pair, which means you are asking your client to install software and manage cryptographic keys before they can read your message. In practice, this works between two security-conscious parties who have agreed on the setup in advance. For ad hoc file delivery to a client who uses Gmail on their phone, it does not work.

Email providers like Microsoft 365 and Google Workspace offer their own "encrypted email" options, but these are typically server-side encryption with the provider holding the keys. Better than plaintext. Not zero-knowledge.

The practical answer for most small businesses: use email for the notification ("your file is ready"), and use a separate, encrypted channel for the file itself.

Is the Password-Protected ZIP Method Actually Good Enough?

For many small businesses, yes. Locally encrypting a file into a password-protected archive and sharing it via an expiring link, with the password sent through a different channel (text message, phone call, separate email), is a legitimate two-factor approach. Even if the link is intercepted, the file contents remain unreadable without the password. Even if the password is intercepted, the attacker does not have the file.

The caveats are real. You need to use AES-256 encryption in the archive, not the legacy ZIP encryption (which is trivially breakable). 7-Zip supports AES-256. The built-in ZIP function on older Windows versions does not. You need to use a strong password, not "password123." And you need to actually send the password through a separate channel, not in the same email as the link.

This method scales poorly. If you send 50 files a week, managing passwords and expiring links manually becomes a full-time job. But for occasional sensitive transfers (quarterly tax filings, signed contracts, employee onboarding documents), it is cheap, effective, and puts you in control of the keys.

What Is the Risk of Employees Pasting Files Into AI Tools?

This is the risk vector that almost no "secure file transfer" guide covers yet, and it is arguably the fastest-growing one.

Your employee receives a 40-page contract. They paste it into a consumer AI chatbot to get a summary. They upload a spreadsheet of client contact information to get it reformatted. They drop a financial report into an AI tool to generate charts. Each of these actions is a file transfer. The data leaves your control and enters a third-party system with its own retention policies, training practices, and breach surface.

Only 37% of companies have formal processes to assess AI tool security before deployment, and 20% of companies report data breaches tied to shadow AI. "Shadow AI" means employees using AI tools that the company has not vetted or approved. It is the new shadow IT, except the data exposure is often immediate and invisible.

If you care about secure file transfer, you need a policy that covers where files go when someone asks an AI to process them. That means either vetting and approving specific AI tools that offer adequate data protections, or drawing a clear line: client data does not go into any AI tool that is not on the approved list.

This is one place where using a privacy-focused AI product matters. If your team needs AI assistance with documents, the tool they use should not retain, train on, or expose that content. At Selina, files uploaded through SelinaSEND are zero-knowledge encrypted (we cannot read them, by design). But that is specific to the file upload path. The broader point stands regardless of what tools you use: any AI interaction involving sensitive documents is a file transfer, and should be treated as one.

How Do I Evaluate a Vendor When I Cannot Do a Security Review?

You are not going to read a SOC 2 report. You are not going to review source code. That is fine. Here are concrete questions that filter out most bad options without requiring technical expertise.

1. Can the vendor read my files? Ask directly. If the answer is anything other than an unqualified "no," the encryption is server-side and the vendor holds the keys. Some vendors will say "we don't look at your files." That is a policy, not a technical control. Policies change. Keys do not disappear.

2. What happens if I forget my password? If the vendor can reset your password and you still have access to all your files, they hold a decryption key. In a true zero-knowledge system, forgetting your password means losing access. That is the tradeoff. It is a feature, not a bug.

3. Where does the encryption happen? On your device (client-side) or on their server? Client-side means the plaintext never touches their infrastructure. Server-side means it does, even briefly.

4. Can I set links to expire? If shared links live forever, every link you have ever sent is a permanent attack surface. Expiration and download limits are basic hygiene.

5. What is the vendor's breach history? Search "[vendor name] data breach" and "[vendor name] CVE." A vendor with zero public vulnerabilities is either very new or very good at suppression. A vendor with disclosed vulnerabilities and fast patches is honest and responsive. A vendor with three critical vulnerabilities in three years on the same product line is telling you something about their code quality.

What Compliance Requirements Apply to Small Businesses?

This depends entirely on your industry and the type of data you handle.

If you handle health information (patient records, insurance claims), HIPAA requires that you have safeguards for electronic protected health information, including during transfer. End-to-end encryption is not explicitly mandated by HIPAA, but it is the clearest path to the "addressable" encryption requirement and the safe harbor provision for breach notification.

If you handle payment card data, PCI DSS requires encryption of cardholder data in transit across open, public networks. TLS satisfies this for the transit portion. Storage requirements are stricter.

If you have clients in the EU, GDPR applies to their personal data. Article 32 requires "appropriate technical and organisational measures" for security, including encryption. The regulation does not specify which encryption, but the principle of data minimization and the requirement to demonstrate compliance both favor end-to-end encryption, because it limits the number of parties who can access the data.

If you are a CPA firm, an attorney, or a financial advisor, you likely have professional obligations around client confidentiality that go beyond any specific regulation. Encrypted file transfer is not optional for you. It is a professional duty.

For most small businesses, the practical guidance is the same regardless of which regulation applies: encrypt files end-to-end, use expiring access, log who accessed what, and retain data only as long as required.

How Much Should Secure File Transfer Cost a Small Business?

Less than you think. The market has bifurcated into enterprise MFT platforms (typically $500 to $5,000+ per month, requiring IT staff to operate) and lighter tools aimed at individuals and small teams ($5 to $30 per user per month, requiring no technical setup).

For a small business, the expensive tools are not just unnecessary. They can be counterproductive. Several 2026 comparative guides show that the market response to the MFT breach epidemic has been to add more certifications, SSO integrations, and compliance checkboxes rather than rethink trust models. You end up paying more for a tool that is architecturally no different from the one that got breached, just with better paperwork.

The right price for a small business is whatever a tool costs that encrypts client-side, generates expiring links, and requires no IT administration. If you are paying more than $20 per user per month, you are likely paying for features you do not use.

What Does a Reasonable Setup Look Like in Practice?

Here is what a 5 to 15 person business with no IT staff can implement in an afternoon.

For sending files to clients: Use a tool that provides zero-knowledge encrypted file sharing with expiring links. Upload the file, set an expiration (24 to 72 hours is reasonable for most business documents), and send the link. If the tool supports password protection on the link, enable it and send the password via text or phone call. SelinaSEND does this: files uploaded fresh are zero-knowledge encrypted, meaning we cannot read them, and links expire on a schedule you set.

For receiving files from clients: Provide an upload portal rather than asking clients to email attachments. An upload portal with end-to-end encryption means the file is encrypted before it leaves the client's browser. You receive it encrypted. The hosting service never sees the plaintext.

For internal file sharing: Use encrypted cloud storage with client-side encryption for anything sensitive. For routine, non-sensitive files (the lunch menu, the office supply order), standard cloud storage with server-side encryption is fine. Not everything requires the strongest protection. Applying the same security level to every file creates friction that makes people circumvent the system entirely.

For AI-assisted document work: Pick one AI tool that does not train on your data and does not retain uploads beyond the session. Make it the only approved option. Put it in writing. A one-paragraph policy ("client documents may only be processed using [approved tool]") is better than no policy, even if enforcement is imperfect.

What Should I Avoid?

A short list, in order of how commonly small businesses make these mistakes.

Email attachments for anything sensitive. Standard email is plaintext in transit between mail servers. Even with TLS between your provider and the recipient's, the email is stored unencrypted on both servers. It is also forwarded, replied-to, and archived indefinitely in ways you cannot control.

Consumer-grade file sharing with no encryption controls. Free tiers of popular file sharing services typically offer server-side encryption only, meaning the provider holds the keys. Standard TLS protects data during delivery, but warehouse staff can open the package. If you are sending client tax returns or medical records through a consumer file-sharing link with no password and no expiration, you are one forwarded link away from a breach.

FTP. Classic FTP transmits credentials and data in plaintext. SFTP (SSH File Transfer Protocol) is the encrypted variant and is fine technically, but it requires server administration and is not something a non-technical team should self-manage. If a vendor tells you to upload via FTP (not SFTP), that is a red flag about their entire security posture.

USB drives. They get lost. They get stolen. They are not encrypted by default. If you must use a USB drive, use one with hardware encryption and a PIN. But really, do not use USB drives for sensitive file transfer in 2026.

Does "More Features" Mean "More Secure"?

No. Often the opposite. Every feature is code. Every line of code is a potential vulnerability. The MFT platforms that suffered mass breaches were not insecure because they lacked features. They were insecure because they had enormous attack surfaces: web interfaces, API endpoints, database connections, automation engines, third-party integrations. The bug classes behind the biggest MFT breaches are not exotic. SQL injection through an unsanitized web form broke MOVEit Transfer. Insecure deserialization broke GoAnywhere. These are well-known vulnerabilities in well-known code patterns.

For a small business, the heuristic is: fewer moving parts, fewer things that can break. A tool that does one thing (encrypted file transfer) and does it with client-side encryption is a smaller target than a tool that also does workflow automation, LDAP directory integration, scheduled batch processing, and multi-tenant administration. You do not need a Swiss Army knife. You need a lock.

What Questions Should I Ask Before I Send My Next Sensitive File?

Three. You can answer them in under a minute.

Can the hosting service read this file? If yes, the file is only as safe as the hosting service's security. Given the track record of the industry, that is not a bet you want to take with client data.

Does this link expire? If no, every file you have ever shared is still accessible to anyone who finds or guesses the URL. Expiration is not a nice-to-have. It is basic containment.

Did I send the password through a different channel than the file? If no, an attacker who intercepts one message has everything they need. Splitting the secret across two channels (the file via link, the password via text or phone) is the simplest form of two-factor security, and it costs nothing.

Those three questions, applied consistently, put you ahead of most businesses regardless of size. The goal is not perfection. The goal is making your data materially harder to steal than the business next door, because attackers, like water, follow the path of least resistance.

If you want a tool that handles the encryption, expiration, and access control so you do not have to think about it every time, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io