Third-Party Risk: Securing the Vendors You Depend On

Your perimeter now runs through other companies

Most organizations have spent a decade hardening their own environment — patching, segmenting, deploying detection — while quietly handing copies of their most sensitive data to dozens or hundreds of outside companies. Your payroll processor, CRM, managed IT provider, marketing platform, and code dependencies each hold data or system access an attacker can use to reach you, and each is defended by a security program you do not control.

Attackers have noticed. The economics are simple: compromise one software vendor and you inherit access to every customer that trusts it. The 2024 Verizon Data Breach Investigations Report expanded its supply-chain analysis specifically because the share of breaches involving a third party climbed sharply — roughly doubling in a single reporting cycle. Landmark incidents like the SolarWinds and MOVEit campaigns did not exploit the victims directly; they exploited software the victims installed and trusted. A vendor breach is now one of the most common ways an otherwise well-defended organization ends up in an incident response engagement.

Third-party risk is not a procurement checkbox. It is an extension of your own attack surface, and it deserves the same rigor you apply to your internal controls.

Start with an inventory you can trust

You cannot manage risk in vendors you have not enumerated. Almost every third-party risk program we build starts by discovering that the "approved vendor list" in procurement covers a fraction of the companies actually touching corporate data. Shadow SaaS, departmental tools bought on a credit card, and free-tier services accumulate faster than any spreadsheet tracks.

A usable vendor inventory captures, for each relationship:

• What data they hold or process — regulated data (PII, PHI, cardholder data), credentials, source code, or nothing sensitive at all.
• What access they have — network connectivity, API tokens, admin rights in your systems, or physical access.
• How critical they are to operations — could a vendor outage stop you from serving customers or making payroll.
• The business owner — the person who actually signed up and can answer for the relationship.

Discovery is not a one-time survey. Pair the procurement list with data from your SSO/identity provider, expense systems, DNS and email logs, and external attack surface management, which routinely surfaces vendor-hosted subdomains and integrations nobody registered. The goal is a single, deduplicated register that reflects reality, not the version everyone hopes is true.

Figure: risk radiates outward through every spoke — and each vendor is itself a hub connecting to fourth parties you never contracted with.

Tier by data access, not by spend

The instinct is to prioritize vendors by contract value. That is the wrong axis. A six-figure office-supply contract carries almost no cyber risk; a free analytics widget embedded in your checkout page can exfiltrate every customer record. Tier vendors by the blast radius of their compromise:

1. Tier 1 — critical. Holds regulated data at scale, has privileged access to production systems, or a failure halts the business. Your MSP, identity provider, payment processor, and core SaaS platforms live here. These get the deepest review and continuous monitoring.
2. Tier 2 — important. Handles some sensitive data or has scoped system access, but a compromise is contained. Standard due diligence and periodic reassessment.
3. Tier 3 — low risk. No sensitive data, no meaningful access. Lightweight review, mostly to confirm the classification is correct.

Tiering is what makes the program survivable. You cannot deeply assess three hundred vendors every year, but you can assess the fifteen or twenty in Tier 1 properly and apply proportionate effort to the rest. If your team lacks the bandwidth to define and defend these tiers, a virtual CISO engagement gives you an experienced hand to build the framework and the risk-acceptance criteria that go with it.

Questionnaires tell you what a vendor says. Evidence tells you what they do.

The default due-diligence tool is a security questionnaire — a spreadsheet of yes/no controls the vendor self-attests to. Questionnaires are not worthless, but they measure a vendor's ability to answer questions, not their actual security posture. For any vendor that matters, insist on independent evidence:

• SOC 2 Type II report. The one artifact worth the most. Type II tests whether controls operated effectively over a period (typically 6–12 months), not just whether they existed on paper on one day. Read the auditor's exceptions and the scope — a clean report that excludes the product you actually use tells you little. Note that many vendors also share a bridge letter to cover the gap since their last report.
• Penetration test summaries. Ask for a recent third-party penetration testing attestation and, ideally, evidence that findings were remediated. A vendor that tests and fixes is materially safer than one that has never had an outsider try.
• ISO 27001 certification, PCI DSS AOC, or HIPAA attestations where the data type demands them.
• Their own subprocessor list — which leads directly to the fourth-party problem below.

For Tier 1 vendors, treat missing or evasive evidence as a finding in itself. "We take security seriously" with nothing to back it is a risk indicator, not reassurance.

Put the controls in the contract

Diligence tells you where a vendor stands today; the contract governs what happens when things change or go wrong. Bake security into the master services agreement and data processing addendum rather than a best-effort side letter. The clauses that earn their place:

• Breach notification with a defined clock — a hard deadline such as notification within 72 hours of discovery, not "promptly." Regulations like GDPR set 72 hours for a reason; your contract should not be looser than the law you answer to.
• Right to audit or to receive current attestations on a stated cadence.
• Data handling, encryption, retention, and deletion requirements, including certified destruction and return of data at termination.
• Subprocessor disclosure and approval, so vendors cannot silently push your data down a chain you never vetted.
• Minimum security controls and liability/indemnification proportional to the data at stake, plus cyber-insurance requirements for critical vendors.

Contracts also define the joint playbook for an incident. When a vendor breach hits, you do not want to be negotiating access to logs and notification duties in the middle of it — that belongs in your incident response plan and in the signed agreement, settled in advance.

Point-in-time reviews go stale immediately

A SOC 2 report is a snapshot. A vendor that was secure at signing can lay off its security team, get acquired, or suffer a breach the week after you onboard them. Annual reassessment is the floor, and for Tier 1 vendors it is not enough on its own. Continuous monitoring closes the gap between reviews:

• Security-rating and external monitoring services that watch a vendor's internet-facing posture — expired certificates, exposed services, leaked credentials — and alert on deterioration.
• Breach and dark-web intelligence that flags when a vendor is named in a disclosure or their credentials appear in a dump.
• Access reviews confirming that vendor accounts, API tokens, and network paths are still needed and still scoped to least privilege. Dormant vendor access is a standard attacker foothold.

Feed these signals into the same security operations workflow that watches your own environment. A vendor's newly exposed admin panel deserves a ticket just as much as one of your own would.

Fourth-party risk: the vendors of your vendors

Your Tier 1 SaaS platform likely runs on a hyperscaler, sends email through a third party, and processes payments through a fourth. Those are your fourth parties — companies you never contracted with but whose failure still reaches your data. The MOVEit campaign hurt thousands of organizations that had never heard of MOVEit; they were customers of companies that used it.

You cannot audit every fourth party, but you can manage the exposure. Require Tier 1 vendors to disclose their critical subprocessors, review whether concentration risk means one hyperscaler outage takes down half your vendors at once, and confirm that your vendors run their own third-party program. A vendor that cannot tell you who they depend on has not thought about the problem — and that answer is itself a risk rating.

Make it a program, not a project

Third-party risk management fails when it lives only in a procurement gate at onboarding and is never revisited. It works when it is a continuous discipline: a live inventory, defensible tiers, evidence-based diligence, contractual teeth, and ongoing monitoring wired into your security operations. That structure is also exactly what auditors expect — a defensible vendor program is a recurring requirement across SOC 2, ISO 27001, and most regulatory regimes, so the work doubles as security compliance evidence.

intSignal builds and runs third-party risk programs for organizations that have outgrown the spreadsheet — from vendor discovery and tiering through evidence review, contract controls, and continuous monitoring. Talk to our security team and we will help you find out which of your vendors is your next incident before an attacker does.