A cloud provider's status page shows the customer portal was down for six hours in March, and the customer's operations team assumes it is owed money. Whether it is depends on documents most of the team never read: whether the provider's number was a contractual commitment or just a target, how downtime is measured, and what remedy the contract names.
On the CompTIA Security+ SY0-801 exam, agreement types sit under objective 5.3, which expects you to explain how organizations manage the risk of working with third parties. This lesson covers the seven agreements the objective names: SLA, SLO, MOU, MOA, NDA, MSA and SOW. It shows what each one does, how the commonly confused pairs differ, and how a scenario's wording points to the right one.
Agreements turn a vendor's promises into obligations you can enforce
Due diligence tells you whether a vendor can protect your data. The agreement is what obliges it to. Security requirements that never reach a signed document are good intentions at best.
Agreements rarely stand alone. A typical enterprise vendor relationship is a set of documents: an NDA signed early so both sides can share sensitive information during evaluation, an MSA with the legal terms for the whole relationship, an SLA setting service levels, and one or more SOWs for specific pieces of work. Privacy and sector rules add their own addenda. GDPR requires a contract between a controller and its processor, usually called a data processing agreement (DPA), and HIPAA requires a business associate agreement (BAA) before a vendor handles protected health information for a covered entity. Because these documents can contradict each other, an MSA often includes an order-of-precedence clause that says which one wins.
Security teams care most about the clauses that decide what happens when something goes wrong: incident notification deadlines, required security controls, audit rights, limits of liability, data return and deletion at termination, and which jurisdiction's law governs a dispute.
An SLA is a contractual commitment with consequences
A service-level agreement (SLA) defines the level of service a provider commits to deliver, how it will be measured and what happens if the provider falls short. It can be a section of an MSA or a separate document. Common metrics are availability and support response and resolution times. For security services, an SLA may also cover the time to notify the customer of an incident or to patch a critical vulnerability.
A useful SLA is precise. "High availability" can't be measured; this can:
Service availability: 99.9% per calendar month, measured at the provider's
API endpoints in 1-minute intervals. Scheduled maintenance
announced at least 5 business days ahead is excluded.
Service credits: below 99.9% -> 10% of the monthly fee
below 99.0% -> 25% of the monthly fee
Severity 1 incidents: response within 15 minutes, 24x7
Security incidents: customer notified within 24 hours of confirmation
Do the arithmetic before signing. A 30-day month has 43,200 minutes, so 99.9 percent allows 43.2 minutes of downtime and 99.99 percent allows about 4.3 minutes. Exclusions matter as much as the number: if maintenance windows and events outside the provider's control don't count, the real commitment may be much weaker than it looks.
The usual remedy is a service credit, a percentage of the fee refunded or applied to future bills. Credits are small next to the business cost of an outage, and many SLAs require the customer to claim them within a fixed window, often 30 to 60 days. Repeated or severe failures may give the customer the right to terminate. An SLA doesn't make a service resilient. If the business can't tolerate six hours offline, it needs redundancy and continuity planning, not a better credit schedule.