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.
How I help
The engineering behind the guide. Each one starts with a map of the platform as it runs today.
Book a callWhere to start
Cloud Security Posture & Hardening
We map every way into your cloud accounts, rank the gaps by what an attacker reaches first, and close the ones that matter, in code, with your team.
$10,000 to $18,000
See what's includedPlatform engineering
I do cloud engineering on the platform you already run. I make it calmer, cheaper, and understood by more than one person on the team.
Read moreCloud security hardening
I find the gaps in your cloud accounts, identity, network, and data, rank them by what an attacker reaches first, and close them with your team.
Read moreOther guides
SOC 2 and security questionnaires
What a SOC 2 report and an enterprise security questionnaire ask of a startup's cloud platform, and what to build before the first big deal.
Read moreNew York rules
What New York's DFS cybersecurity regulation (23 NYCRR Part 500) and the SHIELD Act ask of a startup's cloud platform, and how they reach vendors.
Read moreUS state AI laws
What Colorado's SB 26-189 and other state AI laws ask of a team that builds or deploys automated decisions, read as engineering work.
Read moreAI-assisted development
My AI engineering workflow for a team: how I set up Claude Code, Codex, and similar agents with instruction files, retrieval, shared memory, and code review.
Read moreSecuring AI-generated apps
What changes when an agent writes the code: the new attack paths, the controls that close them on AWS, Azure, and Google Cloud, and the evidence buyers ask for.
Read moreGitHub best practices (free)
A free guide to GitOps guardrails on GitHub: rulesets, independent reviewers, required pull requests and checks, Conventional Commits, and branch names.
Read moreCommon 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?
Prefer email or phone? hello@netninjas.us or +1 (347) 486-4242
