Skip to main content
Study Guide · CompTIA Security+ · SY0-701

What each objective is asking you to know

Plain-English reference for every CompTIA Security+ objective. Each entry covers what the exam tests, key facts, and how the concept connects to neighboring objectives. Pair with Quiz and Flashcards to lock it in.

Objective SP-5.3

Objective 5.3: Explain elements of third-party risk assessment and management

Cert: CompTIA Security+ (SY0-701) Domain: 5.0 Security Program Management and Oversight Weight: ~20% of SY0-701 (Domain 5 total) Depth: Explain. Be able to name the five vendor assessment activities, the vendor selection elements, all eight agreement types (SLA, MOA, MOU, MSA, WO/SOW, NDA, BPA), and the vendor monitoring activities (questionnaires, rules of engagement, periodic reassessment).

What this objective tests

You should be able to define third-party risk in plain English, name the five vendor assessment activities, walk a vendor selection process from due diligence through conflict-of-interest screening, distinguish all eight agreement types on the exam, and describe a vendor monitoring program that uses questionnaires and rules of engagement. The exam loves the agreement-type distinctions because the terms look similar but have different legal weight. SOC analysts and vCIOs read these contracts in the field. Get the vocabulary tight and the SY0-701 items in this objective become a quick-win cluster.

Key facts

What third-party risk is

Third-party risk is the cybersecurity exposure a company inherits when it lets another company touch its data, its network, or its customers. The vendor's password reuse becomes your blast radius. Their patching cadence becomes your unpatched fleet. Their subcontractor decisions become your supply chain. Any time you trust an outside organization with access, identity, data, or operations, some of their risk becomes yours.

The 2020 SolarWinds incident moved supply chain risk from a back-office topic to a board-level conversation. A trusted software vendor was compromised, the malicious update was signed and shipped through the normal channel, and about 18,000 customers downloaded the trojanized build. The customers were not the original target. They took the hit anyway. That pattern is supply chain risk in one sentence.

Vendor assessment activities

Five vendor assessment activities show up on the SY0-701 list. Each one is a different kind of evidence about whether the vendor can actually do what they promise.

ActivityPlain EnglishWhen you use it
Penetration testingAuthorized simulated attack against the vendor or its services, run by your team or a third partyHigh-value engagement, regulated industry, or annual compliance requirement
Right-to-audit clauseContract language that lets you (or your designated auditor) inspect the vendor's controlsHigher-risk vendors with critical data access, especially regulated workloads
Evidence of internal auditsThe vendor's own audit trail (ISMS audits, control-test results, vulnerability scan summaries)Pre-signing due diligence and recurring monitoring
Independent assessmentsThird-party audits the vendor pays for and shares (SOC 2, ISO 27001 cert, PCI ROC, HITRUST CSF)Default for SaaS and managed services with mature compliance programs
Supply chain analysisTracing the vendor's suppliers, software dependencies, and subprocessorsAll critical vendors, especially software supply chain and infrastructure providers

Penetration tests require a rules-of-engagement document before any traffic flies. Rules of engagement specify scope (which IP ranges, which apps, which accounts), allowed methods (pen test vs vuln scan vs red team), blackout windows (no testing during business hours), deliverables (executive summary plus technical report), and escalation contacts (the analyst to call if something breaks). Skip the rules of engagement and the pen test can violate contract terms or even computer-fraud laws.

The big four independent assessments for U.S. business are SOC 2 Type II, ISO 27001 certification, PCI DSS Report on Compliance, and HITRUST CSF certification. SOC 2 Type II is the most common SaaS evidence. It tests operating effectiveness of the trust services criteria (security, availability, processing integrity, confidentiality, privacy) over a period of time (usually 12 months). Type I tests design only, at a single moment. Always ask for Type II for production workloads. ISO 27001 certifies the vendor's information security management system. PCI DSS Report on Compliance applies if the vendor touches payment card data. HITRUST CSF is the de facto healthcare evidence in the U.S.

Supply chain analysis is the activity of tracing the vendor's own vendors. Read the subprocessor list before signing. Map software dependencies. Identify fourth parties (the subcontractor's subcontractor) for critical services. If your cloud backup vendor uses three subprocessors you have never heard of, that is your risk too.

Vendor selection

Vendor selection has two named elements on the exam: due diligence and conflict of interest. Due diligence is the pre-signing investigation. Conflict of interest is the screening for divided loyalties.

Due diligence asks a short list of questions. Who owns the company. Where are they incorporated. Who are the executives and do they have a clean track record. Are they financially solvent (D&B credit report, public filings, recent funding events). Do they hold the certifications the engagement requires. Do they carry cyber liability and errors-and-omissions insurance with appropriate coverage. Do they use subcontractors and which ones. Have they had a public breach and what was the response. Independent verification beats vendor attestation. Always.

Conflict of interest screening asks whether the vendor has other relationships that compromise their objectivity or loyalty. Three common patterns. The auditor who also sells you the software they are auditing. The security firm that tests your competitor and shares findings up the chain. The reseller who earns a commission on the product they recommend. None of these are automatically disqualifying. They do require disclosure, documentation, and a documented decision to accept, mitigate, or walk away.

Agreement types (the SY0-701 list)

Eight agreement types appear on the exam. Memorize them. The exam loves to test the distinctions because the terms look similar.

AcronymFull namePurposeBinding?When used
SLAService Level AgreementPromises measurable performance with penalties (uptime, response time, resolution time)YesOperational promises inside an MSA or SOW
MOAMemorandum of AgreementFormal commitment between two parties on a defined collaborationYesGovernment-to-government, inter-agency, or research partnerships with clear deliverables
MOUMemorandum of UnderstandingNon-binding statement of intent. Often a precursor to a formal contractNoEarly-stage collaborations, letter-of-intent style
MSAMaster Service AgreementUmbrella contract that governs every work order beneath it (warranty, liability, indemnification, IP, termination)YesLong-term vendor relationships with many projects
WO / SOWWork Order / Statement of WorkSpecific scope, deliverables, timeline, and price for one engagement under an MSAYesEach individual project under the umbrella contract
NDANon-Disclosure AgreementProtects confidential information shared between parties (mutual or one-way)YesBefore any real conversation that includes confidential information
BPABusiness Partnership AgreementDefines how two companies operate as partners (revenue share, joint marketing, joint product)YesTrue business partnerships, not vendor relationships

The pattern: NDA before the conversation. MSA before the work. SOW for each individual project under the MSA. SLA carries the operational teeth inside the MSA or each SOW. MOU is non-binding intent. MOA is a binding formal commitment. BPA is for genuine business partnerships, not vendor relationships.

The two pitfalls students hit on the exam. First, mixing up SLA and NDA. SLA is about performance promises with teeth. NDA is about confidentiality. They are not interchangeable. Second, mixing up MSA and SOW. The MSA is the umbrella. The SOW is the specific project. You sign one MSA per vendor relationship and many SOWs over the life of that MSA.

Vendor monitoring

Signing the contract is not the finish line. Vendor monitoring is the ongoing program that keeps an eye on what was promised. Four named activities appear in the objective and in real-world practice.

Periodic questionnaires let the vendor attest to controls. Industry standards include SIG (Standardized Information Gathering) by Shared Assessments, SIG-Lite for low-risk engagements, and CAIQ (Consensus Assessments Initiative Questionnaire) by the Cloud Security Alliance. Pick a template once and use it across vendors so you can compare apples to apples.

Periodic reassessment reruns the original due diligence on a cadence. Annual is common for critical vendors. Biennial works for lower-risk engagements. Reassessment looks at financial health, leadership changes, certification renewals, incident history, and any subprocessor changes since the last review.

Rules of engagement come up in two places. First, in pen testing scope documents as covered above. Second, in any vendor activity that touches production systems: change windows, access methods, escalation contacts, allowed tooling. Write the rules of engagement before the activity starts. Reference them during the activity. Archive them after.

Breach notification clauses force the vendor to tell you within a named window. GDPR-style language requires 72 hours. Many U.S. MSP contracts now require 24 hours. Some highly regulated sectors require shorter windows. Write the window into the MSA and tie it to the SLA penalty schedule so late notification carries a real cost. Track every minute.

Security ratings services watch the vendor's public attack surface and email a score every month. BitSight, SecurityScorecard, and RiskRecon are common providers. Use the trend, not a single number, to decide whether to renew. A vendor whose rating drifted from A to C over six months deserves a conversation before the next renewal.

Conflict-of-interest examples

Three concrete examples from real procurement decisions help anchor the concept.

First, the consulting firm that performs your annual risk assessment and also sells you the GRC platform they recommend in the assessment. The recommendation is suspect. Mitigation: hire one firm for the assessment and a different firm for the platform.

Second, the security testing firm that tests your largest competitor under a separate contract. The firm could (intentionally or not) share methods, findings, or signals between engagements. Mitigation: ask about Chinese-wall procedures and require attestation that no analyst works on both engagements simultaneously.

Third, the reseller of a security tool who earns a commission on every license sold and also tells you which tool to buy. The reseller is incentivized to recommend the highest-commission product, not the best fit. Mitigation: separate the evaluation from the purchase. Have one party recommend and a different party transact.

Common gotchas

  • SLA vs NDA. SLA promises measurable performance with penalties. NDA protects confidential information. Different documents, different teeth.
  • MSA vs SOW. MSA is the umbrella contract. SOW is the specific project under the umbrella. One MSA per vendor relationship, many SOWs over its life.
  • MOA vs MOU. MOA is a binding formal commitment. MOU is a non-binding statement of intent, often a precursor to a formal contract.
  • BPA vs MSA. BPA is for true business partnerships (revenue share, joint marketing). MSA is for vendor relationships. Do not mix them up.
  • SOC 2 Type I vs Type II. Type I tests design at a single moment. Type II tests operating effectiveness over a 12-month period. Always ask for Type II for production workloads.
  • PCI DSS is industry, not regulatory. The card brands enforce, not a government agency. Failing PCI DSS does not bring a federal prosecutor, but it can end a merchant agreement.
  • Penetration testing without rules of engagement. Skipping the rules-of-engagement document can violate contract terms or even computer-fraud laws. Always sign before testing.
  • Conflict of interest is not automatically disqualifying. It requires disclosure, documentation, and a documented decision to accept, mitigate, or walk away. The exam may test the response, not the existence.

Real-world context

A vCIO or SOC manager spends a meaningful slice of every quarter on third-party risk. The work is concrete. Read the new vendor's contract for SLA teeth, right-to-audit cadence, breach notification window, and subprocessor list. Ask for the most recent SOC 2 Type II report and confirm the period covered. Run the CAIQ questionnaire if the vendor is cloud-based. Track the vendor's BitSight score quarterly. File the renewal review 60 days before the renewal date.

When a vendor gets breached, the playbook is also concrete. Hour one: confirm the notification arrived, confirm what data and access were in scope, walk the SLA clock on notification timing, pull the contract clauses that apply (right-to-audit, indemnification, breach notification penalties), open an incident ticket. Hour two through six: independent assessor decision (do we invoke right-to-audit), regulator notification clock starts if regulated data is in scope (HIPAA 60 days, GLBA varies, GDPR 72 hours), insurance broker notification. Days through weeks: post-incident review against the contract, decision about renewal, decision about contract changes for the next renewal.

Sample contract language. A breach notification clause from a typical MSP MSA reads: "Provider shall notify Customer within twenty-four (24) hours of becoming aware of any Security Incident that involves Customer Data or Customer Systems. Provider shall maintain a documented incident timeline and shall make the timeline available to Customer on request. Failure to notify within the required window shall constitute a material breach and shall trigger the SLA penalty schedule in Exhibit B." That is one sentence with three teeth: the window, the documentation, and the penalty link.

Sample SOC ticket. The MSP at fictional Cardinal Harbor Hospital announces it was compromised. The ticket reads SOC-2026-0617. The SOC Tier 1 analyst pulls the MSA, finds the 24-hour breach notification clause, computes time-since-detection (4 hours 34 minutes, inside the window), pulls the subprocessor list (three named subprocessors), flags one (the log aggregation provider) for additional inquiry, opens the right-to-audit decision packet for the CISO, and notifies the cyber insurance broker. That entire sequence runs on the agreement-type vocabulary in this objective.

Sources

  • CompTIA Security+ SY0-701 Exam Objectives, Section 5.3
  • NIST SP 800-161, Cybersecurity Supply Chain Risk Management Practices
  • NIST SP 800-53, control family SR (Supply Chain Risk Management)
  • ISO/IEC 27036-1, 27036-2, 27036-3 Supplier Relationships
  • Shared Assessments SIG / SIG-Lite questionnaire library
  • Cloud Security Alliance CAIQ (Consensus Assessments Initiative Questionnaire)
  • AICPA SOC 2 Trust Services Criteria