Third-party and supplier risk management

Here’s a slightly awkward truth: most SME breaches don’t start with the SME.

They start with a supplier. A SaaS tool. An MSP. A third-party integration somebody connected to Microsoft 365 eighteen months ago, ticked “approve all permissions,” and then promptly forgot about. Attackers know this. They’ve known it for a while. It’s why they’ve stopped banging on the front door and started walking in through a partner’s side entrance instead.

Which makes “third-party risk management” sound like a boring procurement exercise. It isn’t. It’s one of the highest-leverage things an SME can do to not end up in the local paper.

Why third-party risk management matters more than ever

How supply-chain breaches happen through trusted suppliers and platforms

The pattern is almost always the same.

Attacker compromises a supplier.
Supplier has legitimate access into your systems, VPN, API, shared admin account, federated identity, whatever it is.
Attacker uses that legitimate access to walk straight into you, bypassing every shiny control you bought last year.
Your logs show “authorised activity.” Your alarms don’t go off. By the time anyone notices, it’s been a fortnight.

The breach wasn’t your fault. It’s still very much your problem.

Why SMEs are exposed even without a large procurement function

Big enterprises have procurement teams, vendor risk frameworks, and someone whose entire job is reading SOC 2 reports. SMEs have… a finance director who approves the invoice and an IT lead who gets told after the fact. That’s the reality and it means supplier risk quietly piles up in the gap between “we need this tool” and “has anyone actually checked this tool is safe?”

The growing risk from SaaS tools, outsourced IT, and connected vendors

The average SME now runs on dozens of SaaS apps, an outsourced IT provider or two, a handful of freelancers, and a payroll of integrations that knit them all together. Each one is a potential entry point. Each one was probably onboarded at a different moment, by a different person, with different (or zero) checks. Pull that thread and things get interesting quickly.

Why third-party cyber risk is now a business continuity issue, not just an IT issue

If your core SaaS platform goes down because their supplier had a ransomware attack, your business stops. That’s not an IT problem anymore. That’s a “can we still invoice, ship, serve customers” problem. Once you’ve framed it that way, third-party risk is obviously a board-level conversation not a ticket in someone’s queue.

What counts as third-party and supplier cyber risk?

Third parties, vendors, suppliers, MSPs, and SaaS providers explained

The labels get messy, so here’s the simple version: anyone outside your organisation who has access to your data, your systems, or your people counts. That’s your SaaS vendors, your MSP, your accountancy firm, your outsourced marketing agency with admin rights on your website, your hosting provider, your payroll platform – everyone. The job title doesn’t matter. The access does.

Where risk sits: access, data handling, integrations, hosting, and support

Supplier risk lives in five places, mostly:

• Access: do they log in to your systems, and how?
• Data handling: do they hold, process, or transmit your data?
• Integration: are they wired directly into your platforms via API?
• Hosting: are they running infrastructure you depend on?
• Support: do their engineers occasionally have hands on your environment?

A supplier might hit one of these or all five. Scope matters. So does blast radius if they’re compromised.

Common exposure points: shared credentials, excessive permissions, weak controls

The hall-of-fame offenders we see, repeatedly: shared admin accounts (“it was easier”), over-privileged API tokens (“we’ll tighten it later”), suppliers using personal email addresses to log into your tenants, and long-forgotten integrations with permissions that would make an auditor weep. None of this is exotic. All of it is common. Most of it is fixable in an afternoon once you know it’s there.

Why not all suppliers need the same level of scrutiny

The coffee supplier doesn’t need a SOC 2 report. Your cloud hosting provider does. Tiering your suppliers by what they actually touch is the difference between a risk programme that works and a questionnaire mill that nobody reads.

How to run a practical vendor risk assessment before onboarding

Start by classifying suppliers by criticality and data access

Three tiers is usually plenty.

Critical: holds sensitive data, has privileged access, or is essential to operations.
Important: has some data access or moderate integration, but not existential.
Low-risk: minimal or no access to your systems or data. Most SMEs have a handful in tier one, a couple of dozen in tier two, and a long tail in tier three. Spend your time accordingly.

What a good supplier security assessment should cover

A proper assessment asks about identity and access (MFA, SSO, joiners/leavers), data protection (encryption, backups, residency), technical controls (patching, endpoint protection, testing regime), governance (certifications, policies, named security owners), and incident response (how they’d tell you if something went wrong, and how fast). You don’t need fifty pages. You need five or six questions that actually matter, asked properly.

Due diligence cyber security checks for SMEs: what to ask and what to verify

Ask for evidence, not adjectives. “We take security seriously” is not an answer. A current Cyber Essentials certificate, an ISO 27001 statement of applicability, a recent pen test summary, or a SOC 2 Type II report, those are real answers. If a critical supplier can’t produce anything, that’s data too.

How to avoid treating security questionnaires as a box-ticking exercise

The trap is that questionnaires feel like work getting done. Sheets get filled in, filed, and everyone moves on. The value isn’t in the filing. It’s in reading the answers, flagging the weak ones, and going back with follow-ups. A half-completed questionnaire with three good follow-up conversations beats a beautifully filled 80-question template that nobody ever opens again.

Security questionnaires for vendors: what to ask and what evidence to request

Core topics: MFA, patching, backups, access control, encryption, incident response

If you only had six topics to cover, these are the six. Is MFA enforced, everywhere, for everyone? What’s the patching cadence? Are backups immutable and tested? How is access granted, reviewed, and revoked? Is data encrypted in transit and at rest? What’s the incident response process and crucially, what’s your notification SLA if it affects us? That last one is the question most questionnaires forget to ask, and it’s one of the most important.

When to request policies, certifications, audit reports, or penetration test summaries

For critical suppliers, always. For important suppliers, usually. For low-risk suppliers, rarely, and only if something changes. Ask for documents that are dated within the last twelve months. “We had one in 2019” is a finding, not a reassurance.

How ISO 27001 supplier checks can strengthen due diligence

ISO 27001 isn’t a silver bullet, but it’s a useful shortcut. A supplier with a current, properly-scoped ISO 27001 certificate has at minimum had an external body kick the tyres on their information security management. That doesn’t make them invulnerable. It does mean you’re not starting from zero.

How to spot vague or reassuring-sounding answers that do not prove much

Watch for: “industry-standard,” “best-in-class,” “robust,” “enterprise-grade.” These words are the corporate equivalent of “trust me.” If a supplier can’t tell you what the standard is, who set it, or how they measure against it, they probably don’t.

SaaS supplier risk: where SMEs often underestimate exposure

Why SaaS apps can create hidden third-party risk

SaaS tools feel low-risk because you don’t host them, don’t run them, and often didn’t even buy them centrally. That’s precisely the problem. Someone on the marketing team signed up, connected it to your email and calendar, and now it has read-write access to data they didn’t realise they were granting.

Reviewing integrations, API access, SSO, and privileged permissions

Once a quarter, have someone open up the “connected apps” panel in your Microsoft 365 or Google Workspace tenant and just look. Most SMEs who do this for the first time find three things they’ve never heard of and two things that should’ve been revoked when someone left the company.

Data residency, retention, subprocessors, and offboarding considerations

Where does the data live? How long is it kept? Who else processes it on the supplier’s behalf (their subprocessors are now your extended supply chain, welcome to the fun)? And what happens to your data when you leave? These questions get asked at onboarding and then never again which is precisely the wrong way round.

Reducing risk from shadow IT and quickly adopted tools

You don’t stop shadow IT with a strongly-worded email. You stop it with a sensible approval path that’s faster than just signing up with a credit card. Make the safe thing the easy thing, or accept that people will route around you.

Third-party security monitoring after onboarding

Why supplier risk management should not stop after contract signature

A vendor that was secure on the day you signed might not be secure in eighteen months. They’ve hired, fired, been acquired, changed platforms, had an incident, or quietly let their certification lapse. The risk profile moves. Your monitoring should too.

What ongoing monitoring can include: reviews, attestations, alerts, and reassessments

Annual reattestations for critical suppliers. Breach notification clauses that actually work. External breach-monitoring services for your top-tier vendors. And, this is the easy one, just checking in. A 20-minute conversation with your MSP’s security lead every quarter tells you more than any questionnaire.

When to revisit risk: renewals, incidents, product changes, acquisitions, new data access

The obvious triggers: contract renewal, a publicly disclosed incident, a major product change, an acquisition, or a request for broader access. Any of these should automatically restart the risk conversation. “We assessed them in 2022” is not a permanent answer.

Building third-party security monitoring into normal governance

It shouldn’t be a separate project. It should be a standing agenda item in whatever governance rhythm you already have – monthly IT review, quarterly board update, annual risk review. Put it in the calendar. Keep it there.

A practical supplier risk management process for SMEs

Step 1: build a supplier inventory and identify critical vendors

You can’t manage what you haven’t listed. A simple spreadsheet beats a non-existent system. Names, what they do, what they access, who owns the relationship internally.

Step 2: define minimum security requirements by supplier tier

Decide, in advance, what a critical supplier must have (MFA, current certification, defined incident response, contractual notification SLAs) versus what an important one needs versus what’s fine for low-risk. Stops every conversation being bespoke.

Step 3: assess high-risk suppliers before onboarding or renewal

Don’t let anyone sign a critical supplier contract without the security check being done. Build it into the procurement workflow. If that feels heavy, remember it’s lighter than a breach.

Step 4: monitor, document, and improve the process over time

Write things down. What was assessed, what was found, what was agreed. Future-you, or your successor, will be enormously grateful. Then, every year or so, look at the process itself and ask what’s working and what’s theatre.

What to do if a supplier has a breach

Incident response questions to ask immediately

First call, ask: What exactly was accessed? When? Is the attacker still active? Does this affect our data, our users, or our systems specifically? What have you done in the last 24 hours? What are you doing in the next 24? You want crisp answers. Wooliness here is a tell.

Containing exposure across accounts, integrations, and shared data

Rotate every credential the supplier might hold. Revoke API tokens. Disable SSO trust if relevant. Review logs for anything unusual from their access paths. Assume you’re compromised until you’ve proved you’re not, it’s always the faster way to the truth.

Internal communications, legal considerations, and customer impact

Talk to legal early. Talk to your own customers if their data is implicated and always, where possible, before they read about it. Keep communications calm, factual, and updated. “We don’t know yet, here’s what we’re doing, next update at 4pm” is a legitimate message.

Lessons learned: how to strengthen future vendor management security

Every incident teaches you something. Write the lessons down within a week, while they still sting. Bake them into your onboarding process, your questionnaires, your contracts. Otherwise you’ll learn the same lesson again, possibly from the same supplier.

Most SMEs don’t get breached because they missed something exotic. They get breached because a supplier had weak MFA, or an integration had too much access, or nobody had checked in with a vendor since 2022. The fixes aren’t glamorous. They’re just consistent.