Safeguarding Your Business from Third-Party Cybersecurity Threats

Almost every serious breach I have investigated in the last decade had a third party somewhere in the blast radius. Sometimes the attacker walked in through a managed service provider's remote access tool. Sometimes it was a compromised software update. Sometimes it was a marketing contractor with a login to a system nobody remembered granting. The pattern is consistent: the organization spent heavily on its own defenses and almost nothing on understanding who else could reach its data.

I am Alexander Sverdlov. I have run more than 200 security assessments across 14 countries since 2013, and third-party risk is the area where I see the widest gap between what companies think they control and what they actually control. You can harden your own network to an impressive standard and still get breached because a vendor with VPN access ran an unpatched appliance. Your security is only as strong as the weakest partner you have handed a key to.

This post is a practical guide to third-party cybersecurity risk: how to find the vendors that matter, how to assess them without drowning in paperwork, and how to build controls that actually reduce exposure rather than just generating spreadsheets.

Why Third-Party Risk Is Different

Managing your own security is hard but bounded. You know your systems, you control your patching, you can audit your own logs. Third-party risk breaks all of those assumptions. You are trusting an organization whose internal controls you cannot see, whose staff you did not hire, and whose incident response you do not run. When they get compromised, the attacker inherits whatever access you gave them.

Three characteristics make this category especially dangerous:

• Inherited trust. Once a vendor is inside your environment (through an API key, a VPN tunnel, a federated login, or a software agent running with high privileges) their compromise becomes your compromise. Supply-chain attacks like the SolarWinds and Kaseya incidents worked precisely because trusted software carried the payload.
• Invisibility. Most companies cannot produce an accurate list of every vendor with access to their systems or data. Shadow IT, expired contracts with live credentials, and forgotten integrations pile up over years.
• Diffused accountability. When procurement signs the contract, IT provisions the access, and nobody owns the ongoing security relationship, risk falls through the cracks. The vendor assumes you are watching. You assume they are secure. Neither is true.

Step One: Build a Real Vendor Inventory

You cannot manage risk you cannot see. The first exercise I run with any client is building an honest inventory of third parties, because it is almost always incomplete. Pull data from multiple sources and reconcile them:

• Accounts payable records (who are you paying?)
• Identity provider logs (which external accounts and federated identities exist?)
• Firewall and VPN configurations (who has network access?)
• SaaS admin consoles and OAuth grants (which apps have been authorized to read your data?)
• Cloud provider IAM roles granted to external accounts

For each vendor, record what data they can touch, what systems they can reach, and what would happen to your operations if they went down or got breached. This is the foundation. Everything else is prioritization on top of it.

Step Two: Tier Vendors by Actual Risk

Not every vendor deserves the same scrutiny. The company that supplies your office coffee does not need a penetration test report. The payroll processor holding your entire staff's personal and banking data does. Tiering keeps your program proportionate and prevents assessment fatigue.

I usually sort vendors into three tiers based on two questions: how much sensitive data do they hold or access, and how deeply are they integrated into critical operations?

Tier	Examples	Assessment depth
Critical	Cloud hosting, payroll, managed IT/MSP, core payment processing, anything with admin access	Full assessment, evidence of controls, contractual security terms, continuous monitoring, right-to-audit
Important	CRM, marketing platforms, analytics tools with customer data, HR software	Questionnaire plus review of certifications (SOC 2, ISO 27001), periodic re-check
Low	Office supplies, non-integrated tools with no sensitive data access	Basic due diligence, standard contract terms

Spend your assessment effort where a breach would actually hurt. A tiered approach means your team focuses on the ten vendors that could sink the business instead of chasing questionnaires from the hundred that could not.

Step Three: Assess Without Theater

Most vendor risk assessment is theater. A 300-question spreadsheet gets emailed, someone at the vendor fills it out optimistically, it gets filed, and nobody reads it again. That process produces paper, not security. Do these things instead:

Ask for evidence, not assertions

Anyone can tick "yes, we encrypt data at rest." Ask for the SOC 2 Type II report, the ISO 27001 certificate with its statement of applicability, or a recent independent penetration test summary. Read the exceptions section of a SOC 2 report; that is where the real findings live. A vendor who cannot produce any independent evidence of their controls is telling you something important.

Focus questions on what matters

For a critical vendor I want to know: How do they authenticate their own administrators (is MFA enforced everywhere)? How and where do they store your data? Who are their subprocessors (the fourth parties you inherit)? What is their patching cadence for internet-facing systems? How fast will they notify you of a breach, and is that in the contract? Ten sharp questions beat three hundred generic ones.

Validate the connection, not just the paperwork

The vendor's certifications tell you about their environment. They tell you nothing about the specific access path into yours. Review the actual integration: the scope of the API token, the network segment the VPN drops into, the permissions on the service account. A security audit or targeted vulnerability assessment of the integration points often reveals over-provisioned access that no questionnaire would catch.

Step Four: Put Security in the Contract

Trust is not a control. Contracts are where you make security obligations enforceable. For critical and important vendors, insist on clauses that cover:

1. Breach notification timelines. Define how quickly (24, 48, 72 hours) the vendor must notify you of a confirmed or suspected incident affecting your data. Vague "reasonable time" language is worthless during an active breach.
2. Minimum security standards. Require MFA, encryption, patching commitments, and adherence to a recognized framework rather than leaving controls undefined.
3. Right to audit or evidence. Reserve the right to request current audit reports or, for the most critical relationships, to conduct or commission an independent assessment.
4. Subprocessor disclosure. Require notice and approval before the vendor hands your data to their own downstream providers.
5. Data handling at exit. Specify return or verified destruction of your data when the relationship ends, and the revocation of all access.

These terms are far easier to negotiate before signing than after a breach. If a vendor resists reasonable security language, treat that resistance as a risk signal in itself.

Step Five: Monitor Continuously and Plan for the Breach

A vendor assessment is a snapshot. The vendor gets acquired, changes infrastructure, loses key staff, or quietly ships a risky product change. Point-in-time assessments age badly. Build lightweight ongoing checks:

• Re-review critical vendors at least annually, and whenever there is a major change (acquisition, breach disclosure, platform migration).
• Track public breach news for your key vendors so you are not learning about their incident from an attacker inside your network.
• Periodically review the access itself: are old integrations still live, are service accounts still needed, have permissions crept upward?

Finally, assume a vendor will eventually be compromised and rehearse for it. Your incident response plan should explicitly cover third-party scenarios: who you call at the vendor, how you cut their access fast, what data they held, and your own notification obligations to customers and regulators. When a supplier breach hits, the organizations that recover well are the ones that decided in advance how they would respond. A virtual CISO engagement is often the most efficient way for a mid-sized company to stand up this whole program without hiring a full-time team.

Frameworks Make This Repeatable

If you are pursuing SOC 2 or ISO 27001, vendor risk management is a required control area, not an optional extra. Both frameworks force you to inventory suppliers, assess them, and monitor them. Rather than treating that as a compliance chore, use the framework as the backbone of a program you would want anyway. The discipline it imposes (a real inventory, tiered assessments, documented decisions) is exactly what stops a forgotten contractor login from becoming next year's incident report.

Frequently Asked Questions

How many vendors should we actually assess in depth?

Far fewer than most people fear. In a typical mid-sized company, out of dozens or hundreds of suppliers, usually five to fifteen are genuinely critical (they hold sensitive data or have privileged access). Assess those thoroughly, apply a lighter questionnaire to the important tier, and use standard contract terms for everyone else. Depth where it matters beats shallow coverage everywhere.

Is a SOC 2 report enough to trust a vendor?

It is a strong signal, not a guarantee. A SOC 2 Type II report shows an independent auditor tested controls over a period, which is far better than self-attestation. But you still need to read the scope (does it cover the service you actually use?), read the exceptions section, and check the report is current. And it says nothing about how the vendor's specific integration into your environment is configured. Verify the connection separately.

What is fourth-party risk?

Your vendors have their own vendors (subprocessors). When you send data to a SaaS provider that in turn runs on a cloud platform and uses a third-party analytics tool, those downstream providers are your fourth parties, and their compromise can still reach your data. This is why subprocessor disclosure clauses matter: you need visibility into the full chain, not just the company you signed with.

A vendor refuses to complete our security questionnaire. What now?

First, check whether they already have a SOC 2 or ISO 27001 report that answers most of your questions, since mature vendors often prefer to share those instead of filling in bespoke forms. If they have neither certification nor willingness to answer basic security questions, that is a meaningful risk finding for a critical vendor. Weigh it against how much access and data they hold, and consider whether an alternative supplier is warranted.

We are a small business. Is all of this overkill?

The scale changes, the principle does not. A small company might have three critical vendors and manage the whole program in a simple spreadsheet reviewed twice a year. What you cannot skip is knowing who has access to your data and having breach notification and access-removal terms in place. Small businesses are frequently breached through their IT provider or accounting software, so the critical-tier vendors deserve real attention even on a tight budget.

Where to Start

If you do nothing else this quarter, build the inventory and tier it. Knowing exactly who can reach your data, and how badly it would hurt if each of them were breached, puts you ahead of most organizations. From there, tighten contracts and validate the access paths for your critical tier.

If you want an outside assessment of your third-party exposure, or help building a vendor risk program that fits your size rather than a generic template, get in touch. I will tell you honestly where your real exposure sits and what to fix first.