Insights and Resources

The Vendor Security Checklist Every Small Business Needs

Published 2026-09-14 by Joshua Smith · 10 min read

The Vendor Security Checklist Every Small Business Needs

Most businesses create technology risk one convenient purchase at a time.

A department needs a scheduling tool. A payroll vendor requests access. A marketing platform connects to customer records. An AI application asks employees to upload documents.

Each decision may be reasonable. Together, they create a network of outside companies that can store your information, connect to your systems, interrupt operations, or expose customers when something goes wrong.

The practical answer: Classify each vendor by the data, access, and operational dependency involved. Ask the 12 questions below before approving moderate- or high-risk providers, document the answers, and put critical commitments in the contract. The goal is not to eliminate vendor risk. It is to understand who can affect your business and decide which risks you will accept.

Why Vendor Security Deserves Leadership Attention

The 2026 Verizon Data Breach Investigations Report found that third-party involvement increased substantially and accounted for 48% of breaches in its dataset. That category includes suppliers, partners, service providers, software dependencies, and other outside relationships. [1]

Businesses cannot stop using cloud software, payment processors, payroll platforms, internet providers, IT partners, and specialized services. The lesson is that your security and continuity now depend partly on companies you do not control.

Customers are unlikely to care that a vendor caused the problem. They trusted your business with their information and their work. Your company still has to explain the interruption, respond to the incident, and restore confidence.

Start by Classifying the Vendor's Risk

Do not send the same 100-question security form to every supplier. The office coffee company and the platform holding employee Social Security numbers do not deserve the same review.

Start with four questions:

  1. What information will the vendor store, process, or access?
  2. Can the vendor connect to our systems or act on our behalf?
  3. Would an outage stop an important business process?
  4. Are legal, contractual, insurance, or regulatory obligations involved?

Use the answers to place the vendor into a simple tier.

Low risk

The vendor has no system access, receives no sensitive information, and would cause little disruption if unavailable. Basic purchasing review may be enough.

Moderate risk

The vendor handles internal business information or supports an important process, but exposure and operational impact are limited. Complete the core checklist and document the decision.

High risk

The vendor handles sensitive information, connects to critical systems, or supports an operation the company cannot easily perform another way. Require deeper review, stronger contract language, evidence, and a recovery plan.

A small vendor is not automatically low risk. A tiny software company with administrative access to your Microsoft 365 environment may present more risk than a large supplier delivering physical equipment.

The 12 Questions to Ask Before You Buy

1. What data will you collect, access, create, or store?

Ask for a specific answer. "Customer data" is not enough. Determine whether the vendor will handle contact details, payment or health information, employee records, contracts, credentials, recordings, intellectual property, or confidential plans.

Then ask why each type of data is necessary. Do not provide information merely because an integration can collect it.

2. Where is the data stored, and who can access it?

Identify where data is stored and processed. Ask whether vendor employees, contractors, support personnel, or subprocessors can access it and how that access is approved and logged.

Location may affect contractual, regulatory, customer, or insurance requirements. If those obligations are unclear, involve qualified legal or compliance counsel.

3. How do you protect accounts and administrative access?

Require multifactor authentication for administrative and remote access. Ask whether single sign-on is supported, how privileged accounts are controlled, and whether customers can restrict access by role.

Shared administrator passwords and permanent support access are warning signs.

4. How is our information encrypted?

Ask whether information is encrypted in transit and at rest. For especially sensitive data, ask who controls the encryption keys and how backups are protected.

Do not accept "bank-level encryption" as a complete answer. Request the actual security documentation.

5. How do you find and fix security vulnerabilities?

Ask how the vendor tests its applications and infrastructure, how quickly it addresses actively exploited or critical vulnerabilities, and how customers learn about important security updates.

For software installed in your environment, clarify who deploys updates and whether delaying an update changes support or security coverage.

6. What independent evidence can you provide?

Useful evidence may include a recent SOC 2 report, ISO 27001 certification, penetration-test summary, security questionnaire, cyber insurance certificate, or another independent assessment.

Evidence is not a guarantee. A report can be outdated, narrow in scope, or full of customer responsibilities. Review what period, systems, locations, and services it actually covers.

7. Which other companies do you depend on?

Your vendor may rely on hosting providers, payment processors, support contractors, AI model providers, and other subprocessors. Ask about important dependencies and how you will be notified when they change.

This is the supply-chain problem: your vendor's vendors can become your problem too.

8. How will you notify us about a security incident?

The contract should define what must be reported, who receives the notice, what information the vendor will provide, and the notification timeline.

"Without unreasonable delay" may be too vague for a critical provider. Your business may have customer, insurance, contractual, or regulatory deadlines that start before the vendor finishes its investigation.

9. What happens if your service becomes unavailable?

Ask about backups, recovery capabilities, service locations, major dependencies, and tested continuity plans. Understand the service-level commitment, but do not confuse a service credit with a recovery plan.

A refund for downtime does not help you run payroll, communicate with customers, or access a critical project.

10. Can we retrieve and delete our data?

Before signing, determine how your company can export its information in a usable format. Ask what happens to production data, backups, logs, and other copies after termination.

Document the retention period and deletion process. Avoid discovering during a dispute or emergency that your data cannot be exported without a professional-services project.

11. What security responsibilities remain with us?

Many platforms rely on the customer to configure access, manage users, apply retention settings, review alerts, or protect integrations.

Request a shared-responsibility document. Record which controls are included by default, which require additional licensing, and which your business or IT provider must operate.

12. What happens if the vendor is acquired, closes, or materially changes the service?

Ownership, pricing, product direction, support, data practices, and financial stability can change.

For a critical service, identify how you would continue operations, retrieve data, revoke connections, and move to an alternative.

A One-Page Vendor Decision Record

For every moderate- or high-risk technology vendor, keep a short decision record containing:

This record does not need special software. A protected spreadsheet, SharePoint list, or governance system can work if it has a clear owner. It should let someone understand why the tool was approved, what it touches, and what must happen if the company stops using it.

Red Flags That Deserve a Pause

A red flag does not always require rejection. It requires an answer, a control, a contract change, an accepted risk, or another vendor.

Put the Important Answers in the Contract

The Federal Trade Commission recommends putting security expectations in writing, verifying compliance, controlling vendor access, and specifying how vendors may use, retain, and delete information. [3]

For important vendors, the agreement should address the controls that matter to your business, incident notification, cooperation during an investigation, data use, confidentiality, subcontractors, audit or evidence rights, availability, data return, secure deletion, and termination assistance.

This article is not legal advice. Your attorney should review contract terms involving regulated data, significant operational dependency, liability, indemnification, notification duties, or customer commitments.

Vendor Review Is Not a One-Time Event

A vendor can be acceptable when selected and become risky later. It may change owners, add subprocessors, launch AI features, suffer an incident, or change its use of customer data. Your use may also expand.

Review high-risk vendors at least annually and before renewal. Also review them after a major incident, ownership change, important product change, new integration, or expansion into more sensitive information.

Remove unneeded access and unused accounts. Revoke old integrations and API keys. Confirm that departed vendors delete or return data as promised.

Frequently Asked Questions

Do small businesses really need to assess every software vendor?

Every vendor deserves classification, but not every vendor needs a deep assessment. Focus effort on providers that access sensitive data, connect to systems, support critical operations, or create contractual and regulatory exposure.

Is a SOC 2 report enough to approve a vendor?

No. It can provide valuable independent evidence, but you must review the scope, period, exceptions, and customer responsibilities. It also may not address every risk that matters to your business.

Who should own vendor security reviews?

The application owner, IT or security, procurement, and legal or compliance roles may contribute. One person should coordinate the decision and maintain the record.

What if a vendor will not answer our questions?

Consider the relationship's sensitivity and evidence available publicly or under a confidentiality agreement. For a high-risk service, refusal to provide meaningful answers should weigh heavily against approval.

Should we review vendors we already use?

Yes. Start with providers that hold sensitive information, have administrative access, or support operations your company cannot easily perform without. Document the current risk and resolve the most important gaps first.

A Practical Next Step

List every outside company that stores sensitive data, connects to Microsoft 365 or another critical system, or could stop an important operation. Most businesses have more technology dependencies than leadership realizes.

Classify the five most important vendors and use the 12 questions in this article at the next renewal or review.

If you need help identifying hidden connections, reviewing a technology vendor, or building a manageable vendor process, Schilling IT's cybersecurity team can help. You can also start with our free security assessment to identify broader gaps in access, protection, and recovery.

References

  1. Verizon 2026 Data Breach Investigations Report
  2. NIST SP 1326: Cybersecurity Supply Chain Risk Management Due Diligence Guide
  3. FTC Cybersecurity for Small Business: Vendor Security
  4. CISA StopRansomware Guide

Read this article on Schilling IT