Guide · for accountants, advisers and insurance agents
The FTC Safeguards Rule, for an App You Built Yourself
Will Pickeral, William Belle LLC · support@williambelle.co
If you prepare tax returns, keep books, advise on money, or sell insurance, there is a federal rule about how you protect your clients' financial information. It is called the Safeguards Rule, and most people in these fields first hear about it from their professional insurer or a client's lawyer rather than from the FTC.
You may also have built yourself a tool: an intake form, a client portal, a document tracker, something made with an AI tool over a few weekends. That tool is now part of what the rule covers.
This is a plain-English summary, not legal advice. For how it applies to your specific practice, ask your attorney.
Whether it applies to you
The rule sits at 16 CFR Part 314 and applies to businesses the FTC calls financial institutions, which is broader than it sounds. It is not only banks. Tax preparers, accountants who prepare returns, investment advisers who are not registered with the SEC, mortgage brokers, insurance agents, and auto dealers arranging financing have all been named by the FTC as covered.
If your work involves other people's financial information and you are not supervised by a banking regulator, assume it applies and confirm with your attorney.
If you hold information on fewer than 5,000 consumers, four of the heaviest requirements do not apply: the written risk assessment, the continuous checking or penetration testing, the written incident response plan, and the annual written report. Everything else still does. Most solo and small practices sit under that line, which makes this much smaller than it first looks.
What it asks for
| What the rule asks for | Who does it |
|---|---|
| Name one person responsible for the security program | You. It can be you. It has to be someone named |
| Write down what could go wrong and how you address it | You, with technical input |
| Know what information you hold and where it is | Both. Someone has to inventory the systems |
| Limit who can reach what | Technical |
| Scramble information where stored and in transit | Technical |
| A second step at sign-in | Technical |
| Build and change software carefully | Technical |
| Dispose of information you no longer need | Both. A policy, and something that enacts it |
| Train your staff | You |
| Check that your vendors protect it too | You, with technical input |
| Have a plan for when something goes wrong | You, with technical input |
Roughly half is engineering and half is paperwork and habit. An engineer who tells you they can deliver all of it is wrong. One who never mentions the policies and habits leaves you carrying that risk without knowing it.
Where an app built with AI usually falls short
The same four gaps come up in almost every one of these I look at.
A second step at sign-in is missing. The rule specifically asks for multi-factor authentication for anyone reaching client information. AI tools build username-and-password sign-in well and stop there, because that is what was asked for.
Information is not scrambled where it is stored. Almost every modern host encrypts traffic between the browser and the app, so that half is usually fine by accident. Encryption of the database itself is a setting, it is frequently off, and nothing tells you.
Nothing records who looked at what. The rule asks you to track what authorized users do with client information. Most self-built apps keep no log at all, so if a client asks whether their return was opened by anyone else, there is no way to answer.
Anyone can reach anyone's record. This is the serious one. A sign-in page keeps strangers out, but inside the app, records are often reachable just by changing a number in the address bar. AI tools rarely finish this job, because it looks finished from the outside.
None of these mean the app was built badly. They mean the app was built to work, which is a different thing from being built to be checked.
What to do first, in order
1. Turn on a second step at sign-in. For you and for every member of staff. It is usually a setting rather than a project, and it removes the most common way these accounts are broken into. It is also the first thing a regulator or an insurer asks about.
2. Find out whether one client can reach another's records. Sign in as a test client, take the address of a record belonging to a different client, and load it. If it opens, everything else waits until that is fixed.
3. Write one page. Who is responsible, what information you hold, where it lives, who can reach it, and what you would do if it leaked. One page, in your own words. If you hold information on fewer than 5,000 consumers you are not required to have the formal version, and you will still be glad of the page the first time somebody asks.
After those three, the rest is real work but ordinary work: encryption settings, access limits, a record of who did what, and vendor agreements.
What this costs you if you ignore it
Not a fine, usually. The FTC brings relatively few of these cases and tends to bring them against larger firms.
What it costs is deals and clients. A corporate client puts you through a customer security review before renewing. Your professional insurer asks what controls you have. A prospect's IT person asks where the data lives. Each of those is a near-term moment where an honest answer wins the business or loses it, and they arrive with far more warning than an enforcement action does. The questions come first, and they are answerable.
Get a free 20-minute review — show me what you have and I'll tell you what I'd fix first in it, and why. No pitch, and nothing to prepare.