How to assess a vendor's security

Assess a vendor's security by defining what the service will do, what access it needs, and what a failure would affect. Review evidence against that relationship, resolve important uncertainties, and record who accepts the remaining risk. A completed questionnaire or a favorable rating is an input to that decision.

Define the relationship

Start with the proposed use, rather than the vendor's entire product catalog. A public marketing tool and a production infrastructure provider can need different reviews even when both are sold as SaaS.

• Identify the legal entity, product, service owner, and intended users.
• Record the data involved, systems connected, and privileges granted.
• Describe the operational dependency: what happens if the service is unavailable or compromised?
• Identify important subcontractors and any proposed change to data locations or access.

NIST's ICT supplier due diligence guide provides context for researching suppliers. The workflow here is an editorial starting point; tailor the review to your organization and relationship.

Request relevant evidence

Ask for documents that address the service and questions you actually need to resolve. If a report is provided, check its entity, system boundary, reporting period, exceptions, and responsibilities assigned to customers. An organization's logo or certificate title alone does not establish coverage for your planned use.

For each unresolved issue, record the question, supporting source, reviewer, and next action. Separate a missing document from a documented control weakness. Ask the vendor to explain scope gaps before escalating them as findings.

Review rating findings

Security ratings can help surface externally observable issues for investigation. SecurityScorecard describes active and passive collection; Bitsight explains its external ratings and correction process. Neither source provides visibility into every internal process your review may cover.

1. Confirm that the rated entity and attributed assets match the supplier and service under review.
2. Inspect the underlying finding, observation date, and reason it matters to your intended use.
3. Ask for context, remediation evidence, or a documented attribution correction.
4. Record unresolved findings separately from the overall score.

Do not convert one provider's number into another provider's grade. Ask how methodology changes, resolved findings, and aging observations affect the displayed rating.

Record the decision

Create a short decision record: proposed use, evidence reviewed, open issues, required actions, approver, and review date. A conditional approval should state what must happen, who owns it, and what use is permitted before completion. Your organization's policy determines the acceptance criteria.

Plan follow-up

Assign owners for outstanding work and review triggers. Consider changes to access, service scope, subcontractors, important findings, and reported incidents. On termination, track access removal and the agreed treatment of retained records. Monitoring software is useful only when someone reviews and acts on its signals.

Test your review process

Run one representative supplier through intake, evidence review, a disputed finding, approval, and follow-up. Then compare vendor risk tools using that same scenario. Inspect SecurityScorecard and Bitsight for the ratings portion, and keep the final decision with an accountable reviewer.