With the inclusion of Vermont, the U.S. now has 24 states that have a comprehensive, modern privacy law. Many of these laws are baselined around the same bill that initially rose to prominence in 2019 in Washington (which, ironically, has no such law for reasons). I sometimes call this bill the Failed Washington Privacy Act or the Amazon Bill (their lobbyists have pushed this bill in a number of states).

Starting from the same baseline does not mean that these state laws end up identical. While they do drive a significant amount of consolidation (bless!) and standardization around various items such as the bundle of rights an individual consumer has or the definitions of what is considered personal information or sensitive personal information, the legislative sausage making always leaves room for substantive markups that can lead to significant changes in how one goes about designing a privacy program. This means that the devil is always in the details with respect to data privacy compliance.

Today, I want to look at one such example to illustrate this. Under these state privacy laws, a business that is a controller (makes decisions regarding what data is collected and how it is used) is required to (a) post a privacy policy that contains certain information about what personal information is collected and who it is shared with and (b) fulfill consumer requests for access to that information. Seems fairly straightforward until you dive into the text.

Transparency requirements are standardizing in information but not format

Here's the Minnesota Consumer Data Privacy Act's transparency requirements for a privacy notice:

Subdivision 1.Transparency obligations. (a) Controllers must provide consumers with a reasonably accessible, clear, and meaningful privacy notice that includes:
(1) the categories of personal data processed by the controller;
(2) the purposes for which the categories of personal data are processed;
(3) an explanation of the rights contained in section 325M.14 and how and where consumers may exercise those rights, including how a consumer may appeal a controller's action with regard to the consumer's request;
(4) the categories of personal data that the controller sells to or shares with third parties, if any;
(5) the categories of third parties, if any, with whom the controller sells or shares personal data;
(6) the controller's contact information, including an active email address or other online mechanism that the consumer may use to contact the controller;
(7) a description of the controller's retention policies for personal data; and
(8) the date the privacy notice was last updated.

[Emphasis added.]

Note the bolded sections here. This is categorical level information. Instead of disclosing AWS or Google Analytics here, a privacy notice instead requires you to disclose "hosting provider" or "analytics service provider." While this isn't the radical transparency that some advocates want, there's genuine reasons for not requiring public disclosures contain perfect granularity as to your tech stack. The two biggest reasons are usually cybersecurity and the burden of constantly updating a public privacy notice with the names every single time you change a vendor in your tech stack (which can happen often!). There's some terms of art I use around these items ("Hosting Provider," "Email Service Provider," "Payment Processor," etc.) when I draft and one giant category I use for everything else ("Technology Service Provider") when I can't find a good box to shove vendors in.

This is fairly standard across the board. Sometimes there's a requirement to connect the personal information to the specific category of vendor (see California), in which case I use a table format for my privacy notices, and sometimes there's not a requirement to directly correlate the two items and you can leave them as separate sections in the privacy notice. But that does not mean you do not have to know what personal information is processed by which individual specific third party. It just means you don't have to disclose that level of granularity in your public-facing privacy policy or notice because the privacy notice is just the rules of the sandbox you play in and the visible part of the iceberg that is your privacy program.

Conflicting Right to Access requirements emerge

Consumers also have the right to access information about what personal information you collect about them and who you share it with. This is typically called a "Right to Access" or a "Right to Know." How you operationalize this across your infrastructure is the hard part of the job. Writing a privacy notice is actually one of the easier parts of a program. The hard part starts when you need to get under the hood and operationalize something. Here's where the sausage-making that is the legislative lawmaking process makes it challenging.

Let's look at Vermont's new Data Privacy and Online Surveillance Act. A consumer has the right to:

(7) obtain from the controller a list of the third parties to which such controller has sold the consumer’s personal data or, if such controller does not maintain a list of the third parties to which such controller has sold the consumer’s personal data, a list of all third parties to which such controller has sold personal data, provided the controller shall not be required to reveal any trade secret.

[Emphasis added.]

By contrast, look at how California's Consumer Privacy Act handles the same:

Consumers’ Right to Know What Personal Information is Being Collected. Right to Access Personal Information
(a) A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following:
(1) The categories of personal information it has collected about that consumer.
(2) The categories of sources from which the personal information is collected.
(3) The business or commercial purpose for collecting, selling, or sharing personal information.
(4) The categories of third parties to whom the business discloses personal information.
(5) The specific pieces of personal information it has collected about that consumer.

[Emphasis added.]

The "Sales" Limitation

Both of these approaches are not a full-scale disclosure of every vendor you use in your tech stack or party you've shared data with. These consumer privacy rights are very specifically tied to the definitions of "sale" and "third party" under the applicable law. There are two approaches to defining sale:

  • a transaction of data to a third party (not a service provider, processor, or other controller) for money or other valuable consideration; or
  • a transaction of data to a third party (not a service provider, processor, or other controller) for money only.

This means you need to conduct a review of every entity who comes into your tech stack, who receives personal information, and (a) classify them as an entity (Controller, Processor, Third Party under most state laws or the CCPA Business, Service Provider, Contractor, and Third Party framework) and (b) classify whether the data transfer is a sale under applicable law. Then you know which specific third parties or categories of third parties need to be included in the Right to Access consumer right addressed above.

So how do you implement this in practice?

After all, you're designing a process that can capture as many states as possible in one system and process. Depending on your architecture you can

  • split out state-by-state compliance;
  • choose the most restrictive as your common denominator; or
  • choose a risk-based approach tailored to which states you have the greatest financial exposure to and ignore the rest.

If I have the capability of a state-by-state compliance program and can pull data on a state based level and I want to expend the effort training my staff on different compliance schemes and building them out in my workflow, I can adjust my intake form to provide a categorical generic list of third parties to states like California, a specific list to states like Vermont (and Minnesota, Oregon, etc.) that require granularity, and tell state residents without a comprehensive privacy law to go pound sand (I don't actually advise this approach, but some lawyers do in much more polite language).

From an implementation standpoint, what's my deliverable? If it's a generic list, I usually provide a template letter in PDF (dated) with either the transparency section of the privacy policy copied and reformatted to fit the letter format or include in that letter a link back to the privacy notice and reference to the specific section. The latter approach is both easier and, in many cases, lazier, but it also forces the privacy notice to be the source of truth for this information and doesn't replicate information that can go out of date or conflict if someone forgets to update the template form letter.

If I'm providing a specific list of customers, that's coming in a fixed format as well. I do not like providing editable documents for evidentiary purposes. Heaven forbid a bad actor take my deliverable and alter it so they can bring a claim or start an online argument that snowballs into a PR disaster. What this functionally means is I have to have a data map or inventory of all entities that have access to personal and I am exporting from that list the subset of parties that are classified as a "third party" involved in a "sale" of personal information. Once I have that greatly reduced list down to a smaller set, it's just a matter of choosing the format for the deliverable. I prefer to do these things in PDF format personally because of the inability to edit but I have seen people deliver locked .XLSX or .CSV files. Because most consumers don't know what a .JSON file is or other rarer file formats are, I prefer not to use those. I have also provided an HTML file that opens in a browser as well for a data portability request and that was a lot of work to edit but makes for a nice deliverable. The point here is to make the deliverable fixed, uneditable, and easily opened by common consumer software without requiring they get a Computer Science degree.

There's an infinite number of ways to tackle these rights in terms of how you scope them and how you fulfill them. Some states are more prohibitive or provide more guidance than others on how they want to see them fulfilled. Some companies are more risk averse than others. Some technology environments are more complex than others or devote more resources to the privacy program. The devil, as always, remains in the details.

If you need someone to help you with your privacy program, please reach out to me at Brandi@BennettTechLaw.com for help.