The ‘Unencrypted’ Loophole: Why Encryption is Your Only Shield

The fallout from the CDK attack forced thousands of dealers to confront a hard question: if your data is stolen, are you legally required to report it? The answer depends entirely on one word in the FTC Safeguards Rule: unencrypted.

The Regulatory Text: 16 CFR 314.4(j) and 314.2(m)

The breach notification requirement lives in 16 CFR 314.4(j)(1), which states:

“Upon discovery of a notification event, if the notification event involves the information of at least 500 consumers, you must notify the Federal Trade Commission as soon as possible, and no later than 30 days after discovery of the event.”

The critical definition is in 16 CFR 314.2(m), which defines what triggers this notification:

Notification event means acquisition of unencrypted customer information without the authorization of the individual to which the information pertains. Customer information is considered unencrypted for this purpose if the encryption key was accessed by an unauthorized person.

The rule further states that unauthorized acquisition is presumed to include unauthorized access to unencrypted customer information unless you have reliable evidence showing that there has not been, or could not reasonably have been, unauthorized acquisition of such information.

That presumption is important. If an attacker accessed unencrypted data, the burden is on you to prove they did not take it.

What “Encrypted” Actually Means to the FTC

The FTC Safeguards Rule is technology-neutral, meaning it does not name specific algorithms. However, the standard of “current industry standards” effectively maps to algorithms validated under FIPS 140-2 or FIPS 140-3. In practice, this means:

• Symmetric encryption (data at rest): AES-128, AES-192, or AES-256. AES-256 is the industry standard and the safest choice.
• Asymmetric encryption (key exchange): RSA with a minimum 2048-bit key (3072-bit preferred) or ECDSA/EdDSA with at minimum a P-256 curve.
• Data in transit: TLS 1.2 or TLS 1.3. Older protocols (SSL 3.0, TLS 1.0, TLS 1.1) are retired and do not satisfy the requirement.
• Hashing: SHA-256 or stronger. MD5 and SHA-1 are officially retired by NIST.

Using deprecated algorithms is the same as having no encryption at all in the FTC’s eyes.

Encryption at Rest: What It Means for Your Dealership

For a dealership, “data at rest” includes everything stored on your servers, workstations, cloud databases, and backups. This means:

• DMS databases containing customer SSNs, credit applications, and financial records must be encrypted.
• Deal jacket files, whether stored digitally in your DMS or scanned as PDFs on a file server, must be encrypted.
• Backup media, including offsite tapes, USB drives, and cloud backup repositories, must be encrypted independently of the source system.
• Endpoint devices used by F&I managers, sales staff, and service advisors must use full disk encryption (BitLocker on Windows, FileVault on macOS).

Not all encryption methods are equal in a breach scenario. There are critical distinctions:

• Full Disk Encryption (FDE): Protects against physical theft of a device, such as a stolen laptop. However, on a running system where the disk is unlocked, an attacker with remote access can read the data in plaintext. FDE alone does not protect you during a network intrusion.
• Transparent Data Encryption (TDE): Encrypts database files on disk, protecting against theft of backup files or physical drives. Like FDE, it is typically “unlocked” while the database is running, leaving data vulnerable during a live breach.
• Application-Level or File-Level Encryption: This is the strongest approach. Data is encrypted and decrypted per-operation, with keys fetched individually. Even during a live system breach, the attacker must separately compromise the key management system to read the data. This is the method most likely to satisfy the 314.2(m) carve-out during an active intrusion.

Encryption in Transit: Protecting Data on the Move

Every connection that moves customer data must use modern encryption:

• Web traffic between your website and customers submitting credit applications must use TLS 1.2 or 1.3.
• Email containing customer PII should use TLS-enforced transport or encrypted email services. Sending SSNs over unencrypted email is a violation waiting to happen.
• File transfers to lenders, insurance providers, and service contract companies must use SFTP, FTPS, or encrypted API connections.
• VPN connections to your DMS provider or between dealership locations must use current encryption standards.

Key Management: Where Most Dealers Fail

The 314.2(m) definition contains a critical clause: data is considered unencrypted if the encryption key was accessed by an unauthorized person. This means key management is not optional; it is the linchpin of the entire encryption defense.

NIST SP 800-57 provides the framework for key management best practices:

• Separation of keys from data: Never store encryption keys on the same server as the encrypted data. Use a dedicated Key Management Service (KMS), Hardware Security Module (HSM), or a secure vault solution.
• Separation of duties: No single person should have the ability to both manage encryption keys and access the encrypted data.
• Key rotation: Establish defined cryptoperiods, meaning scheduled intervals for rotating keys. This limits exposure if a key is compromised.
• Key inventory: Maintain a documented inventory of all encryption keys, their purpose, their expiration, and their custodian.
• Secure destruction: When keys reach end-of-life, they must be securely destroyed using approved methods.

If your encryption keys live in a configuration file on the same server as your customer database, you have effectively left the vault door open with the combination taped to the wall. The FTC will not consider that data encrypted.

The Ransomware Reality Check

Here is where many dealers get a false sense of security. In a modern double-extortion ransomware attack, the attacker first exfiltrates (steals a copy of) your data, then encrypts your systems and demands payment.

The question is: if your data was encrypted at rest, but the attacker accessed it through a running system where the database was “transparently” decrypted for normal operations, does the carve-out still apply?

The answer is almost certainly no. If the attacker operated within a live environment where data was accessible in plaintext, or if they extracted the encryption keys from memory or configuration files, the FTC treats that data as unencrypted under 314.2(m). Only application-level encryption, where data remains encrypted until individually decrypted by an authorized process with separately secured keys, is likely to hold up.

Documenting Your Encryption Posture

The carve-out only helps you if you can prove your encryption was in place and the keys were not compromised. For an FTC audit, maintain:

1. Your Written Information Security Plan (WISP) explicitly identifying which encryption methods protect which data stores.

2. FIPS validation records proving your encryption modules are certified.

3. A key management policy based on NIST SP 800-57, documenting rotation schedules, access controls, and destruction procedures.

4. Logs from your KMS or HSM showing that encryption keys were not accessed by unauthorized parties during an incident.

5. The Qualified Individual’s annual report to leadership, which must include a status update on the encryption program.

Encryption is not just a technical control. It is a strategic legal defense that can mean the difference between a quiet internal incident and a public FTC notification that invites lawsuits, media coverage, and regulatory scrutiny. If you are not 100% certain about your encryption posture, you are gambling with your dealership’s future.