A Resolver vendor approval does not approve every engagement
Resolver describes a repository that can hold one vendor with several service engagements and says each engagement receives its own evaluation. Buyers should preserve separate intake, vendor, engagement, evidence, condition, approval, and reassessment records so a decision about one service is not silently reused for another.
Third Party Current editorial graphic. Source material: Resolver Third-Party Risk Management; analysis and presentation by Third Party Current.
Name the object before approving it
The direct answer is that a vendor approval should identify exactly what was approved. Resolver's product page distinguishes the vendor repository from the engagements associated with a vendor and says a single vendor can provide several unique services. That distinction matters because a legal entity may deliver a payroll service, a hosted application, a consulting engagement, and a hardware product under different contracts, data flows, locations, subcontractors, recovery dependencies, and control environments.
Preserve the legal entity, parent and affiliate relationships, product or service, business owner, contract, order or statement of work, purpose, users, information types, access method, integration, hosting and processing locations, facilities, fourth parties, transaction volume, critical process supported, start and end dates, and requested decision. A provider identity can organize those records, but it should not become the decision object when the material exposure arises from one bounded engagement.
Keep intake permission separate from risk acceptance
Resolver says a member of the business can submit a request for a vendor risk assessment and, if approved, the vendor-risk team submits a questionnaire. Those are useful workflow stages, but the first approval may mean only that the request is sufficiently defined to enter review. Record who approved intake, the criteria used, what information remained missing, the assessment route selected, and any spend or sourcing authorization separately from the later conclusion about inherent risk, control evidence, residual risk, contract conditions, and accountable acceptance.
Use explicit states such as request received, scope incomplete, intake approved, assessment issued, evidence received, clarification open, control gap confirmed, mitigation proposed, contract condition pending, engagement approved with conditions, rejected, expired, and reassessment due. A completed questionnaire or a vendor category should not advance every engagement automatically. If a business owner changes the service, integration, location, data set, criticality, or subcontracting model during review, preserve the prior scope and route the change through an impact decision.
Bind evidence and conditions to the evaluated service
Resolver describes custom questionnaires, certifications, risk assessments, mitigation plans, documents, reporting, and vendor collaboration. Each material answer and artifact should retain the vendor and engagement identifiers, author, source, version, capture date, covered entity, service, location and period, reviewer, finding, and disposition. A certificate for a parent company, a disaster-recovery plan for another product, or a policy that excludes the contracted location may be relevant context without supporting the engagement being evaluated.
Conditions require the same precision. Link a required contract clause, technical restriction, compensating control, remediation task, insurance obligation, continuity test, or monitoring rule to the engagement and decision that created it. Preserve the owner, deadline, evidence required for closure, approval authority, expiry, and consequence of noncompletion. Closing an action should not rewrite the original exception or silently broaden the approval to another service.
Test one vendor with two materially different services
A representative evaluation should create one vendor with two engagements: a low-data advisory service and a critical hosted application that processes sensitive information through a subcontractor. Reuse one corporate artifact, provide a product-specific report for only the hosted service, change an integration after assessment, approve the advisory work, and hold the hosted service pending a contract condition. Reviewers should reconstruct both scopes, evidence packages, exceptions, decisions, conditions, and reassessment triggers without the first approval turning the second engagement green.
Resolver's official page supports the attributed positioning about vendor requests, questionnaires, a categorized repository, multiple engagements per vendor, unique engagement evaluation, documents, risk assessments, mitigation workflows, and reporting. It does not establish a customer's entity model, scope completeness, questionnaire quality, evidence sufficiency, risk method, control operation, approval authority, contract protection, monitoring coverage, resilience, or outcome. Third-party-risk, procurement, security, privacy, continuity, business, compliance, audit, finance, and legal owners retain those decisions.
What we will watch next
Third Party Current will watch for later primary-source evidence that changes the maintained company, capability, or standards record. The next useful evidence may include implementation documentation, release details, regulator findings, corrected methods, product packaging, customer-observable workflow, or a subsequent company statement. Until then, the dated source and its stated boundary remain attached to this analysis.
