Third Parties, First Principles: Auditing Supplier Trust Without Stalling the Deal
UK enterprises now run substantial parts of their network estate through managed service providers, SaaS platforms and specialist security firms. The commercial logic is sound: scarce skills, round-the-clock coverage and access to tooling that few organisations can justify buying outright. Yet many zero-trust programmes still stop at the corporate perimeter. They authenticate employees, inspect devices and segment internal networks, but treat the supplier as a trusted extension of the estate. That is a category error. In a zero-trust model, a supplier is another identity domain, with its own privileges, weaknesses and failure modes.
The task for technology leaders in 2026 is not to avoid outsourcing. It is to make supplier trust evidence-based, continuous and contractually enforceable without turning procurement into a six-month blockade. The following checklist is designed for that balance.
Start with the access map, not the questionnaire
Before sending a 300-question security assessment, map how each supplier actually reaches your systems. Include named support engineers, shared service accounts, API tokens, monitoring agents, remote-access tools and SaaS-to-SaaS integrations. Record which identities can reach which data, from where, and with what level of standing privilege. Ask whether access is just-in-time or permanent. Require named individuals for privileged work, not generic administrator accounts. This map becomes the basis for tiering suppliers and for later audit.
Make continuous assurance a condition of service
Annual audits are a lagging indicator. A supplier can be compliant in January and compromised in June. Contracts should give you a right to recurring evidence: authentication logs for privileged accounts, patch and vulnerability posture, incident notifications, subprocessor changes and results of penetration tests. Define what counts as a material change, such as a new subprocessor, a merger or a critical vulnerability, and require notification within a set period. Put the evidence in a trust register that someone owns. If the supplier cannot provide telemetry, that is itself a finding.
Write clauses that survive a breach
Legal drafting is not a substitute for security engineering, but weak clauses make a bad incident worse. At minimum, require notification without undue delay and within a defined window; cooperation with forensic investigation; preservation of logs; access to incident reports; data return and deletion; approval rights over subprocessors; audit or evidence rights; and clear termination and step-in arrangements. Under UK GDPR, controllers must notify the ICO within 72 hours of becoming aware of a personal data breach, so supplier notification timelines must support that clock. Define 'security incident' broadly enough to cover availability and integrity, not just data theft. Avoid the fantasy of unlimited indemnity; focus on practical cooperation and recoverability.
Test the relationship before you need it
A contract is not a control. Run a tabletop exercise with each critical supplier: who calls whom, who can revoke access, how quickly can credentials be rotated, and what happens if the supplier's own identity provider is down? Ask the MSP to demonstrate revocation of a privileged account within an agreed time. Rehearse your exit plan, including the return of configuration data and the removal of persistent agents. These tests expose dependency concentration faster than any questionnaire.
Avoid the six-month blockade
Procurement should be proportionate. Tier suppliers by criticality and data sensitivity. Low-risk SaaS can use standard certifications and a short evidence pack. Network operations, identity management and security monitoring warrant deeper scrutiny. Build a pre-approved clause library, reuse evidence across similar suppliers, and run legal and technical workstreams in parallel. Accept recognised certifications as a starting point, then add targeted tests for the risks that matter. Time-box the process and escalate only genuine blockers.
Conclusion
Supplier trust is a living control, not a procurement milestone. Entropy accumulates quietly in unused accounts, unreviewed subprocessors and stale assurances. The organisations that manage it well will not be the ones that trust no supplier. They will be the ones that can prove, repeatedly, why a supplier deserves access, and can withdraw it when the evidence changes.
