SEC and FINRA Third-Party Risk Management for Financial IT Teams

What should financial IT teams document for SEC and FINRA third-party risk management?

A practical SEC and FINRA third-party risk management program should document vendor inventory, risk classification, due diligence, contract requirements, access controls, performance monitoring, incident response expectations, data-retention requirements, and offboarding steps. Financial IT teams should be able to show not just that a vendor exists, but why the vendor is approved, what the vendor can touch, how the risk is supervised, and what happens when something changes or breaks.¹²

That matters because financial firms do not get to outsource accountability when they outsource technology. If a third party supports customer data, core business processes, cybersecurity tooling, remote access, cloud infrastructure, or regulated workflows, the firm still owns the supervisory burden. In our experience, that is where many internal teams feel the pressure: procurement may have signed the contract, but IT, security, and compliance are the ones left proving that the relationship is controlled.

We see the strongest programs treat vendor oversight like an operating discipline rather than a vendor file cabinet. They maintain a current inventory, tie documentation to risk tiers, define required evidence, and make sure leadership can understand where the real exposure sits. That is the difference between a program that looks fine on paper and one that can survive an exam, breach, or outage.

Why do SEC and FINRA care so much about third-party risk?

Because third parties often sit inside the most sensitive parts of the environment. Financial institutions rely on outside providers for cloud hosting, managed security, core systems, communications, endpoint tooling, archiving, identity services, and customer-facing applications. When those providers fail or get compromised, the blast radius can reach multiple firms at once.¹

FINRA has been explicit that firms need a reasonably designed supervisory system for outsourced activities, including written supervisory procedures around what third-party vendors do on the firm’s behalf.¹³ The SEC’s Regulation S-P requirements reinforce the same practical point from the privacy and safeguarding side: if a vendor touches customer information, the firm needs to know how that information is protected, what controls exist, and how incidents are escalated.²

For IT leaders, the takeaway is simple: third-party risk documentation is not just a legal or compliance artifact. It is evidence that your team knows where critical dependencies are, how they are governed, and what needs executive attention next.

What should be in the documentation package?

A good documentation package should help your team answer four questions quickly:

1. Which vendors matter most?
2. What risks do they introduce?
3. What controls prove those risks are being managed?
4. What happens if the relationship changes, degrades, or ends?

1. Vendor inventory and risk tiering

Start with a current inventory of third parties, fourth parties where relevant, and the systems or business functions they support. The inventory should identify:

• vendor name and service owner
• business function supported
• systems, data, and user populations affected
• whether customer information is involved
• whether privileged or remote access is involved
• hosting model and geographic considerations
• dependency criticality for operations, recovery, and compliance
• assigned risk tier and review cadence

This sounds obvious, but it is the foundation for everything else. If the inventory is incomplete, the rest of the program becomes guesswork. FINRA specifically highlights the importance of maintaining a list of third-party services and components used in the firm’s technology infrastructure.¹

A strong inventory also makes it easier to connect third-party oversight with the broader security baseline. That is one reason firms evaluating their overall environment often pair this work with a cybersecurity risk assessment, managed cybersecurity services review, or a broader managed IT services strategy.

2. Due diligence records before onboarding

Before a vendor is approved, the file should show why the relationship makes sense and what checks were completed. The FDIC’s third-party risk guidance is still useful here because it frames the work in practical stages: risk assessment, due diligence, contract structuring, and ongoing oversight.⁴

For financial IT teams, onboarding documentation should usually include:

• business justification and service scope
• inherent risk assessment
• review of security policies and control summaries
• privacy and data-handling review
• financial condition or business viability review
• resilience and business continuity materials
• incident response and breach-notification expectations
• subcontractor or fourth-party disclosure
• regulatory or audit artifacts, such as SOC reports where applicable

The goal is not to collect every PDF a vendor has ever produced. The goal is to document the evidence your team actually relied on to approve the relationship. If an examiner or internal auditor asks why a vendor was classified as acceptable, your team should be able to point to something more concrete than “they seemed fine.”

3. Contracts that reflect security and supervisory expectations

One of the weakest points in many programs is the gap between what the risk team expects and what the contract actually says. FINRA calls out the need to validate data-protection controls in vendor contracts and to define what happens to firm data at termination.¹

At a minimum, documentation should show that contracts address:

• confidentiality and data-use restrictions
• security-control requirements
• breach and incident-notification timelines
• audit rights or evidence-sharing expectations
• subcontractor approval or disclosure requirements
• service-level expectations and support obligations
• data return or destruction at termination
• access removal and transition support

This is also where firms should align legal language with how the environment actually works. If the contract assumes the vendor has no privileged access, but the implementation gives them administrative reach into production systems, the paperwork is lying. That mismatch is exactly what causes trouble later.

For firms building a stronger compliance operating model, it often helps to connect contract review with the same evidence streams used for vendor risk management in financial services, SOC 2 evidence collection, and the broader Datapath resources library.

How should financial IT teams supervise third parties after onboarding?

This is where the real work starts. A lot of programs are decent at onboarding and weak at supervision. SEC and FINRA expectations are not satisfied by a one-time questionnaire if the vendor supports critical systems year after year.¹³

4. Ongoing monitoring and periodic review

Monitoring should match the vendor’s risk tier. High-impact providers should not be reviewed on the same schedule as a low-risk administrative tool. The file should show:

• review cadence by risk tier
• current points of contact and internal owners
• SLA or service-performance tracking
• open risks, exceptions, and remediation status
• control evidence received and reviewed
• changes to service scope, infrastructure, or subcontractors
• internal leadership reporting where required

In our experience, the strongest programs also document what did not pass cleanly. If a vendor misses evidence deadlines, changes control language, introduces a new subprocesser, or suffers a service degradation, that belongs in the record. “Everything is green” is not a useful operating model if nobody can explain the real exceptions.

5. Access governance and technical control documentation

Documentation should connect vendor oversight to technical reality. That means keeping clear records of what access the vendor has, how it is approved, how it is reviewed, and how it is revoked.

A strong file should include:

Control area	What should be documented	Why it matters
Access scope	Systems, data sets, environments, and interfaces the vendor can reach	Prevents vague assumptions about exposure
Authentication	MFA expectations, identity provider integration, account ownership	Reduces unmanaged privileged access
Logging	What vendor activity is logged and how it is reviewed	Supports investigation and supervisory evidence
Change control	How vendor-driven changes are approved and tracked	Lowers operational surprise
Offboarding	Steps for account removal, key rotation, and connection teardown	Closes lingering access risk

This is where financial IT teams often benefit from aligning third-party oversight with their Microsoft 365 security baseline, incident response planning, and broader security-awareness efforts.

6. Incident response and breach communication

FINRA has specifically pointed to involving relevant vendors in incident-response planning and testing.¹ That makes sense. A vendor relationship is not really governed until your team knows what happens during a bad day.

Documentation here should cover:

• who at the vendor declares and escalates incidents
• notification pathways into your firm
• regulatory and customer-notification dependencies
• evidence-preservation expectations
• business continuity and failover assumptions
• tabletop participation or testing history
• post-incident remediation and lessons learned

That matters even more under updated Regulation S-P expectations, where timing and clarity around unauthorized access and customer-information handling are critical.² If your incident process depends on a vendor answering basic questions after a breach, then those expectations need to be documented before the breach happens.

What do firms often miss?

The most common gap is treating third-party risk as a compliance checklist instead of a cross-functional operating process. Procurement may own intake, legal may own contract language, compliance may own policy interpretation, and IT may own implementation. If those teams do not share one evidence trail, the program fragments fast.

We also see firms miss these issues repeatedly:

Fourth-party visibility

It is not enough to understand your direct vendor if that vendor relies on multiple subprocessors for hosting, support, storage, analytics, or remote operations. FINRA explicitly calls out the need to address vendors’ use of other vendors when those downstream relationships may handle firm data.¹

Data-retention and destruction proof

Many teams write “vendor will delete data at termination” into the contract and never collect evidence that it happened. If the relationship ends, your team should be able to prove what was returned, what was destroyed, and what access was removed.

Documentation drift

A file that was excellent at onboarding can become fiction a year later. Staff changes, cloud migrations, M&A activity, control changes, and vendor roadmap changes all create drift. That is why review cadence matters. A stale file is often worse than an incomplete one because it creates false confidence.

Why Datapath for third-party risk management support?

We think third-party risk management should help financial IT teams run a calmer, more defensible environment. The point is not to create more paperwork. The point is to make it easier to see where vendor dependency creates real risk, connect those risks to technical controls, and give leadership cleaner evidence before an audit, outage, or breach forces the issue.

For financial services teams, that usually means tying vendor oversight to identity governance, monitoring, incident response, business continuity, and compliance reporting instead of treating those as separate projects. That is also why teams often move between our homepage, financial services solutions page, managed IT services overview, and resources hub when they are trying to strengthen overall accountability rather than solve one narrow control gap.

If your team wants to tighten third-party governance, clarify documentation requirements, or build a more workable operating model around vendor oversight, talk with our team.

Frequently Asked Questions

What is SEC and FINRA third-party risk management?

SEC and FINRA third-party risk management is the process of identifying, documenting, supervising, and reviewing the vendors that support regulated financial operations, especially when those vendors affect customer information, core systems, cybersecurity, or compliance obligations.

What documents should a financial IT team keep for vendor oversight?

A financial IT team should keep a vendor inventory, risk assessments, due diligence records, contract reviews, access-control documentation, monitoring records, incident-response expectations, and termination evidence such as data-destruction confirmation and access revocation.

Does outsourcing a function reduce the firm’s regulatory responsibility?

No. Outsourcing may shift execution, but it does not remove the firm’s supervisory and safeguarding obligations. The firm still needs documentation showing how the vendor relationship is governed and reviewed.¹²

How often should third-party risk documentation be reviewed?

Review frequency should match vendor criticality and risk. High-risk vendors typically need a more frequent and evidence-driven review cycle, while lower-risk providers may fit a lighter cadence. The key is that the cadence is documented and followed consistently.

Sources

• FINRA Third-Party Risk Landscape (2025)
• FINRA Third-Party Risk Landscape (2026)
• FINRA Regulatory Notice 21-29 overview
• SEC / Regulation S-P vendor oversight summary
• FDIC Guidance for Managing Third-Party Risk
• Thomson Reuters on scoring third-party risk

Footnotes

1. FINRA Third-Party Risk Landscape (2025) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

2. SEC / Regulation S-P vendor oversight summary ↩ ↩² ↩³ ↩⁴

3. FINRA Third-Party Risk Landscape (2026) ↩ ↩²

4. FDIC Guidance for Managing Third-Party Risk ↩