Does the FTC Safeguards Rule require a secure software development policy?

If your firm runs a client portal, an online intake form or a Power Automate flow that someone built for you, and it handles customer information, the FTC Safeguards Rule requires secure development practices for it. Those practices need to be written down, and a short secure software development policy is the simplest place to keep them. Here is what the rule says, what counts and what the policy should cover.

What does the Safeguards Rule say about in-house apps?

It requires firms to adopt secure development practices for in-house apps that handle customer information. 16 CFR 314.4(c)(4) directs covered firms to "adopt secure development practices for in-house developed applications utilized by you for transmitting, accessing, or storing customer information." The same paragraph requires procedures for evaluating, assessing or testing the security of externally developed applications used for the same purposes.

The rule applies to non-bank financial institutions under FTC jurisdiction. The FTC's business guidance on the Safeguards Rule lists examples that include mortgage lenders, mortgage brokers, finance companies, collection agencies, tax preparation firms and investment advisers that are not required to register with the SEC. SEC-registered advisers and broker-dealers fall under Regulation S-P instead; our piece on what SEC examiners ask for under Reg S-P covers that rule.

The FTC's guidance says the information security program must be written. The rule names the obligation but does not define "secure development practices" or point to a required framework. That leaves each firm to choose a method, write it down and keep records showing it was followed. If an examiner asks how the firm secures the client portal it paid a contractor to build, a dated record of reviews answers the question. A general statement in the information security program usually does not.

What counts as an in-house developed application?

The rule does not define the term. A plain reading covers software your firm built, or had built for its own use, that transmits, accesses or stores customer information. For a small lender, adviser or tax practice, that list is often longer than leadership expects. Candidates worth reviewing include:

• A client or borrower portal built by a contractor for your firm.
• Online intake forms that write applicant data to a database, spreadsheet or shared mailbox.
• Low-code apps and automated workflows, such as those built in Microsoft Power Apps or Power Automate, that move customer records between systems.
• Scripts that pull data from a custodian, loan origination system or tax software and reformat it for reporting.
• Spreadsheet macros and small internal tools built by staff, including tools written with the help of AI coding assistants.

Whether each of these falls inside paragraph (c)(4) is a judgment for the firm's Qualified Individual and counsel. Inventorying them is useful either way, because 314.4(c)(2) already requires firms to identify and manage the data, personnel, devices, systems and facilities that support the business.

What should a secure software development policy cover for a small firm?

A secure software development policy is a short, written set of steps that every app touching customer information goes through before and after launch. The rule leaves the method open. NIST's Secure Software Development Framework, SP 800-218, is a widely used reference that groups practices into four areas: prepare the organization, protect the software, produce well-secured software and respond to vulnerabilities.

Scaled to a firm with a handful of internal tools, those four areas translate into a few habits:

• Prepare: name who may build or change an app that touches customer information, and write down the minimum steps they follow.
• Protect: keep code and app definitions in a controlled location with access limited to the people who maintain them, and keep secrets such as API keys and passwords out of code and shared files.
• Produce: review each app before it goes live. Confirm it limits access to authorized users, encrypts customer information in transit and at rest as 314.4(c)(3) requires, and logs user activity in line with 314.4(c)(8).
• Respond: track the components and libraries each app depends on, apply updates, and retire apps that nobody maintains.

Changes to these apps also fall under the change management procedures required by 314.4(c)(7). A new feature in a client portal changes an information system that holds customer data, so routing it through the same approval and record the firm uses for other system changes keeps the evidence in one place.

How do you evaluate apps you did not build?

With a documented, risk-based review of what the provider can show you. When the FTC adopted this requirement in its 2021 amendments to the Safeguards Rule, it rejected comments that evaluating outside software was impractical, stating that "evaluating the security of software does not require access to the source code of that software."

The Commission described workable approaches: asking the provider what security steps it takes, whether it encrypts transmitted information and what its testing found; using third-party assessment services; and setting up automated searches for vulnerabilities, patches and updates for software on the firm's inventory. It also said the depth of evaluation depends on the firm's size and the amount and sensitivity of the customer information involved. Software that others have tested thoroughly may need only a review of those results, while software with little use or testing calls for a closer look.

This overlaps with the service provider duties in 314.4(f): select providers capable of maintaining appropriate safeguards, require those safeguards by contract and periodically assess them. Our piece on vendor oversight under GLBA covers that ongoing review.

Does the 5,000-consumer exception remove this requirement?

No. 16 CFR 314.6 exempts firms that maintain customer information on fewer than 5,000 consumers from four provisions: the written risk assessment, the penetration and vulnerability testing in 314.4(d)(2), the written incident response plan and the annual report to the board. Paragraph (c)(4) is not on that list.

Smaller firms still need secure development practices and a way to evaluate outside software. What changes is scale. A three-person practice with one contractor-built intake form can document its approach on a single page, as long as the page is followed and the reviews are dated.

Do in-house apps belong in Safeguards Rule testing?

Yes, for firms subject to the testing requirement. Customer-facing apps belong in the scope of the firm's required testing. Firms without the small-firm exception must run continuous monitoring or, under 314.4(d)(2), annual penetration testing plus vulnerability assessments at least every six months. A portal or intake form that customers reach from the internet is part of the information system, so the testing plan should name it. Our piece on penetration testing under the Safeguards Rule explains how those options compare.

Access controls apply to apps as well. The user access reviews a firm runs for email and file shares should cover portal administrator accounts and anyone with rights to change an internal tool.

How do you put a secure development policy in place this quarter?

Five steps give a firm a defensible starting record:

1. Build an inventory of every in-house and third-party application that transmits, accesses or stores customer information, with a named owner for each.
2. Write a one- or two-page secure software development policy covering who may build, how apps are reviewed before launch, where code and secrets are kept and how changes are approved.
3. Review each in-house app against that standard, starting with anything customers or applicants use directly.
4. For each third-party app, file the provider's security documentation or test results and set a review date based on risk.
5. Record what you found and fixed so the Qualified Individual can include it in the annual report to the board under 314.4(i), for firms required to produce one.

How can s90 help?

s90 works with mortgage brokers, lenders, tax practices and advisers across Los Angeles and Orange County on the Safeguards Rule. We help build the application inventory, write a secure software development policy sized to the firm, and keep evidence of app reviews, testing and vendor evaluations ready for an examiner. If your firm has tools nobody has reviewed in a while, a short conversation is a good place to start.