How To Prevent Business Email Compromise (BEC) Scams
What Is Business Email Compromise? It goes by several names, but they all describe the same scam. Business email …
Learn ten practical steps to prevent your vendors from becoming your biggest security risk.
• Vendor security assessments before onboarding catch the obvious gaps. But most companies stop there. The real risk is what happens after you sign the contract and stop checking.
• The two biggest third-party breaches of 2024 both started with stolen credentials and no MFA. Requiring MFA for every vendor connection to your systems is non-negotiable.
• Your contract is your only bargaining power after a breach. Build security requirements, breach notification SLAs, and audit rights into vendor agreements before you need them.
• Vendor offboarding is as important as onboarding. When you end a vendor relationship, revoke access immediately and verify they’ve deleted your data. Orphaned vendor accounts are a common attack vector.
You can’t control your vendors’ security. But you can control what access they have, what data they touch, and how quickly you find out when something goes wrong.
Most companies do a vendor security check at onboarding and never look again. That’s how gaps open up.
This guide covers ten steps to prevent third-party data breaches, from vendor assessment to offboarding.
Why Are Third-Party Breaches So Hard to Prevent?
You can lock down your own systems. You can train your own employees. But you can’t force your vendors to do the same.
That’s the core challenge. When you share data with a vendor or grant them network access, your security becomes dependent on theirs. And you usually can’t see what they’re actually doing.
For a full overview of what third-party breaches are and how they happen, see our companion guide. This article focuses on the controls that prevent them.
How Do You Assess Vendor Security Before Onboarding?
Prevention starts before you sign the contract. That’s when you have bargaining power. After the contract is signed, you’re stuck with whatever security standards the vendor already has.
Vendor security assessment is the process of evaluating a third-party vendor’s security controls before granting them access to your data or systems. It typically involves reviewing certifications (SOC 2, ISO 27001), completing security questionnaires, checking breach history, and assigning a risk tier based on what data the vendor will access.
Request certifications. SOC 2 Type II reports are the standard for SaaS vendors. ISO 27001 covers broader information security management. These don’t guarantee good security, but their absence is a red flag.
Run a security questionnaire. Cover access controls, encryption practices, incident response plans, employee training, and sub-processor management. Standard frameworks like SIG or CAIQ save time.
Check breach history. Search for the vendor’s name plus “data breach” or “security incident.” Past breaches aren’t disqualifying, but how they responded matters.
Tier by risk. Not every vendor needs the same scrutiny. A vendor with access to customer PII gets a deeper assessment than one that only handles marketing analytics. Assign tiers: critical, high, medium, and low. Assessment depth scales with the tier.
What Controls Prevent Third-Party Data Breaches?
Once a vendor is onboarded, these controls limit your exposure.
Require MFA for all vendor access
The Change Healthcare breach and the AT&T/Snowflake breach both started with stolen credentials and no MFA. This single control would have blocked both. Require MFA for every vendor connection to your systems. No exceptions.
This includes VPN access, cloud console access, API authentication, and any remote desktop connections. Use hardware keys or authenticator apps. SMS-based MFA is better than nothing but vulnerable to SIM-swapping.
Enforce least-privilege access
Vendors should only access what they need to do their job. A payroll processor doesn’t need access to your product database. Use Vendor Privileged Access Management (VPAM) to enforce permissions and log all vendor activity.
Review vendor access quarterly. Permissions creep over time as vendors ask for “temporary” access that becomes permanent. Set calendar reminders. If nobody reviews access, it only expands.
For particularly sensitive systems, consider just-in-time access provisioning. The vendor requests access when they need it, it’s granted for a specific window, and it revokes automatically. This eliminates standing access entirely.
Segment your network
Put vendor connections on isolated network segments. If a vendor gets breached, segmentation prevents attackers from moving laterally into your core systems. This is the same principle as network segmentation for breach containment, applied to vendor access.
Limit data sharing
Only share the data your vendor actually needs. Audit what’s in their environment periodically. If they have more of your data than the contract calls for, that’s a problem.
Encrypt data in transit and at rest
Any data shared with vendors should be encrypted. This limits the damage even if the vendor’s systems are breached. Require encryption as a contractual minimum.
What Should Your Vendor Contracts Require?
Your contract is your only real bargaining power after a breach. Build these requirements in before you sign.
If your contract only has one security clause, make it the breach notification SLA. Require vendors to notify you within 48-72 hours of discovering a breach affecting your data. Without this, you may not find out for months. Everything else is recoverable. Time isn’t.
Beyond that, specify minimum security standards: MFA, encryption, patch management timelines, and access logging. Reserve audit rights so you can verify compliance. Require data deletion with written confirmation when the relationship ends. Orphaned data at former vendors is a silent risk.
Vendor privileged access management (VPAM) controls and monitors the access that third-party vendors have to your internal systems. VPAM enforces least-privilege permissions, logs all vendor sessions, and can revoke access in real time. It’s the technical layer that makes your access policies enforceable rather than aspirational.
Indemnification. Include clauses that make the vendor financially responsible for breaches caused by their negligence. This won’t eliminate your liability, but it gives you a recovery path.
Cyber insurance minimums. Require vendors to maintain adequate cyber insurance. This ensures they can actually pay if indemnification kicks in.
Sub-processor disclosure. Require vendors to disclose any sub-processors (fourth parties) that will handle your data. You should have the right to approve or reject sub-processors. This is where fourth-party risk hides.
Regular compliance evidence. Don’t just require certifications at signing. Require vendors to provide updated SOC 2 reports or audit summaries annually. A certification from two years ago tells you nothing about their security today.
How Do You Monitor Vendors After Onboarding?
The onboarding assessment is a snapshot. Vendor security changes over time. People leave, systems get reconfigured, new vulnerabilities emerge.
Credential monitoring. Dark web monitoring catches when vendor employees’ credentials appear in breach data or stealer logs. This is often the earliest signal that a vendor’s environment has been compromised.
Security rating services. Platforms like SecurityScorecard track your vendors’ external security standing continuously. They monitor exposed services, certificate management, and patching cadence.
Periodic reassessment. Critical vendors: quarterly reviews. High-risk: every six months. Standard: annually. Plus event-triggered reviews after any vendor breach, acquisition, or major infrastructure change.
Access log review. Periodically review what your vendors are actually accessing in your systems. Compare it against what the contract says they need. If a vendor is accessing data or systems outside their scope, that’s either a misconfiguration or a problem.
Event-triggered reviews. Beyond the regular schedule, trigger a reassessment whenever a vendor announces a breach, gets acquired, has major leadership changes, or makes major infrastructure migrations. These events change the risk profile even if the vendor’s score looked fine last quarter.
How Do You Handle Vendor Offboarding?
Ending a vendor relationship is as risky as starting one. Most companies handle it poorly.
Revoke access immediately. Disable all vendor accounts, API keys, and VPN credentials the day the relationship ends. Don’t wait for the vendor to “hand things off.”
Verify data deletion. Your contract should require the vendor to delete your data and confirm it in writing. Follow up. Don’t assume it happened.
Review exit-period activity. Check logs for any unusual activity during the vendor’s final days. The same departure-window risk that applies to departing employees applies to departing vendors.
Remove from monitoring only after verification. Keep the vendor in your credential monitoring and security rating dashboards until you’ve confirmed all access is revoked and data is deleted.
How Do You Respond When a Vendor Gets Breached?
Despite your best prevention efforts, vendor breaches happen. Your response plan should cover this specific scenario.
Assess exposure immediately. Determine what data the vendor had access to and whether it was affected. Don’t wait for the vendor to tell you the full scope. Their initial report is almost always incomplete.
Activate your incident response plan. Your breach response plan should include a vendor-specific playbook. Who contacts the vendor? Who assesses internal exposure? Who handles notification obligations?
Revoke access. If the vendor’s systems are compromised, cut their connection to yours immediately. Better to lose functionality temporarily than to let attackers pivot through the vendor into your network.
Document everything. Regulators and legal counsel will want a timeline. Record when you were notified, what you found, and what actions you took.
Communicate with affected parties. Depending on what data was exposed, you may have notification obligations under GDPR, CCPA, HIPAA, or state breach notification laws. The clock usually starts when you become aware of the breach, not when the vendor tells you the full scope. Don’t wait for complete information before starting the notification process.
For a deeper look at assessing and managing third-party risk, see our risk assessment framework guide.
Conclusion
Most companies do the onboarding assessment and stop. That’s where the gaps open up. The monitoring piece is where you actually catch problems, because vendor security changes constantly and you won’t notice unless you’re watching.
Check your exposure to see if your vendors’ credentials have already appeared on criminal markets.
Third-Party Breach Prevention FAQ
Request SOC 2 Type II reports or ISO 27001 certification. Run a security questionnaire covering access controls, encryption, and incident response. Check their breach history. Tier them by risk based on what data they’ll access. For a full framework, see our third-party risk assessment guide.
Minimum security standards (MFA, encryption at rest and in transit), breach notification timelines (48-72 hours), audit rights, data deletion requirements at contract end, indemnification clauses, and required cyber insurance minimums.
Critical vendors: quarterly. High-risk vendors: every six months. Standard vendors: annually. Plus event-triggered reviews after any breach, acquisition, or major infrastructure change at the vendor.
VPAM controls and monitors the access your vendors have to your systems. It limits vendor permissions to only what they need, logs all vendor activity, and can revoke access instantly. It’s the technical enforcement layer behind your least-privilege policies.
Credential monitoring catches when vendor employees’ passwords appear in breach data or stealer logs. Security rating services track your vendors’ external security standing over time. Both give you early warning without waiting for the vendor to tell you.
Revoke all access immediately. Disable vendor accounts and API keys. Verify the vendor has deleted your data per contract terms. Review logs for any unusual activity during the exit period. Remove the vendor from monitoring dashboards only after confirming clean handoff.
