A vendor can make your business more efficient while creating a path into your most sensitive information. A payroll provider holds employee records. An IT support company may have administrative access. A software platform can become essential to daily operations before anyone asks what happens if it goes offline.
The challenge is not eliminating every third-party risk. It is understanding which risks matter, verifying that reasonable safeguards exist, and making someone accountable for the decision.
Vendor security should be a repeatable business process—not a questionnaire filed away after the contract is signed. Use this checklist to assess new vendors, review existing relationships, and keep security expectations aligned with how your business actually uses each service.
1. Before Signing: Understand the Exposure
Start with a business question: If this vendor became unavailable or compromised, what could it expose or interrupt? The answer determines how much scrutiny the relationship deserves.
NIST’s cybersecurity supply chain risk management guidance supports prioritizing suppliers according to their importance and the risks they introduce. Applying the same assessment to every vendor wastes resources and can obscure your most consequential dependencies.
- ☐ Name an internal owner. Identify who needs the service, who reviews its security, and who has authority to approve unresolved risks. The business owner should remain accountable after procurement ends.
- ☐ Map the data. Record what the vendor will receive, store, process, or transmit. Include employee information, customer records, financial data, intellectual property, and credentials.
- ☐ Map system access. Identify connected applications, network access, integrations, and administrative permissions. Distinguish what the vendor requests from what the work actually requires.
- ☐ Assign a risk tier. Give deeper scrutiny to vendors supporting essential operations, handling sensitive information, or receiving extensive access. Record the reasoning in a centralized vendor inventory.
- ☐ Verify the company. Confirm its legal identity, ownership, operating locations, and relevant security history. Corroborate material claims rather than relying entirely on sales presentations.
For example, a designer receiving public marketing materials usually presents less exposure than a service provider administering your cloud environment. But if that designer also receives unreleased product plans, the assessment should change. Evaluate the actual relationship, not just the vendor’s category.
2. During Assessment: Ask for Evidence, Not Assurances
“We take security seriously” is not evidence. A useful assessment connects each important safeguard to documentation, a demonstration, or another credible way to verify it.
Identity and access
- ☐ Require multifactor authentication. Require MFA for vendor access to your network and verify protection for privileged accounts and sensitive service administration. Prefer phishing-resistant methods where feasible.
- ☐ Limit permissions. Give vendors only the access needed for the work. Use individually attributable accounts, time-limited access where practical, and a defined process for removing departing personnel.
- ☐ Check accountability. Ask whether important administrative actions and access events are logged, who reviews those records, and whether relevant information will be available during an investigation.
Data protection
- ☐ Verify encryption. Ask how sensitive information is protected during transfer and storage, and who can access it. Clarify responsibilities for encryption keys where relevant.
- ☐ Understand permitted use. Determine whether the vendor can share data, use it for analytics, or train AI models with it. Confirm that the proposed use matches your expectations and obligations.
- ☐ Review retention and deletion. Ask how long information remains in active systems and backups, how deletion works, and what exceptions apply.
Security maintenance and resilience
- ☐ Review vulnerability management. Ask how the vendor finds vulnerabilities, prioritizes fixes, deploys updates, and handles products approaching end of support. Request evidence of remediation rather than only a testing schedule.
- ☐ Check recovery capabilities. For operationally important vendors, review backup practices, recovery testing, and realistic restoration expectations. A backup policy alone does not demonstrate that recovery works.
- ☐ Examine independent evidence. Request documentation appropriate to the risk, such as an independent assessment, a relevant certification, or a penetration-test summary. Check its date, scope, exceptions, and remediation status.
A SOC 2 report, for example, is useful only if it covers the service and controls relevant to your use. It is not a blanket guarantee. If a smaller vendor lacks formal assurance documentation, assess whether alternative evidence is credible enough for the exposure involved.
The FTC’s small-business cybersecurity guidance reinforces the importance of protecting information and checking service-provider safeguards. Your follow-up question should be consistent: What supports this answer, and when was that evidence last updated?
3. In the Contract: Make Expectations Explicit
A security discussion has limited value if the agreement allows broader data use or leaves incident responsibilities undefined. Have appropriate legal and security reviewers translate important findings into enforceable expectations.
- ☐ Document security requirements. Specify relevant access controls, data protections, security maintenance responsibilities, and how compliance will be verified.
- ☐ Define data-handling boundaries. Address ownership, permitted use, sharing, storage locations where relevant, retention, return, and deletion. Ensure the contract matches the service configuration you intend to use.
- ☐ Address subcontractors. Identify relevant downstream providers, define security responsibilities, and establish expectations for notice of material changes. Understand which dependencies could affect your information or service availability.
- ☐ Establish incident coordination. Define reportable events, notification triggers, contacts, escalation paths, evidence preservation, and cooperation during response and recovery.
- ☐ Plan for service interruption and exit. Document recovery expectations, access to your data, transition assistance where needed, and responsibilities when the relationship ends.
Incident notification deadlines should reflect negotiated requirements and applicable legal or regulatory obligations. There is no single deadline suitable for every vendor relationship. Clarify what starts the notification clock and what information the vendor must provide as facts emerge.
For a payroll provider, for example, the agreement should address both confidentiality and continuity: how employee information is protected, how an incident is reported, and what happens if payroll processing becomes unavailable.
4. Before Access Goes Live: Verify the Setup
Assessment answers describe intended safeguards. Onboarding reveals whether those safeguards are actually operating.
- ☐ Confirm access restrictions. Check that MFA, approved permissions, and account ownership are configured before granting access to sensitive systems.
- ☐ Minimize initial data sharing. Provide only the information required. Avoid sending complete production datasets when limited or appropriately de-identified information will do.
- ☐ Test essential processes. Confirm support and incident contacts, validate important logging, and check that data export or recovery procedures are usable where needed.
- ☐ Record unresolved conditions. Assign each gap an owner, a target date, and any interim restrictions. Do not let conditional approval silently become permanent acceptance.
A completed checklist does not make a vendor secure. It makes the decision visible: what was checked, what remains uncertain, and who accepted the risk.
5. After Onboarding: Review Changes and Prepare for Exit
Vendor risk changes when the service changes. A platform that once stored routine documents may later hold acquisition plans. An integration may gain broader permissions. A subcontractor change may introduce a new dependency.
- ☐ Schedule risk-based reviews. Review critical relationships more closely than low-exposure ones. Refresh evidence, permissions, contacts, and remediation status on a defined schedule.
- ☐ Reassess material changes. Revisit the decision after significant incidents, expanded data use, new integrations, ownership changes, or changes in operating locations and underlying suppliers.
- ☐ Monitor business dependencies. Consider whether financial difficulties or operational changes could affect secure, reliable delivery. NIST’s supplier due-diligence guidance includes these broader supplier considerations.
- ☐ Close access when the relationship ends. Disable accounts, revoke tokens and integrations, recover needed data, and obtain appropriate deletion confirmation. Document any information retained under legal or contractual obligations.
For a critical provider, consider how the business would function during an outage or transition. An exit plan is useful only if the data can be retrieved and someone knows how to continue the work.
6. Keep a Simple Decision Record
You do not need a complicated platform to begin. Maintain one assessment record per vendor using these fields:
Vendor | Business owner | Data/access | Risk tier | Evidence reviewed | Gaps | Decision | Remediation owner/date | Next review
Use clear decision labels:
- Approve: The evidence supports the proposed use, and remaining risk is accepted by the appropriate authority.
- Approve with conditions: Specific gaps require remediation or restrictions, with accountable owners and deadlines.
- Do not approve: The exposure exceeds your tolerance, or essential safeguards cannot be verified.
These are practical workflow choices, not official NIST classifications. Document the rationale so another reviewer can understand the decision later.
Make Vendor Security Part of Doing Business
Effective vendor security connects business exposure, credible evidence, written expectations, and ongoing ownership. It cannot guarantee that a provider will never experience an incident. It can help your organization make better decisions and respond with less confusion.
Start with the vendors that can access your most sensitive information or interrupt your most important work. Record what you checked, what remains unresolved, and who owns the next step. Then make that review a routine part of purchasing, renewing, and retiring services.