Tax Document Encryption Requirements: What the IRS Expects

Tax document encryption requirements come from two federal sources: the IRS Publication 4557 security standards and the Federal Trade Commission's Safeguards Rule under the Gramm-Leach-Bliley Act (GLBA). Together they require every tax preparer to encrypt client data at rest and in transit, including documents sent through the scan-to-email feature built into office copiers and multifunction printers. The GLBA scan-to-email encryption requirements are simple: any device that scans a W-2, a driver's license, or a Social Security card and emails it must route that transmission through TLS 1.2 or higher, the same standard that applies to every other email and cloud connection in the practice. Social Security numbers, bank account numbers, and completed tax returns are exposed the moment they leave an unencrypted scanner relay, long before the file ever reaches an inbox.

These requirements aren't abstract. According to the IRS Security Summit, more than 370 data breach incidents affected tax professionals in 2025, compromising roughly 458,000 client records. IBM's Cost of a Data Breach Report puts the average cost of a breached record in the financial services sector at $374, which means a breach touching just 200 client records runs about $74,800 in response costs alone, before any FTC penalty applies.

Encryption converts readable data into coded ciphertext that only someone with the correct decryption key can read. For a tax practice, two standards do almost all of the work.

Advanced Encryption Standard with 256-bit keys (AES-256) is the symmetric encryption algorithm the IRS and the National Institute of Standards and Technology (NIST) recommend for data at rest, meaning anything stored on a server, workstation, laptop, backup drive, or inside a scan-to-email device before it sends the file. A single shared key encrypts and decrypts the data, which is why AES-256 can protect an entire disk or database without a noticeable slowdown.

Transport Layer Security (TLS), the protocol that encrypts data while it moves across a network, covers everything in transit. IRS Publication 4557 sets TLS 1.2 as the floor and recommends TLS 1.3. This is the setting that determines whether a scan-to-email transmission, a cloud sync, or a client portal upload is readable if it's intercepted. Asymmetric encryption, used in tools like S/MIME email certificates, plays a smaller supporting role, typically handling key exchange and identity verification rather than encrypting bulk files. See our guide to symmetric versus asymmetric encryption for a full comparison.

IRS Publication 4557, Safeguarding Taxpayer Data, lists the specific controls examiners check for: encryption of all electronic taxpayer data at rest, AES-256 or equivalent strength with documented key management, TLS 1.2 minimum on every transmission channel, full-disk encryption on any device that touches taxpayer data (including scan-to-email capable printers and mobile devices), encrypted backups with keys stored separately from the backup media, and written documentation covering all of it. See our breakdown of the IRS Security Six checklist for the complete list of required controls.

The FTC's Safeguards Rule, issued under the Gramm-Leach-Bliley Act, classifies tax preparation firms as financial institutions and requires a Written Information Security Plan (WISP) documenting how the firm encrypts customer information. The FTC amended the rule in 2021, with full enforcement beginning in 2023, and as of 2026 civil penalties run up to $50,000 per violation, with potential criminal exposure for willful violations that cause client harm. A WISP that doesn't name specific algorithms, key management steps, and the devices they cover, including scanner and copier email relays, won't satisfy either regulator. For the specific role the rule assigns inside a firm, see our guide to the FTC Safeguards Rule qualified individual requirement.

Encryption is only as strong as the key management behind it. IRS Publication 4557 expects documented procedures for how keys are generated, stored separately from the data they protect, rotated (annually for most systems and quarterly for high-value databases), restricted to authorized staff, and destroyed when a system is retired. An enterprise password manager or a cloud key management service gives most small practices the access logging examiners look for without building anything custom.

Scan-to-email devices deserve the same scrutiny as a server. Many multifunction printers ship with an unauthenticated SMTP relay pointed at an internal mail server, which satisfies neither the TLS 1.2 minimum nor the access logging the FTC Safeguards Rule expects from a financial institution's customer information system. Check the device's network settings against the mail provider's encrypted relay requirements, and if the printer can't support TLS 1.2 or higher, route scanned documents through a secure client portal instead.

Encryption isn't a one-time project. IRS examiners expect proof of continuing compliance as a practice adds devices, staff, and software through the year, so build a quarterly check into the calendar: confirm device encryption is still active, retest the TLS configuration, review key access logs, and verify that any new scanner or printer meets the same TLS 1.2 standard as the rest of the network. For a broader seasonal checklist that covers more than encryption, see our tax season cybersecurity checklist, and review what a gap can cost in our breakdown of WISP penalties.