Third-party risk: assessing and selecting a vendor

Objective 5.3 in this course covers third-party risk — CompTIA's scope note for it manages vendor assessment, selection, agreements, monitoring, questionnaires and rules of engagement. This lesson takes assessment and selection; agreements and ongoing monitoring are the next lesson.

Why this matters

Domain 2 established supply chain as an attack vector that passes every conventional control, because 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.

That is why it sits in Domain 5. You cannot patch a supplier. What you can do is choose them carefully, write the contract so you have rights, and check.

The lesson

Vendor assessment, penetration testing and right-to-audit clauses

Vendor assessment is evaluating a third party's security before you depend on them, and the methods vary enormously in cost and in how much they actually tell you.

From weakest to strongest evidence:

• Self-attestation — the vendor says they are secure. Free, and worth roughly what it costs.
• Security questionnaire — structured self-reporting. Better, still self-reported; covered below.
• Independent assessment / third-party audit report — SOC 2 Type II, ISO 27001 certification, or a sector-specific attestation. Someone independent has looked. Read the scope: a SOC 2 covering one product line says nothing about the one you are buying, and a Type I reports design at a point in time where a Type II reports operating effectiveness over a period.
• Evidence of internal audits — the vendor's own audit findings and how they were closed. Revealing when a vendor will share it.
• Penetration testing — either the vendor's own reports, or a test you commission. The strongest and most expensive, and it needs the contract to permit it, which is the next point.
• Supply chain analysis — looking past the vendor to their suppliers and sub-processors, because your risk includes theirs. This is routinely skipped and is where an MSP's own compromised tooling reaches you.

A right-to-audit clause is the contractual right to inspect the vendor's controls, or to have an independent party do so. It must be negotiated before signing, because afterwards you have no leverage — this is the acquisition point from Domain 4's asset management, applied to services. Large vendors frequently refuse a bespoke audit and offer their standard attestation instead, which is a reasonable outcome provided you have read the scope.

The assessment should be proportionate to the risk: what data the vendor will hold, what access they will have, and how badly their failure would hurt. A payroll processor holding every employee's bank details and a stationery supplier do not get the same scrutiny, and a process that treats them equally either over-burdens the trivial or under-examines the critical.

Evidence of internal audits, independent assessments and supply chain analysis

Reading the evidence is a skill, and the exam expects you to know what these documents do and do not say.

• An ISO 27001 certificate says a management system exists and has been audited against the standard. It is about process, and its statement of applicability is where the substance is — which controls were in scope and which were excluded.
• A SOC 2 report describes controls against the trust services criteria. Type II covers a period, typically 6–12 months, and includes the auditor's testing and any exceptions found. The exceptions section is the part worth reading first; a report with none is either excellent or narrowly scoped.
• A penetration test report is a point in time against a defined scope. Ask when, what was in scope, and — the question people forget — whether the findings were retested.

The recurring failure: accepting a certificate as a pass without reading the scope. A vendor can be genuinely certified for a data centre in one country and process your data in another, entirely outside the certified scope.

Supply chain analysis extends this to fourth parties. Where does the vendor host? Who are their sub-processors? What software do they embed? Privacy regulation generally requires you to know the sub-processors handling personal data, and a software bill of materials from Domain 2 answers the embedded component question.

Due diligence and conflict of interest at selection

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, and the security consequence is an unplanned, rushed migration — or data stranded somewhere.
• Legal and regulatory standing. Sanctions, ownership, jurisdiction, and past enforcement actions.
• Security posture, from the assessment above.
• Operational track record. Incident history — and more informative than whether they have had one, how they handled it. A vendor who disclosed promptly and published a root cause is a better bet than one with no public incidents and no disclosure culture.
• Reputation and references, ideally from customers you found rather than ones they chose.

Conflict of interest is CompTIA's explicit item, and it applies 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 also audits you, or who serves your direct competitor with the same team, has a structural conflict that should be declared and managed.

The control is procedural: declared interests, separation of duties between whoever specifies, selects and approves, and a documented rationale for the choice. This is the separation-of-duties principle from Domain 4 applied to procurement, and it exists because procurement fraud and captured selection are real and common.

Questionnaires, and the answer you cannot verify

A security questionnaire is the standard instrument: a structured set of questions the vendor answers about their controls. Standard frameworks (CAIQ, SIG and similar) exist so vendors are not answering a different questionnaire for every customer.

Their strength is coverage and comparability, cheaply, across many vendors. Their weakness is the heading: every answer is self-reported, and most cannot be verified. "Do you encrypt data at rest?" gets a yes. Whether that means full-disk encryption on the host, or field-level encryption with keys you control, or a checkbox somebody ticked, is not visible in the answer.

How to make them worth something:

• Ask for evidence, not assertions. Not "do you have a policy" but "attach it"; not "do you test backups" but "when did you last restore, and what was the result".
• Ask questions with checkable answers. Version numbers, dates, named standards, specific configurations.
• Cross-check against the independent report. A questionnaire answer that contradicts the SOC 2 exceptions is the most useful finding a questionnaire produces.
• Scale the depth to the risk, and do not send a 400-question document to a supplier who will never touch your data — you will get it back completed carelessly, which is worse than not asking.
• Make the answers contractual. An answer incorporated into the agreement becomes a representation you can act on if it turns out to be false, which is the single thing that converts a questionnaire from paperwork into leverage.

Rules of engagement for a third party working inside your estate

Rules of engagement define what a third party may do, when, and how — and CompTIA lists them under third-party risk rather than under penetration testing alone, because they apply to any external party operating in your environment.

For a penetration test or assessment, they cover: scope (which systems, which addresses, which applications), what is explicitly out of scope, permitted techniques (is social engineering allowed, is denial of service excluded), testing windows, the points of contact on both sides, escalation if something breaks or if a live compromise is found, data handling for anything they extract, and written authorisation. The last is not a formality — without it, the testing is unauthorised access.

For a vendor with operational access — an MSP, a support engineer, an implementation consultant — the same ideas apply as standing controls:

• Named individual accounts, never a shared vendor login, so actions are attributable;
• Least privilege scoped to what they actually need;
• Time-bounded access, ideally just-in-time from Domain 4, enabled for the work and disabled after;
• Monitored and recorded sessions, so what they did is reviewable;
• Defined change and notification obligations — what they must tell you and when;
• and defined offboarding, because vendor access that outlives the contract is one of the most durable holes in any estate.

The exam's framing: 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

• Negotiate the right-to-audit clause before signing; afterwards you have no leverage.
• Read the scope of a certification and the exceptions in a SOC 2 Type II — Type I is design at a point in time, Type II is effectiveness over a period.
• Questionnaire answers are self-reported; ask for evidence, cross-check against the independent report, and make the answers contractual.
• Assessment depth should be proportionate to the data and access involved.
• Conflict of interest applies to the selector and to the vendor, and is managed by declaration and separation of duties.
• Third parties get named accounts, least privilege, time-bounded access and session monitoring — never a shared login.