Compensating controls for FTC Safeguards Rule encryption exceptions: how do you document them?

If you run a tax practice, a dealership finance office or a mortgage brokerage, and one of your systems holds customer information without encryption (an older line-of-business database, a scanner, a partner portal), the FTC Safeguards Rule allows that only in a narrow case. Encryption has to be infeasible, and your Qualified Individual has to approve compensating controls. Here is how to tell a legitimate exception from an unfinished project, which compensating controls hold up, and how to document the decision so it stands up to an FTC inquiry, an audit or a breach.

What does the Safeguards Rule say about encryption?

It requires encryption by default and allows one narrow exception. 16 CFR 314.4(c)(3) directs you to protect by encryption all customer information you hold or transmit, both in transit over external networks and at rest. If encryption of that information is infeasible, you may instead secure it with "effective alternative compensating controls reviewed and approved by your Qualified Individual."

The rule also defines what counts as encryption. Under 16 CFR 314.2(f), data is encrypted when it has been transformed so there is a low probability of assigning meaning without a protective process or key, "consistent with current cryptographic standards and accompanied by appropriate safeguards for cryptographic key material." A password-protected spreadsheet or an outdated cipher may not meet that bar, and neither does strong encryption whose keys sit next to the data. For how examiners test the encryption you do have, see our guide to GLBA encryption evidence.

The rule reaches non-bank financial institutions under FTC jurisdiction: tax preparers, auto dealers that arrange financing, mortgage brokers, non-bank lenders and investment advisers that are not registered with the SEC, among others. SEC-registered advisers and broker-dealers answer to Regulation S-P instead.

When is encryption "infeasible"?

The rule does not define the word, so the judgment belongs to your firm and your Qualified Individual. In the 2021 final rule, the Commission declined to change the encryption requirement and noted that "every aspect of an information security program is based on the judgment of the financial institution and its staff." Its worked example was a pawnbroker with required transmissions that could not be encrypted; the Qualified Individual would need to implement alternative compensating controls to keep that information secure during those transmissions.

Infeasible is a stronger word than inconvenient. The cases that hold up tend to involve a real technical limit: a legacy line-of-business application whose database cannot be encrypted at rest, a government or partner portal that only accepts an unencrypted channel, or a specialized device that stores scanned documents and offers no encryption setting. An exception whose only stated reason is project cost or staff time is much harder to defend, and the approval record should say plainly why encryption cannot be used today.

What are compensating controls, and when are they effective?

Compensating controls are alternative safeguards that reduce the same risk a required control would have addressed when that control cannot be used. Under the Safeguards Rule, an effective one reduces the risk encryption would have addressed, for the same data. Encryption at rest protects against stolen devices, copied databases and backups that leave your control. Encryption in transit protects against interception. A compensating control should answer the specific threat, and the record should say which one.

Examples of compensating controls that commonly appear in encryption exception records include:

• Encrypting at a different layer, such as full-disk encryption on the server or storage that hosts an application database the application itself cannot encrypt.
• Network segmentation that isolates the system so only named users and services can reach it.
• Tighter access control and logging on that system, beyond the baseline the rule already requires.
• Physical controls for paper or devices, such as locked storage and restricted rooms.
• Data minimization, keeping only the fields the process needs and purging the rest on schedule.

Be careful with controls the rule already requires everywhere. Access controls under 314.4(c)(1), multi-factor authentication under (c)(5), secure disposal within two years under (c)(6) and activity monitoring under (c)(8) are baseline obligations. Listing them alone as the compensating control shows nothing extra was done for the unencrypted data.

Does the exception have to be in writing?

The encryption text does not say "in writing," but you will want it written anyway. Compare the multi-factor authentication exception in 314.4(c)(5), which the FTC's business guidance describes as available only if "your Qualified Individual has approved in writing the use of another equivalent form of secure access controls." The encryption exception requires review and approval without naming a format. In practice, a dated, signed record is the only way to show the FTC, an auditor or your board that the review took place and what was approved.

The record also feeds two other obligations. Your written risk assessment under 314.4(b)(1) should rate the risk the exception leaves behind, and the Qualified Individual's annual written report to the board under 314.4(i) covers material matters such as risk assessment and security events. An open encryption exception on a core system is the kind of item that belongs in that report. If your Qualified Individual works for a service provider, the FTC's guidance is direct: "the buck still stops with you," and a senior employee at your firm supervises that person. We cover what belongs in that report in our guide to the Qualified Individual's board report.

What should an exception record include?

Enough that someone outside your firm could read it and agree with the decision. A workable record covers:

• The system, the customer information it holds, and whether the gap is at rest, in transit or both.
• Why encryption is infeasible, with the vendor statement or technical evidence behind it.
• The specific risk encryption would have reduced and the compensating controls that address it.
• Evidence the controls are in place, such as a configuration export or access report.
• The Qualified Individual's name, signature and approval date.
• A review or expiry date, and the plan to remove the exception, such as a software upgrade or vendor change.

The review date matters because 314.4(g) requires you to evaluate and adjust the program when testing, monitoring, operational changes or risk assessments call for it. An exception approved three years ago for software you have since upgraded is a finding waiting to happen.

What happens if an exception system is breached?

The data counts as unencrypted for breach purposes, whatever compensating controls you had. A notification event under 314.2(m) is the unauthorized acquisition of unencrypted customer information, and information is also treated as unencrypted if the encryption key was accessed by an unauthorized person. If a notification event involves at least 500 consumers, 314.4(j) requires notice to the FTC as soon as possible and no later than 30 days after discovery. Our walkthrough of the FTC breach reporting form covers the filing itself.

This is the practical cost of an exception. Encryption can turn a lost laptop into a non-event under the rule. A compensating control may lower the odds of a breach, but once the data is taken, it does not change the reporting outcome. That trade-off is worth stating in the approval record so the Qualified Individual signs with it in view.

Does the small-firm exemption change any of this?

No, the encryption requirement still applies. 16 CFR 314.6 exempts institutions that maintain customer information on fewer than 5,000 consumers from four provisions: the written risk assessment in 314.4(b)(1), continuous monitoring or annual penetration testing in (d)(2), the written incident response plan in (h) and the annual board report in (i). Encryption under (c)(3), and the Qualified Individual's approval of any exception, are not on that list. For a small tax practice, the exception record may be the only written place the decision lives, which is one more reason to keep it.

What should you do this quarter?

• List every system that stores or transmits customer information and confirm encryption at rest and in transit for each, including backups, scanners, email and file transfer.
• For each gap, decide whether encryption is truly infeasible or simply not done yet. Fix the second group.
• Write an exception record for each true exception and have your Qualified Individual sign and date it.
• Check where encryption keys are stored and who can reach them, since key access turns encrypted data into unencrypted data under the rule.
• Put open exceptions in the next board report and set a review date for each.

How can s90 help?

s90 maintains encryption coverage reports and an exception register as part of its FTC Safeguards Rule compliance work, so your Qualified Individual reviews a current list instead of building one from memory. When an examiner, auditor or insurer asks for evidence, our agreements commit to producing it within 24 hours. If you would like a second look at an exception you have already approved, we are happy to talk it through.