Third-party risk: selecting a vendor, the agreement, and monitoring after the ink dries

Objective 5.3 covers how an organisation assesses and manages the risk that comes with depending on someone else: choosing the supplier, writing down what they owe you, checking that it stays true, and controlling what they do inside your environment. This one lesson carries the whole life of a vendor relationship, and it is the applied lab for 5.3.

Why this matters

Domain 2 established the supply chain as a threat vector that passes every conventional control: the malicious update is correctly signed, and the vendor's access is supposed to work. This objective is the answer to that, and the answer is contractual and procedural rather than technical. You cannot patch a supplier. You can choose them carefully, write the contract so you have rights, and keep checking.

The agreement acronyms are near-certain exam items and pure recall. The monitoring half matters for a different reason: vendors are usually assessed thoroughly once, at selection, and then never again. The vendor's security three years later is not the security you assessed.

The lesson

Selecting a vendor: the request documents, due diligence and conflicts of interest

Procurement has a standard sequence of request documents, and each asks a different question:

• RFI (request for information): "tell us what you offer". Used early, to learn the market and the capabilities available before the requirement is fixed.
• EOI (expression of interest): suppliers signal that they want to be considered, often with enough detail to shortlist them. It narrows the field before the expensive stage.
• RFP (request for proposal): "here is our problem, propose a solution". Used when the requirement is known but the approach is open. This is where your security requirements must appear, because a supplier prices only what you asked for.
• RFQ (request for quote): "here is exactly what we want, what will it cost". Used when the requirement is fully specified and price is the main difference.

Due diligence is the investigation before you commit, and it is broader than security: financial stability (a vendor that fails takes your service with it), legal standing and ownership, security posture from the assessment evidence, incident history and how they handled it, and references you found rather than ones they chose. Scale it to the risk: a payroll processor holding every employee's bank details and a stationery supplier do not get the same scrutiny.

A conflict of interest runs in two directions. On your side, the person selecting must not have an undisclosed interest in the vendor: a relationship, a shareholding, a future job. On the vendor's side, a supplier who would also audit the work they delivered has a structural conflict. The controls are procedural: declared interests, separation of duties between whoever specifies, selects and approves, and a written rationale for the choice.

Agreement types from the SLA and its objectives to the MSA, SOW and NDA, and what each is for

• SLA (service-level agreement): the provider's measurable commitments (availability, response times, resolution times) and the remedies if they are missed. Security-relevant terms belong here too: incident notification within a stated time, patching deadlines, support for security issues.
• SLO (service-level objective): one specific, measurable target inside the SLA, such as 99.9% monthly availability or a four-hour response to a critical ticket. The SLA is the agreement; each SLO is a number in it.
• MOU (memorandum of understanding): a record of shared intent between parties, generally not legally binding.
• MOA (memorandum of agreement): a step firmer. It records agreed roles and commitments and is normally intended to bind, though it is less detailed than a full contract.
• MSA (master services agreement): the umbrella contract that sets the standing terms (liability, confidentiality, security requirements, dispute resolution) once, so each piece of work does not renegotiate them.
• SOW (statement of work): the deliverables, timeline and price for one particular piece of work, executed under an MSA.
• NDA (non-disclosure agreement): obliges the parties to protect confidential information. Signed before any meaningful assessment, because it is what makes it safe to share architecture or findings.

The distinctions the exam tests: MOU is non-binding intent, MOA is agreed commitment; MSA is the standing terms, SOW is this job; SLA is the agreement, SLO is a target within it. When a scenario stresses that something is not legally binding, the answer is almost always MOU.

Clauses worth knowing as belonging in these documents: breach notification within a stated period, the right to audit, approved sub-processors, data location, encryption, data return and destruction at termination, and liability for a breach.

Monitoring: right to audit, service levels, vendor assessments, attestations and the vendor registry

Vendor monitoring is continuing to check after signature. Vendors get acquired, change sub-processors, move hosting to another region, lose key staff, let certifications lapse, and have incidents.

• Right to audit: the contractual right to inspect the vendor's controls, or have an independent party do so. Negotiate it before signing; after that you have no leverage. Large providers often offer their standard independent report instead, which is reasonable if you read its scope.
• Service-level monitoring: measuring the SLOs yourself. If the vendor self-reports, the number is whatever their monitoring says. Read what is excluded (planned maintenance, their definition of "down"), and remember that a service credit worth a few percent of one month's fee is not compensation for an outage that stopped your business.
• Vendor assessments: scheduled reassessment, at a cadence proportionate to risk, written into the contract and the calendar. Questionnaires are useful for coverage but every answer is self-reported; ask for evidence, not assertions, and make key answers contractual. Penetration testing, either the vendor's own reports or a test you commission where the contract allows, is the strongest assessment evidence.
• Compliance attestations: formal statements of compliance, such as a SOC 2 Type II report or a PCI DSS attestation of compliance. Check that they are current and that their scope covers the service you actually buy. A report covering one product line says nothing about another.
• Vendor registry: the central list of every third party, with what data and access each has, its criticality, contract dates, named business owner, and next review. It is asset management applied to suppliers. An unowned vendor is an unmonitored vendor, and the registry is also what makes offboarding complete: when a contract ends, every account, API key, OAuth grant and integration the vendor held must end with it.

Constraints: lock-in, jurisdiction, staffing, cost and the assurance you can actually obtain

Third-party risk management happens under real limits, and good answers acknowledge them:

• Vendor lock-in: proprietary formats, integrations and skills make leaving expensive, which weakens every lever you have. Ask about data export and exit assistance at selection, not at termination.
• Geography and jurisdiction: where the vendor and its data sit decides which laws apply, which authorities can demand access, and where a dispute is heard. A service hosted in another country may be lawful to use only with specific safeguards.
• Legal and regulatory factors: some sectors restrict what may be outsourced, or require particular terms in the contract.
• Staffing and resource availability: assessing hundreds of vendors takes people you may not have. That is why assessment depth is tiered by risk.
• Environment: the operating context you are buying into, such as a shared multi-tenant platform you cannot configure, limits which controls you can require.
• Financial and ROI: the cost of assurance (audits, tests, contract negotiation) must be proportionate to the risk and the value of the service.
• Assurance mechanisms: what evidence you can actually obtain. A dominant provider may refuse a bespoke audit and offer only its standard report. Recognise when you have accepted a residual risk because better assurance was not available, and record it in the risk register.

Rules of engagement for a third party testing or working inside your estate

Rules of engagement define what a third party may do, when and how.

For a penetration test or assessment: scope (systems, addresses, applications), what is explicitly out of scope, permitted techniques (is social engineering allowed, is denial of service excluded), testing windows, contacts on both sides, escalation if something breaks or a real compromise is found, handling of any data obtained, and written authorisation. Without that authorisation, testing is unauthorised access.

For a vendor with operational access (a managed service provider, a support engineer, an implementation consultant), the same ideas become standing controls:

• named individual accounts, never a shared vendor login;
• least privilege scoped to the work;
• time-bounded access, enabled for the job and removed afterwards;
• monitored and recorded sessions, so what they did can be reviewed;
• defined notification duties: what they must tell you, and how fast.

The third party's access is your risk, and the controls that manage it are the ones you write down before they start.

What to take into the exam

• RFI learns the market, EOI shortlists, RFP asks for a solution, RFQ asks for a price.
• MOU is non-binding intent; MOA records binding commitments. MSA is standing terms; SOW is one job. The SLA is the agreement; an SLO is a target in it.
• Negotiate the right to audit before signing, and measure service levels yourself.
• Check an attestation's date and scope before relying on it.
• The vendor registry records every third party, its access, its owner and its next review.
• Third parties get named accounts, least privilege, time-limited access and written rules of engagement.