The Supplier You Can't See: Why Third-Party and Supply Chain Exposure Is Your Biggest Blind Spot

A modern office opening onto a data centre, suggesting digital connections and dependencies beyond the organisation’s walls

Your security team can only protect what it can identify. But your organisation’s digital estate does not stop at the office, the firewall or the devices in your asset register. It extends into hosted platforms, SaaS applications, agencies, managed IT providers and the many services that keep your operations running.

The recent PHP alert exposed a familiar problem: many organisations could not answer a basic question. Do we run PHP anywhere? A significant part of the answer may sit with suppliers, hosted platforms and service providers, rather than in systems your team directly manages. Our related read, When Every Hour Counts: How UK Organisations Should Handle a Live, Critical Vulnerability Like the PHP Exposure, examines the immediate vulnerability-response challenge. The wider lesson is about visibility: if you cannot see the dependency, you cannot reliably assess its exposure.

Supplier exposure is part of your exposure

Supplier exposure means the cyber risk created by technology, access or data handled outside your direct control but relied on by your organisation. It is not limited to a supplier’s own corporate network. It includes the systems and components that support the service you use, and the connections that give a supplier access to your environment.

That can include:

Hosted and SaaS platforms storing your data or supporting essential business processes.
Web and marketing agencies operating your website, content management system, analytics or plugins.
Managed IT and security providers with remote administration, monitoring or support access.
Sub-contractors who inherit access through a primary supplier.
Software and appliance dependencies such as libraries, web servers and components bundled into a product.
Cloud and data centre providers underpinning services even when you do not manage the underlying infrastructure.

The risk is practical, not theoretical. A supplier may have privileged access, hold personal or confidential data, or be a link in a service your organisation cannot easily replace. If its systems are compromised, the effects can reach your users, operations, customers and public services. Your supplier’s security is not a substitute for your own oversight.

The government’s Cyber Security Breaches Survey 2025/2026 found that 46% of small businesses and 65% of medium-sized businesses identified a breach or attack in the previous 12 months. Phishing remained the most common attack vector, experienced by 38% of businesses and named the most disruptive by 69% of those affected.

Now the uncomfortable part. The same survey found that just 15% of businesses formally reviewed the cyber security risks of their immediate suppliers, and only 6% looked at their wider supply chain. Just 11% required suppliers to hold any standards or accreditation at all, and only 3% specifically required Cyber Essentials. Larger organisations do more, but not much more: 48% of large businesses review immediate supplier risk, and 24% look further down the chain.

Read those two sets of numbers together. The attack vector most likely to succeed is also the one you are least likely to have scrutinised. Supplier assurance is lagging well behind supplier dependence.

Build a register that reflects business impact

A supplier list used for finance or procurement is a starting point, not an exposure register. To support effective exposure management, your register should help you understand what each supplier does, what it can reach and what happens if it fails.

Start by assigning suppliers to practical tiers:

Tier 1, critical or high exposure: suppliers with privileged access, sensitive data, a direct role in essential services or a dependency that would seriously disrupt operations if unavailable.
Tier 2, material dependency: suppliers that handle business information or support important functions, but have more limited access or workable alternatives.
Tier 3, lower impact: suppliers with no meaningful system access, sensitive data or operational dependency.

For each supplier, record a named internal owner, the service provided, data handled, access granted, key technical dependencies, any sub-contractors you know about, and the business impact of disruption. Include renewal dates and the date assurance was last reviewed. A tier is a prioritisation tool, not a permanent label: reassess it when the supplier’s role, access or data changes.

This gives you a practical picture of the supply chain behind your services, rather than a directory of company names.

Business and IT leaders reviewing supplier assurance documents during an audit meeting

Ask questions that reveal actual control

A certificate or “we take security seriously” statement does not tell you how a supplier will protect your service during a live threat. Ask questions tied to your exposure and require evidence proportionate to the supplier’s tier.

Questions to put to higher-risk suppliers

What systems, software components and sub-contractors support the service? How will you tell us if a material dependency changes?
What access do your staff and sub-contractors have to our environment? Is it named, least-privilege, protected by MFA and removed promptly when no longer needed?
How do you identify and prioritise vulnerabilities? What are your patching timeframes for critical or internet-facing components, and what evidence can you share?
How will you notify us of an incident that could affect our data, service or environment? Who is our out-of-hours contact?
What assurance can you provide? For example, current Cyber Essentials Plus or ISO 27001 evidence, with its scope, validity and any relevant exclusions.
How do you maintain service continuity and recovery? When were backups or recovery arrangements last tested, and what are the dependencies?

These questions should lead to records, named responsibilities and specific answers. If a supplier claims certification, confirm what the certification covers and whether it applies to the service you rely on. Certification is useful evidence; it is not proof that a particular system is patched, that every sub-contractor is covered or that an incident cannot occur.

Put the right expectations in the contract

Security requirements need to be agreed before there is an incident. Work with procurement and legal colleagues to include measures that match the service’s importance and your organisation’s obligations.

Consider provisions for:

A right to audit or request suitable independent assurance, with appropriate safeguards for confidential information.
Incident notification within 24 hours of the supplier becoming aware of an incident that may affect your service, data or systems. This is a contractual expectation you can negotiate; do not confuse it with a general legal deadline for every supplier.
Timely evidence of patching, vulnerability remediation and security testing, where appropriate to the service.
Advance notice of material changes, including new sub-contractors, changes in hosting or changes to access arrangements.
Clear responsibilities for incident co-operation, evidence preservation, customer communications and secure exit or data return.

No contract removes technical risk. But clear obligations give your team a route to timely information and action. If the supplier holds your data or has access to your systems, silence must not be the default incident process.

Monitor the connections you do control

You may not be able to inspect a supplier’s internal network, and you should not assume that you can. You can, however, monitor your own exposure to the service and the access it uses.

Maintain visibility of internet-facing domains, applications and services associated with your organisation, including agency-managed sites.
Review third-party application permissions, integrations and OAuth access in Microsoft 365 or Google Workspace.
Monitor privileged accounts, remote access, unusual sign-ins and changes to supplier access.
Use your network security, endpoint and identity controls to restrict access to what a supplier needs, and log activity where feasible.
Track relevant vendor advisories and vulnerability information against the products and services in your register. Request a software bill of materials (SBOM) when one is available and useful.
Set review dates for assurance evidence and check in when services change, not only at contract renewal.
Make escalation routes clear between your internal owner, supplier contacts and any managed SOC or monitoring provider supporting your team.

This is where threat detection and exposure management complement supplier assurance. Monitoring your own environment can help surface unusual access or activity, but it cannot guarantee detection of every supplier-side incident. A defined operating model matters: know what is monitored, who reviews alerts and who is responsible for taking action. Our managed cybersecurity services can support monitoring and escalation within an agreed scope.

Security analysts monitoring dashboards in a security operations centre

When a supplier will not answer

A missing response is not proof that a supplier is compromised. It is, however, an assurance gap, and for a high-impact supplier, an unresolved one should not disappear into an inbox.

Record which question remains unanswered, the potential business impact and the decision owner. Then set a deadline and consider proportionate steps:

Escalate through the supplier’s account manager, security contact or senior relationship owner.
Ask for alternative evidence, such as an independent assurance report or a scoped security summary.
Reduce or review access while the gap remains, where this can be done safely.
Identify a workaround, alternative provider or exit route for critical services.
If the exposure remains, document a time-bound risk decision with an accountable senior owner.

For critical dependencies, “the supplier did not respond” is not a risk treatment. The decision to accept, reduce or avoid the exposure needs an owner and a review date.

Why the Cyber Security and Resilience Bill changes the conversation

As at 30 October 2026, the Cyber Security and Resilience Bill has completed House of Lords Report stage, which took place on 26 October, and is not yet law. It is proposed legislation, not a duty that should be treated as already in force. During Report stage the Lords passed amendments requiring a 12-month review of the NIS regime's effectiveness and inserting a register of foreign powers for Part 4, while rejecting a frontier AI incident reporting clause. Lords Third Reading is scheduled for 2 November 2026.

The Bill would expand scope to include medium and large managed service providers meeting the relevant definition, as well as data centre operators. It would introduce an initial incident notification within 24 hours, followed by a fuller report within 72 hours for entities in scope, subject to the proposed requirements. See the government’s factsheet on relevant managed service providers and incident reporting.

For customers, the shift is significant: your supplier may have its own reporting and security obligations, but you still need timely information to assess your own impact and response. Ask providers how they will identify affected customers, notify them and share the information you need. Do not assume a supplier’s regulatory scope automatically meets your organisation’s contractual, operational or reporting needs.

Evidence supplier assurance to boards, insurers and buyers

A large spreadsheet of unanswered questionnaires is not convincing assurance. Your board, insurer or public sector buyer needs a concise view of which suppliers matter most, what evidence has been checked, what remains unknown and who owns the decisions.

Report supplier exposure by tier, service criticality, access and data sensitivity. Summarise assurance evidence and its review date, overdue actions, significant exceptions and any risk accepted by a named owner. Distinguish clearly between confirmed controls and supplier statements. For public sector buyers and other organisations running supplier security questionnaires, this creates a traceable basis for responses rather than repeated, last-minute searches.

It also makes cybersecurity compliance more operational: you can show how supplier risks are identified, assessed and followed up, without presenting a certificate or policy as a guarantee. AOS Technologiies works with UK organisations on the visibility side of this problem, connecting assets, vulnerabilities and threat context to prioritised action so that the dependencies which matter get attention first. For organisations seeking cybersecurity services in the UK, the goal should be a clearer view of risk, not a longer product list. Strong supplier oversight supports resilient operations and strengthens your wider ransomware protection by reducing avoidable access and unnecessary dependency blind spots.

Close the blind spot before the next alert

You do not need to control every supplier’s infrastructure to manage your exposure. You do need to know which suppliers matter, ask for evidence, monitor your own connections and act when answers are missing.

Map your dependencies. Name the owners. Challenge the gaps.

Book a free 30-minute cybersecurity review. We’ll cover email security, endpoint protection, phishing exposure, ransomware protection, remote access, identity, data protection and existing controls, and give you a Red, Amber or Green score with prioritised fixes.

Find the exposure. Prioritise the risk. Build your defences now.