Security+ SY0-801 Third-Party Risk: Vendor Selection, Agreements and Monitoring

Third-party risk management is the process of choosing, contracting with, monitoring and constraining the outside organizations that handle your data, systems or services, so that their weaknesses do not become your breaches. A vendor with access to your network or customer records extends your attack surface, but you cannot configure its controls yourself; you can only select it carefully, bind it with agreements and check that it keeps its promises.

CompTIA Security+ objective 5.3 follows the vendor relationship from start to finish:

1. Vendor selection: asking the market (RFI, EOI, RFP, RFQ), investigating candidates (due diligence) and keeping the choice impartial (conflict of interest).
2. Agreements: the documents that turn expectations into obligations (MSA, SOW, SLA, SLO, NDA, MOU, MOA).
3. Vendor monitoring: checking the vendor over the life of the contract (right to audit, service-level monitoring, vendor registry, vendor assessment, compliance attestation, penetration testing).
4. Limitations and constraints: the practical reasons you cannot assess every vendor as deeply as you would like, and the assurance mechanisms that fill the gap.
5. Rules of engagement: the agreed limits on any testing or assessment you carry out against a vendor.

The deciding detail in most questions is timing (before or after a contract exists) and who acts (you examining the vendor, or an independent assessor the vendor hired). Risk registers, risk appetite and risk treatment belong to objective 5.2, and audit techniques such as sampling and interviews to objective 5.5; this lesson focuses on the vendor relationship itself.

The four solicitation documents differ by how well the buyer already knows what it wants: an RFI explores the market, an EOI builds a shortlist, an RFP asks for full proposals against defined requirements, and an RFQ asks only for prices on an exact specification.

Two pairs are easy to confuse:

• RFI vs EOI. Both come early. An RFI is about information: what is possible and who offers it. An EOI is about interest: which vendors want to compete and whether they meet basic qualifications. An EOI assumes the buyer already understands the need well enough to describe the opportunity.
• RFP vs RFQ. Both come after requirements exist. If vendors' methods will differ and you must compare solutions, you need proposals (RFP). If the item is fully specified and only cost is open, a quote (RFQ) is enough.

The documents can be chained. The buyer moves from open to closed questions as its knowledge grows: research first (RFI), optionally a shortlist (EOI), then proposals (RFP) when solutions must be compared, or quotes (RFQ) once the item is fully specified. Sequencing questions are solved by settling each step separately: what is unknown at the start, and what kind of answer is needed at the end.

Due diligence is the investigation of a prospective vendor before a contract is signed, covering its security practices, financial stability, reputation, breach and legal history, and compliance status. Its purpose is to find out whether the vendor can be trusted with what you plan to give it, while you still have the freedom to walk away or negotiate stronger terms.

Typical due diligence evidence includes:

• Security policies, security questionnaires and the vendor's own incident response arrangements.
• Independent reports and certifications (for example a SOC 2 report or an ISO/IEC 27001 certificate).
• Financial statements or credit checks, because a vendor that fails financially takes your service and possibly your data with it.
• Breach history, litigation, regulatory actions and references from other customers.
• The vendor's own suppliers and subcontractors (fourth parties), who may also touch your data.

Due diligence happens before the contract; checking delivered performance and controls after signing is vendor monitoring. The depth should match the risk: a vendor that will hold regulated data deserves far more scrutiny than one that delivers stationery.

A conflict of interest exists when a person who influences vendor selection has a personal or financial tie to a bidder, such as a financial stake, a close family or business relationship, or gifts and hospitality. Because the conflict sits with the person, not the vendor, it is managed at the person: the individual discloses it, and the organization removes (recuses) them from the decisions their interest could bias. The bidder itself has done nothing wrong, so the process stays fair to every vendor while the evaluation stays impartial.

Each agreement type answers a different question: the MSA sets the general terms of the relationship, a SOW defines one piece of work, an SLA defines the service levels and remedies, an SLO is one measurable target inside the SLA, an NDA protects shared information, and an MOU or MOA records cooperation between partners.

MSA vs SOW

If the terms must apply to every future engagement, they belong in the MSA. If they describe what will be delivered on one project, they belong in a SOW. A long-term managed-service relationship often needs both: the MSA for legal and commercial terms, a SOW for each project, and an SLA with its SLOs for ongoing service performance.

SLA vs SLO

The SLA is the agreement; the SLO is a target within it. A clause that names one metric, its value and how it is measured is an SLO. More generally, a SOW describes things a project produces, while SLAs and SLOs describe how well an ongoing service runs.

MOU vs MOA

Both are common between peers such as agencies, universities or partner organizations rather than buyer and supplier. An MOU records that the parties intend to cooperate without accepting binding obligations. When they need to pin down who provides what, under which conditions and how the arrangement can end, they move to an MOA. Whether a particular MOA is enforceable depends on its wording and the law that applies, but it is always the more formal, more specific document of the two.

When an NDA is the right tool

An MSA usually contains a confidentiality clause, but it only exists once a vendor is chosen. If you must share sensitive material earlier, for example source code shown to a prospective development partner or an architecture document needed to scope a proposal, a standalone NDA with each recipient protects it immediately.

Vendor monitoring is the ongoing checking of a vendor's performance and security controls for as long as the relationship lasts, using contractual audit rights, service-level monitoring, a vendor registry, periodic vendor assessments, compliance attestations and, where agreed, penetration testing. A vendor that was sound at signing can degrade, change subcontractors or suffer a breach, so a one-time check is not enough.

Right to audit

A right-to-audit clause gives the customer contractual permission to inspect how the vendor actually operates (its controls, records and facilities). The key feature is that the customer decides who carries out the audit: its own staff or an outside firm it selects. It must be negotiated into the contract; without it, the vendor can refuse. It provides deep but periodic insight, and it is only useful if it is actually exercised.

Service-level monitoring

Service-level monitoring continuously measures what the provider actually delivers against the SLA and its SLOs: uptime, response and restoration times, ticket handling. Its value is evidence. Without your own measurements, you cannot prove a missed target or claim the remedy the SLA promises. Where a requirement is ongoing evidence of performance, monitoring fits; an audit or an annual review is periodic.

Vendor registry

A vendor registry (or vendor inventory) lists every third party with what it does, which data and systems it can access, its business owner, its contract dates and its risk tier. You cannot manage vendors you do not know you have, and the registry is what makes risk-based prioritization possible.

Vendor assessment

A vendor assessment is a periodic review of a vendor's security posture, using questionnaires, evidence requests, attestation reports, interviews or on-site visits. The depth should follow the risk tier recorded in the registry: critical vendors (regulated data, privileged access, essential services) get in-depth, independently verified assessments; low-risk vendors get a lighter questionnaire or none. A questionnaire the vendor fills in about itself is self-reported, so on its own it is weak assurance for a high-risk relationship.

Compliance attestation is independent evidence, produced by an assessor the vendor engages, that the vendor's controls meet a recognised standard; it is the usual assurance mechanism when a vendor will not allow customers to audit or test it directly. Common forms are:

• SOC 2 report: an independent CPA firm's report on controls relevant to security, availability, processing integrity, confidentiality and privacy (the AICPA Trust Services Criteria).
• ISO/IEC 27001 certificate: confirms that an accredited certification body found the vendor's information security management system conforms to the standard.
• PCI DSS Attestation of Compliance (AOC): the formal declaration of a service provider's compliance with the payment card standard.

SOC 2 Type 1 vs Type 2

When a regulator or risk owner needs evidence that controls operate effectively, a Type 1 report is not enough; a Type 2 report is the stronger evidence. Always check that a report's scope covers the services you actually use and that its period is recent.

Why vendors refuse direct audits

Large cloud and SaaS providers usually will not let individual customers inspect or attack their shared underlying infrastructure. In a multitenant environment, one customer's on-site inspection or attack traffic against the shared platform could expose or disrupt other tenants, and thousands of separate audits would be impractical. (The major cloud providers do publish policies that let customers test their own deployed resources within stated rules; what they restrict is the shared infrastructure.) This is the environment constraint in action. The provider offers attestation reports instead, often through a self-service compliance portal under NDA. Attestation and audit rights are not interchangeable: with attestation, the vendor chooses the assessor and you receive the outcome; with a right to audit, you choose who looks and what they examine.

Penetration testing a vendor means simulating attacks against the vendor's systems that serve you, such as a vendor-hosted portal, and it must be both permitted by the contract and bounded by agreed rules of engagement. Testing a third party's systems without explicit written permission is unauthorized access, regardless of how much you pay that vendor.

Rules of engagement (ROE) are the agreed operational limits for any test or assessment. They typically define:

• Scope: the in-scope systems, applications and address ranges, and what is explicitly out of scope.
• Permitted techniques: for example whether social engineering, denial-of-service or exploitation of production data is allowed.
• Test windows: dates and times when testing may run.
• Contacts and escalation: who to notify, including emergency contacts if something breaks or a serious finding appears.
• Handling of findings and data: how results are reported and how any data accessed is protected.

A right-to-audit or penetration-testing clause grants permission in principle; it does not set these operational limits. A SOW may describe the testing engagement as a deliverable, but the ROE governs how testers must behave. Scope changes only through a documented change agreed by whoever authorized the test. Anything found beyond the agreed boundary is reported through the ROE's designated contacts, not explored further, so the system owner can decide whether to authorize more testing.

Penetration test types, reconnaissance methods and the wider assessment process are covered with audits and assessments in objective 5.5.

Third-party risk management is limited by people, money, time, location, law and the vendor's own leverage, which is why organizations prioritize by risk and rely on assurance mechanisms instead of auditing every vendor in depth. Security+ lists eight limitations and constraints:

Telling the near-twins apart

• Jurisdiction vs legal and regulatory factors. Jurisdiction is exposure created by where the vendor sits: whose courts and whose laws apply to it and its data. Legal and regulatory factors are the obligations on your organization that your vendors must help you meet.
• Vendor lock-in vs financial/ROI. A price rise you cannot escape is lock-in; the cause is dependence, and the price is the symptom. ROI asks whether a particular spend, such as an on-site assessment, is worth the risk it addresses.
• Staffing vs financial/ROI. Staffing is about having too few people; ROI is about spending that is not justified even if people were available.

Working within the limits

The standard answer to staffing and resource limits is risk tiering: record every vendor in the registry with its data access and criticality, then spend in-depth, independent assessment effort on the critical tier (for example every vendor handling regulated data) and lighter checks on the rest. Any approach that spreads effort without regard to risk can leave the most dangerous vendors unexamined. Lock-in is best reduced before signing, by requiring data export in open formats and exit assistance in the contract.