Third-Party and Supply Chain Risk Executive Briefing: What Boards Should Know, Ask and Challenge

Most organisations now run critical services on suppliers they do not control, and a single compromised vendor, integration or managed service provider can stop operations or leak data across hundreds of customers at once. Boards are being asked to own this risk explicitly: the UK Cyber Governance Code of Practice asks directors to gain assurance that the organisation is resilient to supply chain risk, NIS2 lists supply chain security among the measures management bodies must approve, and DORA makes financial entities fully responsible for what their ICT providers do. This briefing is for directors, chief executives, chief risk officers, general counsel and CISOs. It covers concentration, SaaS integrations, managed service providers and the contract levers the board can pull, with oversight questions and red flags. It stays at board level: the programme detail sits in the Third-Party Risk Management Guide and the Third-Party Risk Management Maturity Model.

The risk in one paragraph

Your organisation's security is now the sum of its own controls and those of every supplier that holds your data, runs your systems, connects to your SaaS tenants or ships code you deploy. Attackers know this and increasingly target the supplier rather than the customer, because one successful intrusion pays out many times. The exposure has three forms: access (a supplier, MSP or integration holds credentials or tokens into your environment), dependency (a supplier outage stops a critical service, and several of your "independent" suppliers may share the same underlying provider), and data (your information sits in systems you cannot inspect). The board's job is not to assess vendors. It is to make sure management knows which suppliers matter most, has controls proportionate to that, can act fast when a supplier is breached, and has contracts that give the organisation leverage when it counts.

Why this is a board-level issue now

• Regulation names the board: NIS2 Article 20(1) requires management bodies of essential and important entities to approve the cybersecurity risk-management measures taken under Article 21, oversee their implementation, and makes them liable for infringements; Article 21(2)(d) lists supply chain security, including security aspects of relationships with direct suppliers and service providers. NIS2 recital 85 encourages contractual cybersecurity requirements with direct suppliers and recital 86 asks for particular care when selecting managed security service providers.
• Financial services rules are explicit: under DORA Article 28(1) financial entities remain fully responsible for compliance when they use ICT third-party services; Article 28 also requires a register of information and exit strategies, Article 29 covers concentration risk and Article 30 sets key contractual provisions. See the DORA Executive Briefing.
• UK governance expectations: the Cyber Governance Code of Practice (published 8 April 2025 by the UK government with the NCSC) includes action A4: gain assurance that supplier information is routinely assessed, proportionate to risk, and that the organisation is resilient to cyber risks from its supply chain and business partners.
• The attack pattern has shifted to trusted connections: in the Salesloft Drift breach in August 2025, an attacker used OAuth tokens stolen from one chatbot vendor to export data from customers' Salesforce tenants; Google said it was aware of over 700 potentially impacted organisations. No customer was phished and MFA did not help, because the attacker looked like an integration customers had already approved.
• Outages count too: a faulty update from one widely deployed security product in July 2024 showed that dependency risk can be as damaging as malicious compromise. See the Third-Party Concentration Risk Guide.

Concentration: the risk that hides in the supplier list

Concentration risk means too many critical services depend on one provider, or on a small number of providers that themselves share an upstream dependency (a cloud region, an identity provider, a payment processor, a single MSP). It rarely shows up in a supplier register sorted by spend, because the riskiest dependencies are often cheap: a DNS provider, a code-signing service, an endpoint agent with kernel access.

Not all concentration can be removed. Using one hyperscaler is often safer than spreading thinly across three. The board decision is whether the residual concentration is within risk appetite and whether exit and recovery plans have been exercised, not just written. See the Cloud Concentration Risk and Exit Strategy Guide.

SaaS integrations: third parties that log in as machines

Every time a business user connects a SaaS application to email, CRM, code repositories or file storage, a third party gains a standing credential (an OAuth token, API key or service account) into your data. These connections are non-human identities: they are not covered by MFA, rarely expire, are often approved by individual users without security review, and survive the end of the commercial relationship. A typical large organisation has many more of these connections than it has contracted suppliers, so a supplier register alone gives the board a false picture.

• What to ask for: a count of third-party integrations with access to the most sensitive SaaS platforms, the share with a named internal owner, and the share reviewed in the last 12 months.
• What good looks like: user consent to high-risk scopes is restricted, integrations go through an approval path, tokens are revoked when a vendor is offboarded, and integration activity (bulk exports, unusual locations) is monitored.
• Why it is a board matter: the Drift case showed that one vendor holding tokens for many tenants concentrates risk in the same way a shared data centre does.

See the SaaS and OAuth App Governance Guide and the OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide.

Managed service providers: the supplier with the keys

MSPs and MSSPs are the highest-access suppliers most organisations have: they hold administrator rights, remote management tools and often the security monitoring itself. A compromised MSP can be used to push changes to every client at once, and an MSSP that misses an intrusion leaves the board with no early warning. NIS2 recital 86 reflects this by asking entities to take extra care when selecting managed security service providers.

• Access model: named, individual, MFA-protected accounts for MSP staff, delegated rights scoped to the role and time, and no shared global admin accounts.
• Visibility: logs of MSP actions retained in systems the organisation controls, not only the provider's.
• Separation: the MSP's remote management platform is treated as critical infrastructure in its own assessment.
• Exit: credentials, documentation and configuration can be handed back and access revoked in hours.

See the Managed Service Provider Risk Assessment Guide, the GDAP and MSP Delegated Admin Access Guide and the Compromised MSP Playbook.

Contract levers the board can pull

Contracts are where risk appetite becomes enforceable. Boards should not review contracts, but they should know whether standard clauses exist for critical suppliers and how often they are waived. NIST CSF 2.0 GV.SC-05 expects cybersecurity requirements to be integrated into contracts, and GV.SC-10 expects plans to cover what happens after a relationship ends.

The Third-Party Security Contract Clauses Template provides clause wording.

Five questions for the board to ask

1. Which suppliers could stop our critical services or expose our most sensitive data, and how do we know the list is complete? Look for criticality tiers (NIST CSF 2.0 GV.SC-04) that include SaaS integrations and MSPs, not just top-spend vendors.
2. Where are we concentrated, including through our suppliers' suppliers, and is that within appetite? Expect a named owner for each critical dependency and a date the exit or recovery plan was last exercised.
3. If a critical supplier told us today that it was breached, what would we do in the first 24 hours? The answer should name who decides, which credentials and tokens are revoked, and how regulatory reporting clocks are handled (GV.SC-08 expects suppliers in incident planning).
4. Which third parties hold standing access into our environment, and when was that access last reviewed? Cover MSP accounts, vendor remote access, OAuth integrations and API keys.
5. How many critical contracts lack our standard security, notification, audit and exit terms, and who accepted that? Waivers should be recorded as risk acceptances with an owner and expiry.

Red flags in management answers

• "All our vendors completed the questionnaire": questionnaire completion measures paperwork, not risk; ask what changed as a result.
• "They are ISO 27001 certified": ask whether the certificate's scope covers the service you buy.
• No number for integrations: if management cannot say how many third-party apps hold tokens into email, CRM or code, the inventory does not exist.
• Exit plans that have never been tested: an untested plan is an assumption.
• Procurement owns it alone: without security and business owners, assessments stop at onboarding.
• Annual review only: a supplier's risk can change overnight after an acquisition, breach or new subcontractor.

What good looks like

The NCSC organises supply chain security into four stages: understand the risks, establish control, check your arrangements, and continuous improvement. A mature programme maps onto those stages and onto NIST CSF 2.0 GV.SC-01 to GV.SC-10.

Where to invest first

1. A single inventory of high-access third parties: merge procurement records, SaaS integration data and privileged account lists. This is cheap and usually the biggest blind spot.
2. Revocation readiness: the ability to find and revoke every credential, token and remote access path for a named supplier within hours.
3. Standard contract terms for critical tiers: notification hours, audit rights, access terms and exit.
4. Dependency mapping for the top critical services: one tier beyond direct suppliers.
5. A supplier compromise exercise: run with a real critical supplier and the people who would decide on shutting a connection.

Metrics to track

The UK Code (action E2) expects formal cyber reporting at least quarterly with metrics and agreed tolerances; these metrics fit that cycle. See the Board Cyber Risk Reporting Guide.

A 90-day plan

1. Days 1 to 30: name an executive owner; agree criticality tiers; produce the first combined list of critical suppliers, MSPs and SaaS integrations with access to sensitive data.
2. Days 31 to 60: check critical contracts against standard terms and record gaps as risk acceptances; map dependencies for the top five critical services; confirm the revocation procedure for the top ten suppliers.
3. Days 61 to 90: run a supplier compromise tabletop; present the board with the first metric set, concentration findings and a funded remediation plan.

Common failure patterns

• Treating integrations as IT plumbing: OAuth connections approved by individual users bypass procurement entirely, which is how a single chatbot vendor could reach hundreds of CRM tenants in the Salesloft Drift case.
• Assessment at onboarding only: controls drift, and suppliers change owners and subcontractors after the questionnaire is filed.
• Revocation that relies on the vendor: if only the supplier can disable its access, the customer waits while the attacker works.
• Spend-based tiering: low-cost, high-access tools (remote support, DNS, code signing) are under-assessed.
• Paper exit plans: exit and recovery plans that have never been exercised fail when they are needed.

Lessons from incidents

The Salesloft Drift breach is the clearest recent lesson for boards: the attacker moved from a vendor's source code account to the vendor's cloud environment, took OAuth tokens stored there for customer integrations, and used them between 8 and 18 August 2025 to export CRM records and then search them for further secrets. The board-level points are concentration (one vendor held tokens for many tenants), inventory (customers needed to know immediately which integrations could reach their data), and revocation (every token linked to the integration had to be treated as compromised). Related campaigns against the same platform used social engineering to get users to approve malicious connected apps, as described on the ShinyHunters Salesforce campaign page. See also the Supply Chain NHI Breaches Lessons Guide.

Practitioner checklist

• Executive owner for third-party and supply chain risk named and reporting to the board at least quarterly.
• Criticality tiers defined and applied to suppliers, MSPs and SaaS integrations.
• Combined inventory of third-party access: accounts, remote access, OAuth tokens and API keys, each with an internal owner.
• Standard contract terms for critical suppliers covering notification hours, security requirements, audit, subcontracting, access and exit.
• Waivers recorded as risk acceptances with owner and expiry.
• Dependency map for critical services covering at least one tier beyond direct suppliers.
• Tested procedure to revoke all access for a named supplier, with measured time.
• Supplier compromise scenario exercised at least annually with key suppliers.
• Offboarding confirms removal of access, tokens and data at contract end.

Standards and references

• NCSC: Supply chain security guidance
• UK Government: Cyber Governance Code of Practice
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• EUR-Lex: Regulation (EU) 2022/2554 (DORA)

How NHI Mgmt Group can help

We provide independent identity and non-human identity risk assessments and board briefings, with a focus on the vendor integrations, MSP accounts, OAuth tokens and API keys that give third parties standing access to your environment. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, tokens and secrets. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: Third-Party Risk Management Maturity Model · Third-Party Risk Management Guide · Third-Party Incident Response Playbook · Board Briefing: NHI Risk. This guide summarises regulatory expectations for board members and is not legal advice.