Vendor Risk Assessment: How to Tier, Review, and Decide

A vendor risk assessment is the review you run before a supplier touches your systems or data, and it ends in a decision: approve, approve with conditions, or decline. The work has five parts. Tier the vendor by the data and access it will hold, size the review to that tier, read evidence that matches the tier, score the risk that remains after the vendor's controls, and record the decision with an owner and a review date. Most programs fail at the first step and the last one. They send the same long questionnaire to every supplier, then file the answers without deciding anything.

The stakes rose in 2025. Verizon's 2025 Data Breach Investigations Report found a third party involved in 30 percent of breaches, double the share a year earlier. Auditors and regulators expect a documented process as well. SOC 2 criterion CC9.2, ISO/IEC 27001:2022 Annex A controls 5.19 through 5.22, and the supply chain category in NIST CSF 2.0 all ask how you assess suppliers before the contract and during the relationship.

What a vendor risk assessment covers

A vendor risk assessment is one event inside a larger program. Vendor risk management is the program: the inventory, the policy, the tools, and the calendar. The assessment is the decision point for a single supplier, run at onboarding and again when the relationship changes.

Every assessment answers four questions. What will this vendor touch? What could go wrong if the vendor fails or is breached? What does the vendor do to prevent that? What will you do about the risk that remains? Information security takes most of the effort, but a complete assessment also checks financial stability, concentration risk when one supplier carries a critical process, the regulatory terms the relationship requires, and the vendor's own suppliers. A business associate agreement under HIPAA and the processor terms in Article 28 of the GDPR are assessment outputs, because both depend on knowing what data the vendor will handle.

Step 1: Tier the vendor before you send anything

Tiering decides how much work each vendor gets, so it has to happen before the first questionnaire goes out. Four facts drive the tier: the sensitivity of the data the vendor will store or process, the level of access it will hold in your environment, how much of your operation stops if it goes down, and whether a regulation names the relationship. A three-tier model covers most companies:

• Tier 1, critical. The vendor stores or processes regulated or customer data at volume, holds privileged or production access, or runs a process that stops revenue when it fails. Cloud hosting, the identity provider, payroll, and an electronic health record platform sit here. These vendors get the full assessment, negotiated security terms, annual reassessment, and continuous monitoring.
• Tier 2, significant. The vendor handles limited sensitive data or holds user-level access to a system that matters. These vendors get a standard questionnaire backed by an independent report, with reassessment at renewal or every two years.
• Tier 3, low. The vendor touches no sensitive data and holds no system access. These vendors get a short attestation and standard contract terms. Sending them a questionnaire wastes their time and yours.

Tier 1 should be short. If half your vendor list lands there, the criteria are too loose, and the team will spend its hours on suppliers that cannot hurt you while the dangerous ones get the same skim as everyone else. Write the tiering rules down, apply them at intake, and let the business owner who requested the vendor answer the data and access questions, because they know what the tool will be connected to.

Step 2: Size the review to the tier

Independent assurance beats self-reported answers, so ask for it first. A SOC 2 Type 2 report, an ISO 27001 certificate with its Statement of Applicability, a FedRAMP authorization, or a PCI DSS attestation of compliance tells you more than a questionnaire, because a third party tested the controls. For Tier 2 vendors, one current report plus a short gap questionnaire is usually enough. For Tier 1 vendors, the report is the starting point, and the review adds artifacts and questions aimed at the risks specific to your use.

Standard questionnaires save everyone time when a vendor has no report. The Shared Assessments SIG Lite and the Cloud Security Alliance CAIQ are the common choices, and many vendors keep completed copies ready to send. Write custom questions only for the gaps those leave, such as how the vendor will segregate your data from other customers or how fast it will notify you of an incident.

Step 3: Read the evidence behind the answers

A SOC 2 report earns its value only when someone reads it. Check four things before you accept one. First, confirm the period: a report that ended nine months ago says nothing about the controls today, so ask for a bridge letter or a newer report. Second, confirm the scope, because the system the auditor examined has to include the service you are buying. Third, read the exceptions in the auditor's test results, since a qualified opinion or a run of access review exceptions is the part of the report that should change your decision. Fourth, list the complementary user entity controls, which are the controls the vendor expects you to operate, such as reviewing your own users' access to their platform. If you never perform them, the vendor's report does not cover you.

For Tier 1 vendors, verify the claims that carry the most weight. Ask for the date and scope of the last penetration test, evidence that multifactor authentication is enforced for administrative access, the incident response plan's last test date, a certificate of cyber insurance with its limits, and the current subprocessor list. Outside signals add a check on what the vendor told you: breach disclosures, security rating trends, and basic email domain hygiene. When a questionnaire answer contradicts an exception in the vendor's own audit report, treat the exception as the truth and ask about the gap.

Step 4: Score the risk that remains and decide

Scoring should produce a decision someone can defend, and three levels do that better than a weighted model with a hundred inputs. Start from inherent risk, which the tier already captures. Rate the strength of the vendor's controls against the risks that matter for your use. The result is residual risk: high, medium, or low.

Residual risk maps to one of three outcomes. Low residual risk means approval. Medium residual risk means approval with conditions, written into the contract and the vendor's record: a breach notification window, a right to audit or to receive updated reports, data return and deletion at termination, notice before new subprocessors handle your data, and minimum controls the vendor must keep. High residual risk means declining the vendor or finding an alternative, unless an accountable business owner signs a risk acceptance with an expiration date. That signature matters. It moves the decision from the security team's inbox to the person who wants the tool and owns the outcome.

Step 5: Put the decision in the contract and the calendar

An assessment that changes no contract terms and sets no review date leaves the risk exactly where it was. Carry every condition into the agreement before signature, because your bargaining power disappears once the contract is signed. Then set the reassessment date by tier and define the triggers that force an early review: a breach at the vendor, an acquisition, a change in what data you send them, or a new integration with production systems.

Regulators have written this lifecycle into rules. The FTC Safeguards Rule at 16 CFR 314.4(f) requires covered financial institutions to select capable service providers, require safeguards by contract, and periodically assess providers based on the risk they present. Banks follow the 2023 Interagency Guidance on Third-Party Relationships, which runs from planning and due diligence through ongoing monitoring and termination. Financial entities in the EU have kept a register of their ICT third-party arrangements under DORA since January 17, 2025.

Where vendor risk assessments go wrong

The same failures show up in program after program. Every vendor gets the same questionnaire, so low-risk suppliers stall in procurement while critical ones receive no deeper review. Teams accept a SOC 2 report because it exists, without reading the period, the scope, or the exceptions. Nobody owns the decision, so the assessment ends as a filed spreadsheet instead of an approval with conditions. Reassessment dates pass because no one put them on a calendar, and the vendor's subprocessors never enter the review even when they hold your data. The last failure costs the most: findings that never reach the contract, which leaves the company with a documented risk and no remedy.

Fixing these takes discipline more than tooling. A compliance automation platform helps by collecting reports, sending questionnaires, and tracking dates, but it cannot decide what tier a vendor belongs in or whether an exception matters for your use. Those calls belong to people who understand both the vendor's service and your environment. As the vendor list grows, the same tiering rules carry the load, and our guide to scaling third-party risk management covers how the program changes between 20 vendors and 200.

How BD Emerson runs vendor risk assessments

BD Emerson builds tiering criteria that match how your company buys software and services, runs Tier 1 assessments end to end, writes the contract conditions that carry findings into agreements, and sets up the reassessment calendar in the platform you already use, whether that is Vanta, Drata, or a dedicated third-party risk tool. When an auditor or a customer asks how you manage vendors, you hand them a process with decisions, owners, and dates. Start with our third-party risk management services, or send us your vendor list and we will tell you which ten vendors deserve the full review first.