This chapter covers third-party risk in the context of security architecture, a critical topic for SY0-701 Objective 3.2. Third parties—vendors, suppliers, partners, and service providers—introduce vulnerabilities that can undermine even the most secure internal architecture. Understanding how to assess, contract, and monitor these relationships is essential for the exam and for real-world enterprise security. We'll explore vendor due diligence, contractual controls, supply chain risks, and the shared responsibility model.
Jump to a section
Imagine you own a high-rise construction company. You hire a subcontractor to install the building's fire suppression system. You trust that they follow local building codes, use certified materials, and test the system before you sign off. But you don't just hand them the keys and walk away. You require them to provide proof of insurance, you inspect their work at key milestones, and you keep a copy of their installation diagrams. If a fire later reveals that a sprinkler head was faulty, you're liable—not just the subcontractor. That's third-party risk. In cybersecurity, you outsource services like cloud hosting, payroll processing, or vulnerability scanning. The vendor has access to your data or network. If they suffer a breach, you're the one facing fines, lawsuits, and reputational damage. So you perform due diligence (reviewing their security certifications like SOC 2 or ISO 27001), you include contractual safeguards (data protection clauses, right to audit), and you monitor them continuously (reviewing their security reports, conducting penetration tests). Just like the building owner, you can't outsource responsibility—only the work.
What Is Third-Party Risk?
Third-party risk refers to the potential for an organization to suffer harm—financial loss, data breach, regulatory penalty, or reputational damage—due to the actions or inactions of an external entity that has access to its systems, data, or facilities. In SY0-701, this falls under 'Security Architecture' because third parties are a component of the overall enterprise architecture. The risk is not just about malicious vendors; it includes accidental misconfigurations, inadequate security practices, or even a vendor's own breach that cascades to you.
The Shared Responsibility Model
A foundational concept is the shared responsibility model, most commonly associated with cloud services. In this model, the cloud provider is responsible for security 'of' the cloud (physical security, hypervisor, network infrastructure), while the customer is responsible for security 'in' the cloud (data, access management, configuration). For example, in AWS, the customer must configure S3 bucket permissions correctly; a misconfiguration—not AWS's fault—can expose data. The exam tests this distinction: know that the customer always retains responsibility for data classification, identity and access management, and encryption of data in transit and at rest. For SaaS, the provider handles more, but the customer still manages user access and data sharing settings.
Vendor Due Diligence
Before engaging a third party, perform due diligence to assess their security posture. This includes: - Security Questionnaires: Standardized forms (e.g., SIG, CAIQ) asking about policies, certifications, incident response, encryption, etc. - Certifications and Audits: Look for SOC 2 Type II (service organization controls), ISO 27001 (ISMS), PCI DSS (if handling payment data), FedRAMP (for U.S. government). These provide independent validation. - Penetration Test Reports: Some vendors share recent pentest summaries. Review the scope, findings, and remediation timelines. - Background Checks: For critical vendors, check financial stability, legal issues, and history of breaches. - On-Site Assessments: For high-risk vendors, visit their facilities to observe physical security and operations.
Contractual Controls
Contracts are the primary tool to enforce security requirements. Key clauses include: - Data Protection Addendum (DPA): Specifies how data must be handled, stored, and protected. Often required by GDPR, CCPA. - Right to Audit: Allows you to audit the vendor's security controls at any time (or upon notice). - Service Level Agreements (SLAs): Define uptime, response times, and penalties for non-compliance. - Breach Notification: Requires the vendor to notify you within a specific time (e.g., 24-72 hours) after discovering a breach. - Data Return and Destruction: Upon contract termination, the vendor must return or securely delete your data. - Insurance Requirements: Mandate minimum cyber liability insurance coverage (e.g., $5 million). - Sub-processors: The vendor must disclose and get approval for any subcontractors they use.
Supply Chain Risk
Supply chain attacks target less-secure vendors to compromise their customers. Notable examples: SolarWinds (2020) where attackers inserted malicious code into Orion software updates, affecting 18,000 customers including U.S. government agencies. Kaseya (2021) where REvil ransomware exploited a vulnerability in VSA remote management software. To mitigate: - Software Bill of Materials (SBOM): A list of all components in a software product. Review for known vulnerabilities. - Vendor Risk Management (VRM) Program: A continuous process of assessing, monitoring, and remediating vendor risks. - Minimum Viable Security Standards: Define baseline requirements all vendors must meet (e.g., MFA, encryption, logging). - Third-Party Penetration Testing: Engage external testers to evaluate vendor security.
Continuous Monitoring
Due diligence is not a one-time event. Continuously monitor vendors through: - Security Scorecards: Services like BitSight, SecurityScorecard rate vendors based on external data (open ports, SSL/TLS configs, spam reputation). - Automated Questionnaires: Tools like Whistic, OneTrust automate assessment distribution and tracking. - Periodic Reassessments: Annual or bi-annual reviews, or triggered by major changes (acquisition, breach). - Threat Intelligence Feeds: Monitor for mentions of your vendors in breach databases, dark web forums.
Third-Party Access Controls
Limit vendor access to only what is necessary: - Least Privilege: Grant minimal permissions (e.g., read-only, specific IP ranges). - Time-Bound Access: Use temporary credentials or Just-in-Time (JIT) access that expires. - Network Segmentation: Place vendor systems in a separate VLAN with strict firewall rules. - Multi-Factor Authentication (MFA): Require MFA for any vendor accessing your systems. - Privileged Access Management (PAM): For vendors needing admin rights, use PAM solutions that rotate passwords and record sessions.
Incident Response Coordination
Include vendors in your incident response plan. Establish communication channels, define escalation paths, and conduct joint tabletop exercises. During a breach, you need to quickly determine if the vendor is the source.
Regulatory and Legal Considerations
Different regulations impose specific third-party obligations: - GDPR: Article 28 requires a written contract with data processors, and the controller must ensure the processor provides sufficient guarantees. - HIPAA: Business Associate Agreements (BAAs) are required with any vendor handling PHI. - PCI DSS: Requirement 12.8 mandates that service providers are assessed annually. - NIST SP 800-53 Rev. 5: Provides controls for supply chain risk management (e.g., SR-1 through SR-12).
Common Tools and Commands
While SY0-701 is conceptual, knowing relevant tools helps:
- Nmap: Scan vendor external IPs for open ports and services. Example: nmap -sV -p 1-65535 <vendor_ip>
- OpenVAS / Nessus: Vulnerability scanning of vendor-facing systems (with permission).
- Shodan: Search for vendor devices exposed to the internet.
- sslscan: Check SSL/TLS configuration: sslscan <vendor_domain>:443
- testssl.sh: Comprehensive TLS testing.
Real-World Example: Third-Party Breach
In 2019, a third-party vendor for a major bank had weak access controls. Attackers compromised the vendor's VPN credentials, then moved laterally into the bank's network, exfiltrating customer data. The breach cost the bank millions in fines and remediation. This highlights why vendor access must be tightly controlled and monitored.
Exam Focus: What SY0-701 Tests
Vendor Due Diligence: Know the difference between questionnaires, certifications, and on-site assessments.
Shared Responsibility Model: Be able to identify which party is responsible for specific controls in IaaS, PaaS, SaaS.
Contractual Controls: Understand DPAs, SLAs, right to audit, breach notification clauses.
Supply Chain Risk: Recognize examples like SolarWinds and know mitigation strategies (SBOM, VRM).
Continuous Monitoring: Know that security scorecards and periodic reassessments are part of ongoing due diligence.
Identify Third-Party Relationships
Begin by cataloging all external entities that have access to your systems, data, or facilities. This includes cloud providers (AWS, Azure, Google Cloud), SaaS applications (Salesforce, Office 365), managed service providers (MSPs), hardware vendors, and even cleaning or security staff. Use a vendor management database or asset inventory tool. For each vendor, document the type of access (network, data, physical), the sensitivity of data involved, and the criticality of the service to your operations. This step is foundational; you cannot manage risk you don't know exists.
Assess Vendor Security Posture
Perform due diligence using a combination of security questionnaires, certifications (SOC 2, ISO 27001), penetration test reports, and external threat intelligence. For high-risk vendors, conduct an on-site assessment. Use a standardized scoring system (e.g., 1-5) to quantify risk. The assessor should verify that the vendor has incident response plans, encryption in transit and at rest (TLS 1.2+, AES-256), multi-factor authentication, and regular patching. Document findings in a risk register. This step identifies vulnerabilities before contracts are signed.
Negotiate Contractual Safeguards
Work with legal to include security requirements in the contract. Essential clauses: Data Protection Addendum (DPA) specifying data handling, right to audit (with reasonable notice), breach notification timeline (e.g., 24 hours), SLA for uptime and incident response, requirement for vendor to maintain cyber insurance (e.g., $5M), and data return/destruction upon termination. For critical vendors, include a clause requiring disclosure of sub-processors. Ensure the contract allows you to terminate for cause if the vendor suffers a material breach. This step legally binds the vendor to your security standards.
Implement Access Controls
Provision vendor access based on least privilege. Use separate accounts with MFA, restrict to specific IP ranges, and set time-bound permissions via Just-in-Time (JIT) access. Place vendor systems in a segmented network (VLAN) with firewall rules allowing only necessary ports. For privileged access, use a PAM solution to rotate credentials and record sessions. Monitor vendor activity through logs (e.g., VPN logs, authentication logs). This step reduces the blast radius if a vendor account is compromised.
Monitor and Reassess Continuously
Continuously monitor vendor security posture using security scorecards (BitSight, SecurityScorecard), threat intelligence feeds, and automated reassessment tools. Perform annual formal reassessments or trigger reviews after major incidents (vendor breach, acquisition). Review vendor incident reports and patch status. Conduct joint tabletop exercises to test incident response coordination. Update the risk register with new findings. This step ensures ongoing visibility and adaptation to changing risk.
Scenario 1: Cloud Provider Misconfiguration
A mid-sized company uses AWS S3 to store customer data. The cloud provider (AWS) is responsible for the security of the cloud, but the customer is responsible for security in the cloud. An engineer accidentally sets an S3 bucket to 'public' while testing. A security analyst running a cloud security posture management (CSPM) tool (e.g., Prisma Cloud) detects the misconfiguration and triggers an alert. The correct response is to immediately change the bucket policy to private, then review IAM permissions to ensure least privilege. A common mistake is to blame AWS; the exam emphasizes that the customer retains responsibility for configuration. The analyst would see a CloudTrail log showing a PutBucketAcl event with a public-read grant.
Scenario 2: Vendor Breach Notification
A payroll vendor notifies your company that they suffered a ransomware attack, and employee data (SSNs, bank details) may be exfiltrated. The contracted breach notification clause requires notification within 72 hours. The incident response team activates the plan: they isolate any systems connected to the vendor (via VPN), review logs for signs of lateral movement, and notify affected employees. They also engage legal to assess regulatory reporting obligations (e.g., state breach notification laws). A common mistake is to assume the vendor will handle all notifications; however, as the data controller, your organization is legally responsible. The analyst would see alerts from the SIEM for unusual outbound traffic to the vendor's IP range.
Scenario 3: Supply Chain Software Update
Your organization uses a software product from a vendor that was compromised in a supply chain attack (like SolarWinds). The vendor pushes a malicious update containing a backdoor. Your security team has implemented a software bill of materials (SBOM) policy and uses a tool to compare the update's hash against known good values. The hash mismatches, and the update is blocked. The team then quarantines any systems that already received the update and performs forensic analysis. A common mistake is to trust the vendor's digital signature blindly; attackers can sign malware if they compromise the signing infrastructure. The correct response is to verify hashes and use code signing with hardware security modules (HSMs) to protect signing keys.
Exactly What SY0-701 Tests
Objective 3.2 focuses on 'third-party risk in the architecture.' The exam expects you to:
Identify the shared responsibility model for cloud services (IaaS, PaaS, SaaS) and know which party is responsible for what.
Recognize vendor due diligence methods: questionnaires, certifications (SOC 2, ISO 27001), on-site assessments.
Understand contractual controls: DPA, SLA, right to audit, breach notification.
Know supply chain risk examples (SolarWinds, Kaseya) and mitigations (SBOM, vendor risk management program).
Differentiate between third-party risk and fourth-party risk (vendor's vendor).
Common Wrong Answers and Why
'The cloud provider is fully responsible for security.' Wrong because the shared responsibility model means the customer always has responsibilities (data, access, configuration). Candidates choose this because they think 'cloud = provider handles everything.'
'Vendor due diligence is a one-time event.' Wrong because continuous monitoring is required. Candidates think once a contract is signed, risk is managed.
'A SOC 2 Type I certification is sufficient.' Wrong because Type I assesses design only at a point in time; Type II assesses operational effectiveness over a period. Candidates confuse the two.
'Third-party risk only applies to cloud vendors.' Wrong; it applies to any external entity with access (hardware suppliers, janitorial services). Candidates narrow the scope.
Specific Terms and Values
SOC 2: Type I (point-in-time) vs Type II (over time).
ISO 27001: International standard for information security management.
GDPR Article 28: Requires written contract with data processors.
HIPAA BAA: Business Associate Agreement for PHI.
PCI DSS 12.8: Service provider assessment requirement.
SolarWinds (2020): Supply chain attack via compromised Orion updates.
Kaseya (2021): Ransomware via VSA vulnerability.
SBOM: Software Bill of Materials (list of components).
SIG (Standardized Information Gathering): Questionnaire format.
Trick Questions
Question describes a vendor that provides 'infrastructure as a service' and asks who is responsible for patching the hypervisor. Answer: The provider. But if the question asks about patching the guest OS, answer: The customer. Candidates mix these up.
Question gives a scenario where a vendor's vendor (fourth party) causes a breach. Answer: The primary vendor is still responsible, but you should have a clause requiring disclosure of sub-processors.
Decision Rule for Eliminating Wrong Answers
On scenario questions, first identify the type of service (IaaS, PaaS, SaaS) or the relationship (vendor, supplier, partner). Then apply the shared responsibility model. For contractual questions, look for keywords like 'right to audit', 'breach notification', 'DPA'. If an answer says 'one-time assessment' or 'provider fully responsible', eliminate it. For supply chain, if the answer doesn't mention SBOM or vendor risk management, it's likely wrong.
Third-party risk includes any external entity with access to your systems, data, or facilities.
The shared responsibility model divides security responsibilities between provider and customer; the customer always owns data and access.
Vendor due diligence involves questionnaires, certifications (SOC 2, ISO 27001), penetration tests, and on-site assessments.
Contractual controls include DPA, right to audit, breach notification (e.g., 24-72 hours), and data destruction clauses.
Supply chain attacks (e.g., SolarWinds) are mitigated by SBOM, vendor risk management programs, and code signing with HSMs.
Continuous monitoring uses security scorecards (BitSight) and periodic reassessments.
Least privilege, MFA, network segmentation, and PAM limit vendor access risk.
Regulations (GDPR, HIPAA, PCI DSS) impose specific third-party requirements (e.g., GDPR Article 28, HIPAA BAA).
These come up on the exam all the time. Here's how to tell them apart.
SOC 2 Type I
Assesses design of controls at a single point in time
Less rigorous
Often used for initial due diligence
No evidence of operating effectiveness
Cheaper and faster to obtain
SOC 2 Type II
Assesses design and operating effectiveness over a period (typically 6-12 months)
More rigorous
Preferred for ongoing vendor management
Includes testing of controls over time
More expensive and time-consuming
Mistake
Once we sign a contract with a vendor, our third-party risk is eliminated.
Correct
Contracts set expectations, but risk remains. Continuous monitoring, audits, and reassessments are needed because vendor security posture can change (e.g., they get acquired, suffer a breach).
Mistake
The cloud provider is responsible for all security in the cloud.
Correct
The shared responsibility model means the customer is always responsible for data, access management, and configuration. The provider secures the infrastructure; the customer secures what they put on it.
Mistake
A SOC 2 Type I report is the same as Type II.
Correct
Type I assesses controls at a single point in time; Type II assesses operational effectiveness over a period (e.g., 6 months). Type II is more rigorous and preferred for due diligence.
Mistake
Third-party risk only applies to IT vendors like cloud providers.
Correct
Any external entity with access—cleaning staff, contractors, hardware suppliers—poses risk. For example, a janitor with badge access could tailgate into a server room.
Mistake
Penetration testing a vendor is not necessary if they have a certification.
Correct
Certifications provide assurance but are not foolproof. Penetration testing validates that controls work in practice and can uncover issues missed by audits.
The shared responsibility model defines which security tasks are handled by the cloud provider and which are handled by the customer. For IaaS, the provider secures the physical infrastructure, hypervisor, and network; the customer secures the OS, applications, data, and access. For PaaS, the provider secures the runtime, middleware, and OS; the customer secures data and access. For SaaS, the provider secures most of the stack, but the customer still manages user access and data classification. Exam tip: The customer is always responsible for data and identity/access management.
A DPA is a legally binding contract between a data controller (you) and a data processor (vendor) that specifies how personal data must be handled, stored, and protected. It typically includes data breach notification obligations, data retention/deletion policies, and sub-processor requirements. DPAs are required under GDPR (Article 28) and often under other privacy laws. For the exam, know that a DPA is a key contractual control for third-party risk.
Vendor due diligence involves assessing a potential vendor's security posture before signing a contract. Steps include: sending a security questionnaire (like SIG), reviewing independent audit reports (SOC 2, ISO 27001), checking for breach history, requesting penetration test summaries, and for high-risk vendors, conducting an on-site assessment. The goal is to verify that the vendor's security controls meet your standards. For the exam, remember that due diligence is an ongoing process, not a one-time event.
An SBOM is a formal, machine-readable inventory of all components (libraries, modules, dependencies) that make up a software product. It helps organizations identify known vulnerabilities (e.g., Log4j) in their software supply chain. For the exam, SBOM is a key mitigation for supply chain attacks. It allows you to quickly determine if a vulnerability affects your software and to demand that vendors provide SBOMs as part of due diligence.
SOC 2 Type I reports assess the design of a service organization's controls at a specific point in time. Type II reports assess both the design and operating effectiveness of controls over a period (usually 6-12 months). Type II is more valuable for due diligence because it provides evidence that controls actually work in practice. For the exam, know that Type II is preferred for ongoing vendor risk management.
A right to audit clause in a vendor contract gives you the contractual ability to audit the vendor's security controls, either by yourself or through a third party. It typically requires reasonable notice (e.g., 30 days) and may limit frequency (e.g., once per year). This clause is important for verifying that the vendor maintains the agreed-upon security posture. For the exam, it's a key contractual control for third-party risk.
Network segmentation involves dividing a network into smaller segments, often using VLANs or firewalls, and restricting traffic between them. For third-party risk, you place vendor systems in a separate segment with strict firewall rules that allow only necessary communication (e.g., specific ports to specific internal servers). This limits the blast radius if a vendor's system is compromised—attackers cannot easily move laterally to other parts of your network. Exam tip: Always associate segmentation with limiting lateral movement.
You've just covered Third-Party Risk in Architecture — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?