Compliance & Privacy · 2026-08-17
Six Contract Clauses That Test a “Zero PII” Claim
By J. W. Bouckaert
The claim is cheap, the clause is not
"We store no PII" appears in most identity-vendor decks and almost no identity-vendor contracts, at least not in a form a lawyer could enforce. That gap is the tell. A vendor whose zero-PII posture is architectural will let you write it into the agreement with teeth, because the architecture makes the promise cheap to keep. A vendor whose posture is a slide will negotiate every clause below into mush.
We sit on the vendor side of this table, so read what follows as the questions we believe buyers should be asking us, and every vendor in the category. One disclaimer before the clauses: this is an engineering team's view of what the language must pin down, not legal advice. Bring it to counsel; they will tighten it.
Clause 1: Define "derived data," not just "personal data"
The standard DPA defines personal data and stops. The interesting category is what the vendor derives from personal data: hashes, digests, fingerprints, embeddings, scores. Under GDPR, pseudonymised data that can be re-attributed with reasonably available means is still personal data (Article 4(5), with Recital 26 supplying the "means reasonably likely to be used" test). An unkeyed hash of a phone number fails that test trivially, the keyspace is small enough to enumerate, which means a vendor storing plain digests is storing personal data while their deck says otherwise.
Starting language: "Derived Data" means any value computed from Personal Data, including hashes, digests, and fingerprints. Derived Data is Personal Data unless Vendor demonstrates the derivation is not reversible by enumeration, dictionary, or precomputation given the input's keyspace and all keys, salts, or peppers in Vendor's possession.
Clause 2: Keyspace and key, in writing
The one-sentence audit for any digest: what is the keyspace of the input, and where does the key live? A phone number has roughly ten billion possible values; an IPv4 address has about four billion; both are enumerable in commodity time without a key. The clause forces the vendor to answer per data class, in an exhibit, so the answer is a representation rather than a conversation.
Starting language: For each class of Derived Data stored, Vendor shall document: (a) the input keyspace; (b) the transform, including whether it is keyed; (c) where any key material is stored and that it is segregated from the data store; and (d) the rotation procedure. Material changes to this exhibit require notice.
A vendor with real architecture answers this in an afternoon. Ours is public: identifiers are keyed HMAC-SHA-256 under a server-held pepper stored outside the database, with a documented rotation protocol.
Clause 3: Evidence rights over version stamps
Systems migrate. The honest ones carry version markers distinguishing rows written under the current control from legacy rows written before it, and the honest vendors will grant audit rights to that distinction. What you want to prevent is the blended claim: "identifiers are keyed" asserted over a table where a third of the rows predate keying and remain enumerable.
Starting language: Vendor shall maintain per-record versioning sufficient to distinguish data protected by the controls described in the exhibit from data predating those controls, shall report the proportion of legacy records on request, and shall not represent legacy records as protected by current controls.
Clause 4: Breach categories tied to reversibility
A blanket breach clause treats every exfiltration identically, which either over-notifies (burning trust on non-events) or under-notifies (because everything gets argued into the harmless bucket). The better structure defines categories by what the leaked material can actually disclose. A stolen column of keyed digests, where the key lives elsewhere and was not taken, discloses equality relationships and no identities. A stolen key changes the category of every digest it protects. The contract should say both things in advance, so the 3 a.m. analysis is a lookup rather than a negotiation.
Starting language: Security incidents are classified by the data's reversibility at time of exfiltration, considering which keys were compromised. Compromise of key material reclassifies all data protected by that key. Classification determines notification timeline and content per the schedule in this section.
Clause 5: Deletion and exit that respect irreversibility
Standard exit clauses demand return or deletion of "all Customer Data." A zero-PII vendor cannot return identifiers it never stored, and that absence is the property you are buying, but the clause should then say precisely what deletion means for what does exist: digest rows deleted on schedule, backups aging out on a stated window, and, where the vendor supports it, key destruction as erasure for key-scoped data. Ambiguity here is where "we store nothing" quietly becomes "we retain aggregates indefinitely."
Starting language: On termination, Vendor shall delete Derived Data within [X] days and certify deletion, including backup expiry windows. Vendor shall document any data exempt from deletion (aggregates, audit records), the legal basis for retention, and confirm such data cannot be re-attributed to a natural person by enumeration or with any retained key.
Clause 6: The property must survive the subprocessors
GDPR Article 28 already requires flow-down of processor obligations, but generic flow-down language does not carry an architectural property. If the vendor's fraud-scoring partner receives raw identifiers while the vendor itself stores digests, the zero-PII claim is true of one box in the diagram and false of the system you actually bought.
Starting language: Vendor represents that the protections in the exhibit apply to Personal Data throughout its processing chain. No subprocessor receives Personal Data in a form less protected than described, and the subprocessor list identifies which data classes each receives.
From our side
PasskeyBridge signs versions of all six. The reason is unexciting: the architecture was built so the claims are properties of the data model rather than promises requiring discipline. Identifiers exist in storage only as keyed digests with version stamps; the pepper lives outside the database; the null-breach posture is what lets the breach-category clause be generous rather than hedged. The CISO's guide to zero-PII verification covers the architecture behind each answer, and processing phone-derived signals without storing numbers covers the regulatory surface it feeds.
The general test travels beyond us: send the six clauses to any vendor claiming zero PII and watch which ones come back redlined into meaninglessness. The redlines are the audit. If you are evaluating this category now, the identity assurance platform overview maps what the claims should look like when the architecture backs them, and we will put every clause above in front of counsel without flinching.