The short version
The FTC Safeguards Rule (16 CFR Part 314), enforced under the Gramm-Leach-Bliley Act, treats professional tax preparers and accounting firms as "financial institutions." Since 9 June 2023 that carries a specific, enforceable obligation: a written information security program, the WISP, and inside it a set of technical safeguards that include encrypting customer information in transit and at rest, and multi-factor authentication for anyone who accesses it. IRS Publication 4557 restates the same duty for taxpayer data, and the IRS states plainly that tax professionals are legally required to have a written security plan.
None of this makes any single tool "compliant." Compliance is a property of your firm's program, not a checkbox a vendor holds. But the tools you use to send returns, workpapers, and source documents to clients are where a large share of that customer information actually moves, so they either satisfy the technical safeguards the Rule names or they quietly undercut them. This page maps the file-sharing-specific requirements to what to look for, in plain terms, and is honest about where the line between the tool's job and your firm's job sits.
This is not legal advice. Confirm how the Rule applies to your firm with your Qualified Individual or counsel. The facts below cite the FTC's and IRS's own current guidance.
Are you actually covered?
In almost every case, yes. The Safeguards Rule applies to businesses "significantly engaged" in providing financial products or services, and the FTC and the professional bodies are consistent that this includes professional tax preparers and CPA firms handling client financial data. It is not tied to a return-count threshold, so a two-person practice is covered the same as a large firm.
There is a size-based tailoring, but it does not get a small firm off the hook on file sharing. Firms that maintain information on fewer than 5,000 consumers are relieved of some program-level obligations (a written risk assessment, a written incident-response plan, an annual report to a governing body), but the core technical safeguards, encryption of customer information in transit and at rest, multi-factor authentication, and secure disposal, still apply. So "we're small" is not a reason the file-sharing safeguards below stop mattering.
What the Rule requires, and which part is the tool's
The WISP the Rule requires is a whole program, not a feature. At a minimum it names a Qualified Individual to run it, documents a risk assessment, and puts in place access controls, encryption, multi-factor authentication, monitoring and logging, secure disposal, service-provider oversight, an incident-response plan, and staff training. Most of that lives in your firm, not in any product you buy.
A file-sharing tool touches five of those safeguards directly. These are the ones to hold a tool to:
- Encryption in transit and at rest. Client files must be encrypted while moving and while stored. The Rule allows the Qualified Individual to approve compensating controls where encryption is infeasible, but for file sharing it rarely is, so encryption is the expectation.
- Access controls and MFA. Only authorized people reach customer information, and access is protected by multi-factor authentication. For a client-facing tool, that also raises a design question: do clients have to create accounts (and weak passwords), or can they use a no-account upload or download link?
- Monitoring and logging. You can show who accessed what and when, which means the tool needs a real access log by user and timestamp.
- Secure disposal. Customer information is disposed of when no longer needed, which for transfers means link expiry, revocation, and deletion you can evidence.
- Service-provider oversight. You are required to select and retain providers capable of maintaining appropriate safeguards, and to bind them contractually. In practice that means a data processing agreement with each file-sharing vendor, and knowing which legal jurisdiction governs the data.
The requirement the Rule states, and the question it is really about
The Rule says "encrypt at rest." A tool that stores your files with provider-managed AES-256, where the vendor holds the keys, satisfies the literal wording. This is worth stating clearly so nobody misreads the rest of this page: choosing a provider-managed, provider-decryptable tool is not non-compliant. The mainstream accounting file-sharing suites work this way and are used compliantly every day.
But the reason the Rule requires encryption at all, keeping customer data unreadable to parties who should not read it, is only partially served when the provider can decrypt at will, whether by choice, by breach, or by legal compulsion. Zero-knowledge (client-side) encryption is the model where the provider mathematically cannot read content, because files are encrypted on the device before upload and the server only ever holds ciphertext. The Rule does not mandate that model. It is simply the stronger answer to the confidentiality the Rule is trying to protect, and the difference only matters for your most sensitive files, the ones where "who could technically read this" is a question you would not want to answer with "the vendor, and anyone who reaches the vendor's keys."
Retention turns encryption into a long-term bet
Tax returns and workpapers are not transient. Firms commonly retain client records for three to seven years, and often longer for their own liability. That retention horizon interacts with an emerging risk the Safeguards Rule does not address: "harvest now, decrypt later," where an adversary copies encrypted data today and decrypts it once quantum computers mature. NIST finalized its post-quantum key-encapsulation standard, ML-KEM (FIPS 203), in 2024 precisely for long-lived data of this kind.
To be exact, because this is a compliance page and not a sales page: the FTC Safeguards Rule does not require post-quantum encryption, and no firm is out of compliance for using classical AES today. But if you are deciding where seven years of client returns will physically sit, the shelf life of the algorithm protecting them is a fair question to put on the list. It is the one place where the retention period and the choice of cryptography actually intersect.
A file-sharing checklist mapped to the Rule
Use this to evaluate any tool you send client files through. The left column is the safeguard; the middle is what to require of the tool; the right is where to verify it.
| Safeguard the Rule names | What to require of a file-sharing tool | Where to verify |
|---|---|---|
| Encrypt customer info in transit | TLS on every upload and download | Vendor security page |
| Encrypt customer info at rest | Encryption at rest, and a clear answer to who holds the keys | DPA / security whitepaper |
| MFA for access to customer info | MFA on the tool's accounts; ideally no-account links so clients avoid weak logins | Account security settings |
| Access controls / least privilege | Per-file or per-link access, expiry, and revocation | Product documentation |
| Monitoring and logging | An access log by user and timestamp | Product documentation |
| Secure disposal | Link expiry, revocation, and deletion you can evidence | Product documentation |
| Service-provider oversight | A signed DPA that binds the vendor to protect the data; a known legal jurisdiction | Vendor DPA / contract |
The two rows that separate genuinely-confidential handling from the baseline are "who holds the keys" and "which jurisdiction governs the data." Those are the answers your clients are trusting you to get right, and neither is visible in a feature grid.
Where ShieldFive fits, and where your WISP still does the work
ShieldFive encrypts files on the device before upload and stores encrypted file data in the EU. Your password never reaches our servers: the browser turns it into a separate login value with Argon2id and sends only that, and the key that opens the vault is derived separately and stays on the device. That service remains part of the trust boundary; this is not an absolute provider-cannot-decrypt guarantee. Web uploads default to ML-KEM-1024/XChaCha20-Poly1305 with AES-GCM fallback. Android also defaults to the hybrid format, with the same AES-GCM fallback, and reads both formats. The crypto core is open source, but the apps are not fully open source and no external security audit has been completed. Review these limits before including the service in your information-security program. The accounting workflow page describes document requests and client uploads.
What it does not do, stated plainly, because a compliance page that oversells is worse than useless:
- It is not your WISP and does not write one. The Rule requires a Qualified Individual, a risk assessment, an incident-response plan, staff training, and MFA and monitoring across all your systems, email, workstations, tax software, not just file sharing. A tool is one control inside a program you own.
- It carries no SOC 2, ISO 27001, or any third-party certification yet. Its evidence today is open code and a published internal security review. If a client's vendor review requires a named certificate, ShieldFive does not have one.
- It provides no US HIPAA Business Associate Agreement. Healthcare-adjacent engagements need a separate arrangement regardless of the encryption.
- It has no tax-software integration, e-signature, or client-portal workflow. It is the encryption layer, not the practice suite, and it does not replace SmartVault, ShareFile, TaxDome, or Suralink.
ShieldFive can be evaluated as a client-side encrypted transfer tool, with the client-code trust boundary and workflow limitations described above. For the practical requirements on the file-sharing side, the vendor-by-vendor comparison of the workflow suites ShieldFive does not replace, and the persistent-workspace branch rather than per-document transfers, see the accountant file sharing tools comparison.
What to do next
- Get the WISP written. The IRS publishes a free 28-page template, Publication 5708, built for tax and accounting practices. It is the fastest way to a defensible plan.
- Inventory where client information moves, and pin down encryption, key custody, and MFA at each point, not only in file sharing but in email and on workstations.
- Put a DPA in place with each vendor and record its jurisdiction, so the service-provider-oversight safeguard is documented rather than assumed.
- For your highest-liability documents, decide whether "the provider cannot read this" is a requirement. If it is, use one of the zero-knowledge providers we compare side by side for that slice and keep your workflow suite for everything else.
Regulatory facts on this page reflect the FTC's and IRS's published guidance as of 2026-07-20 and will be updated as the guidance changes. This is general information, not legal advice; confirm how the Safeguards Rule and IRS data-security obligations apply to your firm with your Qualified Individual or counsel before relying on it.