Guide · for accountants, advisers and insurance agents
The FTC Safeguards Rule, for an App You Built Yourself
William Belle — Cloud Deployment and Software Engineering Questions: 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.
If you have also built yourself a tool — an intake form, a client portal, a document tracker, something you made with an AI tool over a few weekends — then that tool is now part of what the rule covers. This guide explains what it asks for, which parts are technical, and which parts stay with you no matter who you hire.
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.
There is one threshold worth knowing. If you hold information on fewer than 5,000 consumers, four of the heaviest requirements do not apply to you: the written risk assessment, the continuous monitoring 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
Here is the whole of it, in plain words. I have marked who does each one, because the split matters more than the list.
| 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, and an engineer who ignores the second half leaves you carrying the risk without knowing it.
Where an app built with AI usually falls short
I have looked at a number of these now, and the same four gaps come up.
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 monitor what authorized users do with client information. Most self-built apps keep no log at all, so if a client ever 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 target from built to be checked.
What to do first, in order
If you do nothing else, do these three, in this order.
1. Turn on a second step at sign-in. For you and for every member of staff. This is the single largest reduction in risk available to you, it is usually a setting rather than a project, and it is the thing a regulator or an insurer asks about first.
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 actually 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 real, 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.
That is the argument for doing this now rather than after something happens: the questions come first, and they are answerable.
Get a free 20-minute review — show me what you have and I'll tell you the first three things I'd fix in it, and why. No pitch, and nothing to prepare.