An audit or incident is a bad time to discover that a critical vendor handles more data than expected, relies on an unreviewed subprocessor, or presented assurance evidence that did not cover the service you bought.
A repeatable vendor risk assessment helps surface those issues earlier. It should answer three questions: what risk does the relationship introduce, does the available evidence address that risk and scope, and what must be monitored after approval?
| Checklist trap | Risk-based assessment |
|---|---|
| Same review for every vendor | Depth based on inherent risk |
| Certification logo accepted alone | Scope and assurance evidence reviewed |
| Assessment ends at approval | Periodic and event-driven monitoring |
| Completion treated as assurance | Review decisions and evidence recorded |
1. Establish the Relationship and Scope
Start by documenting what the vendor will provide and what it may access. The assessment cannot be proportionate if the relationship is unclear.
Record:
- Service and business owner
- Data types, classifications, and volumes involved
- System, network, or privileged access
- Business criticality and recovery dependency
- Processing locations and relevant legal requirements
- Subprocessors or other material fourth parties
- Contract term, renewal date, and exit dependencies
This becomes the scope against which evidence and controls are evaluated.
2. Assign an Inherent-Risk Tier
Not every vendor requires the same depth of review. Assign a tier using the potential impact before considering the vendor's controls. Relevant factors can include data sensitivity, access level, business criticality, substitutability, regulatory exposure, processing location, and downstream dependencies.
The following is an illustrative model; each organization should define its own criteria and thresholds.
| Illustrative tier | Potential profile | Possible review depth |
|---|---|---|
| High | Sensitive data, privileged access, or critical dependency | Detailed assurance review, targeted evidence, contract controls, subprocessor review |
| Medium | Limited data or operational dependency | Questionnaire, selected evidence, contract review, scheduled reassessment |
| Low | No material data or system access and low operational impact | Proportionate intake, screening, and change-based review |
Spend may inform business criticality, but it should not replace an impact assessment. A low-cost service can still create material security or operational risk.
3. Review Assurance Evidence for Scope and Period
When a vendor provides a SOC 2 report or ISO 27001 certificate, confirm what it actually covers rather than relying on the logo.
For a SOC 2 report, review the system description, included categories, report type, specified date or review period, auditor's opinion, complementary user entity controls, subservice organizations, and relevant test exceptions. For an ISO/IEC 27001 certificate, review the certified entity, ISMS scope, certificate validity, certification body, and whether the service or location relevant to your engagement is included.
| Evidence question | Why it matters |
|---|---|
| Is the service and legal entity in scope? | Assurance over another service or entity may not address the engagement |
| Type I or Type II? | Type I addresses design at a date; Type II also addresses operation over a period |
| Which categories or ISMS boundaries apply? | Coverage must match the risks being assessed |
| What period or validity dates apply? | The evidence must be interpreted within its stated dates |
| Are subservice organizations involved? | Relevant control responsibilities may sit downstream |
Existing evidence can often support more than one review when its limitations are documented. See how to map one evidence base across SOC 2 and ISO 27001.
4. Test the Risks That Matter to the Engagement
A certification or report is useful evidence, but it may not answer every engagement-specific question. Compare the vendor's evidence with the risks in scope.
Depending on the service, that may include:
- Identity, access, and privileged-account management
- Encryption and key management
- Incident detection, response, and contractual notification
- Availability, resilience, backup, and recovery
- Data retention, deletion, and return
- Secure development and change management
- Subprocessor governance
- Vulnerability management and security testing
Where evidence is missing or does not match the engagement, record the gap and choose a response: request more evidence, add a contractual control, apply a compensating control, escalate for risk acceptance, limit the use case, or reject the relationship.
For evidence-backed customer and vendor questions, see Fill a Security Questionnaire From Your Own Evidence.
5. Record the Decision and Required Actions
An assessment should leave a reviewable record, not only a completed questionnaire. Record the risk tier, evidence reviewed, identified gaps, required remediation, compensating controls, decision owner, approval, reassessment cadence, and any conditions attached to the relationship.
Separate facts from decisions. The report or certificate is evidence; accepting the residual risk is a human decision.
Compass by Truvara supports that separation by keeping vendor context connected to relevant risks, controls, policies, and evidence, then preparing source-linked proposals for a reviewer to accept, edit, or reject.
6. Monitor on a Risk-Based Cadence and on Change
Approval establishes a baseline. Monitoring should then reflect the vendor's risk and the terms of the relationship. Higher-risk or critical relationships may justify more frequent review than lower-risk vendors.
Useful triggers include:
- Certificate expiry or a new assurance report
- Material incident or control failure
- Change in service, data use, access, or processing location
- Addition of a material subprocessor
- Significant contract or ownership change
- Repeated service failure or missed remediation
Monitoring normally continues while the relationship and its risks remain active. At termination, confirm access revocation, data return or deletion, retained obligations, and any required transition controls.
The Takeaway
A vendor risk assessment is a scoped, risk-based decision process. Define the relationship, assign inherent risk, review assurance evidence within its actual scope and dates, test engagement-specific risks, document the decision, and monitor material change.
FAQ
What is a vendor risk assessment?
A documented review of the inherent risk a vendor introduces, the evidence and controls that reduce that risk, and the residual-risk decision governing the relationship.
How should assessment depth be determined?
Use risk factors such as data sensitivity, access, criticality, substitutability, regulatory exposure, location, and downstream dependencies. Do not use contract value alone.
Is a SOC 2 report or ISO 27001 certificate sufficient?
It can provide valuable assurance, but only within its stated entity, system, scope, categories, dates, and limitations. Engagement-specific risks may require additional review.
When does vendor monitoring end?
Risk-based monitoring continues while the relationship remains active. Termination should trigger access, data-disposition, contractual, and transition checks.