Third-Party Risk Management: The Compliance Gap Many Organizations Overlook

Throughout my experiences building compliance programs across heavily regulated industries, I've seen one vulnerability appear time and again — and it almost never originates inside the organization. It comes through the door with a vendor contract.

Third-party risk management is one of the most foundational elements of a mature compliance program and one of the most commonly underdeveloped. Organizations spend significant resources building internal policies, training employees, and preparing for audits, then extend access, data, and operational dependencies to third-party vendors without applying anything close to the same rigor. Regulators have noticed. Enforcement actions tied to third-party failures have become increasingly common across industries, and the message is clear – your compliance obligations don't stop at your own front door.

Why Third-Party Risk Is Different

The challenge with third-party risk is that you are accountable for outcomes you don't fully control. When a vendor mishandles sensitive customer data, violates a regulatory requirement, or fails to maintain adequate security controls, the regulatory and reputational exposure often falls on your organization as well, particularly if you are the entity with the direct relationship with the affected individual or regulator.

I’ve seen this dynamic repeatedly play out in the financial services industry where bank regulators have long held that regulated institutions cannot outsource their compliance obligations. A bank that relies on a third-party vendor for BSA/AML transaction monitoring is still fully responsible for the quality and completeness of that monitoring. If the vendor's model produces poor results, the bank receives the examination finding, not the vendor.

Fintech companies occupy a particularly complex position in this landscape. They are simultaneously heavy consumers of third-party technology and, increasingly, regulated entities in their own right. A payments fintech, for example, might rely on third-party identity verification vendors and a fraud detection platforms all while being subject to state money transmitter licensing requirements and federal BSA obligations. The more a fintech's core compliance functions are outsourced to vendors, the more critical it becomes to treat third parties as a compliance risk in its own right, and not just a technology procurement decision.

This is equally relevant to the cannabis industry, where operators depend on a dense ecosystem of third-party vendors: point-of-sale systems, seed-to-sale tracking platforms, payment processors, and laboratory testing facilities. Each of those relationships carries compliance implications — state cannabis regulators don't distinguish between a licensee's own failure and a failure by its technology vendor that caused inaccurate data. The license is yours, the compliance obligation is yours, and if a vendor failure triggers a violation, your organization answers for it.

Building a Risk-Based Vendor Management Framework

The good news is that third-party risk management doesn't require treating every vendor the same. A risk-based framework allows you to apply the most rigorous due diligence where it matters most and apply lighter-touch processes where the exposure is genuinely low. Here is how I approach building that framework.

Step 1: Classify Your Vendors by Risk

Not every vendor relationship carries the same compliance exposure. A vendor that processes personal data, has access to regulated systems, or performs a function that directly touches your regulatory obligations is fundamentally different from a vendor that supplies office furniture or provides catering for company events.

A useful starting classification considers three dimensions: data access, operational dependency, and direct regulatory exposure. Vendors that score high on any of these dimensions warrant enhanced due diligence. Those that score low can move through a more streamlined process.

Step 2: Conduct Due Diligence Before Onboarding

Due diligence should happen before a contract is signed, and the depth of that diligence should match the vendor's risk classification. For high-risk vendors, this typically means reviewing their compliance policies and procedures, assessing their data security posture, understanding their own third-party dependencies, reviewing any relevant certifications or audit reports such as SOC 2 reports, and asking pointed questions about how they handle regulatory change.

For vendors in highly regulated contexts, the due diligence process should also include a review of their regulatory standing. Are they licensed where required? Have they been subject to enforcement actions?

Step 3: Get the Contract Right

Vendor contracts are one of the most underutilized compliance tools in most organizations. A well-drafted vendor agreement does more than establish commercial terms — it allocates compliance responsibility, establishes audit rights, and creates a contractual foundation for managing problems when they arise.

Key provisions to push for in high-risk vendor contracts include: explicit representations and warranties regarding regulatory compliance; data handling obligations that account for your own regulatory requirements; notification obligations requiring the vendor to alert you promptly to breaches, regulatory inquiries, or material changes to their business; your right to audit or receive audit reports on a periodic basis; and clear liability and indemnification terms for compliance failures caused by the vendor. Compliance teams should be involved in contract review — not handed the final agreement after the commercial deal is already done.

Step 4: Monitor Vendors on an Ongoing Basis

Onboarding due diligence answers the question of whether a vendor was acceptable at the time of engagement. Ongoing monitoring answers the question of whether they remain acceptable. Businesses change, key personnel turn over, security postures degrade, and regulatory environments shift. A vendor that passed your due diligence two years ago may look quite different today.

For most vendors, this could mean an annual attestation that their compliance posture hasn't materially changed, automated monitoring for adverse news or regulatory actions, and triggered reviews when significant events occur — a vendor acquisition, a reported breach, a change in scope of services. For your highest-risk vendors, it may mean annual on-site reviews or a requirement to share updated SOC 2 reports.

Step 5: Have an Exit Strategy

This step is frequently overlooked until it becomes urgent. What happens if a vendor fails to meet your compliance standards, is acquired by a problematic entity, loses a required license, or simply goes out of business? Organizations that haven't thought through vendor exit scenarios often find themselves in an impossible position: continuing a relationship that creates compliance risk because transitioning away is operationally disruptive.

A mature program identifies critical vendor dependencies in advance and maintains documented contingency plans for key relationships. It also ensures that contracts include provisions for data return or destruction upon termination — a requirement that is both good compliance practice and often legally mandated when regulated data is involved.

The Emerging Dimension: AI Vendors

Third-party risk management has taken on new complexity in the AI era. Organizations are deploying AI tools built by third-party vendors at a rapid pace, often without applying the same scrutiny they would to, say, a third-party data processor. This is a gap that regulators are beginning to probe.

The questions that matter for AI vendors are an extension of the core third-party risk framework – What data does the AI system process? How does the vendor handle model updates that might change the system's behavior? What audit trails does the system produce? What happens when the AI makes an error that causes harm? As both the EU AI Act and state-level AI laws in the United States continue to take effect, the compliance obligations that attach to AI deployments will increasingly run through vendor relationships — and organizations that have robust frameworks will be far better positioned to meet them.

The Bottom Line

Regulators across industries operate on a simple principle: if you chose to rely on a third party, you chose to accept accountability for how they perform it. That principle shows up in bank examination guidance, state cannabis regulations, healthcare privacy requirements, and emerging AI frameworks alike.

Organizations that treat vendor relationships as purely commercial decisions, without applying compliance rigor to selection, contracting, and ongoing oversight, are accepting risk they may not fully see until a regulator or an incident makes it uncomfortably visible. The investment required to build a solid third-party risk framework is modest compared to the cost of getting it wrong.