Vendor agreement types — SY0-701

WHAT IT IS

A vendor agreement is a formal, documented arrangement between an organization and an external party — a commercial supplier of software or hardware (NISTIR 4734) — that governs the terms of a relationship. Different agreement types address different dimensions of that relationship: performance expectations, information-sharing boundaries, interconnection security, and contractual obligations. Security professionals select and apply the right agreement type to ensure accountability and protect information assets when third parties are involved.

Mental model

Think of vendor agreements as a layered set of commitments, each answering a distinct question:

• What can be shared and with whom? → NDA
• What is the provider expected to deliver, and how well? → SLA
• What exactly will be built or done under this contract? → SOW / Contract
• How are two connected systems kept secure at the boundary? → ISA

No single agreement answers all four questions. Real engagements often require more than one type working together.

When to use it

Agreement type	Primary purpose	Key NIST grounding
Service Level Agreement (SLA)	Defines responsibilities of the service provider and sets customer expectations, including performance, reliability, and response times	CNSSI 4009-2015; NIST SP 800-47 Rev. 1
Interconnection Security Agreement (ISA)	Specifies information security requirements for connections between systems in different authorization boundaries, including requirements tied to the impact level of information exchanged	CNSSI 4009-2015; NIST SP 800-47 Rev. 1
Non-Disclosure Agreement (NDA)	Delineates specific information, materials, or knowledge that signatories agree not to release or divulge to any other parties	NIST SP 800-47 Rev. 1
Statement of Work (SOW)	Specifies what a developer or vendor must accomplish under a contract, including documentation requirements and security assurance specifications	NISTIR 7622
Contract	The mutually binding legal relationship in which the seller furnishes supplies, services, or construction and the buyer provides payment; the overarching legal instrument	NISTIR 7622, citing 48 C.F.R.
Business Associate Agreement (BAA)	Governs the handling of protected health information between covered entities and their business associates	NIST SP 800-66r2

The ISA is typically accompanied by a formal agreement — such as an MOA or MOU — that defines management roles and responsibilities (NIST SP 800-47 Rev. 1). These two instruments are complementary, not interchangeable.

COMMON MISCONCEPTION

The most common confusion is treating an SLA and an ISA as alternatives to each other. They address fundamentally different concerns. An SLA sets performance expectations — what the provider will deliver and at what quality level (CNSSI 4009-2015). An ISA addresses security requirements specifically for the technical connection between systems in different authorization boundaries (NIST SP 800-47 Rev. 1). A scenario describing two organizations directly connecting their networks to exchange data is an ISA problem, not an SLA problem — even if service quality is also mentioned.

A second trap: assuming a contract alone is sufficient. The NISTIR 7622 definition of a contract establishes the legal and payment relationship, but a contract does not inherently specify what the developer must build (that is the SOW) or what information cannot be shared externally (that is the NDA). Each instrument carries a distinct function.

How it shows up on the exam

Exam questions for this topic typically test application — given a scenario describing an organizational need, candidates must identify which agreement type is appropriate. The cognitive target is distinguishing between agreement types that sound similar but serve different purposes.

Signal phrases to notice:

• "Two organizations are connecting their networks to share data" — points to an ISA, because NIST SP 800-47 Rev. 1 defines system interconnection as a direct connection between systems in different authorization boundaries.
• "The provider must meet defined uptime and response time targets" — points to an SLA, because CNSSI 4009-2015 defines the SLA as setting customer expectations about service responsibilities and performance levels.
• "The vendor must not disclose proprietary data" — points to an NDA, defined in NIST SP 800-47 Rev. 1 as delineating what signatories agree not to release.
• "Specifying the exact deliverables and security documentation a contractor must produce" — points to a SOW, as defined in NISTIR 7622.

Candidates who miss this topic often focus on the word "agreement" and anchor on the legal relationship (contract) for every scenario. The exam exploits this by presenting scenarios where the legal relationship already exists and asking what additional instrument is needed.

Related concepts

• Third-Party Vendor Assessment
• Vendor Monitoring
• Security Governance