MSA, SOW, SLA, BPA, NDA: The Third-Party Risk Alphabet, and Which Document Answers Which Question
Chris Rees
25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings
Most organizations have spent a decade hardening their own systems and then handed the keys to a payroll provider, a managed service partner and forty SaaS vendors, any of whom can be the way in. Security+ objective 5.3 is about that reality, and it tests it with paperwork: a stack of acronyms that candidates confuse because they have never had to sign one. Each document answers a different question. Learn the question, and the acronym follows.
Third parties are your attack surface
A vendor with access to your data, your network or your building extends your trust boundary to an organization you do not control. The risk has two shapes. The direct one is a vendor breach that exposes your data or their access into you. The indirect one is a vendor failure, insolvency or exit that takes a business process with it. Third-party risk management covers both, and it runs as a lifecycle rather than a one-time check.
Selection: due diligence and conflicts of interest
Due diligence is the work you do before signing: financial stability, security posture, breach history, certifications, references, where they process data and who their own suppliers are. The exam pairs it with due care, which is the ongoing reasonable conduct expected of you afterwards. Diligence is the investigation; care is the practice.
Conflict of interest turns up as its own item because it is easy to miss: a vendor selected by an executive who sits on its board, or an auditor assessing a system they also sold you. The control is disclosure and independence, and a scenario describing a cozy relationship between selector and vendor is asking you to name it.
Supply chain analysis looks past the vendor to the vendor's vendors. Your cloud provider's data center operator, your software vendor's open-source dependencies, your hardware supplier's component sources. The exam frames this as "how deep does your assessment go," and the answer is deep enough to find the concentration risk where three of your critical vendors all depend on the same fourth party.
The agreement stack
This is the part of the objective that decides scores, and the trick is to see the documents as a stack rather than a list.
| Document | The question it answers | Typical clue in a stem |
|---|---|---|
| MSA | What are the general terms for everything we do together? | "overarching," "governs all future work," "right to audit" |
| SOW | What exactly will be delivered on this project? | deliverables, milestones, scope of one engagement |
| SLA | How well, measured how, and what if you miss? | uptime percentage, response times, penalties, credits |
| NDA | Will you keep what you learn confidential? | evaluation before a deal, sharing designs or data |
| BPA | How do two partners share a venture? | joint business, revenue split, responsibilities |
| MOU / MOA | Do we intend to cooperate, and on what basis? | agencies or organizations aligning, non-binding, informal |
Two distinctions are tested more than the rest. SLA versus SOW: the SOW says what will be done, the SLA says how well; a stem with a number in it (99.9%, four-hour response) is an SLA question. And MOU versus MOA versus BPA: an MOU is the least formal and typically not enforceable, an MOA is a step more formal with defined obligations, and a BPA is a genuine business partnership with shared stakes. If the parties are running a business together, it is a BPA. If they are just agreeing to help each other, it is a memorandum.
SLAs in detail: the metric, the measurement, and the miss
Because the SLA is the document with numbers in it, it is the one the exam can build arithmetic around. A working SLA has three parts, and a scenario will usually be about one of them being missing.
The metric is what is promised: availability (99.9% is roughly 8.7 hours of downtime a year; 99.99% is under an hour), response time to an incident, resolution time by severity, or a security-specific commitment such as notification within 24 hours of a breach. The measurement is how it is calculated and by whom, and it matters because "99.9% excluding scheduled maintenance" and "99.9% of calendar time" are very different promises. The remedy is what happens on a miss: service credits, termination rights, or nothing at all, which is the most common finding when a security team finally reads the contract.
The exam's angle is usually the security clause. A vendor SLA that promises uptime and says nothing about breach notification, data handling or the right to audit is a business agreement, not a security control, and the answer to "what is missing" is the security requirement, not a faster response time.
Monitoring: the stage that separates programs from paperwork
Signing the contract establishes the trust. Monitoring is how you keep checking whether it is still deserved, and objective 5.3 names the tools.
Questionnaires are the workhorse: periodic self-assessments the vendor completes about their controls. They are cheap and they are self-reported, which is why they are paired with evidence of internal audits and independent assessments such as a SOC 2 report, which someone other than the vendor produced. The exam's ordering rule: a self-attestation is weaker than an internal audit, which is weaker than an independent assessment.
Rules of engagement appear here for a specific reason. If you want to penetration test a vendor's system, or a vendor is going to test yours, the scope, timing, methods and contacts have to be agreed in writing first. A scenario describing a test that touched systems the vendor did not expect is describing missing rules of engagement, and the fix is contractual, not technical.
Monitoring also means watching the SLA: a vendor that has missed its response-time target three months running is telling you something about their capacity before they tell you about their breach.
What to ask, and what counts as evidence
Vendor assessment fails when it becomes a form. A useful assessment is a small set of questions whose answers can be checked, and the exam's ordering of evidence tells you how to weight what comes back.
| Question | Weak evidence | Strong evidence |
|---|---|---|
| Do you encrypt our data at rest and in transit? | "Yes" on a questionnaire | an independent audit report that tested it |
| Who at your company can access our data? | a policy document | an access review export with names and dates |
| How quickly will you tell us about a breach? | a verbal assurance | a notification clause in the MSA with a defined window |
| Who are your subprocessors? | "industry-standard providers" | a published list you are notified about when it changes |
| Can we verify any of this? | a certificate logo on the website | a right-to-audit clause you have exercised |
The last row is the whole point. Certifications and attestations reduce the work of assessment, but they describe the vendor's controls at the time of the audit, against the scope the vendor chose. The right to check for yourself is what keeps the evidence honest, and a scenario that describes a vendor declining to provide evidence is a scenario about a missing clause, not a difficult vendor.
Offboarding: the step everybody forgets
Contracts end. VPN accounts, API keys, badge access and shared mailboxes frequently do not. The lifecycle's last stage is access revocation, data return or certified destruction, and a written confirmation that it happened. Orphaned vendor accounts are among the quietest ways into a network, for the same reason orphaned employee accounts are in identity and access management: nobody is watching an account nobody uses.
Key takeaways
- Third-party risk is a lifecycle: select, contract, onboard, monitor, offboard. The exam tests selection, the paperwork, and monitoring hardest.
- Due diligence is the investigation before signing; due care is the conduct afterwards. Conflicts of interest and supply chain depth are selection questions.
- The stack nests: MSA over SOW over SLA. General terms, then deliverables, then measurable performance. A number in the stem means SLA.
- NDA for secrecy, BPA for partners, MOU/MOA for intent. MOU is the informal, usually non-binding one.
- Right-to-audit lives in the MSA; rules of engagement govern testing. Self-attestation is weaker than internal audit, which is weaker than independent assessment.
Third-party risk is objective 5.3 of Security+ Domain 5, Security Program Management and Oversight, 20% of the exam, and it sits beside the risk management math the same domain tests. Work all 35 Domain 5 topics, from governance and risk through compliance, audits and awareness, with our Security+ Domain 5 study guide.
#SecurityPlus #SY0701 #ThirdPartyRisk #VendorManagement #SLA #MSA #SupplyChainRisk #GRC #CompTIA #CyberSecurity
Make the governance domain count
Risk management, third-party risk, compliance, and audits, Security+ Domain 5 is 20% of the exam. Study all 35 topics with our objective-mapped guide.
Get the Domain 5 guideKeep reading
Establish, Deploy, Maintain: Secure Baselines, Hardening Targets, BYOD vs. COPE vs. CYOD, and WPA3 on Security+
Objective 4.1 is the widest bullet in the biggest domain, and it hides its questions in verbs and ownership: which baseline step failed when settings drifted, which mobile model gives the least control, why WPA3 ends the offline handshake attack, which application control stops which flaw. The baseline lifecycle, hardening emphasis by device class, site surveys and heat maps, MDM and deployment models, 802.1X with RADIUS, and the application security checklist, decoded the way the exam asks them.
Read Security+ deep divesSPF, DKIM, DMARC, and Friends: The Enterprise Security Capabilities Security+ Expects You to Configure
Objective 4.5 is where Security+ stops asking what a control is and starts asking where it goes. Email authentication drawn as one flow (SPF checks the sender, DKIM signs the message, DMARC decides what happens), web and DNS filtering, DLP and what it can actually see, EDR versus XDR, NAC posture checks, file integrity monitoring, and the placement map that answers every scenario in the objective.
Read Security+ deep divesOn-Prem to Serverless: Architecture Models, the Line That Moves, and the Twelve Considerations Security+ Scores Them By
Objective 3.1 reads like a glossary, but the exam never asks for a definition. It describes a workload, names a constraint, and asks which model fits or which risk you accepted. Every model as one decision about how much of the stack you control: the responsibility line from on-prem to SaaS, IaC, serverless and microservices, air gap versus VLAN versus SDN, hypervisor versus kernel, the devices you cannot patch, and the twelve considerations that turn a stem into a rubric.
ReadFollow Skillthropic
Keep learning between study sessions
The same exam-focused teaching, in smaller pieces, wherever you scroll.
Enjoyed this? Get the AI security news that matters.
Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.
No spam. Unsubscribe anytime.