What to Do After a Third-Party Risk Assessment

After a third-party risk assessment, test the assumptions the risk tier and the approval rest on before the contract is signed, starting with what the assessment could not see. The questionnaire, the SOC 2 report and the criticality score all describe one company, and the breach that matters often arrives through a company nobody assessed.

A third-party risk assessment is a structured review of an external party's controls, criticality and exposure, used to assign a risk tier and set onboarding and contract conditions.

What a third-party risk assessment delivers

A third-party risk assessment starts with inventory and inherent risk. Each external party is scored on what it touches: data sensitivity, system access, operational criticality, regulatory exposure. That score sets the tier, and the tier sets how deep the due diligence goes. A stationery supplier gets a short form. A payroll processor or cloud host gets the full treatment, usually as one strand of a wider risk assessment programme.

The full treatment is familiar. A due diligence questionnaire, often a standardised one such as SIG or CAIQ, covering access control, encryption, incident response and subcontractor management. Independent evidence: a SOC 2 Type 2 report, an ISO 27001 certificate, a recent penetration test summary. Financial checks for viability. The assessor weighs controls against inherent risk and records a residual rating, usually plotted on a likelihood and impact grid.

The rating then drives the contract. High-tier vendors get right-to-audit clauses, breach notification windows measured in hours, data location commitments and a requirement to flow security terms down to subcontractors. Onboarding approval is made conditional on remediating findings. A reassessment cycle is set: annually for critical vendors, every two or three years for the rest. The tier becomes the decision: it sets the clauses, the approval conditions and the date the vendor is next examined.

Done properly, this is real work with real value. It forces an organisation to know who holds its data. It turns vague trust into specific contractual obligations. It produces an audit trail regulators recognise, and it follows a risk assessment process most security and procurement teams can run without outside help. A well-run third-party assessment produces a defensible, evidenced description of one company at one point in time.

What it leaves unexamined

That description is also the limit. A companion piece on what to do after a vendor risk assessment covers the vendor that was chosen and the access it receives. The harder gap in third-party assessment sits outside the vendor altogether, in places the method was never built to reach. There are three.

The first is time. A questionnaire is true on the day it is answered. A SOC 2 Type 2 report describes how controls operated over a past period, and it often reaches the customer months after that period closed. The tier is then trusted until the next scheduled review. Every attestation in the file describes the past, while the approval commits the organisation to the future.

The second is scope. The service auditor tests controls within a boundary the vendor defines, and SOC 2 reports commonly use the carve-out method for subservice organizations, which leaves the controls of the vendor's own suppliers outside the opinion. A questionnaire box ticked to confirm that subcontractors are assessed is recorded as a control. Whether that assessment was any good is a question nobody on the customer side can answer.

The third is concentration. Each vendor is assessed on its own file. If six critical vendors run the same file-transfer product or the same hosting provider, that shared dependency appears in none of the six assessments. It lands in the risk register as six medium entries instead of one high one. NIST's supply chain guidance, SP 800-161 Rev. 1, names the underlying problem: decreased visibility into how acquired technology is developed, integrated and deployed.

The residual rating measures the vendor, and the exposure frequently lives one or two layers beneath it.

Name the supplier your most critical vendor depends on and ask whether anyone assessed it before the contract was signed. Start the Walk →

When the gap cost British Airways, the BBC and Boots their staff data

MOVEit Transfer is a managed file transfer product sold by Progress Software. From 27 May 2023, the Cl0p ransomware group exploited a previously unknown SQL injection flaw, CVE-2023-34362, to install a web shell and pull data from MOVEit databases, according to the joint CISA and FBI advisory. Progress released a patch on 31 May. For many victims, the theft had already happened.

On 5 June, British Airways, the BBC and Boots each confirmed that staff data had been taken. None of them ran the compromised server. Their UK payroll provider, Zellis, did. Zellis said a "small number" of customers were affected and that "all Zellis-owned software is unaffected," as Computer Weekly reported. At the BBC, staff ID numbers, dates of birth, home addresses and National Insurance numbers were exposed. At BA, bank details were among the data at risk.

Nothing public describes how any of the three assessed Zellis, and there is no basis for assuming it was done badly. The point is structural. A payroll processor can answer a questionnaire truthfully about its own software, staff and controls and still carry this exposure. Its statement after the breach said as much. The weakness sat in a tool Zellis bought, which made it a fourth party to every customer whose data passed through it.

The scale made the concentration point plain. By mid-2024, Emsisoft's tracker counted 2,773 affected organisations and more than 95 million individuals. Many were hit through a supplier's server, not their own. Emsisoft described organisations hit because they "used a vendor which used a contractor which used a subcontractor which used MOVEit." A tier assigned to the first link in that chain says almost nothing about the last one.

One step before the contract is signed

The step belongs between the residual rating and the signature. The five-step method puts it in order. Frame the decision: what this third party is for, and what data or operations it will hold. List the Tentative Elements: the tier, the contract terms, the onboarding plan. Then surface the Assumptions each element rests on, before anyone treats the tier as settled.

For a critical third party, those assumptions are usually specific. Which fourth parties will hold or move the data, and which of them are carved out of the SOC 2 opinion. How old the evidence is relative to the contract term. Which other critical vendors depend on the same product or host. Whether the flow-down clause is ever checked, or only signed.

Sufficient Certainty is the fourth step: deciding how much testing is enough for this relationship. A stationery supplier does not need a fourth-party map. A payroll processor moving bank details through a file-transfer server does. The question of how much due diligence is enough gets answered per decision. The depth of testing should follow what breaks if an assumption fails, whatever tier the template assigned.

Implement and Monitor closes the loop. Skip the calendar reassessment. Name the signals that reopen the decision: a vulnerability advisory for a named dependency, a change of subcontractor, an acquisition of the vendor. A travel risk assessment needs the same list: a withdrawn escort or a changed route reopens the trip.

When the MOVEit advisory landed, an organisation with that dependency written down could have identified the same day which relationships to reopen.

A third-party approval is only as current as the assumptions recorded alongside it.

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.