Net NinjasBook a call
All guides

Guide

The FTC Safeguards Rule for fintech startups

What the FTC Safeguards Rule (16 CFR Part 314) asks of a non-bank fintech's cloud platform: a written program, encryption, MFA, testing, and vendor oversight.

The Safeguards Rule is the Federal Trade Commission's security rule for financial institutions that aren't banks. It sits in 16 CFR Part 314, under the Gramm-Leach-Bliley Act. It asks for a written information security program that fits the company's size and the sensitivity of the customer information it holds. The 2021 amendments turned that into a concrete list, and a duty to notify the FTC of larger breaches followed.

I'm starting to see fintech founders learn that the rule's "financial institution" is wider than it sounds. It covers companies that lend to consumers, arrange loans, prepare tax returns, or give financial advice. It also covers a company that acts as a finder between buyers and sellers. This guide reads the rule's list as a cloud platform.

This is an engineer's reading of the rules. I wrote it to help teams decide whether the rules touch their platform. It isn't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.

Does it apply to you?

If one of these lines describes your company, the rest of this guide applies. If none does, the rule probably sits outside your company. A thirty-minute call confirms that faster than the text can.

  • We lend money to consumers, arrange or broker loans, or service loans, and we aren't a bank.
  • We prepare tax returns, or give financial, investment, or credit advice to consumers for a fee.
  • We bring buyers and sellers together for transactions they complete themselves. The rule calls this acting as a finder.
  • We hold customer information for a company on that list. Their contract with us has to require safeguards, so their duties reach us through it.
  • We keep customer information about fewer than five thousand consumers. Section 314.6 then lifts four of the duties, and the rest still apply.

What it asks of your platform

A written program with a named owner

Section 314.4 opens with a qualified individual who oversees the program, and that person can be a service provider. The program rests on a written risk assessment, and it gets adjusted when the business or the test results change. The qualified individual reports in writing to the board or a senior officer at least once a year. For a startup, that's one named owner, one risk register, and one yearly report.

The safeguards, read as a cloud platform

The rule lists the controls in section 314.4(c). Customer information is encrypted in transit over external networks and at rest. Multi-factor authentication covers any individual who accesses an information system. Access is limited to what each person needs, changes follow a change management procedure, and the activity of authorized users is logged and monitored. Customer information is disposed of no later than two years after its last use, unless a business or legal reason keeps it.

Testing on a schedule

Section 314.4(d) asks for continuous monitoring. Without it, the rule asks for a penetration test every year and vulnerability assessments at least every six months. Assessments also follow material changes to the business. I build the monitoring first, because a detection that runs every day shows more than a test that runs once a year. The test results feed back into the program.

Service providers and the 30-day notice

Section 314.4(f) makes the company choose service providers that can keep customer information safe, and require those safeguards by contract. A cloud provider and each SaaS tool in the data path are on that list. Section 314.4(j) adds a notice to the FTC. When unencrypted customer information of at least 500 consumers is acquired without authorization, the company notifies the FTC no later than 30 days after discovery.

Common questions

We're small. Does the whole rule apply?
Section 314.6 lifts four duties for a company that keeps customer information about fewer than five thousand consumers. Those are the written risk assessment, the scheduled penetration tests and vulnerability assessments, the written incident response plan, and the yearly report to the board. Encryption, multi-factor authentication, access controls, and service provider oversight still apply. I'd build the full list anyway, because customer numbers grow faster than programs do.
Does a SOC 2 report cover the Safeguards Rule?
It covers much of the same ground, and the evidence overlaps. The rule still has its own items: the named qualified individual, the two-year disposal limit, and the FTC notice. A SOC 2 report is something a customer asks for, and the rule is something a regulator enforces. I'd map the two once and keep one set of controls.
Where would you start?
With the data path. I map where customer information enters, where it's stored, and which vendors it reaches. Encryption, multi-factor authentication, and logging then go on that path first. Which system in your stack holds the most customer information today?

Let's talk.

A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?