Every vendor with access to your systems, data, or network is an extension of your attack surface. A weak vendor is often the easiest path into an otherwise well-protected organization. This guide covers vetting, access control, ongoing monitoring, and safe offboarding for third parties.
Why Vendor Risk Matters
- Attackers increasingly target smaller, less-protected vendors to reach their larger customers ("supply chain" attacks)
- A single vendor with broad, unmonitored access can expose your entire network if compromised
- Many data breach notification laws hold you responsible even when a vendor caused the breach
Vendor Vetting
Before granting any vendor access to your systems or data, understand what you're trusting them with and how seriously they take security.
Before You Grant Access
Vendor Assessment Checklist
Access Control Requirements
Least Privilege for Third Parties
Apply Least Privilege to Every Vendor
- Grant access only to the specific systems and data needed for the vendor's function—nothing broader
- Use time-limited or scoped credentials rather than permanent standing access when possible
- Require MFA for any vendor account with access to your systems
- Use a dedicated vendor account (never a shared generic login) so activity is traceable to that specific vendor
- Log and monitor vendor account activity the same way you would an employee account
- Segment vendor access from your core network where technically possible (separate VLAN, VPN profile, or jump box)
Access Approval Template
Vendor Access Request Form (Starting Point)
| Vendor Name | [Company name] |
| Business Justification | [Why access is needed] |
| Systems/Data Requested | [Specific systems, scope of data] |
| Access Level | [Read-only / Read-write / Admin] |
| Duration | [Start date – End date, or "ongoing, reviewed quarterly"] |
| MFA Required? | [Yes/No — should always be Yes] |
| Approved By | [Name, Title, Date] |
| Review Date | [Next scheduled access review] |
Ongoing Monitoring
Don't Vet Once and Forget
- Review vendor access quarterly—confirm it's still needed and still scoped correctly
- Monitor vendor account activity for unusual times, locations, or data volumes
- Re-assess vendor security posture annually, or after any known security incident on their end
- Track vendor certifications and insurance for expiration
- Maintain an up-to-date inventory of all vendors with system or data access—you can't monitor what you don't know about
Incident Response SLA Template
Vendor Incident Notification Requirements (Include in Contracts)
| Notification Window | Vendor must notify us within [24-72 hours] of discovering an incident affecting our data or systems |
| Notification Method | [Designated contact/email/phone] with written follow-up |
| Information Required | Nature of incident, data/systems affected, containment actions taken, timeline |
| Cooperation Clause | Vendor agrees to cooperate with our investigation and provide requested logs/evidence |
| Remediation Responsibility | [Defines who bears cost of notification, credit monitoring, remediation if vendor is at fault] |
Offboarding Procedures
When a Vendor Relationship Ends
Red Flags for High-Risk Vendors
Watch For These Warning Signs
- Vendor refuses to complete a basic security questionnaire
- No formal incident response process or unclear breach history
- Requests broader access than their function requires
- No MFA support on their platform or for the accounts they issue
- Uses shared, generic logins instead of individual accounts
- Has had a recent, unresolved public security incident
- Subcontracts your data to other vendors without disclosure
- Pushes back on including security/notification clauses in contracts