AegisAI Perspectives · 039
The Safeguards Rule accepts compensating controls instead of email encryption only where it is infeasible and your Qualified Individual approves them.
Yes, but only where encryption is infeasible: 16 CFR 314.4(c)(3) then allows effective alternative compensating controls reviewed and approved by your Qualified Individual2. AegisAI reads each outbound email for customer data, checks who it is going to and whether that is normal for the sender, then applies your policy. This piece covers the exception only. The duty itself is set out in Does the FTC Safeguards Rule require email encryption for customer information?, and the wider controls in What email security does a financial services firm need?
The rule requires encryption of all customer information held or transmitted, both in transit over external networks and at rest1. Customer information is any record with nonpublic personal information about a customer, in paper, electronic or other form9. In the 2021 final rule, the FTC said free or low cost encryption, particularly for data in transit, makes encryption feasible in most situations11.
It says one thing: where you determine encryption in transit over external networks or at rest is infeasible, you may secure the information with effective alternative compensating controls instead. The person who reviews and approves them is the Qualified Individual. That person oversees and enforces the information security program and may work for you, an affiliate or a service provider3.
Compare the wording with the multi-factor authentication clause. That clause accepts reasonably equivalent controls only where the Qualified Individual has approved them in writing4, a point covered in Does the FTC Safeguards Rule require multi-factor authentication for email accounts? The encryption clause says "reviewed and approved" and does not add "in writing".
The Qualified Individual's decision on alternate controls is subject to review in any enforcement action, and without a formal decision a choice not to encrypt is much more likely to be made with no compensating control13.
No. By default Exchange Online uses opportunistic TLS and sends the message without encryption when the recipient's organization does not support TLS15. Gmail behaves the same way: it tries TLS, and if the receiving server does not use it, Gmail still sends the message over a connection that is not secure20.
The rule text names two states for customer information in transit over external networks: encrypted, or secured by approved compensating controls where encryption is infeasible. A default fallback is neither, until someone makes the decision. RFC 8461 describes the same weakness from the protocol side and defines MTA-STS, whose enforce mode tells sending servers not to deliver without TLS and a valid certificate22.
Work through the paths that carry customer information to outside recipients.
List every outbound path that carries customer information, such as statements, loan files or payoff letters. Use the rule's definition, which covers any record with nonpublic personal information.
Require TLS for each partner domain that supports it. In Exchange Online that means connectors, one for mail sent to user mailboxes and one for mail sent from them16. In Gmail it is the Secure transport (TLS) compliance setting, which bounces outgoing mail to listed domains over non TLS connections21.
Publish an MTA-STS policy in enforce mode for your own domain, so servers sending customer replies to you refuse delivery without TLS.
Encrypt the message itself where a recipient cannot take required TLS. An Exchange mail flow rule can require encryption for all messages to a specific recipient or with specific words in the subject18. Recipients outside Outlook read it through the encrypted message portal.
Only where steps 2 to 4 are infeasible for a named path, write the infeasibility finding: the path, then the options tested with the reason each failed.
Name the compensating control for that path and have the Qualified Individual review and approve it. Carry the decision into the written report to the board, which covers risk management and control decisions at least annually5.
Cover key handling in the same record. The rule's definition of encryption includes appropriate safeguards for key material7, and data counts as unencrypted if an unauthorized person accessed the key8.
Re-run the review whenever a service provider handles the mail. If the provider cannot encrypt, the Qualified Individual works with it on compensating controls or the firm stops doing business with it14.
AegisAI reads who is sending sensitive data to whom and whether that is normal for the sender, then applies your policy23. Its agents look at the content and the attachment as well as the recipient and the sender's habits. It finds personal and financial data plus secrets on every outbound email and runs on the API connection inbound already uses, with no MX change. A policy runs in audit on live outbound mail and is then raised to alert, and a held message is logged with the rule that fired. Pre delivery blocking is not available on Google Workspace.
Each row is one setting or decision, with the clause or platform page behind it.
| Option | What it protects | Where it is set | What happens when it cannot apply |
|---|---|---|---|
| Opportunistic TLS | The connection, when the recipient supports TLS | Default in Exchange Online and Gmail | Message is sent without encryption |
| Required TLS per domain | The connection to listed domains | Exchange connectors; Gmail Secure transport (TLS) compliance | Outgoing mail bounces |
| MTA-STS, enforce mode | Connections into your own domain | Policy published by the receiving domain | Sending servers must not deliver |
| Message encryption | The message contents | Exchange mail flow rule | Recipient reads through a portal |
| S/MIME | The message contents | Named by Microsoft as a message encryption option17 | Not stated in the sources used here |
| Compensating control | What the approval names | Qualified Individual review and approval | Only where encryption is infeasible |
Illustrative example, figures are fictional. A consumer lender holds records on 12,000 consumers and emails payoff letters to 40 title companies. Required TLS covers 37 domains. Three domains bounce. Two of them accept portal message encryption. The third runs an intake system that parses attachments and cannot open the portal. The Qualified Individual records the finding for that one domain: required TLS and message encryption were tested and failed. The approved control sends that domain a loan reference only, with no names or account numbers, and an outbound policy in audit flags any message to the domain that carries customer data. The approval names a review date 90 days out.
The rule text gives size no exemption from encryption. The small firm exception in 314.6 lists sections 314.4(b)(1), (d)(2), (h) and (i), and (c)(3) is not on that list10.
The failures sit at the recipient's end. Opportunistic TLS falls back to plain delivery, and portal message encryption asks recipients outside Outlook to authenticate in a portal. TLS also protects the connection and not the message, so a message forwarded on to a server without TLS is not necessarily encrypted. The FTC's view on cost stays the starting point: free or low cost options make encryption feasible in most situations.
It covers two cases: encryption in transit over external networks and encryption at rest. Internal networks are outside the requirement, because the FTC declined to extend encryption to data sent over them12.
The exception also reaches service providers. A provider that cannot encrypt puts the decision back on the Qualified Individual, who develops compensating controls with it or ends the relationship. In both cases the FTC called the approach flexibility to adopt alternatives with the Qualified Individual's approval.
The rule names none. It accepts "effective alternative compensating controls" and leaves the choice to the Qualified Individual.
Required TLS and message encryption are not alternatives in this sense. Microsoft describes TLS as encrypting the connection and Purview Message Encryption or S/MIME as encrypting the contents. Both are encryption, so they come before the exception. A control such as removing customer data from a message, or a policy that flags customer data going to an untrusted path, is the kind of decision the Qualified Individual approves and the FTC reviews.
Record six items for each email path that uses the alternative. The FTC said this decision is reviewed in any enforcement action.
Change settings on the platform you already run. Exchange Online forces TLS through two connectors. Gmail's Secure transport (TLS) compliance setting sits under Apps, Google Workspace, Gmail, Compliance, and changes take up to 24 hours. An Exchange mail flow rule adds message encryption for chosen recipients or subject words.
Each is a setting on an existing tenant. The compensating control route is for the paths these settings cannot reach, and only with the Qualified Individual's approval.
Track three numbers and where each lives.
Yes, in one case. Where encryption in transit over external networks or at rest is infeasible, 16 CFR 314.4(c)(3) accepts effective alternative compensating controls reviewed and approved by your Qualified Individual.
The encryption clause says "reviewed and approved" and does not say "in writing". The MFA clause does say "in writing". The FTC said the decision is reviewed in any enforcement action.
Yes. The 314.6 exception removes sections 314.4(b)(1), (d)(2), (h) and (i) for firms with records on fewer than 5,000 consumers. The encryption duty in 314.4(c)(3) is not among them.
Opportunistic TLS sends without encryption when the recipient does not support TLS, in Exchange Online and in Gmail. Required TLS per domain closes that fallback.
Customer information counts as unencrypted if an unauthorized person accessed the key. A notification event involving at least 500 consumers must be reported to the FTC within 30 days of discovery.
No. The FTC declined to extend the encryption requirement to data transmitted over internal networks.
