If you search “FTC Safeguards Rule requirements,” you’ll find dozens of articles that explain what the nine requirements are. They walk you through the rule, define the terms, and end with a checklist.
What they don’t tell you is which requirements companies actually fail, and by how much.
This post does that. What follows is a ranking of all nine FTC Safeguards requirements from easiest to hardest, based on what we see during real compliance assessments and penetration tests across auto dealerships, mortgage companies, tax preparers, and other covered financial institutions.
If you’re self-assessing, this is where to spend your time. If you’re already working with a consultant, use this as a gut check.
—
A Quick Primer: Who the FTC Safeguards Rule Covers
The FTC Safeguards Rule applies to financial institutions under the FTC’s jurisdiction, a definition that’s broader than most people realize. Auto dealerships offering financing. Mortgage brokers and lenders. Tax preparers. Payday lenders. Accountants. Retailers with private label credit programs. If your business handles customer financial information and falls under FTC jurisdiction (not a bank, credit union, or entity regulated by another federal body), the Safeguards Rule likely applies to you.
The rule was amended in December 2021, and the substantially updated prescriptive technical requirements took effect on June 9, 2023. The days of vague “reasonable security” language are mostly gone. Now there are specific provisions for encryption, MFA, penetration testing, and incident response.
With that context, here’s the ranking.
!The Three Tiers of FTC Safeguards Compliance
—
Tier 1: Where Companies Pass (Usually)
#9: Designate a Qualified Individual
Failure Rate: Low
This one is straightforward: someone at your company must be responsible for the information security program. For larger organizations, that’s a CISO or IT director. For smaller businesses (a single-location auto dealer, a boutique mortgage broker) the rule explicitly permits using an outside service provider for this role.
Most companies get this right because it’s the most visible requirement. There’s a name on a document. The harder question the rule raises, and that auditors sometimes probe, is whether that person has the authority, budget, and access to actually do the job.
Where it fails: The Qualified Individual is a figurehead. They’re “responsible” on paper but haven’t reviewed the security program in 18 months and don’t have authority to enforce controls.
—
#8: Train Staff
Failure Rate: Low-to-Moderate
Annual security awareness training is well understood and widely implemented. Most companies use a third-party platform (KnowBe4, Proofpoint, etc.), run phishing simulations, and keep records.
Where it fails: Training is completed but never validated. The team clicks through a 15-minute annual module and calls it done. No one tests whether the training changed behavior. Phishing simulation failure rates stay high year over year and no one escalates.
—
#7: Maintain an Incident Response Plan
Failure Rate: Moderate
Most covered companies have a written incident response plan. This requirement has been in compliance frameworks long enough that it’s become table stakes.
Where it fails: The plan was drafted, filed, and never tested. It references employees who no longer work at the company. It doesn’t address scenarios specific to the business, like losing access to a cloud-hosted DMS for two weeks (see: CDK Global). And the “notification to customers” section is woefully underdeveloped relative to what state breach notification laws and FTC expectations actually require.
—
Tier 2: Where Companies Start Struggling
#6: Oversee Service Providers
Failure Rate: Moderate-to-High
The rule requires you to select service providers that maintain appropriate safeguards, include contractual security requirements in your agreements with them, and periodically monitor their compliance.
Most companies have gotten good at the contractual language piece; standard security addenda are easy to template. The monitoring piece is where things fall apart.
Where it fails: Vendor contracts have the right language, but no one has actually reviewed a SOC 2 report, assessed a vendor’s security posture, or asked what data the vendor stores and where. In the dealership context, this means CDK or Reynolds & Reynolds has broad access to customer PII with minimal oversight from the dealership side. In the mortgage context, this means the LOS vendor and the credit bureau integrations are approved based on a signed agreement, not a verified assessment.
—
#5: Keep the Program Current
Failure Rate: Moderate-to-High
The program must be updated in response to changes in business operations, results of monitoring and testing, changes in the threat landscape, and results of risk assessments.
Where it fails: The security program was written in 2023, nothing significant has changed on paper since, and no one has formally reviewed whether the program reflects current operations. The business added two new SaaS tools, moved a server to the cloud, hired a remote workforce, and onboarded a new F&I vendor, none of which triggered a program update.
—
#4: Conduct a Risk Assessment
Failure Rate: High
The risk assessment is where the compliance-versus-security gap starts to show up in sharp relief. The rule requires a written risk assessment that identifies reasonably foreseeable internal and external risks to customer information and evaluates the likelihood and impact of those threats.
Where it fails: Risk assessments are completed on a schedule rather than driven by actual threat intelligence. They’re typically self-reported by the same IT vendor who manages the environment, creating an obvious conflict. The methodology is poorly documented. And critically, the assessment rarely produces a prioritized remediation roadmap that actually gets executed. It produces a document that satisfies the requirement and lives in a folder.
A risk assessment that doesn’t change your security posture isn’t a risk assessment. It’s paperwork.
—
Tier 3: Where Companies Get Exposed
#3: Implement Safeguards to Control Identified Risks
Failure Rate: High
This is the requirement that ties the risk assessment to actual controls, and it’s where theory meets reality. The rule specifies that safeguards must include access controls, data inventory and classification, encryption of customer information in transit and at rest, secure software development practices, authentication controls (including MFA), and physical security.
Where it fails: Access controls are misconfigured or stale (terminated employees, over-privileged service accounts, shared credentials). Encryption is implemented for obvious data flows but not for backups, shared drives, or archived deal jackets. MFA is enabled on email but not on the DMS, VPN, or internal admin consoles. Data classification doesn’t exist; no one has mapped where customer PII actually lives.
This requirement is broad by design, and the gaps are correspondingly numerous.
—
#2: Regularly Monitor and Test Safeguards
Failure Rate: Very High
The 2021 amendments, which took effect in June 2023, made this explicit: companies must implement continuous monitoring or conduct periodic pentesting. For companies with a comprehensive security program, the expectation is annual pentesting and biannual vulnerability assessments at minimum.
!Vulnerability Scan vs. Penetration Test
Where it fails: Nearly everywhere.
The most common pattern: an IT vendor runs a vulnerability scan, generates a report, and the company files it as “pentesting.” A vulnerability scan is not a penetration test. A scan identifies potential weaknesses. A penetration test attempts to exploit them to determine real-world impact. The distinction matters enormously, and most compliance assessors aren’t equipped to challenge it.
Companies that do conduct real pentesting often scope it too narrowly: external-only, no social engineering, no physical testing, no assessment of the DMS or loan origination system. The test satisfies the requirement on paper and misses the actual attack surface.
—
#1: The Entire Technical Controls Layer (Taken Together)
Failure Rate: Systemic
Here’s the honest summary: the higher the technical sophistication required, the worse the compliance picture. The three requirements that demand real security work (risk assessment, safeguard implementation, and monitoring/testing) are consistently the weakest across covered industries.
This isn’t a character flaw. It reflects the reality that most small and mid-size financial institutions don’t have dedicated security staff. They have IT vendors and compliance consultants who are trying to help but aren’t security specialists.
The FTC Safeguards Rule was amended precisely because the soft, policy-based requirements weren’t producing security outcomes. The prescriptive technical requirements are the rule’s attempt to force covered companies toward actual security practice, not just documentation.
—
The Bottom Line
If you’re doing a self-assessment, work backward from this list. The paperwork requirements (#9, #8) are probably fine. The program management requirements (#7, #6, #5) need regular maintenance. The technical requirements (#4, #3, #2) are where you’re most likely to have real gaps, and where a real attacker would find them.
The FTC’s enforcement posture is shifting. The agency has made clear that documentation without implementation won’t satisfy the rule. And as breach notification requirements expand across states, a Safeguards failure increasingly becomes a public one.
Compliance is the starting line. Security is the work that comes after.
