Your Vendors Are Your Attack Surface: Third-Party Risk for Small Teams

Count the companies that could read your customer data right now. Your email provider, your cloud host, your CRM, your support desk, your payment processor, the analytics tool, the marketing platform, the accountant's portal, the outsourced developer with a login to production. For a fifteen-person startup, that list is often longer than the staff list.

Every one of those is a third party, and every third party is a way in. Some of the largest breaches of the last decade started with a supplier: a compromised software update, a contractor's stolen credentials, a support tool with too much access. You cannot vet suppliers the way a bank does. You can do a lightweight version that covers the risk that matters, in a few hours a year.

Step 1: make the list

Open a spreadsheet. One row per vendor. Four columns:

1. What they do for you.
2. What data they hold or can reach — none / business data / customer personal data / credentials or payment data.
3. What access they have — none / their own platform only / a login to your systems.
4. Who owns the relationship internally.

Getting the list is most of the value. Finance can pull it from card statements and invoices in an hour; the tools nobody is paying for but everybody uses are the ones to hunt down through single sign-on logs and a team survey.

Step 2: sort into three piles

Critical — they hold customer personal data, payment data or credentials, or they have access into your systems. Cloud host, email, payment processor, the agency with a production login.

Important — they hold business data you would not want public, but no customer records. Project tools, design tools, internal docs.

Low — everything else. The link shortener, the fonts.

Spend your attention on the critical pile. For most small companies it is five to ten vendors.

Step 3: ask critical vendors four questions

You do not need a forty-page questionnaire. You need to know:

1. Do you have an independent security certification or audit? SOC 2 Type II or ISO 27001 are the common ones. A "yes" with a report is a strong signal; a "no" from a company holding your customer data is a decision point.
2. How do you tell us if you have a breach, and how fast? Look for a written commitment — 72 hours is a common benchmark because of GDPR — and a contact route.
3. Where is our data stored and who at your company can see it? Region matters for privacy law; internal access matters for insider risk.
4. Can we turn on single sign-on and two-factor for our users, and get an audit log? If the answer is "only on the enterprise plan", weigh the cost against what they hold.

Most reputable vendors have a trust or security page that answers these; ten minutes of reading per vendor. Record the answers in the spreadsheet with a date.

Step 4: control what you can control

The vendor's security is partly their job. Your side is entirely yours:

• Least access. Give vendors and integrations the minimum permissions. A support tool that only needs to read tickets should not have write access to customer records. An OAuth app that asks for "full access to your Google Drive" to sync one folder is a bad trade.
• Named accounts, no sharing. Agencies and contractors get their own logins, with two-factor, that you can switch off. Never a shared "agency@" account.
• Offboard vendors like people. When a contract ends, remove the access the same day. Add it to the finance workflow: cancelling the subscription triggers revoking the access.
• Review OAuth grants and API keys quarterly. Every "Sign in with Google/Microsoft" app and every API key issued to a vendor is standing access. Most companies have dozens they have forgotten.
• Get a copy of your data. If a critical vendor disappeared tomorrow, could you export? Test it once.

Step 5: the software supply chain

If you build software, your dependencies are vendors too — thousands of them. Three habits cover most of the risk:

• Pin versions and update on a schedule, using automated tooling that opens pull requests for known-vulnerable packages.
• Use the platform's official registries and lockfiles, and be suspicious of a brand-new package with a name one letter away from a popular one.
• Sign and verify where your ecosystem supports it, and keep build machines as locked down as production. The most damaging supply-chain incidents of recent years compromised the build, not the code.

Step 6: contracts, briefly

For the critical pile, make sure the contract or terms include: a breach notification commitment, a data processing agreement if personal data is involved (required under GDPR and expected under Qatar's data protection law), and clarity on data deletion when the contract ends. You do not need a lawyer for a SaaS click-through; you need to know these clauses exist.

What this looks like as a routine

• Once: build the list, sort the piles, ask the four questions, fix access.
• Quarterly: review OAuth grants, API keys and contractor accounts; remove what is unused.
• Annually: re-ask the four questions of critical vendors; refresh the list against finance.
• On every new tool: the person buying it fills in the four columns before the card is charged.

That is a few hours a year. It will not make a supplier breach impossible — nothing does — but it means that when a vendor emails you at 2 a.m. to say they have been compromised, you already know what they had, what it reaches, and which switch to flip first.