Publish date
November 12, 2026
{x} minute read
Written by
Reviewed by
Table of contents

In mid-October 2026, attackers used a compromised credential belonging to ConnectWise Cloud Backup, a Microsoft 365 backup app formerly called SkyKick, to sign in to customer tenants. 

‍Microsoft later reported attempted sign-ins to more than 2,250 tenants. Because managed service providers (MSPs) roll the app out across their clients, the impact reached organizations that may never have bought it directly.

Many security teams likely spent the first hours of that incident on questions a vendor inventory should answer, and usually can’t: Do we use ConnectWise, under either name? What’s it connected to? Who approved it, and is it still in use?

Most vendor inventories are built to answer “Who do we pay?” An incident asks “What would we lose?” Here’s why most inventories can’t answer the second question, and what changes when every vendor has a record you can act on.

If you rebuild your list every time someone asks, it isn’t an inventory

Effective risk management starts with the blast radius: what you’d lose if a vendor were compromised or went offline. You need that view every day, and you need it fastest during an incident. An invoice will tell you a vendor costs $40,000 a year. You’ll need to look somewhere else to find out if it holds a copy of your customer database.

Most inventories can’t show you that, because they only exist when someone builds them. Ask for the full list, and someone on your team disappears for a day, pulling from accounts payable, the procurement system, the contract repository, and a spreadsheet a former analyst started years ago. 

Each source exists for a different job, and none of them holds the vendor relationship itself. Even the names don’t match: Microsoft in procurement might be Microsoft Ireland Operations Ltd in the finance export. A practical first step is to pick one canonical name and ID per vendor, then map every source system’s name to it.

The consolidated list that comes out of this can get you through a basic request, like a board update, and that used to be enough. It won’t satisfy the increasing regulatory scrutiny, such as the register of information under the EU’s DORA, which asks financial entities for contractual and dependency details on each third party. 

The list also starts going stale the day it’s finished, so the next request kicks off the rebuild all over again.

Even a complete vendor list still can’t answer “Are we exposed?”

Say the list problem is now solved. Every vendor appears once under a single name, and your list stays current. When a vendor hits the headlines like ConnectWise did, you can confirm within seconds that you use it. But a name is where the list runs out of answers.

To answer “Are we exposed?”, each vendor’s record needs a few basic fields. Each one answers a question an incident like the ConnectWise one raises:

  • Canonical name and ID (Do we use ConnectWise, under either name?): Confirms you use the vendor, whatever name it goes by in finance or procurement, or went by before a rebrand.
  • Data and access (What’s it connected to?): Shows which of your systems the vendor connects to and what data it can reach.
  • Approver (Who approved it?): Shows who signed off and on what basis, so you can check whether today’s use matches what was approved.
  • Lifecycle stage (Is it still in use?): Separates vendors in active use from ones still in procurement or on their way out.
  • Tier (What would we lose?): Reflects how much of the business depends on the vendor and what breaks if it leaks your data or goes offline.
  • Business owner (Who owns it now?): Gives you the first person to call, someone who knows how the tool is used day to day.
In UpGuard Vendor Risk, every vendor, monitored or not, can now carry its tier, labels, attributes, contacts, and lifecycle stage in one record. When a name comes up, you start with a full picture of the relationship.
A person using a laptop to take an UpGuard Vendor Risk product tour

Your vendor tiers have a shelf life

Think about where a Microsoft 365 backup tool sits in most tiering models. It’s an IT utility your MSP may have set up years ago, so it gets tiered on what it does, if anyone tiers it at all.

That’s the gap the ConnectWise breach exposed. A tier should track a vendor’s blast radius, and this one covered much of your Microsoft 365 data from day one. It kept that reach through an ownership change and, in some tenants, after anyone stopped using it.

You tier a vendor at one point in time, and its inherent risk keeps moving on two sides:

  • The vendor changes: It adds AI features to a product you bought for something else, changes how it stores or processes your data, gets acquired, or takes on a new subprocessor.
  • Your use changes: A trial in one team becomes a company-wide rollout, someone grants it access to a core system, or it starts holding data nobody considered at onboarding.

None of these changes updates a spreadsheet on its own. You find out through people and processes, and each signal is only useful if there’s a record to update. Here’s where each signal tends to show up, and what to revisit in the vendor’s record when it does:

Signal Who usually sees it first What to revisit
A new integration or access grant to a core system IT or the system admin Systems connected, data in scope, owner, tier
A renewal with a bigger scope or new modules Procurement or the business owner Data in scope, criticality, tier, contract terms
A sub-processor or terms update, including new AI features Legal or privacy, through a vendor notice How data is handled, tier
An acquisition or change of ownership The news, or a vendor notice Contacts, reassessment
A rollout from one team to many The business owner or IT Criticality, owner, tier
A scheduled review The third-party risk team All of the above

Each signal comes back to one question: what can this vendor reach now? If the answer puts the vendor in a tier you monitor, it goes into continuous monitoring.

If the change already comes through a process your team runs, such as a vendor access request in ServiceNow, you can add UpGuard Risk Automations to start the follow-up in Vendor Risk. It can move the vendor into monitoring and send an onboarding questionnaire.

One system that measures the right thing

With UpGuard Vendor Risk as your system of record for your entire vendor portfolio, the answer to your CISO's, auditor's, regulator’s, or board’s questions lives in one place.

Every vendor gets a record, including the ones you don’t monitor today. You can apply a lifecycle stage to track where each relationship stands across procurement, onboarding, in use, offboarding, and archived.

Your current spreadsheet comes with you. Import your existing list of monitored and non-monitored vendors, lifecycle stages included, and retire the copy your team reconciles every quarter.

‍Continuous monitoring remains the active layer for vendors that warrant it, with a security rating, alerts, questionnaires, and risk assessments. When a stored vendor’s inherent risk rises, you re-tier it and bring it into monitoring from the record you already hold, so your response starts from what you know about that vendor.

Stopping monitoring doesn’t erase your work. A vendor’s questionnaires, documents, risk assessments, and remediation history stay in the platform while it’s stored, out of view, and come back the moment you monitor it again.

The record connects to intake as well. Requests that come through the Onboarding Portal can end in a stored vendor record, so a request lands in your inventory, whatever the outcome.

Get visibility from discovery to offboarding

Two UpGuard products make your vendor record even more complete. UpGuard User Risk detects the apps employees use in managed browsers, including ones that never pass through single sign-on, and shows which of those vendors you already monitor in Vendor Risk. From there, your team decides which of the others belong in your inventory.

Risk Automations works at the other end of the lifecycle too. When an offboarding request comes through, it can archive the vendor in Vendor Risk and keep its record.

Replay the ConnectWise incident with a system of record in hand

Picture the ConnectWise incident landing on a team with a complete vendor record. One search confirms you use the app under either name and shows what it can reach. The record names the owner and the MSP that set it up, so the first call takes a minute. The hours other teams lost to basic questions go into disabling the app and checking sign-in logs.

A record for every vendor, with monitoring for the ones that matter, gives you a straight answer when an auditor asks how many third parties you have. It also gives you a head start when a tier-four vendor starts to matter.

Vendor Risk can now hold that record for every vendor, from the first intake request to offboarding, with continuous monitoring for the ones that need it. Explore Vendor Risk and see how the platform keeps every vendor in your portfolio in one system of record.

Related posts

Learn more about the latest issues in cybersecurity.