How should security teams control personal data sharing with third parties under GDPR?

Why This Matters for Security Teams

Under GDPR, third-party sharing is not just a contract issue. It is an identity and access problem that has to be governed like any other sensitive workload. If a processor, support vendor, or analytics partner can reach personal data, security teams need a clear legal basis, purpose limitation, and evidence that access is both minimal and revocable. That means treating the vendor path as a controlled identity event, not a one-time onboarding task.

This matters because excessive or poorly governed access is still the norm. NHI Mgmt Group reports that 92% of organisations expose non-human identities to third parties, which shows how easily delegated access expands beyond the original purpose Ultimate Guide to NHIs — Key Research and Survey Results. OWASP also flags identity sprawl, secret misuse, and over-privilege as recurring failure modes in the OWASP Non-Human Identity Top 10. In practice, many security teams discover third-party data exposure only after a support workflow, SaaS integration, or delegated token has already outlived the purpose it was meant to serve.

How It Works in Practice

A practical GDPR control model starts with mapping each third party to a named purpose, a data category, and a specific access method. Security teams should not accept broad vendor accounts when a narrower path will do. If the third party needs remote support, use just-in-time access, short-lived credentials, and an explicit approval trail. If the third party is accessing data through APIs or service integrations, the identity should be tied to a workload identity, not a shared login or long-lived secret.

Operationally, this usually means combining RBAC with tighter controls such as JIT provisioning, PAM, logging, and revocation workflows. The important point is that access should expire when the task ends. That aligns with the guidance in the Ultimate Guide to NHIs — Standards, which emphasises lifecycle control, offboarding, and visibility. It also fits the visibility problem highlighted by the 52 NHI breaches Report, where identity compromise is often amplified by stale privileges and weak offboarding. For third-party OAuth and SaaS links, current guidance suggests reviewing grants at the app and tenant level, because a single connected tool can expose much more than the original business owner expects.

• Define the lawful basis and purpose before access is granted.
• Issue the minimum role needed for the specific task.
• Prefer short-lived tokens, JIT approval, and automatic expiry.
• Log access to data, admin actions, and delegation changes.
• Revoke credentials and connected app grants during offboarding, not after an incident.

These controls tend to break down when vendors use shared admin consoles or unsupported legacy integrations because revocation and attribution become unreliable.

Common Variations and Edge Cases

Tighter third-party control often increases operational overhead, requiring organisations to balance auditability against support speed and business continuity. That tradeoff is real, especially for break-glass support, managed service providers, and cross-border processing chains where more than one controller or processor touches the same dataset.

There is no universal standard for every edge case, so current guidance suggests documenting the exception, narrowing the scope, and time-boxing the access. For example, emergency access can be pre-approved through PAM with stronger logging and post-event review, while routine support should stay on JIT. If a third party uses automation, treat its secrets as sensitive as human credentials: rotate them, store them in a secrets manager, and confirm who can retrieve them. When multiple subprocessors are involved, the data flow should be visible end to end, because GDPR accountability does not stop at the first contract boundary. This is also where the research base matters: the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack show how quickly delegated access and exposed secrets can spread across trusted workflows. Security teams should therefore verify not only what the third party can see today, but also how quickly that access can be turned off tomorrow.

Related resources from NHI Mgmt Group

• How should security teams control SaaS data sharing risk?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?