Tax preparers and the FTC Safeguards Rule: collecting client documents

The FTC Safeguards Rule is 16 CFR Part 314. Its definition of a financial institution gives this example: “An accountant or other tax preparation service that is in the business of completing income tax returns is a financial institution” (16 CFR 314.2). IRS Publication 5708 says tax and accounting professionals are considered financial institutions “regardless of size” (Publication 5708).

The core obligation is in 16 CFR 314.3(a): develop, implement and maintain an information security program “that is written in one or more readily accessible parts,” with safeguards appropriate to your size and complexity, your activities and the sensitivity of the information. The IRS calls this document a written information security plan, or WISP.

A firm that maintains customer information about fewer than 5,000 consumers is exempt from four requirements: the written risk assessment, continuous monitoring or periodic penetration testing, the written incident response plan, and the annual written report to a board (16 CFR 314.6). It is not exempt from the written program, from encryption or from multi-factor authentication.

Publication 4557, Safeguarding Taxpayer Data (revised June 2024), states that under the Safeguards Rule “tax return preparers must create and enact security plans to protect client data,” and that failure to do so “may result in an FTC investigation.” Its checklist includes encrypting “all sensitive files/emails” and, if sensitive data must go by email, encrypting it; it suggests secure file transfer instead of email.

Publication 5708, Creating a Written Information Security Plan for your Tax & Accounting Practice (revised August 2024), is a template. Its sample policy on electronic exchange says PII will not be emailed in plain text “unless encryption or password protection is present,” that passwords must reach the recipient by a different method than the data, and that the firm “may use a Password Protected Portal to exchange documents containing PII” once the firm’s data security coordinator has approved its protocols.

The PTIN form asks about the same obligation. Line 11 of Form W-12, the PTIN application and renewal form (revised October 2025), asks the preparer to answer yes or no to: “I am aware that paid tax return preparers are required by law to create and maintain a written information security plan that provides data and system security protections for all taxpayer information.”

Encryption, 16 CFR 314.4(c)(3): “Protect by encryption all customer information held or transmitted by you both in transit over external networks and at rest.” Where that is infeasible, you may instead use “effective alternative compensating controls reviewed and approved by your Qualified Individual.” The rule defines encryption as a transformation giving “a low probability of assigning meaning without the use of a protective process or key,” with “appropriate safeguards for cryptographic key material” (16 CFR 314.2).

Access, 16 CFR 314.4(c)(1): authenticate and “permit access only to authorized users,” and limit each user’s access “only to customer information that they need to perform their duties and functions.” Multi-factor authentication, 314.4(c)(5): required “for any individual accessing any information system,” unless your Qualified Individual approves in writing an equivalent or more secure control.

Two more paragraphs bear on document intake. 314.4(f) requires you to select service providers “capable of maintaining appropriate safeguards,” to require those safeguards by contract and to assess the providers periodically; any tool that stores your clients’ uploads is such a provider. 314.4(c)(6) requires procedures to dispose of customer information “no later than two years after the last date the information is used” to serve the client, with limited exceptions.

The rule names outcomes, not products, and does not mention end-to-end encryption. Encryption in transit and at rest with keys the provider manages matches the wording of 314.4(c)(3). What end-to-end encryption changes is who else can read the files, which matters for your risk assessment and for how much you rely on the provider’s own safeguards.

Client portals and mainstream file-sharing services can meet the rule. Publication 5708’s own template lists a password-protected portal as a way to exchange documents, and a provider that encrypts in transit and at rest and agrees by contract to maintain safeguards fits what 314.4(c)(3) and 314.4(f) ask for. If your practice software already includes a portal your clients use, that is a reasonable default.

Plain email is the method the IRS material argues against most directly. Publication 4557 says a legitimate business “will never email and request personal or sensitive information be sent to them via email, unless through a secured mail service,” and its checklist tells firms to caution customers against sending sensitive data by email.

A password-protected attachment meets the wording of the sample policy but moves the work to the client, who has to create an encrypted file and send the password separately. Many will not, and the file still sits in both mailboxes.

Google Drive has no upload-only request link. The usual workaround, a Google Form with a file-upload question, requires respondents to sign in to a Google account (Google Forms help).

End-to-end encrypted request links go further than the rule requires on one point: the provider holds only ciphertext, which limits what a breach at the provider exposes. They do not take the provider off your service-provider list, and they do not do the workflow work a portal does.

ShieldFive File Request sends the client one link. The client opens it without an account, enters a PIN you gave them separately, and uploads. Each file and its filename is encrypted in their browser to your firm’s public key, a hybrid of ML-KEM-1024 and X25519, and the server stores only ciphertext; you decrypt in your own browser. Your firm account supports an authenticator-app code as a second sign-in factor, off until you turn it on. Creating requests needs a free ShieldFive account; the client never signs up.

What it does not do well: chasing. On Firm seats (and during the trial), if you add the client’s email, ShieldFive reminds them at most twice, after about three and seven days, while required items are missing. The reminder cannot contain the upload link, because the decryption key never reaches our server, so it points the client back to the link you sent. You also get a reminder to follow up. There are no recurring requests; you create a new request each time. Expiring or revoking a link stops new uploads, but files already received stay in your account until you delete them, so your disposal schedule still applies.

Like any web app, we serve the JavaScript that does the encryption. The guarantee is “encrypted in the client’s browser, ciphertext at rest”, not a claim that no compromised server could ever interfere. The request security page sets out the threat model.

Publication 5708’s outline asks for a data collection and retention policy: the minimum PII you collect, who can access it, where it is stored and in what format, and when it is destroyed. For document intake, write down:

Method. The tool clients use to send documents, and that PII is not accepted by plain email. If a client emails a document anyway, what staff do with it: save it to the approved location and delete it from the mailbox.

Encryption. How the method protects files in transit and at rest (314.4(c)(3)), and who holds the keys.

Access. Which staff can open received documents (314.4(c)(1)), and that their accounts use multi-factor authentication (314.4(c)(5)).

Passwords and PINs. That any password or PIN for a file or link goes by a different channel from the file or link, as Publication 5708’s sample policy requires.

Service provider. The vendor, the contract or terms that require it to maintain safeguards, and when you last reviewed it (314.4(f)).

Retention and disposal. How long intake documents are kept, where the working copy lives, and when uploads and links are deleted: no later than two years after last use unless an exception applies (314.4(c)(6)).

Incidents. Who to contact at the vendor, and the FTC duty in 314.4(j): an event involving the information of at least 500 consumers must be reported to the FTC as soon as possible and no later than 30 days after discovery.

This page summarises public rule text and IRS guidance as of the date at the top, with a link to each source. It is not legal advice and does not tell you whether your practice complies. The rule scales its requirements to your size and risk; for decisions about your own plan, read the sources and, where needed, ask a lawyer or a security professional who knows your practice.