Vendor Risk Assessment Sampling: How Internal Audit Should Test The Program

Vendor risk assessment sampling helps internal audit determine whether a TPRM program works consistently across the full third-party population, not only for a few visible vendors. A defensible sample starts with a complete population, uses risk-based strata, tests each selected relationship across relevant lifecycle stages, and keeps enough evidence for another reviewer to reproduce the conclusion.

The goal is not to prove that every vendor file is perfect. It is to determine whether the program’s governance, risk decisions, controls, and escalation practices are designed appropriately and operating as management represents. This guide gives internal auditors and TPRM leaders a practical method for building the population, selecting cases, testing evidence, evaluating exceptions, and reporting results.

Why Vendor Risk Assessment Sampling Matters

Third-party portfolios are usually too large for internal audit to review every relationship. A sample allows the audit team to obtain evidence efficiently, but only when the selection method reflects the program’s risks. A handful of recent files supplied by management may look clean while missing older vendors, acquired entities, low-spend providers with sensitive access, emergency purchases, rejected vendors, terminated relationships, and cases with overdue remediation.

The Institute of Internal Auditors’ Third-Party Topical Requirement establishes a baseline for assurance over third-party governance, risk management, and controls. It applies to relevant assurance work from September 15, 2026 and includes downstream relationships where applicable. The accompanying guidance emphasizes risk-based judgment and documentation of applicability and exclusions. Sampling is how auditors translate that broad expectation into testable evidence.

NIST SP 800-53A adds a useful principle: assessment procedures should be tailored to organizational risk tolerance, and conclusions should be supported by evidence about whether controls are implemented and meeting their objectives. In a TPRM audit, that means testing the decision trail rather than merely confirming that a questionnaire exists.

Start With A Complete Vendor Population

The most important sampling control is population completeness. If the source population excludes relationships that bypassed intake, no statistical technique can repair the problem. Ask management for the official vendor inventory, then reconcile it to independent sources.

Useful reconciliation sources include:

Accounts payable and procurement records.
Contract lifecycle management and purchase-order systems.
Identity, single sign-on, privileged access, and service-account inventories.
Cloud expense, corporate-card, and software spend records.
Privacy records of processing activities and data-transfer inventories.
Application, API, integration, and configuration-management inventories.
Business continuity lists of critical external dependencies.
Incident, exception, risk-acceptance, and offboarding records.

Record the extraction date, source owner, fields received, filters applied, and reconciliation differences. Investigate unmatched records before selecting the sample. A vendor that appears in identity data but not in the TPRM platform may be more important to test than a perfectly documented Tier 1 provider.

Define The Audit Objective Before Selecting Cases

A sample should answer a defined question. “Review vendor files” is too vague. Better objectives include determining whether inherent-risk tiering is accurate, due diligence is proportionate, required approvals occur before onboarding, contract controls reflect identified risks, monitoring is completed on time, issues are escalated, and access and data are removed at exit.

Map each objective to a population, selection method, test procedure, expected evidence, and exception rule. If the objective concerns annual reassessments, the population should include relationships due during the audit period, not every active vendor. If the objective concerns termination, use the offboarded population. This prevents a common error: drawing one convenient sample and trying to use it for every lifecycle assertion.

Use Risk-Based Strata Instead Of One Random Pool

Segment the population so that materially different risks remain visible. Typical strata include criticality tier, inherent-risk rating, data sensitivity, privileged or production access, regulated processing, geography, subcontractor dependency, business unit, contract value, onboarding channel, assessment status, and lifecycle stage.

A practical sample often combines methods:

100 percent testing: all very small but material groups, such as vendors supporting a critical service or relationships with open severe findings.
Judgmental selection: unusual, high-risk, overdue, disputed, recently changed, or exception-heavy cases.
Random selection: cases from the remaining population to reduce management or auditor selection bias.
Coverage selection: enough cases to include major business units, risk tiers, service types, and lifecycle stages.

Do not describe a judgmental sample as statistically representative. Internal audit can still draw a sound control conclusion from risk-based testing, but the workpapers should state what the sample supports and what it does not.

How Large Should The Sample Be?

There is no universal vendor-file sample size. The decision depends on the audit objective, population size, control frequency, expected deviation, desired assurance, risk significance, and whether results will be projected to the population. Follow the internal audit function’s approved methodology and involve a sampling specialist when statistical projection matters.

For nonstatistical testing, document why the number and mix of items provide sufficient coverage. A smaller sample may be reasonable for a highly automated preventive control with stable evidence. A larger or more targeted sample may be necessary where decisions are manual, business units follow different practices, data is unreliable, or prior audits found inconsistent execution.

A Lifecycle Test Program For Each Selected Vendor

1. Intake And Ownership

Confirm the business owner, service description, legal entity, intended use, data, access, geography, subcontractors, and business dependency were captured. Compare intake answers with contracts, architecture diagrams, privacy records, and actual access. Inconsistent facts may show that the scope was understated.

2. Tiering And Inherent Risk

Reperform the tier or score using the policy in effect when the decision was made. Confirm that criticality and inherent risk were not treated as the same concept. Investigate overrides, missing inputs, unsupported low-risk classifications, and changes that should have triggered reassessment.

3. Due Diligence And Evidence

Determine whether required domains were reviewed by qualified owners. Inspect evidence dates, scope, legal entity, system coverage, exceptions, complementary user controls, and reviewer conclusions. A certificate or report title alone does not prove that the evidence covered the service being purchased.

4. Findings And Approval

Trace identified gaps to severity, owner, due date, remediation evidence, risk acceptance, compensating controls, and final approval. Confirm approval occurred before production use unless a documented exception permitted otherwise. Test whether expired exceptions were reopened or quietly left in place.

5. Contracting

Compare risk findings with executed clauses for confidentiality, security, privacy, incident notification, audit rights, continuity, subcontractors, data return or deletion, and termination. Document whether material gaps were escalated and accepted by authorized decision-makers.

6. Ongoing Monitoring And Renewal

Inspect reassessment timing, evidence refreshes, incident and performance monitoring, financial or geopolitical reviews where relevant, issue aging, and material-change triggers. Verify that alerts resulted in proportionate action rather than accumulating without ownership.

7. Exit

For terminated vendors, test access removal, credential revocation, data return or deletion evidence, asset recovery, integration shutdown, final invoices, legal holds, record retention, and confirmation that downstream processors were addressed.

Build Workpapers Another Auditor Can Reperform

For every selected item, retain the population identifier, selection rationale, procedure performed, evidence examined, evidence date, result, exception, owner response, and conclusion. Link screenshots and documents to the specific attribute tested. Avoid conclusions such as “adequate” without explaining the criteria and evidence.

Keep a sample-control matrix that maps each item to each lifecycle attribute. This reveals whether a supposed pass is actually “not applicable,” “not tested,” or “evidence unavailable.” It also makes patterns visible across business units, tiers, and reviewers.

Evaluate Exceptions Without Overstating Them

An exception is a fact that differs from the criterion. It is not automatically a program failure. Determine whether it is isolated or systemic, preventive or detective, design or operating, and whether it changes risk. Consider root cause: incomplete population, unclear policy, workflow configuration, capacity, training, data ownership, or governance.

Expand testing when exceptions suggest broader exposure. Examples include the same missing approval across one business unit, repeated reliance on expired evidence, a workflow that allows production access before approval, or a recurring contract-clause gap. Conversely, one documentation error may not justify a population-wide conclusion if the control operated and other evidence is reliable.

Common Sampling Mistakes

Accepting management’s curated list. Reconcile the population independently.
Selecting only high-risk vendors. Include lower tiers to test whether classification itself is reliable.
Testing only completed assessments. Include overdue, rejected, exception, and bypass cases.
Using one sample for unrelated objectives. Define the relevant population for each control assertion.
Counting documents instead of testing decisions. Inspect scope, quality, conclusions, and follow-through.
Projecting judgmental results statistically. Describe limitations accurately.
Ignoring changes after onboarding. Test renewals, incidents, service changes, and exits.

Analyst Takeaway

Effective vendor risk assessment sampling begins before the sample is drawn. Establish population completeness, connect selections to clear audit objectives, combine risk-based and unbiased coverage, and test the entire decision trail. The strongest conclusion is not “the file contained the required documents.” It is “the organization identified the exposure, obtained relevant evidence, made an authorized decision, and monitored the relationship in line with policy and risk.”

FAQ

What is vendor risk assessment sampling?

Vendor risk assessment sampling is the selection and testing of third-party relationships from a defined population to evaluate whether TPRM governance, due diligence, contracting, monitoring, issue management, and exit controls operate consistently.

Should internal audit use random or judgmental sampling for TPRM?

Most TPRM audits benefit from a combination. Judgmental selections cover critical, unusual, overdue, or exception-heavy relationships, while random selections from the remaining population reduce selection bias and reveal routine execution problems.

How many vendor assessments should internal audit test?

There is no universal number. Sample size should follow the audit function’s methodology and reflect the population, control frequency, risk, expected deviation, desired assurance, and whether results will be statistically projected.

What evidence should be retained for a vendor sample?

Retain the population source, selection rationale, procedures, criteria, documents examined, dates, results, exceptions, management responses, and conclusion. Another qualified reviewer should be able to understand and reperform the work.

When should testing be expanded?

Expand testing when exceptions indicate a possible systemic cause, such as incomplete inventory, workflow bypass, repeated expired evidence, inconsistent tiering, unauthorized risk acceptance, or the same control failure across a business unit.