This chapter covers vendor due diligence in security, a critical component of the Security Program Management domain under SY0-701 Objective 5.4. Vendor due diligence is the process of assessing and managing the risks associated with third-party vendors, suppliers, and partners before and during the engagement. This topic is heavily tested on the exam because supply chain attacks and third-party breaches are among the most impactful threats organizations face. You will learn the specific steps, documentation, and contractual safeguards required to perform effective vendor due diligence.
Jump to a section
Imagine you're hiring a contractor to build a new wing onto your house. You wouldn't just pick the cheapest ad from a flyer; you'd check their license, insurance, past work, and references. You'd ask about their subcontractors, their safety record, and whether they've ever been sued for shoddy work. That's due diligence. In security, your organization is the homeowner, and the vendor is a contractor building a digital wing—like a cloud service or a network appliance. The vendor's security posture is their license and insurance. A penetration test report is like a reference from a previous client. A right-to-audit clause in the contract is your right to inspect the work at any time without notice. If the contractor uses unlicensed electricians (subcontractors with poor security), your house could burn down—just as a vendor with weak security could lead to a data breach. The analogy is mechanistic because it mirrors the layered verification: you don't just trust a claim; you demand evidence (certifications, test results, contractual protections) and you verify through independent means (audits, assessments). Skipping this step is like hiring a contractor who says 'trust me' but has no track record—you're risking your house, or in security, your entire organization's data and reputation.
What is Vendor Due Diligence?
Vendor due diligence (VDD) is the systematic evaluation of a third party's security posture, financial stability, legal compliance, and operational practices before entering into a business relationship. The goal is to identify, quantify, and mitigate risks that the vendor could introduce to your organization. On the SY0-701 exam, vendor due diligence is a key part of supply chain risk management (SCRM) and is explicitly listed under Objective 5.4: Explain the importance of applicable regulations, standards, and frameworks that impact organizational security posture, including vendor due diligence.
The Threat: Supply Chain Attacks
Supply chain attacks exploit trust relationships between organizations and their vendors. A single compromised vendor can be a vector into multiple clients. Notable examples include the SolarWinds Orion attack (2020), where attackers inserted malicious code into software updates, affecting 18,000 customers including US government agencies. The attack leveraged a trusted vendor relationship—customers trusted the update because it came from a known supplier. Another example: the Target breach (2013) originated from a third-party HVAC vendor's compromised credentials, leading to theft of 40 million credit card numbers. These attacks underscore why vendor due diligence is not optional; it's a security imperative.
How Vendor Due Diligence Works Mechanically
The process typically follows a lifecycle:
Tiering and Categorization: Not all vendors pose the same risk. Vendors are categorized by the type and sensitivity of data they handle, their access to your network, and the criticality of their service. For example, a cloud email provider handling PII is high risk; a janitorial service is low risk (unless they have physical access to server rooms).
Questionnaire and Assessment: A security questionnaire (e.g., SIG, CAIQ) is sent to the vendor covering domains such as:
- Data encryption at rest and in transit (AES-256, TLS 1.2+) - Access controls (MFA, RBAC) - Incident response capabilities - Business continuity and disaster recovery (BC/DR) - Compliance with regulations (GDPR, HIPAA, PCI DSS) - Subcontractor management
Evidence Review: The vendor provides supporting documentation:
- SOC 2 Type II report (audited controls for security, availability, processing integrity, confidentiality, privacy) - Penetration test summary (must be recent, e.g., within 12 months) - ISO 27001 certificate - PCI DSS Attestation of Compliance (AOC) if handling cardholder data - FedRAMP authorization for cloud services used by US federal agencies
Independent Verification: The organization may perform its own technical testing, such as:
- External vulnerability scanning of vendor-facing systems (with permission) - Review of the vendor's security logs or SIEM data (if allowed) - On-site audit (for high-risk vendors)
Risk Scoring: Based on the assessment, a risk score is assigned (e.g., low, medium, high). High-risk vendors may require remediation plans or risk acceptance with executive sign-off.
Contractual Safeguards: The contract must include:
- Right-to-audit clause: the organization can audit the vendor's security controls at any time - Service Level Agreements (SLAs) for uptime and incident response times - Data protection addendum (DPA) specifying data handling, breach notification timelines (e.g., 72 hours for GDPR) - Insurance requirements (cyber liability insurance minimums) - Termination for cause if security standards are not met
Continuous Monitoring: Due diligence is not a one-time event. Ongoing monitoring includes:
- Periodic reassessments (annually or upon major changes) - Monitoring vendor security news (breaches, CVEs) - Automated vendor risk scoring platforms (e.g., BitSight, SecurityScorecard)
Key Components, Variants, and Standards
NIST SP 800-161 Rev 1: Supply Chain Risk Management Practices for Federal Information Systems and Organizations. This is the authoritative US government framework for vendor risk management.
ISO 28000: Supply chain security management systems.
Shared Assessments Program: Industry consortium providing the Standardized Information Gathering (SIG) questionnaire and the Vendor Risk Management Maturity Model (VRMM).
Cloud Security Alliance (CSA) CAIQ: Cloud-specific questionnaire.
GDPR Article 28: Requires data processors to provide sufficient guarantees to implement appropriate technical and organizational measures.
PCI DSS Requirement 12.8: For merchants, requires maintaining and implementing policies and procedures to manage service providers.
How Attackers Exploit Weak Due Diligence
Attackers target vendors because they often have weaker security than the primary organization. Common exploitation paths:
Credential Theft: Phishing a vendor employee to steal VPN credentials, then using them to access the client's network (e.g., Target breach).
Software Supply Chain: Compromising a vendor's software build environment to inject malware into updates (e.g., SolarWinds).
Physical Access: A vendor with physical access (e.g., cleaning crew) could insert a hardware keylogger or USB drop.
Data Aggregation: A vendor that aggregates data from multiple clients becomes a high-value target (e.g., cloud service provider breach).
Defensive Deployment: Practical Steps
Defenders should:
Create a Vendor Risk Management (VRM) policy that defines tiers, assessment frequency, and remediation timelines.
Use a VRM platform to automate questionnaires and scoring.
Require evidence of security controls (not just attestations). For example, ask for the actual penetration test report, not just a summary.
Perform technical validation: For a cloud vendor, test their API security; for a SaaS vendor, check their SSO implementation.
Include contractual teeth: Ensure the right-to-audit clause is exercisable and that breach notification timelines are contractually binding.
Real Command/Tool Examples
OpenVAS or Nessus: Can be used to scan vendor-hosted systems if permitted.
Nmap: To discover vendor attack surface (with permission).
Shodan: To check if vendor assets are exposed to the internet with known vulnerabilities.
Vendor Risk Platforms: BitSight, SecurityScorecard, and UpGuard provide external security ratings based on observed data (e.g., SSL/TLS strength, open ports, patch cadence). These platforms can continuously monitor vendors without direct access.
# Example using Shodan CLI to check vendor IP range
shodan search "org:VendorName" --fields ip_str,port,org,product# Example using nmap to scan a vendor's public web server
nmap -sV -p 443,80 --script ssl-enum-ciphers vendor.comSummary
Vendor due diligence is a multi-phase process that includes categorization, assessment, evidence review, independent verification, contractual safeguards, and continuous monitoring. The exam focuses on the key documents (SOC 2, ISO 27001, PCI DSS AOC), contractual clauses (right-to-audit, SLA, DPA), and the importance of supply chain risk management. Remember: due diligence is not just about checking boxes; it's about verifying that the vendor's security posture meets your organization's risk appetite.
Identify and Categorize Vendors
First, inventory all existing and potential vendors. Assign each vendor a risk tier based on data access, network connectivity, and criticality. For example, a cloud-based payroll provider handling PII and SSNs is high risk; a printer supply vendor with no data access is low risk. Use a standard risk matrix: likelihood vs. impact. This step is crucial because not all vendors require the same level of scrutiny. The exam tests that you can identify which vendors need due diligence—typically any vendor that handles sensitive data or has network access.
Send Security Questionnaire
Send a tailored security questionnaire to the vendor. Use industry-standard templates like the SIG or CAIQ for consistency. Questions should cover: encryption standards (AES-256, TLS 1.2+), access control (MFA, RBAC), incident response (detection, containment, notification), BC/DR (RTO/RPO), compliance (GDPR, HIPAA, PCI DSS), and subcontractor management. The vendor's responses are the first evidence of their security posture. On the exam, be prepared to identify which questionnaire is appropriate for a given scenario (e.g., CAIQ for cloud vendors).
Review Evidence and Certifications
Request supporting documentation: SOC 2 Type II report (audited controls), ISO 27001 certificate, PCI DSS AOC, penetration test report (within last 12 months), and business continuity plan. Review these for validity (e.g., SOC 2 report must be Type II, not Type I, and must cover the relevant trust services criteria). Check the date and scope—an outdated or narrow report is a red flag. The exam may ask what type of report to request (SOC 2 Type II) or what certification covers information security management (ISO 27001).
Perform Independent Verification
If the vendor is high risk, conduct your own technical testing. This could include external vulnerability scanning of the vendor's public-facing systems (with written permission), reviewing their security ratings from platforms like BitSight, or conducting an on-site audit. For cloud vendors, test their API endpoints for authentication flaws. For on-premises vendors, verify physical security controls. The goal is to validate the vendor's claims. The exam highlights that independent verification is a best practice, especially for high-risk vendors.
Contractual Safeguards and SLA
Ensure the contract includes: right-to-audit clause (allowing you to audit the vendor's security at any time), data protection addendum (DPA) specifying data handling and breach notification timelines (e.g., 72 hours for GDPR), SLA for uptime and incident response, and minimum cyber insurance requirements. Also include a termination clause for breach of security obligations. The exam tests that you know which contractual elements are essential, especially the right-to-audit and DPA.
Continuous Monitoring and Reassessment
Vendor due diligence is not a one-time event. Continuously monitor vendors through automated security rating services, news alerts, and periodic reassessments (annually or upon significant changes). If a vendor suffers a breach, reassess immediately. The exam expects you to understand that due diligence is an ongoing process, not a checkbox. A common scenario: a vendor changes their data center—this should trigger a reassessment.
Scenario 1: Cloud Email Provider Assessment
A medium-sized healthcare organization is migrating to a cloud email provider that will handle PHI (Protected Health Information). The security analyst sends the provider a SIG questionnaire. The provider returns it quickly, but the analyst notices that the answers about encryption are vague: 'We use industry-standard encryption.' The analyst requests the SOC 2 Type II report. The report shows that the provider uses AES-256 at rest and TLS 1.2 in transit, but the scope of the report does not include the email service itself—only their internal IT systems. This is a red flag. The analyst also runs an external scan of the provider's login portal using nmap and finds that TLS 1.0 is still enabled. The correct response: reject the provider or require remediation (disable TLS 1.0) and request a new SOC 2 report with the email service in scope. A common mistake: accepting the SOC 2 report at face value without checking scope and date. The analyst would use a tool like Nessus to scan the portal and review the SOC 2 report's scope section.
Scenario 2: Software Vendor Supply Chain Risk
A financial services firm uses a third-party software for trade reconciliation. The vendor releases a critical security patch. The firm's patch management team applies the patch within 24 hours. However, the vendor had been compromised, and the patch contained a backdoor (SolarWinds-like attack). The firm's due diligence should have included: (a) verifying the vendor's software build integrity (e.g., code signing, SBOM), (b) testing patches in a sandbox environment before production, and (c) contractual requirement for the vendor to disclose any security incidents. The correct response: implement a software bill of materials (SBOM) requirement in contracts, test patches in a staging environment, and use code signing verification. Common mistake: assuming that because the patch is from a trusted vendor, it's safe. The analyst would use tools like VirusTotal to scan the patch and check digital signatures.
Scenario 3: Third-Party Data Processor Breach Notification
A retailer's payment processor suffers a breach that exposes credit card numbers. The retailer's contract requires notification within 24 hours. The processor notifies after 72 hours, violating the SLA. The retailer's incident response team must: (a) activate their own incident response plan, (b) engage forensic investigators, (c) notify affected customers and credit card companies, and (d) assess legal liability. The correct response: enforce the contractual breach notification timeline and consider terminating the contract. A common mistake: relying solely on the processor's investigation without conducting an independent forensic analysis. The retailer's team would use their own SIEM to check for any indicators of compromise that may have flowed from the processor.
What SY0-701 Tests on Vendor Due Diligence
Objective 5.4 focuses on the importance of applicable regulations, standards, and frameworks that impact organizational security posture. Vendor due diligence is a subset of this objective. The exam will test:
Key documents: SOC 2 Type II (audited controls), ISO 27001 (ISMS), PCI DSS AOC (payment card data), FedRAMP (cloud for US federal), GDPR DPA (data processing).
Contractual clauses: Right-to-audit, SLA, DPA, breach notification timeline.
Supply chain risk management: The importance of vetting vendors, especially those with access to sensitive data or networks.
Continuous monitoring: Due diligence is ongoing, not a one-time event.
Common Wrong Answers and Why Candidates Choose Them
SOC 2 Type I instead of Type II: Candidates see 'SOC 2' and assume it's sufficient. But Type I is a point-in-time report; Type II covers a period (usually 6-12 months) and is more reliable. The exam will specify which type is needed.
Accepting a vendor's self-attestation without evidence: Candidates think a signed statement is enough. The exam emphasizes that independent verification (audit reports, penetration tests) is required.
Treating all vendors equally: Candidates fail to categorize vendors by risk. The exam will present a scenario with multiple vendors and ask which requires the most scrutiny—typically the one handling PII or with network access.
Assuming a certification (e.g., ISO 27001) covers all aspects: ISO 27001 certifies an ISMS, but it doesn't guarantee specific controls like encryption or incident response. The exam may ask what additional evidence is needed.
Specific Terms and Values
SOC 2: Type II, trust services criteria (security, availability, processing integrity, confidentiality, privacy).
ISO 27001: International standard for information security management.
PCI DSS: Requirement 12.8 for service provider management.
GDPR Article 28: Data processor obligations.
Right-to-audit clause: Allows the organization to audit the vendor.
SLA: Service Level Agreement, often includes uptime (e.g., 99.9%) and response times.
Common Trick Questions
Question asks for 'the best way to verify a vendor's security controls.' Wrong answer: 'Review their marketing materials.' Correct: 'Request a SOC 2 Type II report.'
Question asks for 'what should be included in a vendor contract.' Wrong answer: 'A list of all employees.' Correct: 'Right-to-audit clause and data protection addendum.'
Question asks for 'when should vendor due diligence be performed.' Wrong answer: 'Only when a breach occurs.' Correct: 'Before engagement and continuously.'
Decision Rule for Eliminating Wrong Answers
When faced with a vendor due diligence scenario question, eliminate any answer that:
Relies solely on the vendor's word (self-attestation, promises, marketing).
Uses a point-in-time report (SOC 2 Type I) when a period report (Type II) is available.
Ignores risk categorization (treating all vendors the same).
Proposes a one-time check instead of ongoing monitoring.
Omits contractual protections (right-to-audit, DPA, SLA).
Vendor due diligence is a multi-step process: categorize, assess, verify, contract, monitor.
Key documents: SOC 2 Type II, ISO 27001, PCI DSS AOC, FedRAMP authorization.
Essential contract clauses: right-to-audit, data protection addendum (DPA), SLA, breach notification timeline.
Due diligence is continuous, not one-time; monitor vendors via security ratings and periodic reassessments.
Supply chain attacks exploit trust; always verify vendor security independently.
Risk categorization: high-risk vendors (PII, network access) require the most scrutiny.
Common exam traps: confusing SOC 2 Type I vs Type II, accepting self-attestation, ignoring ongoing monitoring.
These come up on the exam all the time. Here's how to tell them apart.
SOC 2 Type II
Audited by a CPA firm
Covers specific trust services criteria (security, availability, etc.)
Report includes detailed test results and opinions
Valid for a period (typically 6-12 months)
Commonly requested for US-based service organizations
ISO 27001
Audited by an accredited certification body
Covers the entire ISMS (Information Security Management System)
Certificate indicates compliance with standard requirements
Valid for 3 years with surveillance audits
International standard, widely recognized globally
Mistake
A vendor's ISO 27001 certification guarantees their security controls are effective.
Correct
ISO 27001 certifies that an Information Security Management System (ISMS) exists and is followed, but it does not guarantee specific technical controls like encryption strength or patch cadence. Independent evidence such as a SOC 2 Type II report or penetration test is still needed.
Mistake
Vendor due diligence is only required for vendors that handle sensitive data.
Correct
While high-risk vendors need more scrutiny, all vendors should be assessed to some degree. Even a vendor with no data access could be a vector if they have physical access or network connectivity. The exam emphasizes a risk-based approach.
Mistake
A right-to-audit clause is optional and rarely exercised.
Correct
The right-to-audit clause is a critical contractual safeguard that allows the organization to verify the vendor's security posture at any time. It is not optional for high-risk vendors. The exam tests that this clause should be included.
Mistake
Once a vendor passes due diligence, no further checks are needed.
Correct
Due diligence is an ongoing process. Vendors' security postures can change (e.g., new vulnerabilities, acquisitions). Continuous monitoring through security ratings, reassessments, and news alerts is required. The exam emphasizes continuous monitoring.
Mistake
A SOC 2 Type I report is equivalent to a Type II report.
Correct
SOC 2 Type I evaluates controls at a single point in time; Type II evaluates the operational effectiveness of controls over a period (usually 6-12 months). Type II is more reliable and is what the exam expects for due diligence.
SOC 2 Type I reports on the design of controls at a specific point in time, while Type II reports on the operating effectiveness of controls over a period (usually 6-12 months). For vendor due diligence, Type II is preferred because it provides evidence that controls actually worked over time. The exam will test that Type II is the appropriate report to request.
A right-to-audit clause gives your organization the legal right to audit the vendor's security controls at any time, without prior notice. This is crucial because it allows you to independently verify that the vendor is maintaining the agreed-upon security posture. Without it, you rely solely on the vendor's self-reporting, which may be incomplete or inaccurate.
A DPA is a legally binding document that outlines how a vendor (data processor) will handle, protect, and process your organization's data. It is required when the vendor will process personal data, especially under regulations like GDPR or CCPA. The DPA specifies data handling, breach notification timelines, and subprocessor management. It should be included in every vendor contract involving sensitive data.
Vendor due diligence should be performed initially before engaging with the vendor, and then continuously or at least annually thereafter. Additionally, reassessment should occur when there are significant changes, such as a vendor merger, acquisition, data center relocation, or after a security incident. Continuous monitoring via security rating services can supplement periodic reassessments.
A VRM platform (e.g., BitSight, SecurityScorecard, UpGuard) automates the collection and analysis of vendor security data. It provides external security ratings based on observed data (e.g., SSL/TLS strength, open ports, patch cadence) and can send questionnaires, track remediation, and generate reports. These platforms help organizations scale vendor due diligence across many vendors.
Look for the scope (what systems were tested), the methodology (e.g., OWASP Top 10, NIST), the date (should be within the last 12 months), the findings (both critical and high), and the remediation status. Ensure the test was performed by a reputable third party, not the vendor's internal team. Also check that the report includes evidence of remediation for any critical findings.
PCI DSS Requirement 12.8 mandates that merchants and service providers maintain policies and procedures to manage service providers with access to cardholder data. This includes: (a) maintaining a list of service providers, (b) ensuring a written agreement that includes acknowledgment of security responsibilities, (c) establishing a process for due diligence, (d) monitoring the service provider's PCI DSS compliance status, and (e) maintaining information about which service providers are compliant. This is a key exam point.
You've just covered Vendor Due Diligence in Security — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?