Handling PII Passed Through Third-Party API Integrations

PII stopped meaning "name and social security number" a while ago. Under GDPR and CCPA, it now covers IP addresses, cookie IDs, device fingerprints, and other data that can be tied back to a real person. Every time your app calls a third-party API, someone on your team makes a judgment call about what counts as sensitive. Get that call wrong at the design stage, and you're shipping unmasked PII to production without knowing it, which is a bit like leaving your front door unlocked because you assumed the neighborhood was fine.

The whole game comes down to timing. Get the classification right before you write a line of integration code, or fix it later on an incident response call at 2am, half-awake, trying to remember which vendor has your customers' phone numbers.

GDPR spells this out directly: IP addresses, cookie IDs, device identifiers, all personal data, full stop. CCPA and its update, CPRA, go further, folding in device fingerprints, household-level data, and behavioral patterns like purchase history and browsing activity. The stuff your analytics team calls "engagement signals" counts as PII the moment it can be reasonably tied to one person, whether or not anyone meant it that way.

The distinction that trips up engineers most is direct versus indirect identifiers. A name is direct. A device ID or a cookie is indirect, and indirect data flows through analytics tools, tracking pixels, and AI APIs constantly, usually without anyone flagging it. The same IP address can be harmless in one integration and regulated PII in another, depending on what else it's paired with. Sensitivity lives at the field level, not the system level. Classifying a whole API as "safe" and calling it done is the mistake that shows up in every postmortem, and it's tempting precisely because it's faster.

In practice, PII moves through vendor APIs constantly: contact details through support tooling, sensitive records through AI endpoints, transaction data through analytics platforms, and payment information through multiple hops before a transaction clears. None of these get flagged as "PII integrations" in most architecture reviews. They just get called "the chatbot" or "the payments flow," which is exactly how something this important ends up hiding in plain sight.

Why the exposure surface is larger than most teams realize

Put a dollar figure on it and the abstraction disappears fast. IBM's 2025 Cost of a Data Breach Report puts customer PII at $160 per exposed record and employee PII at $168. Multiply either by a breach involving tens of thousands of records and the number stops feeling like a rounding error.

Third-party compromise deserves its own paragraph, because the pattern is ugly in a specific way. IBM puts the average cost of a breach that starts with a compromised vendor at $4.91 million, well above the overall average, and the time to detect and contain it averages 267 days, among the highest IBM tracked. Why so slow? Because it exploits trust. Nobody's watching the front door when the attacker walked in through a vendor's back door with a key you handed them yourself.

APIs specifically are having a rough stretch. Indusface tracked a 104% year-over-year jump in API-targeted attacks in the first half of 2025, with vulnerability attacks on APIs alone up 13x in that same window. Separately, Salt Security found 95% of organizations had already experienced an API security incident. Not "worried about." Experienced, past tense, already happened.

Then there's shadow AI: the unsanctioned generative tools employees adopt without telling security, because the free version of some chatbot solved an everyday problem faster than filing a ticket. Breaches tied to unsanctioned AI tools exposed customer PII far more often than standard breaches, according to IBM, and took longer to surface, adding real dollars to the average cost along the way. Shadow AI is a governance risk wearing a productivity costume. It's a slow leak with a delayed alarm.

Underneath all of this sits a more basic problem: most organizations don't know where their PII actually lives. Not because nobody's looking, but because it's scattered across cloud services, endpoints, and third-party systems that never show up on one dashboard. IBM found the costliest breach pattern of all was data spread across multiple environments, more expensive than any single-environment breach in the report. You cannot protect what you cannot find, and most security teams are working from an inventory that went stale months ago.

How PII leaks through third-party API integrations specifically

Every third-party API integration extends your security perimeter into somebody else's house, and you don't get to pick their locks. The vendor might run a tighter ship than you do. Might not. Either way, when something goes wrong on their end, the regulatory fallout and the reputational hit land on you, the integrating organization, not on them. That asymmetry is the whole problem in one sentence.

OWASP's API Security Top 10 is the field guide for how this plays out in practice. Broken Object Level Authorization sits prominently on the list: an attacker changes an object ID in a request and suddenly they're looking at someone else's records. Broken Object Property Level Authorization is sneakier. The backend hands back more fields than the interface ever displays, sensitive details sitting in the raw response even though the screen shows only a name and a job title. Anyone with a browser's developer tools open can see the raw response and grab what the interface never meant to show.

Take an employee directory app calling /api/user/{ID}. The screen shows a name and a role. The actual JSON coming back includes private contact info and admin account details, sitting right there in the network tab for anyone who bothers to look. Nobody built that on purpose. It happened because the backend team optimized for "return the object" instead of "return only what's needed," which is the kind of shortcut that feels harmless until it isn't.

The last two items on that OWASP list circle a related failure: unsafe consumption of third-party APIs. Developers trust data coming from a vendor more than they'd trust raw user input, which is backwards, since the vendor's security standards are often lower than your own. Attackers know this. Compromise the third-party API your system trusts, and you get a side door into everything that system touches. Add RESTful over-fetching and GraphQL endpoints with introspection left switched on, and you've got payloads leaking fields nobody meant to expose in the first place.

The Marks & Spencer incident from April and May of 2025 is the real-world version of this, and it didn't involve a single line of exploited code. The threat group Scattered Spider used social engineering to manipulate a third-party service desk into granting access. That's the entire technical exploit: a phone call. What followed was a ransomware attack that disrupted operations across more than 1,400 stores, exposed customer names, emails, birthdates, addresses, phone numbers, and order histories, and caused substantial reported losses in revenue. M&S suffered significant reported losses in market value in the aftermath. The vendor relationship was the attack surface, and nobody had to write a single exploit to walk through it.

LLM and AI API pipelines are the newest version of this problem, and most teams haven't caught up. Send raw text containing PII to a third-party model endpoint, and that data might get embedded, stored in model context, or logged by the vendor, all outside your control and often outside your visibility entirely.

The regulatory obligations that attach the moment PII moves to a third party

This isn't a regional problem you can wall off to "the EU team" and forget about. Roughly 144 countries, covering more than 80% of the world's population, had data protection laws on the books as of early 2025.

Under GDPR, the data controller stays liable for what a processor does with the data, even after it's out of the controller's hands. Article 28 requires a written Data Processing Agreement before any processor touches personal data belonging to EU residents. Skip the paperwork and you're exposed regardless of what the vendor actually did wrong, which is a hard lesson to learn after the fact.

The fines aren't theoretical. GDPR penalties top out at €20 million or 4% of global annual turnover, whichever is higher, for the worst violations, and €10 million or 2% for lesser ones. Cumulative fines since GDPR took effect in May 2018 have hit €7.1 billion, with roughly €1.2 billion of that landing in 2025 alone, per DLA Piper's GDPR Fines and Data Breach Survey published in January 2026. That's a regulatory regime with real teeth and a growing appetite, not a paper tiger.

CCPA and CPRA are not a US copy-paste of GDPR, and plenty of domestic teams assume DPAs are something that only matters in other regions. They're wrong, flatly. CCPA and CPRA require written service provider contracts that explicitly block the vendor from selling the data, disclosing it further, or mixing it with data the vendor collected on its own. Violations carry per-infraction fines under the CPPA, and several other US state privacy laws run similar requirements for written agreements.

HIPAA enters the picture whenever a third-party API handles protected health information on a covered entity's behalf. Where it applies, a Business Associate Agreement is required.

CPRA's new Automated Decision-Making Technology rules take effect January 1, 2026, with phased compliance deadlines starting January 1, 2027. They require meaningful disclosure of how a decision-making system works, a description of likely outcomes, and an opt-out mechanism, which matters directly for any integration feeding PII into an AI inference API.

PCI DSS v4.0 puts APIs in scope by name now. Requirement 6.2.3 mandates a review of custom code, APIs included, before release. Requirements 8.6.1 through 8.6.3 cover non-human credentials, meaning API keys and service accounts, with 8.6.3 specifically requiring periodic rotation. PCI DSS, NIST SP 800-53, GDPR Article 32, SOC 2, ISO 27001: they all now write API security requirements directly into the standard. The API layer used to be an afterthought in compliance frameworks. That era is over.

What a Data Processing Agreement actually needs to say

A DPA is required with every vendor touching personal data, and that list runs longer than most teams assume: cloud providers, CRM platforms, email tools, analytics vendors, payment processors, AI inference APIs. Not just the companies that call themselves "data vendors" on their homepage.

The most common failure is something other than skipping the DPA. It's signing one, treating it as the finish line, and leaving the annexes blank. Annex 1 needs to spell out the purposes of processing and the categories of data and data subjects involved. Annex 2 covers the security measures the processor commits to. Annex 3 lists approved sub-processors. A DPA with empty annexes doesn't satisfy GDPR Article 28, no matter how official the cover page looks.

International transfers add another layer. Any DPA moving personal data outside the EEA needs Standard Contractual Clauses, and the European Commission's 2021 update is the version that counts now. Major cloud providers build these into their standard DPAs, but smaller or custom vendors need this checked line by line, because assuming it's already there is exactly how gaps happen.

CCPA and CPRA contracts need explicit language blocking three things: selling the data, disclosing it further without authorization, and combining it with data the vendor collected independently. General "we'll keep it safe" language doesn't cut it, and any lawyer who tells you otherwise hasn't read the statute closely.

Sub-processor chains are where a lot of DPAs quietly fail. Signing an agreement with your primary vendor doesn't automatically bind whatever sub-processor that vendor uses downstream. The agreement needs to require the primary vendor to flow equivalent obligations down the chain, in writing, to anyone else touching the data.

Breach notification terms matter more than most contract reviewers give them credit for. GDPR's 72-hour notification window means the vendor's own notification speed to you needs to be spelled out contractually, not left to goodwill and good intentions. Add deletion terms too: how the vendor honors erasure requests, how long it retains data, how it confirms deletion actually happened. That's Article 17 territory under GDPR, and it maps directly onto CCPA and CPRA deletion rights as well.

Finally, preserve audit rights. GDPR Article 28 gives the controller the right to audit the processor, and vendors love to hand over a SOC 2 report and call it a day. A SOC 2 report is useful. It is not the same thing as the audit right the regulation actually grants, and the DPA needs to say so in writing, not leave it implied.

Engineering controls that reduce PII exposure before data leaves your system

Data minimization comes first, not last. Build integrations that send only the fields the third-party function actually needs. If the vendor's API doesn't need a full profile object or clinical notes, don't send them. This sounds obvious and gets ignored constantly anyway, usually because trimming a payload takes more effort than just shipping the whole object and moving on.

Classify APIs by risk before you build, not after the fact. Public-facing APIs that handle PII and involve a partner integration are high risk. Internal APIs touching PII sit in the moderate tier. Sandbox and test APIs are low risk. Security controls should scale to match: treating a test endpoint like a payment API wastes engineering time, and treating a payment API like a test endpoint gets you breached.

Sensitive categories, financial records, health data, government IDs, deserve their own dedicated endpoints rather than getting folded into one general-purpose payload alongside everything else.

Tokenization is worth understanding in detail, because it's doing more work than most teams give it credit for. It swaps a sensitive value (an email, a card number, a national ID) for a format-preserving token, with the real mapping stored in a locked-down vault elsewhere. Tokenization has moved well past its PCI roots into PII, PHI, behavioral data, and LLM pipelines across cloud environments. The flow works in stages. A client sends a request with identifiers, an edge gateway pulls those identifiers out, a tokenization service swaps in pseudonyms and logs the mapping to the vault, and the tokenized payload continues on to microservices and third-party APIs. Re-identifying anything requires an authorized vault request, logged and audited every time. One catch that trips people up constantly: the vault has to support purging original values, or you can't honor a GDPR erasure request or a CCPA deletion request. Tokenization that can't delete is noncompliant tokenization. It's just obfuscation with extra steps.

Pseudonymization is related but distinct, and GDPR Article 4 is specific about the definition: data processed so it can't be tied to a person without additional information, and that additional information has to be held separately. If the re-identifying field sits in the same payload as the pseudonymized data, nothing's actually been pseudonymized. Someone's just renamed a column and called it a day.

LLM pipelines need their own tokenization strategy, applied before chunking and embedding, not after. PII, PHI, and PCI in raw text should get tokenized ahead of any embedding step. Training or fine-tuning should run on tokenized corpora unless there's a clear legal basis for using raw data, and retrieval rules need to stop tokenized content from surfacing improperly in generated outputs.

None of this matters if the transport layer is loose. TLS on every API call, no exceptions, and that includes verifying the third-party endpoint enforces TLS on its side too, not just assuming your client handles it correctly. Pair that with scoped, least-privilege API credentials that authorize only what the integration needs, with rotation enforced. PCI DSS v4.0's Requirement 8.6.3 makes credential rotation mandatory for non-human credentials, which turns it into an audit line item whether anyone likes it or not.

Runtime controls and monitoring that catch what design controls miss

Design controls only cover what you anticipated. API gateways cover what you didn't. A gateway sitting at the boundary can inspect, log, and enforce payload schema before anything leaves your environment, and it can block outbound payloads that include a field tagged as high-risk PII, even if a developer forgot to strip it during a rushed Friday deploy.

Logging deserves more scrutiny than it usually gets, because logs quietly turn into a second PII store nobody signed off on. Full request and response bodies captured in logs mean PII now lives in two places, and the log store often has weaker access controls than the production database it's supposedly just observing. Better to log at the level of "was an email field present" rather than the actual value, and to lock down log retention and access with the same rigor as production itself.

Keep a live inventory of every external API endpoint that touches PII: what data categories flow through it, and whether the vendor's DPA is current. This isn't optional bookkeeping. NIST SP 800-228 and ISO 27001 both require asset and configuration management that reaches into the API layer, and you genuinely cannot monitor an endpoint you forgot existed. This gap is not hypothetical, it's the most common one on the list.

Vendor security assessments need to happen before onboarding, sure, but also on a recurring schedule after that. A vendor's security posture at the moment you sign the contract tells you nothing about its posture eighteen months later, after staff turnover, a platform migration, or a cost-cutting round that quietly gutted the security team.

Last piece: watch for PII drift in outbound payloads over time. APIs grow. New fields get added to requests and responses as features ship, often without anyone running them past a security review first. Automated scanning that checks live payloads against a PII classification schema catches the fields that shouldn't be there, the ones that snuck in three sprints ago and nobody noticed. Design controls catch what a team planned for. Monitoring catches what nobody did, which, honestly, is most of it.