Personally Identifiable Information (PII), and the right way to upload your customer data to Faraday

We get it, when you’re working quickly, it can be tempting to attach a file to an email and call it a day. But when the data can identify an individual human being, email is not the right channel.

At Faraday, data security is something we take extremely seriously (just check out this blog) but it’s also a shared responsibility, and small process choices can make a big difference. That’s why we want to make sure all our customers, clients, and partners are on the same page about how we protect Personally Identifiable Information (PII). Accordingly, this is a quick guide to what counts as PII, why we don’t want it sent over email, and the secure ways to get that data into Faraday so you can get to the fun parts.

What is PII

In the most basic sense, PII is any piece of data that can identify a specific person, either on its own or in combination with other fields.

Within Faraday, the easiest way to think about this is to look at the identity fields we use to recognize individuals and households during identity resolution. In dataset identity sets, the core fields you should treat as PII include name, location information, and contact details. These are the same building blocks we expect clients to map when they want strong match rates.

In practical terms, that means a file containing any of the following should not be emailed to us:

• First name and last name
• Street address, city, state, or postcode when tied to a person or household
• Email address
• Phone number
• Email hashes

This is also why “we removed the name” is not a safe workaround. A full address, phone number, or email can still identify an individual. Even less complete combinations can be enough to narrow someone down (ie there might only be one "Maureen" in zip code 05400).

If you want a more technical view of how these identifiers work together, our datasets documentation outlines the identity resolution priority order and the standard identity fields we recommend mapping.

What is usually ok to share

It is worth noting that some data can be sent through email. Aggregated data is often the distinguishing factor. For example, counts or summaries at a ZIP code or regional level are typically fine, as long as that data cannot be used to identify a specific individual.

But when in doubt, treat anything that looks like a row-level customer record as PII. And if you’re unsure DON’T just send it. Reach out to support with questions when you have them before sending potentially sensitive information.

How you should send data to Faraday

So we’ve established the rule: do not email us files that contain PII.

But we still need those identifiers to resolve identities, append customer context, and build predictive models. The difference is that we need them coming through the secure paths designed for sensitive data.

To send PII to Faraday, use one of these options:

• upload through the Faraday app
• upload CSVs via your normal dataset workflows
• use an established integration or connection
• or upload programmatically through the methods you already use with Faraday.

These options are built for secure transfer and handling of sensitive customer data. If you’re unsure which route is best for your setup, reach out to support and we’ll help you pick the right path.

Why we care about PII

This is not about slowing anyone down. It’s about protecting your customers and keeping your data flows aligned with the security standards both of our teams expect.

Email is convenient, but it is not designed for handling sensitive, row-level customer identifiers. The secure upload paths in Faraday are. Using them protects your customers, reduces risk for your team, and helps keep our shared data workflows clean and consistent.

And this isn’t where our commitment to data security ends. Faraday is also SOC 2 audited, compliant with all federal and local regulations, and we treat secure data handling as an operational discipline. We store data with trusted cloud vendors, encrypt it in transit and at rest, and control access with measures like multifactor authentication.

All of this only works as intended when PII comes through the secure paths built into the platform, rather than unencrypted email.

If you think you have an exception

If your current process can’t conform to these guidelines, reach out to support. We’ll help you find a secure path forward.

In closing

At the end of the day, we’re here because we all care about the same thing. Protecting our customers’ private information.

If you take one thing from this post, make it this: PII should come to Faraday through the platform, not through email. That simple choice helps keep your team, your customers, and your data operations safer, while still allowing you to get the full value of customer context and predictive modeling.