CompTIA SecurityX (CAS-005) objective 1.3 asks you to evaluate and manage third-party, vendor, and supply chain risks. This matters because modern businesses almost never build everything themselves; they buy software, rent cloud computing, and hire managed services, which means your security depends on strangers you choose to trust. If you cannot identify the risks in that chain, you cannot protect the organisation — and the exam will check if you can.
Jump to a section
A simple way to picture Third-Party and Supply Chain Risk Management
You are the owner of a busy restaurant, and you decide to hire a general contractor to renovate your kitchen. You don't build the new ovens or lay the tiles yourself; you trust the contractor to bring in specialists (electricians, plumbers, carpenters) and source materials (wood, steel, wiring) from various suppliers.
Here is the catch: you are still responsible for the final result. If the electrician uses faulty wiring that starts a fire, your restaurant burns down, not theirs. You must vet each subcontractor, inspect the materials delivered, and check the contractor’s insurance before a single hammer swings. You ask for a detailed schedule and a written contract that states exactly what happens if a delivery is late or if a worker does not show up.
This is third-party and supply chain risk management. In IT, your business (the restaurant) uses vendors (the contractor) to build or operate critical systems (the kitchen). Those vendors rely on their own suppliers (subcontractors and material sources). A flaw anywhere in that chain — a weak password in a vendor’s office, a faulty chip from a factory overseas, a software library with a hidden vulnerability — can become your problem. You cannot control every link, but you can assess, monitor, and contract for security just as you would check a contractor’s credentials and inspect every bag of cement before it touches your kitchen floor.
Third-party and supply chain risk management (TPCRM or SCRM) is the practice of identifying, assessing, and controlling risks that come from partners, vendors, suppliers, and their own subcontractors. In a traditional setup, a company might host its own servers in a locked room, write its own code, and manage its own network. Today, nearly every organisation buys software-as-a-service (SaaS) like Salesforce or Microsoft 365, uses cloud infrastructure from Amazon Web Services (AWS) or Azure, and hires specialised firms to handle payroll, customer support, or even security monitoring itself. Each of those relationships introduces risk because you must trust someone else to do their job securely.
A third party is any external organisation that provides a product or service to your company. A vendor is a specific type of third party that sells goods or services directly to you — for example, a software vendor like Adobe. A supply chain is the entire network of organisations, people, activities, and resources involved in creating and delivering that product or service. If a vendor uses a subcontractor to write part of their software, that subcontractor is downstream in the supply chain, and their security mistakes can still reach you.
The core process has three phases: assessment, contracting, and monitoring.
Assessment happens before you sign a contract. You ask the vendor to complete a security questionnaire, review their SOC 2 Type II report (a third-party audit of their controls), or run a technical scan of their systems. You evaluate their data handling practices, their incident response plan, and whether they encrypt data in transit and at rest. You also check their financial health: a vendor that might go bankrupt next year could leave you stranded with no support.
Contracting is where you put legal teeth into security requirements. Your contract should specify:
The vendor must notify you within 24 hours of a security breach.
The vendor cannot sub-subcontract critical functions without your written approval.
The vendor must delete your data when the contract ends.
The vendor must allow you to audit their security controls.
The vendor must maintain cyber insurance coverage with a minimum limit.
Monitoring happens after the deal is signed. You periodically review the vendor's security posture, check for news of breaches, and re-assess when the vendor is acquired or releases a major update. Many organisations use a vendor risk management (VRM) platform that automatically pulls security ratings (like BitSight or SecurityScorecard) and alerts on changes.
Why does this exist? Because the SolarWinds attack of 2020 showed the world that an attacker could compromise one software vendor and then infect thousands of that vendor's customers. Similarly, the Target breach of 2013 began when attackers stole credentials from an air conditioning vendor that had network access to Target's payment systems. Modern attackers know they can target a small, less-secure vendor and then use that foothold to reach a bigger, more secure company.
What does this replace? It replaces the old model where a company simply reviewed a sales brochure and shook hands. It replaces the assumption that a well-known brand automatically has good security. And it replaces reactive, firefighting security with a proactive, process-driven lifecycle where you continuously evaluate the people you trust.
Identify All Third-Party Relationships
Compile a complete list of every vendor, partner, supplier, and subcontractor that your organisation uses. Include software-as-a-service tools, cloud providers, managed service providers, hardware suppliers, and even cleaning or HVAC contractors if they have physical or network access. You cannot manage risk you do not know exists.
Initial Risk Assessment
For each third party, evaluate their security posture using a security questionnaire, review third-party audit reports (SOC 2, ISO 27001), and scan their public-facing systems if possible. Classify each third party by risk level (low, medium, high) based on the sensitivity of data they handle and the criticality of their service. High-risk vendors get deeper scrutiny.
Negotiate Security Contracts
Write legal contracts that include mandatory security requirements: minimum encryption standards, breach notification timelines (e.g., 24 hours), right-to-audit clauses, data deletion upon contract end, and limits on subcontracting. This step turns your security expectations into enforceable obligations.
Implement Continuous Monitoring
Set up automated tools to track vendor security scores (from services like BitSight or SecurityScorecard), subscribe to breach notification feeds, and schedule periodic reviews (quarterly for high-risk, annually for low-risk). Monitoring catches changes before they become breaches.
Conduct Periodic Re-assessments and Incident Response
When a vendor is acquired, changes their data centre, or suffers a breach, trigger a full re-assessment. If a breach occurs that impacts your data, execute your incident response plan with the vendor. Document all findings in your risk register and update your risk treatment decisions accordingly.
Imagine you are the IT manager at a mid-sized accounting firm called LedgerPro with 500 employees. You have just been told the firm will start using a new cloud-based customer relationship management (CRM) system from a vendor called ClientFlow. The CEO wants it live in six weeks.
Your first step is to perform a vendor risk assessment. You request ClientFlow’s SOC 2 Type II report, which is a third-party audit of their security controls. You read the report and notice that ClientFlow encrypts data at rest using AES-256 but does not require multi-factor authentication (MFA) for administrator accounts. That is a gap. You also look at their data centre locations because the firm has clients in Europe, so GDPR compliance is mandatory. ClientFlow claims they are GDPR-compliant but shows no audit evidence. You flag both issues.
Next, you negotiate the contract. You insist on a clause requiring MFA for all admin access to the CRM. You also demand a 24-hour breach notification window, a data-processing agreement that meets GDPR standards, and a clause that ClientFlow must delete your firm’s data within 30 days if the contract ends. You also require that ClientFlow cannot subcontract the hosting of your data to a third party without your explicit written consent.
Once the contract is signed, you set up monitoring. You subscribe to a security-rating service that gives ClientFlow a score based on their publicly visible security posture. You also set a calendar reminder to review their SOC 2 report annually. Six months later, you get an alert: ClientFlow’s security rating dropped by 20 points because they had an exposed database on the internet for three hours. You call their security team, get an explanation, and update your risk register (a document that lists all known risks and their severity) to reflect the new information.
Later, ClientFlow announces they have been acquired by a larger software company. You immediately initiate a re-assessment because the ownership change could mean new policies, new personnel, or new subcontractors. During the re-assessment, you discover the acquiring company uses a different data centre provider — one located in a country with weaker data-protection laws. You demand evidence of equivalent protection before approving the change.
This entire walkthrough shows that third-party risk management is not a one-time checkbox. It is a continuous cycle of assess, contract, monitor, and reassess. An IT professional uses tools like vendor risk management platforms, security questionnaires (such as the Standardized Information Gathering questionnaire, SIG), and constant vigilance to protect their organisation from risks that flow through the supply chain.
The CAS-005 exam will test your knowledge of third-party and supply chain risk management in several specific ways. Expect multiple-choice questions that present a scenario, then ask you to choose the best risk treatment — avoid, transfer, mitigate, or accept. They love to test whether you know when to perform each action.
Scenarios often involve:
A vendor that refuses to allow a security audit.
A subcontractor that suffered a breach.
A software vendor that uses open-source libraries with known vulnerabilities.
A cloud provider that changes their terms of service regarding data residency.
The correct answer pattern is usually: assess the risk first, then apply the lifecycle stage that matches. Do not jump straight to contract termination unless the vendor is unwilling to fix a critical issue. The exam wants you to show a measured, lifecycle-based approach.
Key concepts you must memorise:
Supply chain attack: an attacker compromises a less-secure element upstream to reach a more valuable target downstream.
Vendor risk management (VRM): the formal process of assessing, monitoring, and managing risk from third-party vendors.
Software supply chain security: protecting the integrity of software components (libraries, containers, binaries) throughout the development and delivery pipeline.
Bill of materials (SBOM): a list of all software components in a product, used to track vulnerabilities.
Right to audit clause: a contract provision that lets you inspect the vendor’s security controls.
Service-level agreements (SLAs): contractual guarantees about performance, availability, and security.
Fourth-party risk: the risk from your vendor's own vendors.
Common traps:
Trap 1: The exam gives you a vendor with a clean security questionnaire but no third-party audit report. The trap is to accept on face value. The correct response is to require independent audit evidence.
Trap 2: A vendor offers a cheaper price but has no data centre redundancy. The trap is to pick cost savings. The correct response is to assess the risk of downtime against the business criticality.
Trap 3: The question says ‘the vendor is a household name, so they must be secure.’ The trap is to skip assessment. The correct response is to assess every vendor equally, regardless of brand reputation.
Trap 4: The exam describes a vendor that has been acquired. The trap is to ignore the acquisition. The correct response is to re-assess the vendor because ownership change creates new risks.
Trap 5: A vendor suffers a breach that does not affect your data. The trap is to ignore it. The correct response is to still investigate because the breach reveals systemic weaknesses that could affect you later.
Definitions to memorise:
Risk avoidance: not engaging the vendor at all.
Risk transfer: requiring cyber insurance or moving liability via contract.
Risk mitigation: mandating controls like MFA or encryption.
Risk acceptance: formally acknowledging the risk but taking no action, typically documented and approved by senior management.
Third-party risk extends invisibly through your vendor's own vendors, so a breach at a subcontractor can reach your data.
The supply chain risk lifecycle has three phases: assessment before contracting, contracting with enforceable security clauses, and continuous monitoring after signing.
A right-to-audit clause in your contract lets you inspect your vendor's security controls, but only if you actually exercise it.
A software bill of materials (SBOM) lists every component in a vendor's product and helps you track known vulnerabilities.
If a vendor is acquired by a new company, you must re-assess them immediately because ownership change can alter their security posture.
Treat every vendor the same way for risk assessment regardless of their brand reputation, because attackers target weak links, not famous names.
The exam tests whether you can distinguish between risk avoidance (don't hire), transfer (insurance), mitigation (controls), and acceptance (documented decision).
These come up on the exam all the time. Here's how to tell them apart.
Third-Party Risk
Focuses on direct contractual relationships with external organisations that provide services or products.
Typically assessed at the point of engagement and re-assessed periodically.
Does not inherently extend visibility past the immediate vendor.
Example: evaluating a single SaaS vendor's security controls before signing a contract.
Supply Chain Risk
Encompasses the entire network of upstream suppliers, subcontractors, and their own dependencies.
Requires mapping the vendor's own supply chain, which can be deep and opaque.
Explicitly includes risks from fourth parties, open-source components, and hardware sourcing.
Example: tracing the origins of a chip used in a server that your vendor assembles.
Risk Assessment
Performed upfront before a vendor relationship begins, often using questionnaires and audit reports.
Static — captures the vendor's state at that moment in time.
Focuses on evaluating controls, policies, and certifications.
Produces an initial risk score and treatment recommendation.
Risk Monitoring
Ongoing process after the relationship is active, using alerts, security ratings, and breach feeds.
Dynamic — catches changes like security rating drops, new vulnerabilities, or acquisitions.
Focuses on verifying that controls remain effective and that no new risks have emerged.
Triggers re-assessment when significant changes are detected.
Risk Mitigation
Involves implementing controls to reduce the likelihood or impact of a risk, e.g., requiring MFA from the vendor.
Reduces risk directly within your environment or the vendor's environment through contractual requirements.
Cost is borne by your organisation for enforcement and verification.
Example: requiring the vendor to encrypt all data in transit and at rest.
Risk Transfer
Shifts the financial consequences of a risk event to another party, usually via insurance or indemnity clauses.
Does not reduce the probability of the event, only the financial damage to your organisation.
Requires paying a premium or negotiating contract terms that hold the vendor liable.
Example: requiring the vendor to maintain a $10 million cyber insurance policy and naming your organisation as an additional insured.
Right-to-Audit Clause
Gives your organisation the legal right to inspect the vendor's security controls, systems, and processes.
Focused on verifying security compliance, not performance.
Usually exercised infrequently (annually or upon suspicion of breach).
If violated, you may start a formal review or terminate the contract.
Service-Level Agreement (SLA)
Specifies measurable performance metrics such as uptime percentage, response times, or data loss limits.
Focused on service quality, not security controls (though security SLAs exist).
Monitored continuously via automated dashboards and reports.
If violated, you may claim credits or penalties as defined in the contract.
Mistake
Only very large companies like banks need to worry about third-party risk.
Correct
Every company that relies on any external vendor, including software-as-a-service (SaaS) tools and cloud infrastructure, has third-party risk. Small businesses are often the most vulnerable because attackers target them as easier entry points into larger clients.
Beginners assume security threats only apply to huge corporations. In reality, the supply chain means that any link in the chain can be exploited, so small vendors are frequent attack vectors.
Mistake
A signed contract with a vendor guarantees they will follow all the security requirements you wrote in it.
Correct
A contract is only as strong as your ability to enforce it. Without monitoring (regular audits, security rating checks, breach notification clauses), the vendor may ignore requirements or change practices after signing.
People mistakenly think legal documents automatically enforce behaviour. But contracts require active oversight and the willingness to act on violations.
Mistake
If a vendor uses a well-known cloud provider like AWS, then the vendor's security is automatically good.
Correct
Cloud providers offer a secure infrastructure, but the vendor is responsible for their own configuration — such as setting proper access controls, encrypting data, and patching their software. A misconfigured AWS S3 bucket owned by a vendor can still leak your data.
The shared responsibility model is widely misunderstood. Beginners think the cloud provider secures everything, but the vendor still owns their portion of the application and data.
Mistake
Once you assess a vendor before signing, the work is done and you never need to look at them again.
Correct
Third-party risk management is a continuous lifecycle. Vendors can be acquired, change their security practices, suffer breaches, or introduce new software components with vulnerabilities after the initial assessment.
People naturally treat security as a one-time project rather than an ongoing process. The SolarWinds attack proved that a trusted vendor can be compromised months after initial vetting.
Mistake
A vendor's SOC 2 report is proof that they are fully secure and have no vulnerabilities.
Correct
A SOC 2 Type II report describes the vendor's controls at a point in time and only covers the systems in the audit scope. It does not test for every possible vulnerability, and the vendor may not apply the same controls to all systems.
SOC 2 reports look impressive and technical, so beginners treat them as a guarantee. In reality, they are a snapshot of controls, not a real-time security scan.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A third party is any external organisation you directly deal with (like a software vendor). A supply chain includes that vendor plus all of its own suppliers and subcontractors, forming a chain that extends beyond your direct relationship.
Yes, because a free trial still involves data being shared with that vendor. Even if you do not pay, the vendor holds your data, so you must assess whether their security practices meet your standards before signing up.
A SOC 2 Type II report is an independent audit of a vendor's security controls over a period of time (usually 6–12 months). It shows whether the vendor has controls in place for security, availability, processing integrity, confidentiality, and privacy. It is important because it gives you evidence of a vendor's security posture from a trusted external examiner.
No. Marketing claims are not evidence. You must ask for proof: audit reports, security certifications, data encryption details, and breach history. Relying on claims alone is a common mistake the CAS-005 exam will test you to avoid.
That is a serious red flag. Without the right to audit, you cannot verify their security controls. Your options are to negotiate a right-to-audit clause, accept the risk if the service is low-risk, or choose a different vendor. The exam expects you to treat refusal as a potential risk that requires a decision.
An SBOM is a list of all the open-source and commercial components inside a piece of software. If a vulnerability like Log4j is discovered, you can check the SBOM to see if your vendor uses that component. The CAS-005 exam tests whether you understand SBOMs as a tool for managing software supply chain risk.
Risk transfer means shifting the financial impact to another party, usually through cyber insurance or contracts that hold the vendor liable. Risk mitigation means reducing the likelihood or impact by implementing controls like MFA or encryption. The exam will ask you to choose the correct action based on the scenario.
You've finished Third-Party and Supply Chain Risk Management. Continue through the CAS-005 study guide to build a complete picture of the exam.
Done with this chapter?