Managing Third-Party Risk for Compliance Frameworks

Managing Third-Party Risk for Compliance Frameworks

There’s a pattern that shows up in almost every audit of an organization that handles sensitive data: their own internal controls are in reasonable shape, but their vendor relationships are a mess.

Not because the vendors are inherently risky — though some are — but because the organization has never systematically evaluated them. They’ve signed contracts, maybe exchanged a questionnaire once, and then handed over access and moved on. From a compliance standpoint, that’s a problem. Under frameworks like CMMC 2.0 and NIST 800-171, the responsibility for protecting CUI doesn’t stop at your perimeter. If a vendor touches your data or your systems, your compliance program needs to account for them.

Why Third-Party Risk Is a Framework Requirement, Not Optional

CMMC 2.0 Practice SC.L2-3.13.9 requires organizations to control the flow of CUI in external systems. NIST 800-171 goes further with its supply chain risk management provisions, requiring organizations to assess the security practices of suppliers and service providers who handle CUI. ISO 27001 has explicit third-party security controls in Annex A.15.

The implication is clear: “we trust our vendors” isn’t a control. An assessor is going to ask how you’ve verified that trust, what contractual security obligations exist, and how you monitor ongoing compliance. If your answer is “we signed an NDA,” that’s a finding.

The Three Layers of Vendor Risk

Not all vendors carry equal risk. Before you build a vendor risk program, it helps to think in tiers:

Tier 1 — Critical Access. These vendors have direct access to CUI, your systems, or your network. Managed IT providers, cloud platforms that store or process your data, security tools with admin rights. These vendors require the most scrutiny: formal security assessments, contractual security requirements, and regular review cycles.

Tier 2 — Indirect Exposure. Vendors who don’t touch CUI directly but whose products or services could create exposure if compromised. Software vendors, SaaS tools used by employees, development contractors. These require baseline questionnaires, security addenda in contracts, and periodic re-evaluation.

Tier 3 — Minimal Risk. Vendors with no meaningful access to systems or data — office supplies, facilities, general professional services. These typically require only standard contract terms and business-level due diligence.

The first step in any vendor risk program is building this inventory and categorizing what you have. Most organizations discover they’ve given Tier 2 access to vendors they’ve been treating as Tier 3.

What Evidence Looks Like

Saying you’ve assessed your vendors isn’t the same as showing it. Assessors want to see a paper trail.

Vendor inventory. A maintained list of all vendors with access to systems or data, their tier classification, the nature of their access, and their most recent assessment date. This doesn’t need to be elaborate — a well-maintained spreadsheet or a module in your compliance platform works — but it needs to exist and be current.

Completed security questionnaires. For Tier 1 and Tier 2 vendors, you should have a completed security questionnaire on file. Standardized questionnaires like the Standardized Information Gathering (SIG) questionnaire or a custom internal version that maps to your framework requirements both work. The key is that you asked, they answered, and you retained it.

Contractual security requirements. Vendors in Tier 1 and Tier 2 should have security obligations in their contracts or in a Data Processing Addendum (DPA) or Business Associate Agreement (BAA) if applicable. At minimum: data handling requirements, breach notification timelines, right to audit provisions, and requirements to notify you of significant changes to their security posture.

Review cadence documentation. High-risk vendors should be reviewed annually at a minimum. Track when each vendor was last reviewed and when the next review is due. Gaps in review cycles are a common finding.

The Access Provisioning and Deprovisioning Problem

One of the most common third-party risk failures isn’t in the initial assessment — it’s in what happens over time.

Contractors and vendor representatives get access, then the project ends, the contact changes, or the relationship evolves in ways nobody tracked. You end up with stale accounts, overly broad permissions, and sometimes access for people who have left the vendor entirely.

For frameworks that require least-privilege and access reviews, vendor access needs the same treatment as employee access: a periodic user access review that looks specifically at third-party accounts, their current permissions, and whether those permissions are still appropriate. Evidence of this review — who conducted it, when, what accounts were reviewed, what actions were taken — is exactly the kind of documentation that satisfies an assessor.

Building the Program Without Starting from Scratch

The good news is that most of what you need to build a vendor risk program is probably already available in your organization. You have contracts. You have some kind of vendor contact list. You likely have a few questionnaires floating around from specific vendor negotiations.

The work is in systematizing it:

1. Build the inventory. Pull together every vendor who has network, system, or data access. This is usually a multi-team effort involving IT, Legal, and whoever manages vendor relationships.

2. Classify the tiers. For each vendor, determine what they have access to and apply the tier classification. When in doubt, classify higher — it’s easier to downgrade later than to explain a gap.

3. Close the documentation gaps. For Tier 1 and Tier 2 vendors where you don’t have a completed assessment on file, send a questionnaire. For vendors where contractual security language is missing, engage Legal to address it.

4. Establish review cycles. Set calendar reminders or automated workflows to trigger annual reviews for high-risk vendors. Make someone specifically responsible for tracking the review cadence.

5. Document access provisioning and deprovisioning. When a vendor is onboarded, document what access they’re getting and why. When the relationship ends, document the deprovisioning. These records become evidence in an access review.

---

Third-party risk is one of the areas where compliance programs most commonly underinvest until an incident or an audit makes it unavoidable. The frameworks are explicit about it, and assessors know to look closely at vendor relationships because they know it’s where gaps tend to hide. Building a lightweight, maintained program now is significantly less painful than explaining a gap later.