You Can Outsource the Technology—Not the Risk

A small business rarely operates its technology alone.

An outside provider may manage the network. A cloud platform stores customer records. A payroll company processes employee information. A software vendor runs scheduling, billing, inventory, or sales. An accountant, website developer, or support technician may have access to important systems.

These relationships usually make sense. A capable provider can deliver expertise, security, reliability, and support that would be difficult for a small business to maintain internally.

But outsourcing the work does not outsource the consequences.

If the vendor is breached, unavailable, or using access the business does not understand, the customer still experiences the interrupted operations, exposed information, missed payments, frustrated clients, and recovery costs.

The objective is not to distrust every vendor or bring all technology back in-house. It is to understand where the business has placed its trust—and make that trust deliberate.

A Vendor Can Become Part of Your Operating System

Small businesses often evaluate vendors according to features, price, and customer service. Cybersecurity may appear as a technical detail to be handled by the provider.

That view misses how deeply some vendors become connected to daily work.

A technology provider may:

Hold administrator access to computers, email, cloud services, or the network
Store customer, employee, payment, health, or financial information
Maintain backups or recovery credentials
Connect remotely through tools that are available at all times
Operate a platform required to sell, schedule, invoice, communicate, or deliver services
Depend on additional subcontractors and cloud providers the business never selected directly

The relationship may begin as a software purchase or support contract. Over time, it can become a critical operational dependency.

That dependency creates three questions:

Access risk: What can the vendor or its tools reach?
Data risk: What information can the vendor view, store, change, or lose?
Continuity risk: What work stops if the vendor becomes unavailable?

These questions matter more than whether a provider uses the word “secure” on its website.

Real Incidents Show Different Forms of Vendor Risk

Third-party incidents do not all look the same. Some spread through trusted administrative tools. Some expose data handled by widely used software. Others make an essential service unavailable even when the customer’s own network has not been breached.

Kaseya: trusted management access became an attack path

In July 2021, a supply-chain ransomware attack targeted Kaseya VSA, a remote monitoring and management product used by managed service providers. CISA and the FBI issued guidance for both the service providers and their downstream customers. Kaseya shut down its software-as-a-service servers and advised customers running the product on their own systems to shut those servers down while the incident was addressed.

Remote management tools are intentionally powerful. They allow technicians to install software, change settings, troubleshoot systems, and administer many customer environments efficiently. That same reach can magnify the impact when the tool or the access surrounding it is compromised.

The lesson for a small business is not to avoid managed service providers. It is to know which remote-management tools are installed, require strong authentication and individually attributable accounts, limit privileges where practical, and understand how the provider will contain and communicate an incident.

MOVEit: third-party software became a data-exposure path

In 2023, the CL0P ransomware group exploited a previously unknown vulnerability in Progress MOVEit Transfer, software used by organizations to exchange files. According to a joint CISA-FBI advisory, attackers exploited the vulnerability in internet-facing MOVEit applications and stole data.

A business does not need to operate its own file-transfer server to be affected by a product vulnerability. Sensitive information may pass through a service provider, payroll processor, benefits administrator, law firm, accountant, or other partner using that technology.

The lesson is that vendor risk follows the data. A business should know which providers receive sensitive information, why they need it, how long they retain it, which other parties process it, and how quickly the business will be notified if that information may have been exposed.

CDK Global: the vendor’s outage became the customer’s outage

In June 2024, a cyber incident at CDK Global disrupted systems used by automobile dealerships. Public filings by affected dealership groups described interruptions to software supporting sales, customer relationships, financing, service, inventory, accounting, and other back-office functions.

Several companies reported activating continuity plans and using manual or alternative processes while CDK’s systems were unavailable. The incident demonstrated a different kind of third-party risk: a business can suffer significant disruption even when the attack occurs outside its own environment.

The lesson is straightforward. If a vendor operates a process the business cannot function without, the continuity plan must address that vendor’s failure—not only failures inside the business.

Responsibility Is Shared, but Consequences Are Not

Vendor contracts often divide security responsibilities between the provider and the customer.

The provider may secure the platform, maintain its infrastructure, and respond to vulnerabilities. The customer may remain responsible for deciding who receives access, enabling available security features, protecting user accounts, configuring integrations, retaining appropriate backups, and reporting suspicious activity.

Problems occur when each side assumes the other is handling a control.

A cloud application may offer multifactor authentication, but the customer never enables it. A managed service provider may maintain backups, but nobody agrees on how quickly the systems must be restored. A vendor may log administrative activity, but the customer cannot obtain those records during an investigation. An employee leaves, but neither company removes the account because ownership was never defined.

“The vendor handles security” is not a responsibility model.

For each critical provider, the business should be able to explain:

What the provider protects
What the business must configure or monitor
Who responds when something goes wrong
How the two organizations will communicate
What evidence each party must preserve
How operations and data will be recovered

The answers do not need to fill a large policy manual. They do need to be understood before an incident.

Start by Identifying the Vendors That Matter Most

Not every vendor deserves the same review.

Requiring a detailed security assessment from the company that delivers office plants would waste time. Applying the same light review to a provider with administrator access to every computer would ignore meaningful risk.

A small business can begin with three practical tiers.

Critical providers

These vendors can access sensitive data, administer important systems, move money, or stop essential operations. Examples may include an IT provider, payroll company, payment platform, cloud email service, electronic health-record provider, or core industry application.

Critical providers deserve the strongest review, clear contractual expectations, identified incident contacts, and a tested continuity or exit plan.

Important providers

An outage or breach would cause a backlog, customer inconvenience, or limited exposure, but the business could continue temporarily. These providers need documented ownership, appropriate access controls, and a workable recovery process.

Limited-impact providers

These vendors have little or no sensitive access, and their failure would not materially interrupt the business. Basic purchasing and account-management practices may be sufficient.

This risk-based approach keeps the effort proportional. Vendor oversight should reduce uncertainty, not create a procurement department the business does not need.

Ask for Evidence, Not Perfection

A small business usually cannot perform an enterprise-level audit of every provider. It can still ask focused questions and request reasonable evidence.

For a critical technology provider, ask:

Does the provider require multifactor authentication for administrative and remote access?
Does each technician use an individual account, or are credentials shared?
How is customer access separated and limited?
Which sensitive information is stored, and is it encrypted appropriately?
Which subcontractors or subprocessors can access the service or data?
How are security updates and known vulnerabilities handled?
How are backups protected, and how often is recovery tested?
What independent assessments, certifications, or security reports are available?
How quickly will the provider notify the business of a suspected incident?
Will the provider supply relevant logs and cooperate with an investigation?

A certification or assessment report can be useful evidence, but it is not a guarantee. It may cover only certain systems, controls, or dates. The business should focus on the risks that matter to the relationship rather than treating a report or logo as a complete answer.

A good vendor may not disclose every technical detail, and it should not expose information that would weaken its security. It should, however, be able to explain its security responsibilities, demonstrate that important controls exist, and discuss how it handles incidents affecting customers.

Put the Important Expectations in Writing

Verbal assurances tend to disappear when personnel change or an incident becomes expensive.

Contracts for critical providers should address the issues that would matter during a failure. Depending on the service, those provisions may include:

Required safeguards for sensitive information and privileged access
Multifactor authentication and individual accountability for remote administration
Timeframes and contact methods for incident notification
Cooperation, record preservation, and access to relevant logs
Use and disclosure of subcontractors or subprocessors
Backup, availability, and recovery expectations
Data ownership, export, return, and secure deletion
Requirements for removing access when personnel or contracts change
Responsibilities at termination or transition to another provider

The objective is not to shift every possible loss to the vendor through legal language. It is to remove ambiguity about what each party must do.

Contract terms should be reviewed by qualified legal counsel when the relationship involves regulated information, significant financial exposure, or complex liability. Cybersecurity expectations are operational requirements as well as legal provisions; the people who understand the workflow should help define them.

Review Remote Access Before Buying Another Security Product

Vendor access is often created for a legitimate reason and then left in place indefinitely.

A former technician’s account remains active. A remote-support tool launches automatically on every device. A shared administrator password is known by several people. The provider can reach far more of the network than the service requires. Nobody inside the business knows how to disable the connection.

Before purchasing another product, review the access that already exists:

List the vendors that can connect remotely or administer business systems.
Identify the accounts, tools, integrations, and permissions each vendor uses.
Confirm that access requires multifactor authentication and individual accounts.
Remove obsolete accounts and unnecessary privileges.
Restrict access to the systems and times required for the work where practical.
Retain logs sufficient to understand what administrative actions occurred.
Document how the business can suspend vendor access during an incident.

The person who manages the connection should not be the only person who knows how to disconnect it.

Plan for the Vendor to Be Unavailable

Cybersecurity planning often concentrates on preventing unauthorized access. Vendor incidents also create availability problems.

Choose each critical provider and ask:

Which business activities stop if the service is unavailable for four hours, one day, or one week?
What information would employees need to continue using a manual or alternate process?
Can the business export essential records in a usable format?
Are emergency contacts stored somewhere other than the unavailable platform?
Who can authorize the fallback process?
How will transactions completed manually be reconciled when service returns?
Which customers, employees, regulators, or partners may need notification?

Do not build a manual process for every feature. Preserve the minimum activities needed to protect people, serve customers, meet essential obligations, and maintain cash flow.

A fallback procedure that has never been practiced is an assumption. Test one realistic vendor outage and observe where the business loses information, authority, or access.

Prepare for the End of the Relationship

Vendor risk does not end when a contract expires.

The business may still need to recover its data, disable accounts, remove remote software, rotate credentials, transfer domain or cloud ownership, update integrations, and confirm that retained copies are deleted according to the agreement.

Before adopting a critical service, determine:

How data can be exported and in what format
Whether the export includes attachments, history, settings, and audit records
How long the vendor will make data available after termination
Which accounts, tokens, keys, and integrations must be revoked
Who owns domains, administrative accounts, encryption keys, and recovery methods
What assistance is available during transition

If the only practical way to leave a vendor is to lose essential information or interrupt the business indefinitely, the relationship contains a form of operational lock-in that leadership should understand.

A Ten-Question Third-Party Risk Review

Choose one critical vendor and ask:

What essential business outcome does this provider support?
What systems, accounts, and data can the provider access?
What would stop if the provider were unavailable tomorrow?
Which security responsibilities belong to the provider, and which remain with us?
Are privileged and remote connections protected by multifactor authentication and individual accounts?
Which subcontractors or subprocessors also support the service?
How and when will we be notified of a suspected incident?
Can we obtain the logs and information needed to investigate and meet our obligations?
Can we continue essential work and recover our data during an extended outage?
How will access, integrations, and retained data be removed when the relationship ends?

If nobody inside the business can answer these questions, the first step is not replacing the vendor. It is clarifying the relationship.

Use Vendors Deliberately

Outsourcing can be one of the smartest security decisions a small business makes. A qualified provider may offer better tools, deeper expertise, faster support, and more resilient infrastructure than the business could build alone.

The mistake is treating the relationship as a transfer of responsibility.

Know which vendors are critical. Understand their access. Follow the sensitive data. Define responsibilities. Prepare for an outage. Plan how the relationship will end.

You can outsource the technology. You can outsource many of the tasks. You can even contractually allocate parts of the liability.

But your employees, customers, revenue, and reputation will still experience the consequences.

That risk remains yours to manage.