Vendor and third-party risk for SMBs: how to vet your software supply chain

If your SMB wants a practical vendor-risk process, start with one rule: review vendors based on what they can break, reach, or expose. A bookkeeping app with no sensitive data is not the same risk as your MSP, payroll platform, EHR add-on, or cloud identity provider. Criticality should drive the depth of review.

Sources: NIST CSF 2.0 C-SCRM quick-start guide, CISA SMB supply-chain fact sheet, CISA vendor SCRM template for SMBs, FTC Safeguards Rule summary, HHS sample business associate agreement provisions

The plain-English answer

Most small businesses do not need a giant third-party risk program. They do need a repeatable way to sort vendors by importance, ask better questions before buying, put the right obligations into contracts, and revisit high-impact vendors after go-live.

That is enough to avoid most of the damage we see.

Why this matters more than SMB owners think

NIST's CSF 2.0 supply-chain quick-start guide defines cybersecurity supply chain risk management as a systematic process for managing exposure to cybersecurity risk throughout supply chains. It also makes the point that the supply chain ecosystem includes business partners and digital service providers, not just hardware suppliers.

That is the useful framing for SMBs.

Your software supply chain is not just the code library issue that makes headlines. It is also:

• The MSP with remote admin access
• The payroll vendor with employee data
• The cloud backup provider
• The ecommerce plugin handling customer payment flows
• The outsourced bookkeeper with mailbox access
• The EHR, PMS, or billing vendor in regulated environments

If one of those relationships is weak, your business may still be the one explaining the incident to customers, regulators, or insurers.

The first question is not "Do they have SOC 2?"

The first question is: what can this vendor access, store, process, or influence?

NIST's quick-start guide says suppliers should be known and prioritized by criticality. That is the right first move for a small business because it prevents the classic mistake of treating every vendor as equal.

We use three buckets.

Tier 1: high-impact vendors

These vendors can materially harm you if they fail or are compromised.

Examples:

• MSPs and MSSPs
• Identity providers
• Cloud infrastructure providers
• Payroll and HR platforms
• Accounting and tax systems
• EHR or practice management vendors
• Payment processors and ecommerce platforms

If they touch privileged access, regulated data, customer financial information, or core operations, they belong here.

Tier 2: meaningful but contained vendors

These vendors matter, but the blast radius is narrower.

Examples:

• Project-management platforms
• CRM tools with limited sensitive data
• Marketing tools with customer contact data
• Specialized SaaS apps used by one function

Tier 3: low-impact vendors

These vendors are replaceable, have little or no sensitive data, and cannot reach core systems.

Examples:

• Basic design tools
• Scheduling tools with little sensitive information
• Generic productivity apps with narrow access

This one step makes the rest of the process manageable.

What to ask before you buy

CISA's SMB vendor-risk resources are useful because they are built for organizations without a dedicated third-party risk team.

For a Tier 1 vendor, we would ask six practical questions before signature:

1. What data do you store or process for us?

Get concrete. PII, financial data, PHI, credentials, logs, backups, customer communications, admin metadata.

2. What level of access do you need?

Read-only access, mailbox access, endpoint agent privileges, domain admin, API tokens, SSO integration, backup access. This matters more than brochure language.

3. How do you secure customer environments?

You are looking for substance: MFA, role-based access, logging, backup protections, patching, encryption, incident handling, and how they control support access.

4. Who are their subprocessors or critical dependencies?

Your vendor's vendor becomes your problem faster than most teams expect.

5. How will they notify you about incidents?

Do not settle for "we take security seriously." Ask who notifies you, how fast, and what information you will get.

6. How do you offboard?

What happens to data, credentials, agents, backups, and shared integrations when the contract ends?

What documents are worth requesting

You do not need a 200-question spreadsheet for every SaaS purchase.

For higher-impact vendors, ask for what will actually help you decide:

• A recent SOC 2 report or similar independent assessment, if they have one
• Security overview or trust-center documentation
• Incident-response or security-contact process
• Subprocessor list
• Data-retention and deletion terms
• Details on encryption, MFA, and admin-access controls where relevant

If the vendor handles regulated data, the contract side matters even more.

HHS's sample business associate agreement provisions are a good reminder that in healthcare, security promises cannot stay verbal. A business associate agreement has to set permitted uses and disclosures, require safeguards, require breach reporting, and flow the obligations to subcontractors where applicable.

Likewise, under the FTC's Safeguards Rule, covered financial institutions are responsible for taking steps to ensure service providers safeguard customer information in their care.

Different regulation, same lesson: if the vendor matters, paper matters.

What to put in the contract

You do not need to turn every SaaS agreement into a legal war. You do need to cover the basics.

For high-impact vendors, push for contract language around:

• Breach or security-incident notice timing
• Security responsibilities and minimum control expectations
• Use of subprocessors
• Return or destruction of data at termination
• Audit, report, or evidence rights where appropriate
• Access revocation and offboarding steps

If the vendor will have admin access into your environment, we would also want the relationship to line up with the same operational expectations discussed in what controls do cyber insurers require in 2026: MFA, monitored access, backup protection, and documented response procedures.

The vendor review should scale with the risk

This is where SMBs either do too little or too much.

Too little

They buy a critical platform based on features and price alone, then discover after deployment that support access is loosely controlled, the incident-notice language is weak, and nobody knows where the data sits.

Too much

They send the same heavy questionnaire to every low-risk app and create process fatigue that eventually gets bypassed.

NIST and CISA's direction supports a better middle path: prioritize by criticality and apply deeper review where the business impact is real.

A simple review model that actually works

For most SMBs, we recommend this:

For Tier 1 vendors

• Collect basic security documentation
• Review contract terms
• Confirm access model
• Identify subprocessors
• Record owner and renewal date
• Re-review annually or after major changes

For Tier 2 vendors

• Document data type and access level
• Review available security materials
• Confirm offboarding process
• Revisit at renewal

For Tier 3 vendors

• Record the tool, owner, and business purpose
• Avoid collecting more sensitive data than needed
• Keep the approval lightweight

That is a vendor-risk program. It is just scaled to reality.

The software supply chain angle SMBs miss

Sometimes the vendor itself is fine, but the integration path is not.

Examples:

• A website plugin that can change checkout behavior
• An OAuth grant that gives broad mailbox or file access
• A remote-support tool with persistent privileged access
• An agent installed widely without clear ownership

CISA's supply-chain material is useful here because it focuses on practical mitigation steps, not abstract governance. For SMBs, that usually means understanding dependencies, reducing single points of failure, and making sure leadership actually treats supplier disruption and supplier visibility as business risk.

When to say no

Say no, or at least slow down, when:

• The vendor cannot explain who has access to your data
• The vendor refuses to discuss incident-notification expectations
• The vendor has no clean offboarding story
• The vendor wants broad privileged access with weak controls
• The contract gives you no practical recourse on data handling
• The tool is low value but high exposure

Small businesses often act as if vendor refusal is normal. Sometimes it is. It is still signal.

The regulated-industry wrinkle

If you are in healthcare, legal, finance, or another regulated environment, vendor review is not just prudent. It is often tied directly to your compliance position.

• Healthcare: you may need a business associate agreement and evidence the vendor can safeguard ePHI.
• GLBA-covered businesses: the FTC Safeguards Rule makes service-provider oversight part of your job.
• Insurance applications: underwriters increasingly ask how you handle privileged access, backups, and outsourced security operations.

That is why this topic pairs naturally with cyber insurance questionnaire 2026: 22 controls and with operational buying decisions like whether the business needs an MSSP, an MSP, or a narrower managed security layer.

Where Obsidian Ridge fits

We do not sell a bureaucratic vendor-risk portal.

Where we fit is helping SMBs identify:

• Which third parties are actually dangerous
• What evidence matters
• How to keep high-impact vendors from becoming blind spots in identity, endpoint, email, and backup security

In practice that usually connects to managed ITDR, managed detection and response, and sharper pre-renewal evidence work through cyber insurance readiness.

FAQ

Do small businesses really need a vendor risk process?

Yes, but it can be small. Criticality-based review is enough for many SMBs if they apply it consistently.

What is the first thing I should ask about a new vendor?

Ask what the vendor can access, store, process, or influence in your environment. That answer determines review depth.

Should every vendor get the same questionnaire?

No. High-impact vendors need deeper review than low-risk tools with no sensitive data or privileged access.

What matters more: a SOC 2 report or the contract?

Both matter, but neither is sufficient alone. A report gives evidence about control posture. The contract defines obligations, notification expectations, and what happens when something goes wrong.

What if the vendor is strategically important but security answers are weak?

Treat that as real risk. Escalate the decision, tighten contract terms if possible, reduce access where you can, and be honest internally that the convenience is coming with exposure.