Enterprise Readiness

Third-Party Risk Is Now Breach Risk: The Vendor-Security Program a Small Team Can Actually Run

Dark cyberpunk illustration of a fortress built from stacked glass data cubes at night, tethered by glowing orange supply lines to smaller outbuildings, with one outbuilding cracked open and cyan data draining back along the line toward the fortress.

A large bank does not let a vendor touch its data on a handshake. Before a supplier gets an API key, a mailbox scope, or a login, it clears a security questionnaire, a penetration-test summary, a SOC 2 report, and a contract that names a breach-notification window and a right to audit. A risk team re-checks the important vendors every year and watches the rest continuously. That machinery is expensive, and it exists because the numbers stopped being ignorable. Verizon's 2026 Data Breach Investigations Report ties 48 percent of confirmed breaches to a third party, up from 30 percent the year before. Roughly half of every breach now arrives through an outside party a company decided to trust.

If your business stores records in a vendor's systems, lets a SaaS app read your email or CRM, or hands a managed-service provider a login, that statistic is describing you. The only reader who can close the tab is one with no outside software and no supplier with access to anything, and that company does not exist. What you do not have is the bank's budget or its risk team. So this is the right-sized version of that program: the handful of parts that would have changed the outcome of the 2026 vendor breaches, built to run on a spreadsheet and a recurring calendar entry instead of a governance department.

What the 2026 vendor breaches have in common

On June 15, iRhythm, the company behind the Zio cardiac monitor, told the SEC in an Item 1.05 filing that an intruder had used social engineering to reach "certain third-party-hosted business applications," exfiltrate patient protected health information along with proprietary and personal data, and demand payment to keep the files offline. iRhythm found the activity on June 8; the extortion note arrived June 9; by June 10 it had determined the loss was material. Its own products, clinical systems, and manufacturing were never touched. The entire breach happened inside software a vendor ran on iRhythm's behalf, and iRhythm had no server to patch and no console to lock down.

Two months earlier the Everest extortion group listed Citizens Financial Group and Frost Bank, claiming roughly 3.4 million records from one and 250,000 from the other. As the post-incident analysis laid out, neither bank was broken into. Both outsourced statement printing and tax-document fulfillment to the same supplier, and that one vendor's compromise exposed regulated financial data from two unrelated banks at once. Everest then added the back-office processors TSYS, Symcor, and Fiserv to the same campaign, working down a list of providers that each hold data for many downstream customers.

The mechanism under both stories is the one the DBIR quantifies, and the cleanup timeline is the part that should worry a small business most. When a third party is breached, the fix is slow: Verizon found that only 23 percent of third-party organizations had fully remediated missing or misconfigured multi-factor authentication on their cloud accounts, and half of the weaker findings sat open for close to eight months. You inherit that clock. Your data stays exposed for as long as your vendor takes to clean up, and unlike a vulnerability in your own network, there is nothing on your side to fix.

Step one, inventory the vendors and the apps that already hold your data

Every control below depends on a list almost no small team keeps: who holds your data, and what they can reach. Build two inventories. The first is human - the suppliers, contractors, and managed-service providers with a login or a copy of your records. A spreadsheet is enough. The second is the one that surprises people, because nobody approved it in a meeting: the OAuth applications and service principals wired into your Microsoft 365 or Google Workspace tenant, each carrying a standing token that reads mail, files, or directory data without a password or an MFA prompt. Microsoft documents how to review those grants in the Entra portal; the fast way to see all of them at once is Graph PowerShell.

# Inventory every third-party app with standing access to your Microsoft 365
# tenant: its delegated (act-on-behalf-of-a-user) OAuth grants and the scopes
# it holds. Run as a Global Reader or Cloud Application Administrator.
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"

$tenantId = (Get-MgContext).TenantId

# Non-Microsoft service principals are the vendors and add-ons you have trusted.
$thirdParty = Get-MgServicePrincipal -All |
  Where-Object { $_.AppOwnerOrganizationId -ne $tenantId -and
                 $_.ServicePrincipalType -eq 'Application' }

$grants = Get-MgOauth2PermissionGrant -All
foreach ($sp in $thirdParty) {
  $g = $grants | Where-Object ClientId -eq $sp.Id
  [pscustomobject]@{
    App     = $sp.DisplayName
    Consent = ($g.ConsentType | Select-Object -Unique) -join ','
    Scopes  = ($g.Scope -join ' ').Trim()
  }
} | Sort-Object App | Format-Table -Wrap

Read the Scopes column first. Any app carrying Mail.Read, Mail.ReadWrite, Files.ReadWrite.All, or Directory.Read.All can pull exactly the data an extortion crew wants, and a ConsentType of AllPrincipals means it reads across every mailbox in the company rather than one user's. The app nobody on the team can name is your first thing to revoke. iRhythm's intruder did not need a zero-day; they talked their way into an application that already carried this kind of access, and the token did the rest.

Step two, tier vendors by the data they can reach

A large program grades every vendor against dozens of controls. You do not have time for that, and the good news is you do not need it. Rank each vendor once, by the size of the loss if that vendor were breached tomorrow, and spend your limited effort where the loss is largest.

  • Tier 1 - holds regulated or bulk personal data, or can reach your production systems. Your payroll processor, your practice-management or EHR host, your MSP, the SaaS platform that stores customer records. A breach here becomes a reportable incident with your name on the notification letter. These get real diligence.
  • Tier 2 - holds internal data or limited personal data. Marketing platforms, ticketing, an analytics tool with read access to the CRM. A breach is painful and embarrassing without being a mass-notification event.
  • Tier 3 - no access to sensitive data. The design tool, the status-page service. Track them only so they cannot quietly climb a tier the day someone connects them to something that matters.

For every Tier 1 vendor, ask four questions and keep the written answers: do you enforce MFA on every account that can reach our data; are our records encrypted at rest; will you notify us of a security incident within a fixed number of days, in writing; and where do you store any tokens or credentials you hold on our behalf. CISA frames the same short list for smaller organizations in its Securing Small and Medium-Sized Business Supply Chains handbook, without the enterprise questionnaire overhead. A vendor that cannot answer those four has given you your answer.

Step three, put the requirements in the contract and the review on the calendar

Inventory and tiering do nothing on their own; two mechanisms turn them into protection, and both are free. The first is the contract. Before the next renewal, get a written incident-notification clause into every Tier 1 agreement - a defined window, the categories of data covered, and the vendor's obligation to preserve logs and cooperate. Seventy-two hours is the number regulators and insurers increasingly expect. CISA's Cross-Sector Cybersecurity Performance Goals put contractual notification and MFA at the center of vendor risk precisely because, without that clause, you find out about the breach when the extortion group posts your files.

The second mechanism is a recurring review, and it is a calendar entry, not a project. Quarterly, re-run the OAuth inventory from step one, kill the grants nobody uses, and confirm your Tier 1 vendors still enforce the controls they attested to. The reason the order matters is speed of cleanup. When iRhythm's and Citizens' vendors were breached, the downstream companies could not patch anything; their only levers were the ones set in advance - what data the vendor was allowed to hold, what the contract obligated, and how fast access could be revoked. A business that has never inventoried its vendors learns all of that during the incident, while a lawyer explains what "material" means to the board.

Start the vendor inventory before an extortion email starts it for you

The first vendor breach you hear about will probably not be a patch you missed. It will be a message from a group you have never heard of, holding data you forgot a supplier had. Build the two lists this week - the vendors with a login and the apps with a token - rank them by what a breach would expose, and get a notification clause into your top contracts before the next renewal comes up. That sequence is the part of a Fortune 500 vendor-risk program that actually moves your exposure, and it fits inside a spreadsheet, a short PowerShell run, and a standing meeting.

If your team has never counted the third-party apps and suppliers wired into the business, that count is where a vendor-risk review starts. It is usually a short engagement, and it usually surfaces at least one Tier 1 vendor, or one live OAuth token, that nobody remembered was there.

Need a vendor-risk process that fits your team?

We help small teams build a right-sized third-party risk program: a real vendor inventory, data-access tiering, and the contract and monitoring controls that reduce exposure without a governance department. Book a session to map your vendor risk with our team.