How to know who is inside your estate, rank them by the access they hold rather than the money they cost, verify their claims properly, write terms that still bite at renewal, and survive the day the breach is theirs.
Who needs this: CISO, Head of Procurement/Vendor Management, Legal Liaison, Platform and Application Engineering leads, SaaS/IT Operations, Enterprise Risk | Read time: 26 min | Maps to: CSF 2.0 GOVERN (GV.SC), IDENTIFY (ID.AM, ID.RA), PROTECT (PR.AA, PR.PS) | CIS Controls 2, 15 | ISO/IEC 27001:2022 A.5.19–A.5.23
Cyber-friends, the most expensive thing in your environment right now is probably a token you forgot you issued.
Between 8 and 17 August 2025, attackers tracked as UNC6395 used OAuth refresh tokens that customers had voluntarily issued to Drift — a conversational marketing tool bolted onto Salesforce — to query and export records from more than 700 organizations, including Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint, Tanium and Zscaler. The attackers had first reached Salesloft's GitHub environment months earlier, pivoted into Drift's AWS environment, and helped themselves to the token store. No customer had a vulnerability to patch. No customer's MFA failed. No customer's password would have helped. And the highest-value loss was secondary: API keys, Snowflake tokens, cloud credentials and passwords that customers' own staff had pasted into support-case text over the years (AppOmni; Cloud Security Alliance; FINRA).
That is what third-party risk looks like in practice, and it is why the discipline has stopped being a procurement formality. Third-party involvement now appears in roughly 48% of confirmed breaches — about a 60% year-over-year increase — and of the third parties studied, only 23% had fully remediated their known MFA issues (DBIR 2026 via SecurityWeek; Help Net Security). ENISA measured supply chain at 10.6% of all EU threats in its 2025 Threat Landscape (ENISA ETL 2025).
Here is the governing idea for this entire chapter, and if you take nothing else, take this: your blast radius is defined by standing trust, not by the size of the vendor's breach. A twelve-person startup with an AllPrincipals mailbox grant can cost you more than a nine-figure infrastructure contract with read-only access to a reporting database. Every control in this chapter exists to make standing trust visible, small, time-boxed, and revocable in an afternoon.
Every third-party program is built on one artefact, and almost nobody has it: a list of who is inside your estate and what they can reach. Ask procurement and you will get a supplier master keyed on payment terms. Ask IT and you will get an application catalog that stops at the things IT bought. Neither one knows about the marketing team's transcription tool with full calendar and mailbox scope, because it cost forty dollars a month on a corporate card and nobody signs a contract for that.
The record you need is small. Twelve fields, and every one of them earns its place because a control or a decision reads it.
| Field | Why it exists | Where you actually get it |
|---|---|---|
| Legal entity, product, and your tenant/account ID | You cannot serve an evidence demand on "the CRM thing" | Contract, invoice, admin console |
| Business owner (a named person, not a department) | Someone has to answer at T+0 | Procurement or the requesting team |
| Data classes accessed, using your Chapter 8 tiers | Drives tier, DPA and notification analysis | Design review, admin console scopes |
| Access mechanism(s) — OAuth grant, API key, SSO/SCIM, VPN peer, SFTP, human login | This is the containment list on a bad day | IdP, SaaS admin, network config |
| Direction of keys — issued by you, issued to you, or both | Rotation is asymmetric; people forget the reverse direction | Secrets store, vendor console |
| Operational dependency — what stops if they stop | Drives tier and continuity planning | Business owner, in writing |
| Tier (1–4) | Sets every downstream requirement | Calculated, §2 |
| Assurance held and its expiry date | Stops silent expiry of your evidence | Diligence file |
| Contract, DPA and security addendum locations | Legal needs these in minutes, not days | Contract repository |
| Sub-processor list URL and last-reviewed date | Fourth-party exposure, §7 | Vendor's trust page |
| Named security contact and escalation path | The generic support inbox is not a channel | Contract or account team |
| Last review date and next due date | Makes staleness auditable | The register itself |
When procurement will not help — and often they genuinely cannot — build the list from telemetry instead of from paperwork. Five sources, in the order that gives you the most coverage per hour:
ConsentType = AllPrincipals — that grant reaches every user's content.Reconcile those five into one list. You will find duplicates, ghosts, and at least one integration whose owner left the company. That is not a failure of the exercise; that is the exercise.
Actionable takeaway: Produce a single reconciled vendor register from AP data, your IdP application list, OAuth grants, egress DNS and the contract repository — this quarter, in a spreadsheet if necessary — and refuse to accept any row where the business owner field says a department name instead of a person.
Most tiering models are contract value with a security hat on. That is how a $400-a-month meeting-transcription tool with full mailbox and calendar scope ends up in Tier 4 while a facilities-management contract with read-only access to a badge database sits in Tier 1 getting an annual questionnaire it does not need. The money is not the risk. The access is the risk, and the dependency is the other risk.
Score each vendor on two independent axes, and take the higher of the two as the tier:
| Tier | Definition | Diligence | Contract | Ongoing |
|---|---|---|---|---|
| Tier 1 — Critical | Restricted data, or write access to a system of record, or an outage stops revenue/safety/regulated service | Full evidence review, architecture and integration review, named security contact, references | Full security addendum, audit rights, breach notice measured in hours, sub-processor notice with objection right | Quarterly review, continuous monitoring of grants and scopes, annual joint exercise |
| Tier 2 — Significant | Internal data at volume, or read access to a system of record, or a multi-day outage is materially disruptive | Evidence review with a scoping call; exceptions triaged | Security addendum, breach notice, sub-processor list, right to evidence | Annual review, semi-annual grant/scope check |
| Tier 3 — Limited | Limited internal data, no standing production credentials, replaceable within days | Short questionnaire plus current assurance report or certificate | Standard terms plus breach notice and data-deletion clause | Annual attestation refresh |
| Tier 4 — Minimal | Public data only, no integration, trivially replaceable | Record it and move on | Standard terms | Re-confirm at renewal |
Two rules keep this honest. First, any vendor holding an OAuth grant with tenant-wide scope is Tier 1 or Tier 2 regardless of price — that is the Drift lesson written as a policy line. Second, tier is a property of the integration, not of the company. The same vendor can hold a Tier 1 integration into your CRM and a Tier 4 marketing microsite. Tier the connection.
Actionable takeaway: Re-tier your whole register against data access and operational dependency this quarter, ignore contract value entirely while you do it, and expect the top tier to shrink and change membership. A program that reviews everything reviews nothing well.
A SOC 2 report is the most commonly presented and least commonly read document in this discipline. Someone asks for one, the vendor sends 90 pages, procurement confirms it exists, and it goes in a folder. The AICPA — which promulgates the professional standards for these engagements — has itself published on the risks of quick-turn work under the headline "Promises of 'fast and easy' threaten SOC credibility" (AICPA SOC 2 resources). When the standard-setter is worried about report quality, "they sent us their SOC 2" is not an answer.
Start with what the thing actually is. SOC 2 reports against the 2017 Trust Services Criteria with Revised Points of Focus (2022), TSP Section 100. There are five categories — Security (the mandatory one, the Common Criteria), Availability, Processing Integrity, Confidentiality and Privacy — and the Common Criteria are built on COSO's 17 principles plus supplemental criteria. Critically, points of focus are guidance, not requirements: they are not all relevant to every service organization, and treating them as a checklist is a common and expensive mistake (AICPA TSC 2017 with 2022 points of focus). For your purposes the incident-response hooks live in CC7.x (system operations — monitoring, incident detection and response) and CC9.x (risk mitigation); A1.x covers recovery and backup if Availability is in scope.
Now open the report and answer six questions in this order. The order matters, because questions one and two can make the rest irrelevant.
And be equally clear about what a SOC 2 does not tell you. It is not a penetration test. It is not a vulnerability assessment. It says nothing about the security of a product that is out of scope, nothing about periods outside the report, and nothing about how this vendor compares to another vendor with a report from a different firm. It is an opinion on whether described controls were suitably designed and — in a Type 2 — operating effectively during a stated window. That is genuinely useful. It is not a warranty, and the auditor is not your indemnitor.
The other evidence types, briefly and with the same scepticism:
Actionable takeaway: For every Tier 1 and Tier 2 vendor, record six fields against their assurance report — categories, in-scope products, type, period end, exception count, and whether the complementary user entity controls are implemented on your side — and make the CUEC field mandatory. If nobody on your side owns the controls the auditor assumed you were running, the report is decorative.
Here is the sequencing rule, and getting it backwards is why so many security addenda are worthless: your leverage exists before signature and at renewal, and essentially nowhere else. Once the integration is live, the data has migrated and the business depends on the vendor, a request to add audit rights is a request for a favor. Security has to be in the room before the commercial terms close, which means the tiering in §2 must be done at intake, not after go-live.
| Clause | What to require | Why the weak version fails |
|---|---|---|
| Breach notification | Notice without undue delay and no later than a stated number of hours from the vendor becoming aware, with awareness defined as reasonable belief, not confirmed conclusion | "Prompt notice upon confirmation" lets the vendor's counsel run your regulatory clock. Your GDPR and NIS2 clocks start when you have the facts |
| Notification content | Minimum contents specified: systems affected, your data categories, time window, whether your tenant is confirmed in scope, IoCs, and a named contact | A one-line "we are investigating" satisfies a vague clause and tells you nothing you can act on |
| Cooperation and evidence | Obligation to provide logs, forensic findings and a written incident report on a defined timetable, and to preserve evidence | Without it you are asking nicely during the worst week of their year |
| Sub-processors | Current list maintained, advance notice of changes, and a right to object with a defined consequence | A list with no notice duty is a snapshot of a moving target |
| Audit and assessment | Annual assurance report delivered without asking, plus a right to assess or to receive evidence on request; on-site rights for Tier 1 | "Available upon reasonable request" plus a fee schedule is a refusal in a suit |
| Security requirements | Referenced to a named standard and version, with a floor: MFA for all vendor personnel accessing your data, encryption in transit and at rest, personnel screening, secure development | Aspirational language ("industry standard measures") is unenforceable and unmeasurable |
| Scope of access | Integration scopes named and a duty to seek written approval before expanding them | Vendors expand OAuth scopes in product releases. Without this clause it is a changelog entry, not a change request |
| Data return and deletion | Return in a usable format and certified deletion within a stated period after termination, including from backups on a stated schedule | "Deleted in accordance with our retention policy" is their policy, not yours |
| Flowdown | The vendor imposes equivalent terms on its own subcontractors | Fourth parties inherit nothing by default |
| Termination assistance | Defined exit period with continued service at agreed rates | Concentration risk (§7) is unmanageable if you cannot leave |
| Survival | Confidentiality, deletion, audit and notification obligations survive termination | Otherwise your obligations end exactly when your exposure peaks |
Two structural traps. The security addendum must be incorporated into the agreement and must win the order-of-precedence clause — a beautifully drafted schedule that the MSA subordinates to the vendor's standard terms is expensive theatre. And terms must survive renewal: auto-renewal on the vendor's then-current terms quietly deletes everything you negotiated. Put a renewal review in the register with a date and an owner, and check the terms you have, not the terms you remember.
Some of this is not optional. NYDFS 23 NYCRR Part 500 §500.17(a) requires notice to the Superintendent no later than **72 hours after determining that a cybersecurity incident has occurred at the covered entity, its affiliates, or a third-party service provider (23 NYCRR 500.17). New York's amended breach law (S2659B, effective 21 December 2024) requires vendors to notify the data owner within 30 days (Hunton). If you handle CUI, DFARS 252.204-7012 — a separate and older obligation than the CMMC program rules, and live today — already requires rapid reporting to DoD at DIBNet within 72 hours of discovery**, and that obligation flows down your own supply chain (DoD DIBNet).
Actionable takeaway: Write one security addendum with the eleven clauses above, make it mandatory for Tier 1 and Tier 2 at intake, and add a renewal-review date with a named owner to every register row — because auto-renewal on the vendor's current terms is how negotiated protection silently disappears.
Your vendors are not only companies. Some of them are packages, base images, GitHub Actions and models, and they are onboarded by a developer running one command with no purchase order and no review. This is the part of third-party risk that procurement structurally cannot see.
SBOM. The federal baseline was replaced in July 2026 by 2026 Minimum Elements for a Software Bill of Materials, issued jointly by CISA, NSA, FBI, ASD's ACSC, the Canadian Cyber Centre, NKIB and ANSSI, superseding NTIA's 2021 document. Scope now explicitly covers all software including open source, AI systems, and SaaS. The accepted formats are SPDX and CycloneDX — and SWID tags were removed, on the stated basis that they are not a widely used SBOM format with multiple tools (CISA; PDF). Guidance still listing SWID is out of date.
The new baseline has 17 data fields, and three of them change what an SBOM is worth to you:
| New element | Why it matters to a buyer |
|---|---|
| SBOM Author Signature | The integrity of the document, not just the software. An unsigned SBOM is an assertion in a text file |
| SBOM Generation Context | A build-time SBOM and a post-build binary-analysis SBOM have very different trustworthiness. Now the vendor must say which you have |
| Component Hash (algorithm and value) | Makes component identity verifiable rather than merely claimed |
SLSA v1.2 is the current approved release, organized into tracks with the Build track most mature (slsa.dev):
| Level | What it buys you |
|---|---|
| Build L0 | Nothing. L0 is the absence of SLSA |
| Build L1 | Provenance exists describing how the package was built; signatures not yet required |
| Build L2 | Builds run on a hosted platform that generates and cryptographically signs provenance |
| Build L3 | Hardened platform: builds cannot interfere with each other, and secret signing material is inaccessible to user-defined build steps |
(SLSA levels) The threat SLSA addresses is tampering between source and consumer — which neither SAST nor an SBOM addresses on its own.
SSDF (NIST SP 800-218 v1.1) organises secure development into four practice groups: PO Prepare the Organization, PS Protect the Software, PW Produce Well-Secured Software, RV Respond to Vulnerabilities (NIST SSDF). It is the framework behind federal secure-software attestation, which is why it shows up in procurement questionnaires far outside government. If you buy or build anything with generative AI or foundation models in it, SP 800-218A is the community profile that augments SSDF with AI-specific practices, final since 26 July 2024 (NIST).
The 2025–2026 record is not theoretical, and the pattern is consistent: the attacker takes the build system, because CI runners hold more standing privilege than any human user and authenticate with long-lived secrets.
aquasecurity/trivy-action stole LiteLLM's PyPI publishing tokens; malicious wheels shipped five days later with the payload injected into the distributed artefacts (LiteLLM; Resecurity).Add dependency confusion as a design flaw rather than an incident: when a build resolves an internal package name against both a private and a public registry, a public package with the same name and a higher version can win. The fix is configuration, not vigilance — scope internal packages to a namespace you own, and configure the client so internal names resolve only against the internal registry.
Sequence matters here for one specific reason: pinning before cooldown, and cooldown before scanning. If versions float, a cooldown window is meaningless because the build can still pull whatever is newest at build time; and scanning tells you about known-bad after you have already executed install scripts.
| # | Control | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 1 | Pin every third-party dependency and every CI Action to an immutable identifier — a commit SHA for Actions, a digest for container images, a committed lockfile for packages | Platform Engineering | No floating tags or version ranges remain in build configuration | Diff showing tags replaced by SHAs/digests; lockfile enforcement setting |
| 2 | Enable an adoption cooldown so newly published versions are not pulled immediately. GitHub's Dependabot waits at least three days after a release is published before opening a pull request, and "the cooldown configuration option in the dependabot.yml still controls the behavior," so you can set a window that fits the project (The Hacker News) | Platform Engineering | cooldown configured in every repository's dependabot config, or the equivalent in your dependency bot | The config file; a PR showing the delay applied |
| 3 | Disable automatic install scripts in CI where the ecosystem allows it, and run untrusted installs in a network-restricted job | Platform Engineering | Install-script execution disabled or explicitly allow-listed | CI config; job network policy |
| 4 | Replace long-lived registry and cloud credentials in CI with short-lived OIDC-federated credentials | Platform Engineering | No static publishing token remains in any repository or runner secret | Secret inventory before/after; OIDC trust policy |
| 5 | Isolate publish jobs — separate workflow, separate runner, separate credentials, human approval, and no third-party Actions in that workflow | Platform Engineering | Publishing cannot be triggered from a build job | Workflow definition; approval configuration |
| 6 | Restrict what a runner can reach: egress allow-list, no cloud metadata access, least-privilege job tokens | Platform Engineering | Runner cannot reach the metadata endpoint or arbitrary internet hosts | Network policy; a negative test result |
| 7 | Ingest SBOMs and dependency inventories somewhere queryable, and wire the query into exposure management | Security Engineering | A named component can be traced to products and versions in under an hour | The query and its runtime, dated |
| 8 | Secret-scan the repository, the CI logs and the free-text stores your vendors can read | Security Engineering | Scan runs on a schedule with a triaged rotation queue | Redacted findings; rotation queue with owners |
The cheap version, if you have no platform team and no budget: steps 1, 2 and 4 are free and available in the tools you already pay for. Pinning is a text change. Cooldown is a configuration flag. OIDC federation replaces a stored token with a trust policy at no license cost. Those three would have blunted every incident listed above.
Actionable takeaway: Pin by digest, turn on a cooldown of at least three days, and delete every long-lived publishing token from CI in favor of short-lived OIDC credentials. Not next quarter. This sprint.
Most organizations have an inventory of the SaaS applications they buy. Almost none have an inventory of which SaaS applications hold tokens into their other SaaS applications. That second list is the one attackers work from, because an OAuth grant is a spare key you cut for a contractor: it keeps working after you change the locks, after the project ends, and after somebody lifts it out of their van.
The mechanics of consent abuse, the detection queries and the revocation commands are Chapter 4, Section 9. The incident procedure is Chapter 14.5. What belongs here is the governance layer — treating each grant as a third-party record with a lifecycle.
The integration register. For every grant, record: the publisher and application ID; the granting tenant; whether consent is delegated or application-level and whether it is AllPrincipals; the exact scopes; who approved it and when; the business owner; the data classes reachable through those scopes; and a review-or-expiry date. Then apply four rules:
Two more things the Drift case put beyond argument. Support tickets, CRM notes and chat exports are a credential store — your staff paste keys into them and your vendors can read them, so secret-scan those fields on a schedule and rotate what you find. And AI integrations are the fastest-growing population in this register: copilots, meeting notetakers, agent frameworks and MCP servers all onboard through the same consent screen, often with broader scopes than the human tools they replace. Chapter 7 owns AI governance; the grant is a row here like any other.
Actionable takeaway: Build the SaaS-to-SaaS grant register this month, revoke every grant with no named owner, and put quarterly re-attestation on the calendar with non-response defaulting to revocation. If you can only do one thing, filter your tenant-wide grant export to AllPrincipals and work that list first.
Your vendor has vendors. Their sub-processor list is a real document with real consequences, and reading it is the cheapest fourth-party control available. The Trivy → LiteLLM chain is the illustration: a compromised security scanner poisoned a build that shipped poisoned wheels to everyone downstream. Nobody in that chain had a relationship with the attacker's actual entry point.
Then there is the harder problem: everyone depends on the same vendor. Concentration risk is not about a single supplier failing — it is about a single supplier failing for everyone at once, which means your fallback plan and your competitors' fallback plans and your recovery vendor's fallback plan all fire simultaneously.
The documented cases in the 2024–2026 window make the shape clear:
What to do about it, at a realistic budget. Nobody is going to fund a second identity provider. So do the analysis, then buy the cheap mitigation:
Actionable takeaway: Build the function-to-vendor map, find the names that appear more than twice, and write and test a five-day degraded-mode procedure for each. Redundancy is expensive; a rehearsed manual process is nearly free and it is what actually gets used.
The full incident procedure is Chapter 14.5 and I will not duplicate it. What belongs in the control chapter is the honest boundary of your authority, because teams waste the first six hours discovering it.
What you cannot do: investigate their network, direct their responders, set their disclosure timeline, or verify their claims independently. You will be told less than you want, later than you want, in language written by their counsel.
What you can do, immediately: cut standing access, hunt their identity across your own estate, preserve your own logs before retention kills them, and run your own regulatory analysis on your own clock. Your notification obligations start when you have the facts, not when the vendor confirms your tenant was in scope.
The evidence demand. Issue it in writing, through the single vendor channel, in parallel with your containment — never instead of it. Ask for: whether your tenant or account is confirmed in scope; the precise window of unauthorized access; the data categories and record counts involved for you specifically; which of your credentials, tokens or keys were exposed; indicators of compromise you can hunt with; whether their sub-processors were involved; what they have remediated; and a written incident report by a stated date. Log every request and response with timestamps — that log is what turns "the vendor was unhelpful" into a documented fact.
Prepare it in peacetime. NIST SP 800-61r3 rates ID.IM-02 — improvements identified from tests and exercises "including those done in coordination with suppliers and relevant third parties" — as High priority, and ties supplier inclusion in exercises explicitly to GV.SC-08 (NIST SP 800-61r3). Read that as an instruction: once a year, run a tabletop with your Tier 1 vendors in the room, or at minimum a joint call that walks the notification path end to end. The first time you use a vendor's security contact should not be during an incident, and a vendor security contact that has not been dialled since onboarding is a phone number, not a control. Chapter 18 owns exercise design.
Actionable takeaway: Pre-draft the evidence demand as a template, store it with the vendor register, and confirm the named security contact for every Tier 1 vendor twice a year by actually contacting them. A contact you have never used is a hypothesis.
Chapter 15 owns the notification clocks in full. Three obligations belong here because they are specifically about third parties and they change how you write contracts.
The common thread: regulators have stopped accepting "it was our vendor" as an answer. CSF 2.0 made cybersecurity supply chain risk management its own Category (GV.SC) under the new GOVERN Function precisely because it is a governance obligation, not a procurement task (NIST CSF 2.0), and CIS Control 15 (Service Provider Management) carries the same expectation in the control catalog (CIS Controls).
Actionable takeaway: Map your vendor register against the regimes that bind you, and where a regime imposes a clock, make the contractual notice window shorter than the regulatory one. If your vendor has 72 hours to tell you and you have 72 hours to tell a regulator, you have zero hours to work with.
Starting from nothing, in this order — each step makes the next one cheaper:
Ninety days, no licences, and you will be ahead of most organizations several times your size. Not because you bought anything. Because you finally know who has the keys.
[IG1] [GV.SC] [ID.AM] [CIS 15][IG1] [ID.AM] [A.5.19][IG1] [GV.SC] [ID.RA]AllPrincipals) OAuth grant is classified Tier 1 or Tier 2 by policy, irrespective of spend. [IG2] [GV.SC] [PR.AA][IG2] [GV.SC][IG2] [GV.SC][IG2] [GV.SC][IG3] [GV.SC][IG2] [GV.SC][IG2] [GV.SC] [A.5.20][IG2] [GV.SC] [RS.CO][IG2] [GV.SC] [A.5.21][IG1] [GV.SC][IG2] [ID.AM] [PR.AA][IG2] [PR.AA] [GV.SC][IG2] [PR.AA][IG2] [PR.DS] [DE.CM][IG2] [PR.PS] [CIS 2][IG2] [PR.PS][IG3] [PR.AA] [PR.PS][IG3] [ID.AM] [GV.SC][IG3] [GV.SC][IG2] [GV.SC] [RC.RP][IG1] [RS.CO] [GV.SC][IG3] [GV.SC-08] [ID.IM-02]You will never audit your way to a secure supply chain, and you will never afford a second copy of everything. What you can do is know exactly who holds a key, take back the ones nobody can name an owner for, and make sure the ones that remain expire on a date you chose. Stay pinned, stay scoped, and revoke like you mean it.