The vendor perimeter is where most breaches now begin

Third-party vendor data access is no longer a secondary risk category. According to SecurityScorecard’s 2025 Global Third-Party Breach Report, 35.5% of all breaches in 2024 were third-party related, and that figure is likely conservative given how often compromises several layers deep in a vendor ecosystem go misclassified or unreported. Verizon’s most recent Data Breach Investigations Report put the share at 30%, double the prior year. The trajectory is clear.

The financial weight matches the frequency. IBM’s 2024 Cost of a Data Breach report puts the average cost of a third-party breach above $5.08 million. In Germany specifically, the average breach cost reached 4.9 million EUR in 2024, placing it among the five most expensive countries globally. Gartner research attributes the premium to the added complexity of managing incidents that span multiple entities, legal jurisdictions, and data environments.

Supply chain breach exposure has also become structurally concentrated. Fifteen companies now represent 62% of the global technology market. Half of all enterprises work with more than 100 vendors, up from 38% in 2023. For each direct vendor relationship, organisations typically carry indirect exposure to nearly 14 times as many fourth and fifth parties. When a single managed file-transfer platform or SaaS tool is compromised, the blast radius is not bounded by your own perimeter.

What recent incidents reveal about systemic gaps

The MOVEit breach of June 2023 is the clearest recent example of concentrated supply chain risk. Three SQL injection vulnerabilities in Progress Software’s MOVEit Transfer platform exposed data from close to 1,700 organisations and nearly 100 million individuals. The Cl0p ransomware group exploited the flaws to reach payroll provider Zellis, which in turn exposed data from British Airways, the BBC, and others. No single downstream organisation had introduced the vulnerability; all of them inherited it through a shared dependency.

The Snowflake campaign of 2024 followed a different vector. A group tracked as UNC5537 used credentials harvested by infostealer malware to access Snowflake cloud accounts at over 160 companies, most of which had no multi-factor authentication configured. AT&T, Ticketmaster, and Santander were among those affected. The campaign made cloud platforms the second most common third-party attack vector in 2024, and it illustrates how permissive access configurations inside a vendor platform become your problem even when the vendor’s own infrastructure is not compromised.

More recent incidents confirm the pattern is accelerating. The Samsung Germany breach of March 2025 exposed around 270,000 customer records through third-party vendor Spectos. In June 2025, procurement vendor Chain IQ Group AG suffered a ransomware attack that exposed over 130,000 employee records from clients including UBS and Pictet. Marks and Spencer lost £300 million when a TCS contractor’s compromised credentials exposed 9.4 million customer records, causing six weeks of operational disruption. In each case, the primary organisation’s own controls were irrelevant: the exposure came through a trusted third party.

Vendor access is not a configuration detail. It is an architectural decision with regulatory and financial consequences that compound across every party in your supply chain.

What GDPR and NIS2 actually require from you

GDPR Article 28 is unambiguous on GDPR third-party processors: a controller must use only processors that provide sufficient guarantees to implement appropriate technical and organisational measures, and the processor must not engage a sub-processor without prior written authorisation from the controller. That chain of accountability does not end at your direct vendor; it extends to every sub-processor they engage.

In practice, this means your Data Processing Agreements must enumerate sub-processors, specify the categories of data each can access, and include audit rights. Where a vendor cannot demonstrate those controls, the controller remains liable for the resulting processing. Supervisory authorities across the EU have consistently treated inadequate vendor oversight as a controller-side failure, not a vendor-side one.

NIS2 extends similar logic to operational continuity. Entities in scope must address supply chain security as part of their risk management obligations, which includes assessing the security practices of direct suppliers and, where relevant, the suppliers of those suppliers. The 2024 SecurityScorecard data showing that 98% of Europe’s top 100 companies had faced third-party breaches in the prior year was published specifically in the context of the DORA deadline, underscoring that regulators are watching this space closely. Among Europe’s top 100 financial institutions, 96% were impacted by at least one third-party breach in the past year, up from 78% the year before.

A practical audit framework for vendor data access

Before you can limit third-party vendor data access, you need an accurate inventory. Most organisations undercount their vendor relationships because SaaS procurement happens outside IT governance and sub-processors are rarely tracked beyond the first tier. Start there.

  1. Map every data flow to a vendor or sub-processor. Include SaaS tools, managed service providers, payroll platforms, file-transfer services, and any system with API access to production data. Document what categories of personal data each can reach, under what conditions, and who authorised the access.
  2. Classify vendors by data sensitivity and replaceability. A vendor with access to HR records or financial data warrants stricter controls and more frequent review than one processing anonymised analytics. Replaceability matters because it determines how much leverage you have in contract negotiations.
  3. Review Data Processing Agreements against Article 28 requirements. Confirm sub-processor clauses are specific, that audit rights are enforceable, and that breach notification timelines meet the 72-hour GDPR requirement. If your DPA was signed three years ago, it almost certainly needs updating.
  4. Enforce least-privilege access at the technical layer. Vendor accounts should access only the data required for the contracted service. Network segmentation, scoped API tokens, and time-limited credentials reduce blast radius when a vendor is compromised. The Snowflake campaign succeeded largely because credentials were over-privileged and MFA was absent.
  5. Run vendor risk assessments on a schedule, not just at onboarding. Security postures change. A vendor that passed a review at contract signing may have acquired a sub-processor, changed cloud infrastructure, or suffered an undisclosed incident since. Annual reassessment is a minimum; quarterly for critical suppliers is defensible under NIS2.
  6. Test your incident response for third-party scenarios. A tabletop exercise that assumes the breach originates inside your perimeter will not prepare your team for the coordination overhead of a MOVEit-style event. Simulate scenarios where a critical vendor notifies you of a compromise and you must assess exposure, notify affected data subjects, and engage your supervisory authority within 72 hours.

How infrastructure architecture reduces vendor risk surface

Vendor risk management cloud architecture matters as much as process. When your workloads run on infrastructure that is itself subject to foreign jurisdiction, every vendor and sub-processor relationship inherits that jurisdictional complexity. Schrems II invalidated the Privacy Shield framework precisely because US surveillance law created a structural incompatibility with GDPR, regardless of what any individual vendor’s DPA said.

Running on sovereign European infrastructure removes that layer of uncertainty. DIVERSITY operates its own carrier-neutral infrastructure entirely within Europe, under European law, with ISO 27001-certified operations. That means the cloud layer itself is not a sub-processor with opaque sub-processors of its own; it is a defined, auditable component in your data processing chain. For regulated industries navigating DORA, NIS2, or sector-specific supervisory expectations, that architectural clarity is not a marketing claim: it is evidence you can present to an auditor.

Network segmentation and access controls implemented at the infrastructure level are more durable than those configured inside a shared-responsibility SaaS environment. When you control the network, you can enforce that a vendor’s service account cannot reach data outside its designated segment, regardless of what permissions the vendor’s own platform would allow. That is a meaningful reduction in blast radius, and it is the kind of control that Article 28 audit rights are supposed to verify.

Reducing exposure is an ongoing operational discipline

The 41.4% of ransomware attacks that now originate through third parties are not a temporary anomaly. Attackers follow the path of least resistance, and for most European enterprises, that path currently runs through the vendor ecosystem. Tightening it requires consistent effort across legal, procurement, IT, and security functions.

The organisations that will demonstrate meaningful progress under GDPR and NIS2 are those that treat cloud vendor access audit as a recurring operational discipline rather than a pre-contract checkbox. That means keeping the vendor inventory current, enforcing technical controls that do not depend on vendor self-attestation, and choosing infrastructure partners whose own compliance posture does not add jurisdictional risk to an already complex picture.