Compliance

TPRM compliance and regulations: a practitioner's map

Every compliance regime that touches vendor risk was written by a different body, for a different purpose, with its own vocabulary for the same underlying problem. This hub covers regulations with a distinct, named third-party or vendor obligation - what the text actually requires, not just that it exists - and maps each one to concrete TPRM actions.

"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.

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. A vendor can be in scope for one, both, or neither, 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. 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 HIPAA (healthcare business associate agreements), PCI DSS (service-provider requirements under Requirement 12.8), ISO/IEC 27001 Annex A's supplier-relationship controls, CCPA/CPRA service-provider and contractor terms, NYDFS Part 500's third-party service provider policy, the GLBA Safeguards Rule, SOX ITGC third-party controls, and FedRAMP for government cloud vendors each impose distinct, specific duties and will get the same treatment as GDPR and NIS2 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. 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), and DORA (a highly prescriptive ICT third-party regime for EU financial entities, covered alongside other cross-sector frameworks). Sector-specific regimes such as HIPAA, PCI DSS, GLBA, and NYDFS Part 500 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.