Vendor Risk Lifecycle and Agreements

Why Domain 5 Cares About Vendors

On CompTIA Security+ SY0-701 (90 questions, 90 minutes, pass at 750 on a 100–900 scale), third-party risk lives in Domain 5, Security Program Management and Oversight — the heaviest domain at 20% of the exam. Objective 5.3 names supply-chain and vendor concepts directly, so expect several scenario items that hand you a vendor problem and ask which agreement, lifecycle phase, or control answers it.

A third party is any external entity (cloud host, payroll processor, payment gateway, MSP, law firm) that touches your systems or data. A fourth party is your vendor's subcontractor (a subprocessor). Third-party risk management (TPRM) decides who may handle data, what controls they owe, how performance is measured, and how the relationship ends. The exam frames this as extending your attack surface: every integration, API token, and VPN tunnel a vendor holds is a path into you.

Two related supply-chain ideas show up in the same objective. Supply-chain risk covers hardware, software, and managed-service providers — think of a tampered firmware image or a compromised software update poisoning every downstream customer. Concentration risk appears when many of your critical services depend on one provider or one region, so a single outage cascades. CompTIA wants you to reason about inherent risk before compensating controls and about residual risk after them, and to remember that accountability for the data never transfers to the vendor even when the work does.

The Vendor Risk Lifecycle

The lifecycle matters because the threat is dynamic. A vendor acceptable two years ago may add a subprocessor, move data to a new region, suffer a breach, or quietly stop meeting uptime. Continuous monitoring — not the signing ceremony — is where Security+ expects mature programs to catch trouble.

Notice how the evidence column maps to a verifiable artifact at each phase. That is deliberate: on the exam, the better answer is almost always the one backed by an objective artifact (a signed clause, a destruction certificate, a scoped access list) rather than a verbal assurance. Offboarding is the most-missed phase in real breaches — dormant vendor accounts and un-revoked API keys are a recurring root cause — so treat the termination checklist and proof of data return or destruction as non-negotiable deliverables, not paperwork.

Agreement Types You Must Recognize

Decision rules the exam rewards

• Uptime, response time, or restoration target → SLA.
• Broad, long-term legal terms → MSA.
• Concrete deliverables and dates → SOW (a WO if it rides under an existing MSA).
• Secrets shared during evaluation → NDA.
• A partner processes regulated data → BPA.
• Non-binding intent between organizations → MOU/MOA.

Worked Scenario

A school district selects a hosted identity platform. At selection, it classifies student records as sensitive and rates the vendor high risk because the platform will authenticate every student and staff account. Before signing, due diligence pulls the security questionnaire, a recent SOC 2 Type II report, a data-flow diagram, the breach-notification process, and the subprocessor list.

At contracting, the MSA carries data-protection duties, audit rights, a 72-hour breach-notification clause, and termination language; the SOW scopes the migration; the SLA sets availability and support targets; an NDA covers architecture discussions. At onboarding, access is limited to named administrators and the vendor streams logs to the district SIEM (Security Information and Event Management). At offboarding, the district disables federation, exports required records, obtains a certificate of destruction, and revokes API tokens and VPN access.

Common Traps

• Treating a sales security statement as a contractual obligation — only signed terms bind.
• Buying an SLA for uptime but omitting incident-notification and data-return clauses.
• Onboarding before due diligence finishes.
• Granting vendor access through shared accounts instead of named, least-privilege identities.
• Ignoring fourth-party subprocessors and concentration risk.
• Ending a contract without revoking accounts, API keys, and VPN access or recovering stored data.

A final distinction the exam likes: an SLA is operational and measurable, while an MSA is legal and durable. When a question describes a percentage, a time window, or a penalty for missed performance, the answer is the SLA even if a master contract is mentioned in the same sentence. When the question is about who bears liability, owns intellectual property, or how disputes are resolved across the whole relationship, that is the MSA. SOWs and work orders both define deliverables, but the work order is the lighter instrument issued under an existing master so a new project does not require renegotiating the umbrella terms.