Third-party risk management does not end when procurement approves a supplier or the contract is signed. Due diligence establishes an initial view of risk. It does not show whether that risk remains controlled once delivery is under way.
Technology programmes change. Architectures evolve, teams and subcontractors change, new dependencies emerge and temporary workarounds become permanent. Over time, delivery reporting can also diverge from what is happening within the programme.
For CTOs and Transformation Programme Directors, the continuing question is, can you demonstrate that the supplier is delivering what was agreed, operating the controls your organisation depends on and managing the technical risks that could affect the outcome?
This is the purpose of Trust & Verify – trusting the supplier to deliver while independently verifying the assumptions, controls and evidence on which the organisation relies.
Key takeaways
- Third-party risk management must continue throughout technology delivery rather than ending after due diligence.
- Supplier assurance should examine delivery evidence, dependencies and operating controls rather than relying on questionnaires, certifications and contractual commitments alone.
- Technology supplier risk includes delivery performance, architecture, security, data, resilience, subcontractors and the ability to exit.
- Verification should reflect the potential consequences of failure, with the most important suppliers and dependencies receiving the greatest scrutiny.
Technology delivery changes third-party risk
Third-party risk management, or TPRM, is the process of identifying, assessing, controlling and monitoring risks created by the external organisations on which a business depends.
These organisations can include software vendors, cloud providers, systems integrators, outsourced engineering teams, managed service providers, specialist consultancies and subcontractors further down the delivery chain.
The problem arises when TPRM is treated primarily as a procurement activity. The supplier completes a questionnaire, security teams review its certifications, legal agrees the contract and procurement records the relationship.
Delivery then begins and the risk starts to change.
Architectures evolve, delivery teams change, subcontractors are introduced and new technical dependencies emerge. The supplier assessed at the outset may no longer represent the risk the organisation faces six months later.
The FCA’s guidance on outsourcing and operational resilience makes this particularly clear for regulated financial services organisations. Firms must identify and manage operational risks throughout the lifespan of third-party arrangements and remain responsible for the regulatory obligations that apply to them.
The specific obligations vary between sectors, but the wider principle remains – responsibility for an outsourced outcome does not disappear when delivery passes to a third party.
A contract allocates responsibility. It does not prove that the responsibility is being discharged.
The contract must also make verification possible. Depending on the risk, this may require access to technical evidence, audit rights, notification of material changes and subcontractors, co-operation with testing and clear obligations covering remediation, data return and exit.
Without those provisions, an organisation can remain accountable for a risk without having the access or information needed to assess it properly.
Technology leaders must therefore look beyond the supplier’s corporate risk profile and examine the risk within the delivery itself.
| Risk area | What needs verifying | Useful evidence |
|---|---|---|
| Delivery | Is the programme genuinely progressing? | Working software, delivery metrics, backlog evidence and release history |
| Architecture | Are critical dependencies understood? | Architecture diagrams, dependency maps and recorded technical decisions |
| Security | Are the agreed controls operating effectively? | Security-test results, vulnerability reports, access reviews and remediation evidence |
| Data | Who can access, process or transfer important data? | Data-flow maps, access records and processor or subprocessor information |
| Resilience | Can the service continue or recover if a dependency fails? | Recovery tests, incident exercises and continuity evidence |
| Subcontractors | Which other organisations are involved in delivery? | Supplier registers, sub-outsourcing details and responsibility mapping |
| Governance | Are material risks visible to decision-makers? | Risk registers, decision logs and exception records |
| Exit | Can the organisation change supplier or bring the capability back? | Tested exit plans, current documentation, data-return provisions and knowledge-transfer arrangements |
This is how third-party risk becomes technology delivery risk.
Map the dependencies that matter
Effective verification starts with understanding what the organisation depends on to deliver an important business or service outcome.
The supplier register alone will not provide that view. Technology leaders need to identify the systems, people, datasets, platforms and external organisations that must continue to function for the outcome to be delivered.
Supplier size is a poor measure of operational importance. A small provider may support a critical component for which there is no immediate substitute, while a much larger supplier may be relatively straightforward to replace.
The NCSC’s Supply Chain Security Guidance recommends understanding suppliers, their access and relevant subcontracting relationships, then prioritising assurance according to the risk they create.
The practical question is; what could materially disrupt this outcome and which third parties sit in that path?
Without that map, supplier assurance remains generic. With it, the organisation can concentrate scrutiny on the dependencies whose failure would have the greatest effect.
Verify supplier claims against delivery evidence
Once the dependencies are understood, the organisation needs evidence that important supplier claims remain true.
- If testing is reported as complete, review the test results and unresolved defects.
- If a platform is described as resilient, establish what recovery testing has taken place and what it demonstrated.
- If delivery is reported as on track, inspect working software, delivery metrics and release history rather than relying on a status colour.
- If security requirements have been met, identify which controls were tested, what issues remain and who accepted any exceptions.
This is the distinction between governance and assurance. Governance defines what should happen. Assurance establishes whether it is happening.
The evidence must also support the decisions leaders need to make. That includes whether the programme is ready to go live, whether the architecture creates an unacceptable risk, whether remediation is achievable and whether continuing with the current supplier remains the right course.
Good third-party assurance makes those decisions possible before problems become a crisis.
Build verification into active delivery
Controls are often assessed at the start of a programme and checked again near the end. Risks that emerge between those points can remain hidden until the organisation has fewer options.
An approved architecture may change during implementation. Testing can appear healthy until integration exposes unresolved dependencies. A supplier may meet contractual milestones while accumulating technical debt that makes the service fragile or expensive to operate.
Adding more stage gates will not necessarily expose those problems. Verification needs to sit close enough to delivery for leaders to see changes while there is still time to respond.
This is also the difference between technical due diligence and ongoing delivery assurance. Catapult CX’s guide to technical due diligence reports explains how evidence supports technical decisions before a commitment is made.
Due diligence asks whether the proposition is credible before the organisation commits. Ongoing assurance establishes whether it remains credible during delivery.
Monitor changes in third-party risk
Third-party risk changes throughout the relationship. Reassessment may be required when a supplier:
- changes ownership
- introduces a new subcontractor
- replaces a critical technology
- moves part of the service or its data
- suffers a security or operational incident
- loses key personnel; or
- becomes more difficult to replace
In UK financial services, the FCA expects firms to manage risk throughout the lifespan of third-party arrangements and apply relevant controls across the extended supply chain. The specific regulatory obligations vary by sector and organisation, but the operating requirement is consistent – the organisation must notice material changes and reassess the risk when they occur.
An assessment completed at the start of the relationship cannot validate a dependency that has since changed.
Maintain an executable exit
An exit clause does not necessarily provide an executable exit.
The organisation needs to understand:
- where its data is held and how it will be returned or deleted
- whether technical and operational documentation is current
- who holds the knowledge needed to operate the service
- which components and environments can be transferred
- what intellectual-property or licensing restrictions apply
- whether another supplier or internal team could take over; and
- how long substitution would realistically take
These questions should be tested during the relationship rather than considered for the first time when the supplier needs to be replaced.
For systemic cloud dependencies in UK financial services, exit planning overlaps with regulatory concerns about concentration and substitutability. Catapult CX covers this narrower issue in its guide to the UK Critical Third Party regime and cloud concentration risk.
The same practical principle applies to technology suppliers more broadly. A dependency the organisation cannot explain, recover or exit requires greater scrutiny than one it can.
What should a supplier risk assessment verify?
The depth of a supplier risk assessment should reflect the service’s importance, the sensitivity of the information involved, the supplier’s access, the availability of alternatives and the consequences of failure.
A low-risk commodity application should not receive the same scrutiny as a systems integrator building a regulated customer platform or a provider processing sensitive information.
For organisations using data processors, the ICO’s guidance on contracts and due diligence recommends checks proportionate to the processing risk. Depending on that risk, the evidence may include site visits, system testing, audit requests and regular compliance checks.
For technology delivery, a practical supplier risk framework should answer four questions.
- What could go wrong?
Identify the effect on the organisation if the supplier underperforms, suffers a security incident, loses or exposes data, experiences an outage or can no longer provide the service.
The assessment should consider both the likelihood of failure and the potential effect on customers, operations, regulatory obligations and delivery outcomes.
- What are we relying on the supplier to do?
Define the services, controls and responsibilities the supplier owns, including any responsibilities shared with the organisation or another provider.
This is particularly important at organisational boundaries. A control can fail because the supplier believes the client owns it while the client assumes the supplier is responsible.
- What evidence demonstrates that it is happening?
Specify the testing, artefacts, records and operating evidence required to provide reasonable assurance.
The evidence should correspond to the claim being assessed. A certification may provide useful information about the supplier’s wider control environment, but it does not necessarily demonstrate that a specific project, service or technical control is operating effectively.
- What happens if the evidence changes?
Define the events that trigger reassessment and agree the relevant escalation thresholds, remediation actions, decision owners and timescales.
This allows the organisation to respond when evidence weakens rather than waiting until the programme reaches a crisis.
Together, these questions turn a supplier risk assessment from a point-in-time document into an operating mechanism for managing risk throughout delivery.
8 warning signs that supplier risk is affecting delivery
Third-party risk does not always appear as a formal supplier issue. It often shows up as recurring delivery friction.
| Warning sign | What may be causing it | What to verify |
|---|---|---|
| Continual re-baselining | Weak delivery capability, unrealistic assumptions or unresolved dependencies | Completed outcomes, blockers, capacity and the assumptions behind the original plan |
| Consistently green RAG reporting | Weak challenge, unsuitable measures or risks excluded from reporting | Underlying delivery measures, unresolved risks and confidence in forecasts |
| Security issues discovered late | Security assurance operating separately from engineering | Security ownership, test timing, unresolved findings and accepted exceptions |
| Dependence on named supplier personnel | Key-person risk and knowledge concentrated with individuals | Current documentation, succession arrangements and evidence of knowledge transfer |
| Repeated change requests | Weak scope control, incomplete discovery or misunderstood architecture | Original requirements, decision history and the root cause of each change |
| Resistance to technical scrutiny | Limited transparency, unclear responsibility or inadequate evidence | Contractual access rights, requested evidence and ownership of the relevant controls |
| Previously undisclosed subcontractors | Unassessed fourth-party access or dependency | Who is involved, what they provide, which data or systems they can access and whether approval was required |
| Exit arrangements remain untested | Lock-in, undocumented dependencies or unrealistic substitution assumptions | Exit responsibilities, data return, knowledge transfer, transition timescales and alternative provision |
None of these signs proves that a supplier is failing. Each indicates that the organisation needs better evidence before deciding whether to continue, intervene or change course.
Effective assurance should make those decisions faster. It should concentrate on the suppliers and dependencies that matter, define the evidence expected from each party and make exceptions and remediation actions visible to the people accountable for them.
Collecting more information is not the objective. The purpose is to establish enough control and evidence to make a sound decision while viable options remain.
When independent third-party risk verification is needed
Most supplier relationships can be managed through effective collaboration between the organisation and the supplier.
Independent verification becomes valuable when the available reporting no longer gives leadership sufficient confidence. This may happen when delivery is repeatedly re-baselined, status reporting conflicts with what teams are experiencing, security and engineering disagree over readiness, responsibility is disputed or costs continue to rise without corresponding evidence of progress.
At that point, another status meeting is unlikely to resolve the underlying uncertainty. Leadership needs an evidence-based view of the programme.
Catapult CX’s Trust & Verify Advisory examines whether the programme narrative is supported by the technical and delivery evidence. It establishes:
- what is happening within the programme
- the causes of the current position
- which risks could materially affect the outcome
- who owns those risks
- what can realistically be remediated; and
- which decision leadership now needs to make
The evidence may support continuing with confidence, requiring remediation, changing direction or concluding that further investment is no longer justified.
The value lies in replacing assumption with evidence that supports a clear leadership decision.
Trust is the starting point and verification maintains control
Organisations will continue to depend on technology suppliers. Effective third-party risk management makes those dependencies visible, testable and manageable throughout delivery.
Contracts, certifications and due diligence establish the starting position. Ongoing verification shows whether the supplier, controls and delivery remain dependable as the programme changes.
Trust is the commercial starting point. Verification is the operating discipline.
Frequently asked questions about third-party risk management
What is third-party risk management?
Third-party risk management is the process of identifying, assessing, controlling and monitoring risks created by external organisations on which a business depends.
These can include suppliers, software vendors, cloud providers, contractors, consultants, delivery partners and outsourced service providers. The risks commonly include operational resilience, cyber security, data protection, regulatory compliance, financial viability, technology delivery and the ability to exit.
What is a supplier risk assessment?
A supplier risk assessment examines the risks created by using a particular supplier and whether appropriate controls exist to manage them.
The depth of the assessment should reflect the importance of the service, the sensitivity of the information involved, the access granted to the supplier, the availability of alternatives and the consequences of failure.
How should organisations prioritise suppliers for assessment?
Prioritisation should reflect the potential effect of failure rather than supplier size or contract value alone.
The greatest scrutiny should apply to suppliers that support important services, access sensitive information, operate critical controls, create difficult-to-replace dependencies or rely on subcontractors that introduce additional risk.
What is the difference between vendor risk management and third-party risk management?
The terms are often used interchangeably.
Vendor risk management usually focuses on organisations supplying products or services. Third-party risk management is broader and can also cover contractors, consultants, outsourcers, strategic partners and other external organisations on which the business depends.
Does completing supplier due diligence remove third-party risk?
No. Due diligence establishes a view of the supplier and its risks at a particular point in time.
Technology, ownership, personnel, subcontractors, threats and delivery arrangements can all change. Material supplier risks therefore require monitoring and reassessment throughout the relationship.
What is the difference between supplier due diligence and ongoing assurance?
Supplier due diligence assesses whether the proposed arrangement is credible and appropriately controlled before the organisation commits.
Ongoing assurance examines whether the supplier, delivery and controls continue to meet the organisation’s requirements after the relationship has begun.
What evidence should a technology supplier provide?
The evidence depends on the service and level of risk. It may include:
- working software and release history
- delivery metrics and backlog information
- architecture and dependency documentation
- security-test results and remediation records
- access reviews and data-flow information
- recovery tests and incident exercises
- subcontractor details
- risk, decision and exception records; and
- current exit and knowledge-transfer plans
The evidence requested should correspond to the specific claim or control being assessed.
What is fourth-party risk?
Fourth-party risk arises from organisations used by a direct supplier to help provide its service.
These can include subcontractors, cloud platforms, software providers and specialist delivery partners. The organisation may not contract with them directly, but their disruption, security failures or access to data can still affect the service it receives.
Who is responsible for third-party risk in a regulated organisation?
Responsibilities depend on the organisation and regulatory regime, but outsourcing a service does not automatically transfer accountability for the outcome.
In UK financial services, the FCA states that firms remain responsible and accountable for the regulatory obligations applying to outsourcing and third-party service arrangements. Technology, security, procurement, legal, risk and business owners may all contribute to managing the relationship, but accountability must remain clearly assigned within the organisation.
