Which of the Following Is Not Permitted Disclosure of PII?
Ever stared at a compliance checklist and wondered whether sharing a customer’s email address with a partner is a “no‑go” or just a gray area? In practice, you’re not alone. Now, in the world of personal identifiable information (PII), the line between “okay to share” and “definitely off‑limits” can feel like a moving target. The short version is that not every piece of data is treated the same, and the rules change depending on who you’re talking to, why you’re talking, and how you protect it.
Below we’ll break down what counts as not permitted disclosure of PII, why it matters, and what you can actually do to stay on the right side of the law (and your company’s policies) Nothing fancy..
What Is PII, Anyway?
When most people hear “PII” they picture a Social Security number or a credit‑card code. That’s part of it, but the reality is broader. Think of PII as any piece of information that can be used—on its own or combined with other data—to identify a specific individual.
Direct identifiers
- Full name, SSN, driver’s license number, passport number, biometric data.*
Indirect identifiers (when combined)
- Email address, phone number, IP address, date of birth, ZIP code.*
Context matters
A lone ZIP code isn’t PII, but a ZIP code plus a birthdate and gender? That’s a different story. In practice, most privacy frameworks (GDPR, CCPA, HIPAA, etc.) treat any data that could reasonably be linked back to a person as PII Simple, but easy to overlook..
Why It Matters / Why People Care
You might think “I’m just sending a marketing email—what’s the harm?” Yet, the fallout from an unauthorized disclosure can be severe:
- Regulatory fines – GDPR can slap you with up to 4 % of global revenue; CCPA can hit $2,500 per violation.
- Reputation damage – One data breach can erode customer trust for years.
- Legal liability – Victims can sue for negligence, especially if the data includes health or financial details.
In practice, companies that treat PII as a “nice‑to‑protect” asset end up paying the price when a breach surfaces. The cost isn’t just monetary; it’s the loss of goodwill that took months to build.
How to Spot a Not‑Permitted Disclosure
Below is the meat of the article. We’ll walk through the most common scenarios where sharing PII crosses the line into “not permitted.” Think of this as your cheat sheet for compliance meetings That's the part that actually makes a difference. No workaround needed..
1. Sharing PII with Unauthorised Third Parties
If a vendor or partner hasn’t signed a data‑processing agreement (DPA) that outlines permissible uses, you’re likely overstepping.
- Example: Sending a CSV of customer emails to a freelance designer for a newsletter layout without a DPA.
- Why it’s a no‑go: The designer could inadvertently expose the list, and you have no contract guaranteeing they’ll keep it secure.
2. Disclosing Sensitive PII Without Explicit Consent
Sensitive categories—health records, biometric data, financial info—require a higher bar. Even if you have a general privacy notice, you still need explicit, informed consent for these items Turns out it matters..
- Example: Posting a patient’s lab results on an internal Slack channel that isn’t encrypted end‑to‑end.
- Why it’s a no‑go: Health data is protected under HIPAA (U.S.) and GDPR’s “special categories.” Consent must be specific and documented.
3. Publishing PII in Public‑Facing Content
Anything that ends up searchable on the internet is a public disclosure. Even a “soft” identifier can become risky when combined with other public data.
- Example: Writing a case study that includes a client’s full name, city, and project budget.
- Why it’s a no‑go: Readers can piece together the identity, especially if the client is a small business with a unique project.
4. Transferring PII Across Borders Without Adequate Safeguards
Cross‑border data flows are heavily regulated. If you move EU citizen data to a server in the U.Now, s. without Standard Contractual Clauses (SCCs) or an adequacy decision, you’re violating GDPR.
- Example: Exporting a list of European customers to a cloud bucket hosted in a country lacking an adequacy agreement.
- Why it’s a no‑go: The data could be accessed by foreign authorities without the same privacy protections you promised.
5. Using PII for Purposes Outside the Original Collection Reason
Purpose limitation is a core principle. If you collected an email address for order confirmations, you can’t suddenly use it for a targeted ad campaign without a new lawful basis.
- Example: Adding a “subscribe to offers” checkbox after checkout without a separate consent flow.
- Why it’s a no‑go: The original purpose (transactional communication) doesn’t cover marketing.
6. Disclosing PII in Response to Unverified Requests
A common trap is replying to a “customer” who claims they need their data but hasn’t proven their identity Small thing, real impact..
- Example: Sending a full credit‑card statement to an email address that matches the last four digits of a card.
- Why it’s a no‑go: You’ve effectively handed over sensitive data to a potential fraudster.
7. Sharing Aggregated Data That Can Be De‑identified Poorly
Even when you think you’re “anonymizing,” re‑identification attacks can reverse‑engineer the dataset Which is the point..
- Example: Publishing a spreadsheet of user ages, zip codes, and purchase amounts.
- Why it’s a no‑go: Researchers have shown that a handful of data points can uniquely identify a large portion of the U.S. population.
Common Mistakes / What Most People Get Wrong
Mistake #1: Assuming “Public” Means “Free to Use”
Just because a piece of info is already on a social media profile doesn’t give you a blanket right to reuse it in a marketing database. The context of collection matters Worth knowing..
Mistake #2: Believing “Encryption = Permission”
Encrypting data is essential, but it doesn’t replace the need for a lawful basis. You can’t encrypt a breach‑prone list and then claim you were fine sharing it with anyone Simple, but easy to overlook..
Mistake #3: Relying on “Company Policy” Over Law
Internal policies are great, but they can’t contradict legal obligations. If your handbook says “share customer emails with any partner,” that policy is invalid under GDPR/CCPA.
Mistake #4: Over‑Aggregating to Avoid Responsibility
Some think “if we combine data into a report, it’s no longer PII.” Wrong. Aggregated data can still be PII if it includes enough quasi‑identifiers.
Mistake #5: Ignoring the “Reasonable Expectation” Test
Regulators often ask, “Would a reasonable person expect this data to be shared?” If the answer is no, you’re likely on thin ice.
Practical Tips / What Actually Works
-
Map every data flow – Create a visual diagram of where PII enters, rests, and exits your organization. Spot the “outside the fence” arrows and plug them Turns out it matters..
-
Implement a Data‑Processing Agreement library – Keep a template DPA ready, and require signatures before any third‑party gets a copy of PII.
-
Use role‑based access controls (RBAC) – Only give employees the minimum PII they need to do their job. The fewer eyes on the data, the lower the risk.
-
Adopt a “purpose‑first” consent model – When you collect data, ask for consent per purpose (transactional, marketing, analytics). Store that consent metadata alongside the record.
-
Deploy data loss prevention (DLP) tools – Set rules that flag outbound emails containing SSNs or credit‑card numbers to a compliance inbox for review Easy to understand, harder to ignore. Practical, not theoretical..
-
Run regular re‑identification tests – Hire a privacy researcher (or use open‑source tools) to try and re‑identify your anonymized datasets. If they can, you need stronger masking.
-
Document every request for data – Whether it’s a user’s right‑to‑access request or an internal data pull, log who asked, why, and what you delivered. This audit trail protects you if regulators knock It's one of those things that adds up. And it works..
-
Train, but keep it real – Move beyond “slide decks.” Use real‑world scenarios (like the ones above) in your privacy training so staff can spot a not‑permitted disclosure on the spot And that's really what it comes down to. Surprisingly effective..
FAQ
Q: Is it ever okay to share a customer’s first name and city with a partner?
A: Only if the partner has a legitimate need, a signed DPA, and the data is used for a purpose the customer consented to. Otherwise, it’s a risky disclosure Practical, not theoretical..
Q: Does hashing a password count as “disclosing” PII?
A: No. Hashing transforms the data into a one‑way string, which is not reversible. Still, you must still protect the hash with strong salts and limit access.
Q: What about employee data? Is that PII too?
A: Absolutely. Employee records contain SSNs, payroll info, health data, and are subject to the same privacy rules as customer data.
Q: Can I share a list of email addresses with a marketing agency if I delete the names?
A: Email addresses are considered indirect identifiers. Without a proper DPA and a lawful basis (e.g., consent for marketing), that share is still not permitted Small thing, real impact..
Q: How do I know if a cross‑border transfer is allowed?
A: Check whether the destination country has an EU adequacy decision, or put SCCs or Binding Corporate Rules in place. Documentation is key.
When it comes down to it, the biggest guard against an illegal PII disclosure is mindfulness. On top of that, do we have consent? If you pause and ask, “Do we really need to share this? But is there a contract? ” you’ll catch most pitfalls before they become headlines.
So the next time you’re tempted to forward that spreadsheet, remember: not every piece of data is free to roam, and the cost of a slip‑up is rarely worth the convenience. Keep the data tight, the contracts tighter, and the consent forms on standby. Your future self (and your compliance officer) will thank you Not complicated — just consistent. Practical, not theoretical..
