"Compliance" gets used loosely in TPRM, but the regulations behind it are not interchangeable. Some name third-party risk directly and set a binding duty with penalties attached; others regulate a category of data or a sector and only reach vendors indirectly, through what a contract with them must say. Confusing the two produces programs that can name a regulation but cannot point to the clause that actually governs a given vendor decision. This cluster takes each regime in turn and stays specific: which article or section applies, what it obligates you to do about vendors, and what a program does with that in practice.
What this cluster covers today
GDPR and third-party risk
The EU's data-protection regulation does not regulate vendors directly - it regulates what a controller must have in place, mainly the Article 28 processor contract, before letting any processor touch personal data. Covers the eight mandatory contract terms, sub-processor authorization and flow-down under Article 28(2) and (4), cross-border transfer mechanisms since Schrems II, and the breach-notification chain that starts with the vendor and ends at the supervisory authority.
NIS2 and supply-chain security
The EU's broad cybersecurity directive for essential and important entities, reaching well beyond finance into energy, health, transport, manufacturing, and more. Its Article 21 supply-chain clause makes per-supplier security assessment a named baseline measure, backed by board-level accountability under Article 20 and a 24/72-hour incident-reporting clock under Article 23.
HIPAA and third-party risk
The US healthcare privacy and security law, operating almost entirely through the business associate agreement (BAA) any vendor touching protected health information must sign. Covers what a BAA must contain across both the Privacy Rule (45 CFR 164.504(e)) and the Security Rule (45 CFR 164.314(a)), why a business associate's own subcontractors are themselves business associates under the 2013 Omnibus Rule, the direct civil-liability exposure that followed HITECH, and the 60-day breach-notification chain.
PCI DSS and third-party risk
The card brands' own contractual security standard, reaching any vendor that stores, processes, or transmits cardholder data. Covers the five sub-requirements of Requirement 12.8 (TPSP inventory, written agreements, due diligence, ongoing monitoring, and a responsibility matrix), Requirement 12.9's mirror-image obligations on the TPSP itself, and what actually counts as evidence - an Attestation of Compliance scoped to the right services, not just a vendor's claim to be "PCI compliant."
NYDFS Part 500 and third-party risk
New York's cybersecurity regulation for DFS-licensed financial services companies, operating through Section 500.11's written third-party service provider policy and its four required contractual protections. Covers why the Section 500.19 small-business exemption does not reach 500.11, and how Section 500.17's 72-hour breach-notification clock is triggered by an incident at a third-party service provider as well as inside the covered entity itself.
SOX and third-party risk
Unlike the other regimes in this cluster, Sarbanes-Oxley's text never names a vendor at all - the third-party obligation is derived entirely from how broadly the SEC and PCAOB scope internal control over financial reporting. Covers the Section 404(a)/404(b) split, which filers are exempt from the auditor attestation under Dodd-Frank Section 989G, how PCAOB AS 2201 and AS 2601 pull a service organization into audit scope, and what a SOC 1 report's Type 1/Type 2 distinction and complementary user entity controls (CUECs) actually cover.
How to tell these regimes apart
Two questions place any regulation in this space. First, what triggers it - GDPR (Regulation (EU) 2016/679) is triggered by processing personal data of an EU data subject, regardless of sector; NIS2 (Directive (EU) 2022/2555) is triggered by operating in a designated sector as an essential or important entity, regardless of what data is involved; HIPAA is triggered by a vendor touching protected health information on behalf of a US covered entity, regardless of where the vendor sits in a subcontracting chain; PCI DSS is triggered by a vendor touching cardholder data, and applies by card-brand and acquirer contract rather than by statute. A vendor can be in scope for one, more than one, or none of these, depending on what it does and who it does it for. Second, what it actually asks of you - GDPR's third-party mechanics run almost entirely through one contract clause (Article 28) plus the transfer rules in Chapter V; NIS2's run through a risk-management measure (Article 21) with no equivalent single contract template, leaving more of the "how" to national implementing law; HIPAA's run through the BAA itself, but split across two separate rules whose requirements are easy to satisfy only partially; PCI DSS's run through Requirement 12.8 on the customer side and the mirror-image Requirement 12.9 on the TPSP's own side, with a validated Attestation of Compliance as the evidence that ties the two together. Reading a regulation's actual third-party article, rather than a summary of "what it requires," is the only reliable way to tell which obligations are binding and which are a reasonable practice built on top.
General standards and certifiable frameworks - ISO/IEC 27001, DORA, the CSA CAIQ, SOC 2 - are covered in the separate frameworks cluster, since they apply across sectors rather than naming a specific data category or industry the way the regimes here do. DORA in particular reads like a compliance regulation but lives there because it is discussed alongside the other cross-sector frameworks it most often stacks with.
More regimes are coming
This cluster is still early. Vendor-facing obligations under ISO/IEC 27001 Annex A's supplier-relationship controls, CCPA/CPRA service-provider and contractor terms, the GLBA Safeguards Rule, and FedRAMP for government cloud vendors each impose distinct, specific duties and will get the same treatment as GDPR, NIS2, HIPAA, PCI DSS, NYDFS Part 500, and SOX above as this hub grows.
Where to start
Start from what actually applies to you, not from the longest list. If you process EU personal data, read the GDPR page and confirm every processor has an Article 28 contract on file. If you or a critical supplier sit in a NIS2-designated sector, read the NIS2 page and check that supply-chain security shows up in your board-level risk reporting, not just your security team's backlog. If any vendor touches protected health information, read the HIPAA page and confirm its business associate agreement covers both the Privacy Rule and Security Rule content - and that the BAA chain actually reaches its subcontractors. If any vendor touches cardholder data, read the PCI DSS page and confirm its Attestation of Compliance is actually scoped to the service you use, not just present. Either way, the underlying TPRM work is the same: a current vendor inventory, evidence-based assessment instead of a self-reported form, and continuous monitoring fast enough to meet whichever breach-notification clock applies.
Frequently asked questions
What compliance regulations affect third-party risk management?
The regulations with the most direct third-party impact today include GDPR (Article 28 processor contracts, sub-processor authorization, and cross-border transfer rules for any vendor that processes personal data), NIS2 (Article 21's supply-chain security duty for essential and important entities across a wide range of sectors), HIPAA (the business associate agreement any vendor touching protected health information must sign, with direct liability reaching a business associate's own subcontractors), PCI DSS (Requirement 12.8's written-agreement and monitoring duties for any vendor touching cardholder data, mirrored by Requirement 12.9 on the vendor's own side), NYDFS Part 500 (Section 500.11's third-party service provider policy for DFS-licensed financial services companies, which even the regulation's small-business exemption does not excuse), SOX (a derived rather than named obligation - internal control over financial reporting reaches a vendor's systems whenever a material financial process runs on them, tested through SOC 1 reports under PCAOB AS 2601), and DORA (a highly prescriptive ICT third-party regime for EU financial entities, covered alongside other cross-sector frameworks). Sector-specific regimes such as GLBA add further obligations depending on the industry and data involved. Which ones actually apply to a given program depends on the sector it operates in and the type of data its vendors touch, not on which regulations are best known.
How is GDPR different from NIS2 for vendor risk?
GDPR is triggered by processing personal data belonging to someone in the EU, regardless of sector, and its third-party mechanics run mainly through one clause - the Article 28 processor contract - plus the Chapter V rules for moving data outside the EU/EEA. NIS2 is triggered by operating as an essential or important entity in a designated sector, regardless of what data is involved, and its supply-chain duty (Article 21) is a broader risk-management measure rather than a single contract template, backed by board-level accountability and a 24/72-hour incident-reporting clock. A vendor relationship can be in scope for one, both, or neither regulation depending on the sector and the data - they are not alternative versions of the same requirement.
Which regulation should a TPRM program address first when several apply?
Address whichever regulation is triggered by your actual business first, not the one with the most name recognition. A company processing EU personal data through its vendors has an immediate, checkable action: confirm every relevant processor has a compliant Article 28 GDPR contract on file. A company operating in a NIS2-designated sector has a different immediate action: confirm supply-chain security is documented as a board-level risk-management measure under Article 21. Where more than one regime applies to the same vendor - a common case for cloud and SaaS providers - the underlying TPRM controls largely overlap: a current vendor inventory, evidence-based assessment, and continuous monitoring satisfy the practical intent of most of these regulations at once, even though each still requires its own specific contract language and reporting timeline.