FTC Safeguards: What Must Vendors Prove?

A covered nonbank should ask service providers for evidence that matches the customer information they access and the services they perform. Select capable providers, require appropriate safeguards in the contract, and periodically assess their continued adequacy. A questionnaire is a starting point, not the entire oversight process or a compliance guarantee. (FTC guidance)

The Federal Trade Commission (FTC) explains these service-provider duties in its Safeguards Rule guidance for automobile dealers, including the three-part requirement in Title 16 of the Code of Federal Regulations (CFR), section 314.4(f). This article focuses on a practical evidence review for institutions covered by that rule, not an assertion that every bank or credit union is subject to FTC jurisdiction (FTC staff FAQs).

What are the key takeaways?

• Identify providers by their access to customer information and the service relationship (FTC service-provider definition).
• Require appropriate safeguards contractually and reassess based on risk (FTC guidance on 16 CFR 314.4(f)).
• Match evidence requests to the actual service instead of sending every vendor an identical checklist.
• Assign an internal owner to review exceptions, approve access, and track corrective work.

Which vendors count as service providers?

The FTC describes a service provider as a person or entity that receives, maintains, processes, or is otherwise permitted access to customer information through providing services directly to a covered financial institution. A data recipient is not automatically a service provider without the relevant service relationship (FTC staff FAQs, service providers).

Begin with a working inventory of customer-information flows. Our recommendation is to include applications, outsourced administration, document storage, support access, and disposal services, then validate which entries meet the rule’s definition. Ask business owners about services bought outside central procurement.

For each entry, record the information involved, why access is needed, who authorizes it, and how the relationship ends. Distinguish a provider that can administer a customer database from one that handles sealed paper records. The review should explain those differences instead of hiding them inside a generic high-risk label.

Do not equate a familiar brand with a completed assessment. Identify the contracting entity and the offering actually purchased. If another company performs the service, ask how that dependency is governed and what evidence your institution can receive. Treat unsupported answers as open questions, not automatic failures or automatic approval.

What does the rule require you to do?

The service-provider provision requires reasonable steps to select and retain providers capable of maintaining appropriate safeguards, contractual requirements to implement and maintain those safeguards, and periodic assessment based on the risk and continued adequacy of the provider’s safeguards. These are related duties, not alternatives (FTC explanation of 16 CFR 314.4(f)).

FTC staff also explains that a provider does not necessarily need every safeguard required of the covered institution. Appropriate safeguards depend on the service: direct system access and paper shredding present different issues (FTC service-provider FAQs).

Our recommended purchasing sequence is therefore simple: define access, choose the evidence needed to assess that access, resolve material gaps, and carry the agreed requirements into the contract. After onboarding, verify that the deployed service still matches the assumptions used to approve it.

This is operational guidance, not legal advice. Have counsel determine coverage and contract language for the specific relationship. A vendor review file should make the decision understandable without suggesting that an analyst’s checklist can replace the institution’s legal obligations.

What evidence should you request first?

Request a small, service-specific package that answers how access is controlled, how information is protected, and how problems reach your team. The following checklist is our recommended review structure, not a list of documents individually mandated by the FTC.

1. Service boundary: a description of the systems, customer information, support roles, and downstream dependencies involved. Compare it with the service order.
2. Access controls: evidence of how privileged users are approved, authenticated, reviewed, and removed. Ask for sanitized configuration or review records rather than real credentials.
3. Protection of stored information: an explanation of relevant encryption, key responsibilities, backup access, and disposal practices. Match the request to the data and service.
4. Monitoring and response: a sample escalation record and an explanation of who investigates suspicious access. Identify information the provider can preserve and export.
5. Assurance and exceptions: relevant independent reports, their scope, unresolved findings, and management responses. Track evidence gaps instead of treating a report cover page as clearance.
6. Contract and exit: safeguards commitments, cooperation expectations, notification contacts, return or deletion terms, and responsibilities when the relationship ends.

How do you evaluate evidence without overcollecting data?

Use the least sensitive artifact that answers the review question. A redacted access-review record may be more useful than an unfiltered export of employee accounts, and a controlled demonstration may answer a configuration question without copying customer information into the vendor-risk system.

Label each conclusion as supported, partially supported, or unresolved. Record the artifact, date, reviewer, and service scope. If a provider says that a control is inherited from a platform, ask which party configures it and what evidence shows that the purchased deployment uses it.

Our practical test is whether another reviewer could reproduce the conclusion from the retained material. “Vendor says yes” may document a representation, but it should not be confused with a tested configuration or an independent examination. State the strength and limits of the evidence plainly.

For independent assurance, a managed security service provider (MSSP) may offer a System and Organization Controls (SOC) 2 report. Our related guide, how to read an MSSP SOC 2 report, explains that separate review workflow. Use it when such a report is offered, while keeping this service-specific decision in focus.

How often should you reassess a provider?

The FTC provision describes periodic assessment based on the risk presented and the continued adequacy of safeguards; the cited guidance does not turn every relationship into an identical annual questionnaire exercise. Design the review around the actual risk rather than inventing a universal interval (FTC service-provider oversight guidance).

We recommend recording a review cadence and change triggers for each relationship. Examples include expanded data access, a material incident, a changed service operator, a new integration, or an unresolved assurance finding. A calendar reminder should support oversight, not be the only reason a review occurs.

Assign corrective actions to named owners with agreed dates and acceptance criteria. If a gap cannot be resolved promptly, document the business decision, the temporary restriction, and who has authority to accept the remaining exposure. Revisit the decision when the assumptions change.

How would our SOC support provider oversight?

Our U.S.-based security operations center (SOC) would start with the provider’s actual access paths and the telemetry available to the institution. In a hypothetical suspicious-support-login review, we would identify who can disable access, what activity can be reconstructed, and how evidence reaches the internal decision-maker.

We would not treat a signed questionnaire as proof that the login was legitimate or that monitoring was complete. We would distinguish contractual commitments from observed activity and document any blind spots. This is a proposed operating approach, not a description of a client incident.

A virtual chief information security officer service can help assign ownership across procurement, operations, and security. The managed SOC pricing guide provides a resource for clarifying whether investigation and reporting work is included in the purchased service.

What else should buyers know?

Does every vendor need the same safeguards?

No. FTC staff guidance explains that safeguards should fit the service and information involved; a provider does not necessarily need every safeguard applicable to the institution (FTC FAQs).

Is a contract enough by itself?

No. Contractual safeguards are one part of the provision, alongside reasonable selection and retention steps and periodic risk-based assessment (FTC explanation of 16 CFR 314.4(f)).

Must every review be performed annually?

The cited service-provider provision calls for periodic assessment based on risk and continued adequacy, rather than specifying one universal interval for all providers (FTC FAQs).

Should we request real customer records as evidence?

We recommend avoiding unnecessary copies. Use redacted artifacts, synthetic examples, or controlled demonstrations where they answer the question, and define secure handling for any sensitive evidence that is genuinely necessary.

Need help defining the next step?

Bring your provider inventory and an example review file to identify gaps in evidence and ownership. Schedule a security review or Call 833-92-CYBER to discuss scope and ownership.