FTC Safeguards Rule Compliance Requirements for Startups

A tax preparation firm in Atlanta found out it was a "financial institution" under federal law just weeks before tax season. Nobody at the firm had any idea that preparing returns triggered coverage under the FTC Safeguards Rule, and the scramble to put a compliance program together nearly shut down its busiest stretch of the year. That story captures the mistake startups make across the board: they assume the rule is written for banks, when the rule itself is written around activity, not industry label. Issued under the Gramm-Leach-Bliley Act and significantly amended in 2021, with requirements effective June 9, 2023, the Safeguards Rule applies to any entity "significantly engaged" in financial activities, a phrase broad enough to pull in businesses that would never think to call themselves financial institutions. The test a company needs to run is not "what industry are we in" but "what do we actually do with customer data": identify the financial activities performed, work out whether the FTC or another regulator has jurisdiction over them, and write that determination down rather than lean on a label. Fintech startups carry a second layer of exposure here too. If a covered company gives a payroll processor, a cloud storage provider, or an IT support firm access to customer data, that covered company is required to put security terms into its vendor contracts and monitor compliance with them, and that mandate flows downhill. If a startup provides services to a covered firm, it can end up holding Safeguards Rule obligations it never signed up for, simply because it sits inside somebody else's vendor oversight chain.

Businesses the rule covers

The list of entities the Safeguards Rule names is longer, and stranger, than most founders expect. It covers mortgage lenders, brokers, and servicers; payday lenders; check cashers; insurance companies; investment advisors that aren't required to register with the SEC; and nonbank entities such as tax preparers, debt collectors, and real estate appraisers that handle nonpublic personal information. It also reaches auto dealers that arrange financing for customers, a category the FTC has stated directly: dealers who finance or help arrange financing for consumers count as financial institutions under the rule, because lending money is itself a financial activity. The list continues through accountants and tax preparers handling customer financial records, financial advisors and investment firms not regulated by the SEC, debt collectors, check cashing businesses, real estate settlement services such as title companies and closing agents, wire transfer services, and credit counseling services that help consumers manage debt. None of these businesses look like a big bank, and that's the point. A startup building software for any of them, or operating as one of them, needs to run the same test: does the business receive, maintain, or transmit nonpublic personal financial information about consumers? If so, the Safeguards Rule almost certainly applies. The data that triggers coverage is defined broadly: Social Security numbers, account numbers, credit card details, information pulled from loan applications, credit reports, transaction histories, and anything else that could tie an individual to a financial service relationship. One assumption deserves to be retired outright: there is no size exemption built into coverage itself. Plenty of small businesses believe they're exempt because they're "too small" to matter to a federal regulator, but the rule applies regardless of headcount or revenue once the underlying activity qualifies.

What "nonpublic personal information" includes

Founders tend to underestimate what counts as nonpublic personal information, and that underestimate quietly shrinks their whole security program before it's even built. NPI covers personally identifiable financial information a consumer provides or that the institution collects about them: Social Security numbers, account numbers, credit card numbers, loan application details, credit reports, transaction histories, and any data point that could identify a person in connection with a financial service. That data travels across multiple systems, and each stop needs its own review. A single customer application might start on a company's website, land in a CRM, pass through a financing provider's systems, and end up stored in a cloud document platform, and each one of those stops needs its own security review because each one now holds NPI. Customer information doesn't stay put in a single database. It spreads into email accounts, cloud storage, paper files, employee laptops, backup systems, and third-party applications, and every one of those locations falls inside the rule's scope the moment it contains covered data. This specific and common engineering mistake appears in how teams scope their security controls. Teams apply encryption, access controls, and monitoring to the production database, treating that as the job done, and this produces a scope gap: staging environments, QA systems, analytics warehouses, backups, machine learning training sets, and vendor-hosted systems sit under lighter controls or none. The Safeguards Rule does not grant production any special status. If a program protects only production and leaves those other environments exposed, it fails to meet the rule's standard, no matter how strong the production controls are. The risk compounds further because of how the rule defines discovery. An event counts as "discovered" on the first day any employee, officer, or agent of the institution knows about it, not the day someone in legal or security formally confirms it. So if NPI sits in an unmonitored staging environment that gets compromised, the regulatory clock starts the moment a junior engineer notices something odd, whether or not anyone escalates it that day.

The nine elements every covered institution's security program must include

The 2021 amendments took what had been flexible, principle-based guidance and turned it into nine specific, enforceable requirements, and every covered institution has to build these into its security program. The first is a designated Qualified Individual who oversees, implements, and enforces the program; this can be an employee or an outside service provider, but many smaller firms have nobody formally holding that role, which makes it one of the most common gaps examiners find. The second is a risk assessment that identifies threats to customer information, and it has to be a living document: a risk assessment completed years ago and filed away does not satisfy a rule that expects ongoing assessment reflecting current systems, data flows, and the threat environment as it actually stands today. The third element is the set of safeguards used to control the risks that assessment identifies, and it carries the most operational detail. It includes access controls that authenticate users and restrict access to NPI on a need-to-know basis; an inventory of data and systems so the company knows where NPI actually lives; encryption of customer information both at rest and in transit; secure development practices for any in-house application that touches NPI; multi-factor authentication for anyone accessing systems that contain NPI, requiring at least two of a knowledge factor, a possession factor, or an inherence factor; data retention and disposal policies that securely delete NPI once it's no longer needed, unless a separate law requires it to be kept; a change management process for system updates and modifications; and activity monitoring and logging to catch unauthorized access or unusual behavior. Beyond that core safeguards cluster, the rule requires regular testing and monitoring of those safeguards, employee training on information security, oversight of third-party vendors that handle customer data, a written incident response plan for when a breach happens, and periodic evaluation of the whole program as the business and the threat landscape change. The last element is board or senior leadership reporting, delivered at least annually by the Qualified Individual, and it applies to institutions holding 5,000 or more customer records under the rule's own threshold. What happens when these elements go missing is visible in the FTC's case against Blackbaud. The agency alleged the company let employees use weak or duplicated passwords, skipped multi-factor authentication, and stored Social Security numbers and bank account numbers without encryption, so an attacker sat undetected on the network for more than three months. None of this lives in a drawer as optional paperwork. The rule requires five things in writing specifically: the security program itself, the risk assessment, any approved alternative to multi-factor authentication, the incident response plan, and the report delivered to the board. An institution's compliance evidence needs to be built around exactly those five documents.

The penetration testing and vulnerability assessment cadence the rule sets

Testing under the Safeguards Rule is not a once-a-year box to check, and the rule's own language makes that explicit. Unless a covered institution has what the rule calls "effective continuous monitoring or other systems to detect, on an ongoing basis, changes in information systems that may create vulnerabilities," it has to run annual penetration testing along with vulnerability assessments at least every six months, after any material change to its systems, and whenever other circumstances might materially affect the program. That requirement has applied since June 9, 2023. The word "effective" is doing real work in that sentence. Continuous monitoring is a genuine alternative to the fixed testing schedule, but it is not a lighter standard dressed up as one: a company has to actually demonstrate that its monitoring detects changes creating vulnerabilities as they happen, not merely that it has some dashboard running in the background. Startups that invest early in that kind of visibility are choosing the harder build now in exchange for not being tied to a biannual assessment calendar later, and that's a legitimate operational trade, not a shortcut. The evidence a company needs to keep for testing has four parts: the risk assessment that defined the scope of what gets tested, the actual test and scan reports, the record of remediation and retesting after issues are found, and the Qualified Individual's annual report to the board, which has to address testing results as a material matter. 16 CFR Part 314 stands out among federal rules because it names penetration testing, defines it, and sets a frequency for it. That leaves no real ambiguity about whether testing is required. For any given company, the open question is whether what it's already doing satisfies that definition. That question gets sharper for startups built on shared infrastructure. If a startup relies on a SaaS platform to process customer financial data, it has to make sure that platform is either covered by its own testing program or separately assessed, and a vendor's SOC 2 report does not stand in for the covered institution's own testing obligation under the rule.

The breach notification requirement and the rule's definition of "discovery

A notification requirement added in 2023 and effective May 13, 2024 turned a security incident from an internal engineering problem into a regulatory event with a fixed deadline attached. Covered financial institutions must notify the FTC as soon as possible, and no later than 30 days after discovering a notification event, defined as a security breach involving unauthorized acquisition of unencrypted customer information that affects a significant number of consumers. The discovery definition carries over from the broader rule here too, so it closes off the informal delay tactics companies often reach for. An event counts as discovered from the first day any employee, officer, or agent knows about it, not the day a formal investigation confirms what happened or a legal team signs off on calling it a breach. So for a startup, the 30-day clock can start running because of what an engineer flagged in an internal chat message weeks before anyone brought in counsel, not because of when a formal incident response process officially kicked off.