The FTC Safeguards Rule for product teams

The Safeguards Rule tends to arrive at an engineering team in translated form: a questionnaire from compliance, a control matrix, a list of yes-or-no items. Something is lost in that translation, because the rule names engineering practices directly, and the named version is more specific than the questionnaire version.

This page goes through the provisions in 16 CFR 314.4 that apply to the code, in the rule's own words, with what each one means for a build.

Secure development practices are a named requirement

Section 314.4(c)(4) requires you to adopt secure development practices for in-house developed applications utilized by you for transmitting, accessing, or storing customer information, and procedures for evaluating, assessing, or testing the security of externally developed applications you utilize for the same purposes [1].

This is worth thinking about, because it is unusual. Most regulation governs the properties of a finished system. This provision governs how you make it. Your development process is covered by the regulation.

The practical consequence is that "we build securely" is not a satisfying answer, and neither is a policy document asserting it. What satisfies it is a process with artefacts: a defined set of practices, evidence that they are applied, and something that catches it when they are not. This is one of the places where a check suite derived from obligations is not just good engineering but the most direct available evidence, which we cover in why AI-native development fits regulated work.

It also creates a specific risk for teams using generated code. If your development practice is that a model writes the implementation and the same run writes the tests, it is difficult to argue that is a secure development practice when the published evidence says only 55 percent of model generations produce secure code [2]. The defensible version pairs generation with independent verification. The indefensible version is generation alone with a passing pipeline.

Logging covers reads

Section 314.4(c)(8) requires implementing policies, procedures, and controls designed to monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information by such users [1].

Read that carefully: the activity of authorized users. Not unauthorized access. The rule is concerned with what the people who are supposed to have access actually did, which is a materially different requirement from intrusion detection, and it is the single most commonly under-built control we see.

Almost every application logs writes. Writes are easy to log because they already pass through a small number of code paths, and because the team wanted an undo history anyway. Reads are logged far less often, because reads are everywhere, because logging them is expensive, and because nothing in the product breaks if you do not.

But a support agent opening four hundred customer records in an afternoon is exactly the pattern this provision exists to catch, and it produces no writes at all. If your logging is write-only, that afternoon leaves no record.

The engineering requirement, then, is that access to customer information generates a record naming the actor, the record, and the time, on read as well as write, through every path: the application, the internal admin tool, the reporting interface, the support console, and direct database access. That last one is uncomfortable and usually unaddressed.

MFA covers any information system

Section 314.4(c)(5) requires multi-factor authentication for any individual accessing any information system, unless your Qualified Individual has approved in writing the use of reasonably equivalent or more secure access controls [1].

The key word is "any," in both places. In practice teams implement MFA on the customer-facing product, where it is visible and expected, and leave it off the internal admin console, the analytics tool, the log aggregator, the deployment pipeline, and the database bastion. Each of those is an information system. Each is accessed by individuals. Several of them provide broader access to customer information than the customer-facing product does.

Note also the exception mechanism. The rule does not simply permit alternatives, it requires that the Qualified Individual approve them in writing. An undocumented decision that a particular internal tool does not need MFA is not the exception the rule describes; it is just a gap.

Encryption covers all copies

Section 314.4(c)(3) requires you to protect by encryption all customer information held or transmitted by you both in transit over external networks and at rest, with an exception for cases where encryption is not feasible, which again requires the Qualified Individual's review and approval of compensating controls [1].

Teams verify this on the primary database and stop, usually because the cloud provider encrypts it by default and the console shows a check mark. The word "all" covers more: backup snapshots, the analytics replica, exports to object storage, files generated for a monthly report, the data warehouse, the log aggregator if any customer information has leaked into logs, and any local copy on a developer machine.

That last category, customer information in logs, is worth an explicit check. Error payloads routinely contain full request bodies. If a request body contains customer information and the error handler sends it to a third-party monitoring service, you have transmitted customer information to a third party outside your encryption boundary, usually without anybody deciding to.

Change management is named

Section 314.4(c)(7) requires you to adopt procedures for change management [1]. It is one clause, easy to skim, and it means that how changes reach production is a regulated control rather than an internal preference.

What a defensible change management procedure contains is not mysterious: changes are reviewed by someone other than the author, changes are tested before release, releases are recorded with what changed and who approved it, and there is a defined path for emergency changes that still produces a record. The most common failure is not the absence of a process but the presence of an undocumented bypass: a deployment path that skips review, used rarely, by two people, for urgent fixes, with no record that it happened.

Disposal has a deadline

Section 314.4(c)(6) requires procedures for the secure disposal of customer information in any format no later than two years after the last date the information is used in connection with providing a product or service to that customer, unless it is necessary for business operations or other legitimate business purposes, is otherwise required to be retained by law or regulation, or targeted disposal is not reasonably feasible given how the information is maintained. It also requires periodically reviewing your data retention policy to minimise unnecessary retention [1].

Two things follow. There is a default deadline, and most systems have no mechanism that implements it. And "in any format" again means the copies, which is where disposal almost always fails: the record is removed from the primary store and persists in a backup, an export, and a spreadsheet somebody generated in 2023.

Testing has a defined cadence

Section 314.4(d)(2) requires continuous monitoring or, absent that, annual penetration testing plus vulnerability assessments at least every six months and whenever there are material changes to your operations or business arrangements [1].

The clause that matters for a product team is the last one. A material change triggers an assessment, which means a significant re-architecture, a new third-party integration handling customer information, or a migration is not something you assess at the next scheduled interval. It is its own trigger.

The Safeguards Rule applies to non-banking financial institutions as defined by the FTC, and whether it applies to you is a question for counsel rather than for this page. What we can say is that where it applies, it names the practices above specifically, and a control that exists in a policy but not in the running system is a gap regardless of how well the policy is written.

If you want to see how your product measures against these provisions, how to audit an existing financial application covers the process and get in touch to run it with us.