SecureLayer
The contract is ready. The vendor demo was impressive. The business team wants to sign this week. Then someone asks: "Has security reviewed this?"
This is the moment that determines whether vendor security assessment is a real process or a rubber stamp. A vendor risk assessment conducted properly before the contract is signed identifies security gaps, establishes contractual protections, and prevents your organisation from inheriting risks that surface months later as data breaches, compliance failures, or operational disruptions.
A vendor risk assessment conducted after the contract is signed is damage control, not risk management.
Every vendor with access to your data, systems, or network introduces cybersecurity risk that you own. A supply chain breach through a vendor is your breach. Your customers, your regulators, and your board don't distinguish between "we were breached" and "our vendor was breached." The liability and reputational damage are yours.
This guide provides the complete vendor risk assessment process: what to assess, how to assess it, the security questionnaire that reveals real posture, the red flags that should stop a deal, and the checklist that ensures nothing gets missed. For the broader programme framework, see our third-party risk management guide.
When to Conduct a Vendor Risk Assessment
Before Contract Signing
The assessment must happen before you sign. After signing, your leverage disappears. Before signing, you can require security improvements, negotiate contractual protections, or choose an alternative vendor. After signing, you're locked in.
Before Granting Access
Some vendor relationships don't start with a formal contract (trial periods, freemium tools adopted by teams). Assess before granting data access regardless of contract status.
At Contract Renewal
Vendor security changes over time. Renewal is the opportunity to reassess and renegotiate security terms. Review current compliance certifications, recent penetration testing reports, and any incidents since the last assessment.
After Vendor Changes
Vendor acquisition, leadership changes, major platform migrations, or security incidents should trigger reassessment regardless of the contract cycle.
The Vendor Risk Assessment Process
Step 1: Classify the Vendor's Risk Tier
Not every vendor needs the same assessment depth. Classify based on data sensitivity, system access, and business criticality.
Tier 1 (Critical). Vendor stores or processes sensitive data (PII, financial, health, IP). Has production system access. Business operations depend on the vendor. Replacement would take months.
Tier 2 (High). Vendor accesses internal systems or handles some personal data. Important to operations but replaceable within weeks.
Tier 3 (Medium). Vendor has limited data access. Non-critical function. Multiple alternatives available.
Tier 4 (Low). No data access. No system connectivity. Commodity service.
Risk TierAssessment MethodTimelineCriticalFull questionnaire + evidence review + pentest report + architecture review3 to 4 weeksHighDetailed questionnaire + SOC 2/ISO review + insurance verification2 to 3 weeksMediumStandard questionnaire + certification verification1 to 2 weeksLowMinimal or no assessmentImmediate
Step 2: Issue the Vendor Security Questionnaire
The security questionnaire is your primary assessment tool. It should be comprehensive enough to reveal real posture but focused enough that vendors complete it accurately.
Step 3: Review Evidence
Questionnaire responses are claims. Evidence validates them. Request and review supporting documentation for critical assertions.
Evidence to request:
SOC 2 Type II report (covers the past audit period, not just a point in time). ISO 27001 certificate with scope statement. Most recent penetration testing report (evaluate scope, methodology, findings, remediation). Cyber insurance certificate of coverage. Business continuity and disaster recovery test results. Incident response plan. Data processing agreement. Architecture diagram showing how your data is handled.
Step 4: Evaluate Penetration Testing Evidence
Reviewing the vendor's penetration testing report is one of the highest-value steps in vendor assessment. See our penetration testing reports guide for what quality looks like.
What to evaluate:
Recency. Was testing conducted within the past 12 months? Testing older than 12 months provides limited assurance.
Scope. Did testing cover the systems that process your data? A vendor that tested only their marketing website while your data lives in their API platform has a scope gap.
Methodology. Was testing conducted by a qualified provider? CREST certification indicates quality. Was manual testing conducted, or was it just automated scanning? See our evaluating testing quality guide.
Findings. Were critical and high findings remediated? Was retesting conducted to verify fixes? Are there open findings? What's the remediation timeline?
Testing types. Did the vendor conduct web application testing, API testing, cloud testing, and network testing appropriate to their architecture?
Step 5: Assess Risk and Make a Decision
Rate the vendor's overall security posture based on questionnaire responses and evidence review.
Step 6: Negotiate Contractual Protections
Assessment findings inform contract terms. See the contractual controls section below.
The Vendor Security Questionnaire
Section 1: Security Governance
- Does your organisation have a dedicated CISO or security leader?
- Is there a documented information security policy reviewed within the past 12 months?
- Do you conduct security awareness training for all employees? How frequently?
- Do you have a formal risk management programme?
- Do you carry cyber insurance? What are the coverage limits?
Red flags: No dedicated security leadership. Policies not updated in 2+ years. No employee security training.
Section 2: Compliance and Certifications
- Which compliance certifications do you maintain? (SOC 2, ISO 27001, PCI DSS, HITRUST, others)
- Please provide your most recent SOC 2 Type II report.
- Please provide your ISO 27001 certificate with scope statement.
- Are there any outstanding audit findings? If so, provide remediation timelines.
- Have you been subject to any regulatory enforcement actions in the past 3 years?
Red flags: No SOC 2 or ISO 27001 for a critical vendor handling sensitive data. Expired certifications without renewal timeline. Outstanding critical audit findings.
For compliance context, see our penetration testing compliance guide.
Section 3: Technical Security Controls
- Is MFA enforced for all employee and administrative access?
- Describe your encryption approach for data at rest and in transit.
- How do you manage privileged access (PAM)?
- Describe your patch management programme and SLAs by severity.
- Do you have endpoint detection and response (EDR) deployed?
- Describe your network segmentation approach.
- How do you manage secrets (API keys, credentials, encryption keys)?
Red flags: MFA not enforced. No encryption at rest. No PAM. Patch SLAs undefined or not tracked.
Section 4: Data Handling
- Where is our data stored geographically?
- Who within your organisation has access to our data?
- How is our data isolated from other customers' data?
- What is your data retention policy?
- Describe the process for returning and deleting our data upon contract termination.
- Do you use our data for any purpose beyond providing the contracted service (analytics, model training, etc.)?
- Do any subcontractors or fourth parties access or process our data?
Red flags: Data location unknown. No tenant isolation for multi-tenant platforms. No data deletion process. Data used beyond contracted purposes without consent. Undisclosed fourth-party processing.
Section 5: Security Testing
- When was your most recent penetration test? Please provide the report.
- Who conducted the testing? Are they CREST certified?
- What was the testing scope? (Web application, API, cloud, network, mobile)
- Were all critical and high findings remediated? Was retesting conducted?
- How frequently do you conduct penetration testing?
- Do you conduct vulnerability assessments? How frequently?
Red flags: No penetration testing ever conducted. Testing older than 12 months. Testing by non-qualified provider. Unresolved critical findings. Testing scope doesn't cover systems handling your data.
Section 6: Incident Response
- Do you have a documented incident response plan?
- When was the plan last tested (tabletop exercise)?
- What is your breach notification timeline for customer-affecting incidents?
- Describe any security incidents affecting customer data in the past 3 years.
- Do you have forensic investigation capability (internal or retained)?
Red flags: No incident response plan. Plan never tested. Breach notification timeline exceeding 72 hours. Undisclosed breach history.
Section 7: Business Continuity
- Describe your backup strategy and testing cadence.
- Do you have geographic redundancy for critical systems?
- What are your recovery time (RTO) and recovery point (RPO) objectives?
- When was your disaster recovery plan last tested?
Red flags: Backups not tested. Single-region deployment for critical services. RTO/RPO undefined.
Section 8: Application Security
- Do you follow a secure development lifecycle (SDLC)?
- Do you conduct static and dynamic application security testing?
- How do you manage open-source dependency vulnerabilities?
- Do you conduct code reviews with security focus?
Red flags: No SDLC. No application security testing in development. No dependency scanning.
Vendor Risk Assessment Checklist
Pre-Assessment
- Vendor classified by risk tier (critical, high, medium, low)
- Appropriate questionnaire selected for risk tier
- Questionnaire issued to vendor with response deadline
- Business owner identified for the vendor relationship
- Assessment timeline communicated to procurement
Evidence Review
- SOC 2 Type II report reviewed (scope, exceptions, findings)
- ISO 27001 certificate verified (scope, expiration, surveillance audits)
- PCI DSS attestation reviewed (if processing payment data)
- Penetration testing report reviewed (scope, recency, methodology, findings)
- Cyber insurance certificate reviewed (coverage limits, exclusions)
- Business continuity/DR test results reviewed
- Data processing agreement reviewed
- Architecture diagram reviewed (data flow, storage, access)
Security Controls Verification
- MFA enforcement confirmed
- Encryption at rest confirmed with key management approach
- Encryption in transit confirmed (TLS 1.2+)
- Privileged access management confirmed
- Patch management SLAs defined and tracked
- EDR deployment confirmed
- Network segmentation confirmed
- Secrets management approach validated
Data Handling Assessment
- Data storage locations identified and acceptable
- Tenant isolation mechanism confirmed (for multi-tenant)
- Data access restricted to authorised personnel
- Data retention policy defined and acceptable
- Data return and deletion process confirmed
- Subcontractor/fourth-party processing disclosed and assessed
- Data usage limited to contracted purposes
Incident and Continuity Assessment
- Incident response plan current and tested
- Breach notification timeline acceptable (72 hours or less)
- Breach history disclosed and reviewed
- Backup strategy adequate with tested restoration
- RTO/RPO defined and acceptable for your needs
- Geographic redundancy adequate
Risk Decision
- Overall risk rating assigned (strong, adequate, weak, unacceptable)
- Risk findings documented with evidence
- Business decision documented (approve, approve with conditions, reject)
- Compensating controls defined for accepted risks
- Risk acceptance signed by appropriate authority
Contractual Controls
- Security requirements clause included
- Data handling and privacy clause included
- Breach notification clause with defined timeline
- Right-to-audit clause included
- Compliance maintenance requirement included
- Subcontractor approval clause included
- Data return and deletion clause included
- Liability and indemnification clause included
Post-Assessment
- Assessment results documented and stored
- Reassessment date scheduled (annual for critical/high)
- Continuous monitoring activated (breach alerts, certification tracking)
- Vendor added to TPRM inventory with all metadata
- Business owner notified of assessment results and conditions
Vendor Assessment for Specific Contexts
SaaS Vendor Assessment
SaaS vendors host your data in multi-tenant environments. Focus assessment on tenant isolation, API security, data encryption and residency, SSO/MFA support, and compliance certifications. See our SaaS compliance readiness guide.
Cloud Service Provider Assessment
Shared responsibility means assessing what the provider secures and what you must secure. Focus on compliance certifications, incident notification, data residency, encryption key management, and IAM capabilities.
Financial Services Vendor Assessment
Financial regulators expect rigorous vendor assessment. OCC, FFIEC, and NYDFS have specific vendor management expectations. MAS TRM requires assessment of outsourced services. See our financial services testing criteria.
Healthcare Vendor Assessment
HIPAA requires Business Associate Agreements with vendors processing ePHI. Assess HIPAA compliance, encryption, access controls, breach notification, and BAA terms. See our healthcare penetration testing guide.
M&A Vendor Assessment
During due diligence, the target company's vendors become your vendors. Assess the target's vendor inventory, TPRM programme maturity, critical vendor contracts, and inherited vendor risks. See our M&A pentesting guide and cybersecurity due diligence guidance.
When to Require Independent Penetration Testing
Of the Vendor's Product
For critical vendors, reviewing the vendor's own pentest report may not be sufficient. Exercise your right-to-audit clause to commission independent penetration testing of the vendor's platform.
When to require it: The vendor has no pentest report. The vendor's report scope doesn't cover the systems handling your data. The vendor's report is from a non-qualified provider. Your data sensitivity warrants independent validation.
Of Your Integration Points
Regardless of vendor assessment, your integration with the vendor creates attack surface. API penetration testing of integration endpoints, authentication testing at boundaries, and data flow validation should be part of your own security testing programme.
Common Vendor Assessment Mistakes
Accepting the questionnaire at face value. Vendors self-report favourably. Always request evidence (SOC 2 reports, pentest reports, certificates) to validate claims.
Skipping the pentest report review. The penetration testing report is the most revealing document a vendor provides. It shows what an independent security expert found. Skipping this review misses the most objective security evidence available.
Assessing once at onboarding, never again. Vendor security degrades over time. Annual reassessment for critical vendors is the minimum. See our how often to test guide.
No contractual enforcement. Assessment without contractual clauses is advisory. The vendor has no legal obligation to maintain the security posture you assessed. Every finding should map to a contractual requirement.
Ignoring the vendor's vendors. Fourth-party risk is real. Your critical vendor's insecure subcontractor creates risk you didn't assess and may not know about.
Letting urgency override due diligence. "We need this signed by Friday" is not a security assessment methodology. A vendor onboarded without assessment creates unmanaged risk that persists for the contract duration.
How AppSecure Supports Vendor Risk Assessment
AppSecure provides the security testing that validates vendor security and protects your integration boundaries.
Independent Vendor Testing. When right-to-audit clauses permit, AppSecure conducts independent penetration testing of vendor products, providing objective security evidence beyond vendor self-assessment.
Integration Security Testing. API penetration testing of vendor integration endpoints validates authentication, authorisation, data handling, and error handling at every boundary. Web application testing of vendor-facing portals ensures your systems are secure.
Your Security Posture. Vendors assess your security just as you assess theirs. Comprehensive testing of web applications, APIs, cloud, networks (external and internal), and mobile applications strengthens your position in vendor assessments.
Application security assessment and offensive security testing for comprehensive coverage. Compliance-mapped reports serving SOC 2, ISO 27001, and PCI DSS.
Zero False Positives. 3-Week Delivery. 90-day support. Complimentary retesting. Continuous testing and PTaaS for ongoing validation.
Contact AppSecure:
Frequently Asked Questions
1. What is a vendor risk assessment?
A vendor risk assessment is the process of evaluating a third-party vendor's cybersecurity posture before granting them access to your data, systems, or network. It evaluates security governance, technical controls, data handling practices, compliance certifications, incident response capability, business continuity, and penetration testing evidence. The assessment determines whether the vendor's security is adequate for the risk they introduce and informs contract terms, compensating controls, and ongoing monitoring requirements.
2. When should a vendor risk assessment be conducted?
Before signing the contract (this is when you have maximum leverage). Before granting any data or system access. At contract renewal (reassess current posture, renegotiate terms). After vendor changes (acquisition, leadership, platform migration, security incident). Annually for critical and high-risk vendors. Assessment timing matters: conducting assessment after the contract is signed turns risk management into damage control.
3. What should a vendor security questionnaire cover?
A comprehensive questionnaire covers security governance (leadership, policies, training), compliance (certifications, audit findings), technical controls (MFA, encryption, patching, EDR, segmentation), data handling (storage location, isolation, retention, deletion), security testing (penetration testing, vulnerability assessment), incident response (plan, testing, notification timeline, breach history), business continuity (backups, DR testing, RTO/RPO), and application security (SDLC, dependency management).
4. How do I evaluate a vendor's penetration testing report?
Evaluate recency (within 12 months), scope (covers systems processing your data), methodology (industry-standard, manual testing included), tester qualifications (CREST certified or equivalent), findings severity (were critical and high findings found?), remediation (were findings fixed and retested?), and testing types (appropriate to vendor's architecture: web, API, cloud, network). A vendor that tested only one system while your data sits in another has a scope gap.
5. What are the biggest red flags in vendor security assessment?
No penetration testing ever conducted. No SOC 2 or ISO 27001 for a vendor handling sensitive data. MFA not enforced. No dedicated security leadership. Undisclosed breach history. Unresolved critical vulnerabilities from penetration testing. No incident response plan. Data location unknown. No tenant isolation in multi-tenant platforms. Expired compliance certifications without renewal timeline. Each red flag should be addressed before contract signing or accepted with documented compensating controls.
6. What contractual protections should I negotiate?
Minimum security control requirements, data handling and privacy obligations, breach notification within 72 hours, right to audit the vendor's security, compliance certification maintenance, subcontractor notification and approval, data return and deletion on termination, and liability and indemnification for security incidents. Without contractual requirements, your assessment findings are unenforceable suggestions.
7. How does vendor risk tiering work?
Tier vendors by data sensitivity, system access, business criticality, and replaceability. Critical vendors (sensitive data, production access) receive full assessment with evidence review and potentially independent testing. High vendors receive detailed questionnaire and compliance review. Medium vendors receive standard questionnaire. Low vendors receive minimal assessment. Tiering focuses resources on the vendors that create the most risk. Not every vendor needs the same depth.
8. Should I require independent penetration testing of vendor products?
For critical vendors where your data is highly sensitive, the vendor has no existing pentest report, the vendor's report doesn't cover systems handling your data, or the vendor's testing quality is questionable: yes. Exercise your right-to-audit clause and commission independent testing. For high vendors with current, quality pentest reports from qualified providers: reviewing their existing report is usually sufficient.
9. How do I handle vendors that refuse to provide security evidence?
If a critical vendor refuses to provide SOC 2 reports, pentest reports, or security questionnaire responses, treat this as a major red flag. Options include escalating the request through the vendor's security or compliance team, accepting limited evidence with compensating controls and enhanced monitoring, choosing an alternative vendor with better transparency, or accepting the risk with formal documentation and executive sign-off. A vendor unwilling to demonstrate security may have security they can't demonstrate.
10. How often should vendor assessments be repeated?
Critical vendors: annually with continuous breach monitoring. High vendors: annually. Medium vendors: every two years or at contract renewal. All vendors: immediately upon breach notification, acquisition, significant infrastructure change, or leadership change. The reassessment should review updated evidence (current SOC 2 report, recent pentest report, current certifications) against the same criteria used for initial assessment. Track improvement or degradation over time.