The plain language requirement in CCPA — a how-to
The CCPA regulations require that businesses notify consumers about their data practices via a privacy policy that is written in plain language (11 CCR § 999.308(a)(2)(a)).
(2) The privacy policy shall be designed and presented in a way that is easy to read and understandable to consumers. The policy shall:
a. Use plain, straightforward language and avoid technical or legal jargon.
b. Use a format that makes the policy readable, including on smaller screens, if applicable.
c. Be available in the languages in which the business in its ordinary course provides contracts, disclaimers, sale announcements, and other information to consumers in California.
d. Be reasonably accessible to consumers with disabilities. For notices provided online, the business shall follow generally recognized industry standards, such as the Web Content Accessibility Guidelines, version 2.1 of June 5, 2018, from the World Wide Web Consortium, incorporated herein by reference. In other contexts, the business shall provide information on how a consumer with a disability may access the policy in an alternative format.
e. Be available in a format that allows a consumer to print it out as a document.
So…how exactly can this “plain, straightforward language” requirement be achieved, when we also have new requirements in the CCPA that detail specific things to include in a privacy policy (11 CCR § 999.308(c)) and when the CCPA doesn’t necessarily make things easier with its new defined terms (legal jargon, which we are supposed to avoid)? And we also have the issue of technical jargon, which has always been difficult to contend with, since engineers are the ones designing systems that process data and they have their own language around these things.
Below is a “how-to” guide that can be used to edit an existing privacy policy or to write a new one using plain language.
First: Understand what “plain language” means
Writing in plain language means being clear and concise.
Plain language in the context of web sites has been defined by Ginny Redish in her book Letting Go of the Words as:
A web site is successful only if site visitors can:
- find what they need
- understand what they find
- act appropriately on that understanding
- do all that in the time and effort that they are willing to spend
Plainlanguage.gov and the Center for Plain Language are great resources for more about plain language writing. All of these resources suggest that the writer put themselves in the shoes of their audience. What kind of content is the reader expecting and what information would be most important to them?
Writing for the reader is the crux of clear and concise writing. And readers are often not engineers or privacy professionals. A good target for what is clear and concise may be something that an 8th grader could understand. If your product or service is aimed at another audience, maybe the 5th-grade level is more appropriate.
Step 1: Read the privacy policy with no pen
This is a simple read, just to get yourself in a fresh state of mind. If you can, change your location from your usual desk or work place (oh, how I miss coffee shops…with a privacy screen covering the laptop of course).
Step 2: Read the policy a second time and prepare a “question draft.”
It is difficult to make a piece of writing make sense if you do not understand what it says in the first place. Resist the urge to begin redlining your privacy policy immediately and instead, put yourself in the shoes of the reader (say, a high schooler) and use the comment function of Microsoft Word or Google Docs to note down what you don’t (or what you think your readers may not) understand fully.
Go get answers to those questions. You may need to engage with other stakeholders or functions within the business to get these answers. For example, the engineering and product design/management functions are usually best placed to know exactly what data is being collected in various product flows and what that data is then being used for. The marketing function is a great resource for what behavioral advertising cookies are being placed and how that data is being used. The compliance function may have information about what data they need to have in order to comply with law or detect or prevent fraud.
Step 3: Read the policy for a third time and start a terminology list
The third time you read through the privacy policy, start a list of what terms, defined or otherwise, you are using in the policy. Excel or Google Sheets are good tools for this. This will allow you to identify what legal and technical jargon you are using. This identification is a key part of your plain language writing exercise, since the CCPA requires that we avoid using this kind of jargon.
Identify in your terminology list:
- legal terms of art
- technical jargon
- acronyms
- complex words
- defined terms
What you are likely to find are some inconsistencies in terminology, especially if the business has been around for a while. This happens because, as a company grows, things change. For instance, a new paragraph gets added to the privacy policy to address a new product, but the entire privacy policy is not necessarily reviewed to make sure the terms used in that new paragraph are consistent.
Be overly inclusive when you make your terminology list. It can become a useful tool for many purposes, and if your company has a content team, they will thank you for it and likely add it to their own terminology list.
Step 4: Read the policy a fourth time and use a plain language checklist
There are many different books and resources that have plain language checklists. Here are a few: (Five Steps to Plain Language, Plain Language Guidelines, Checklists from plainlanguage.gov, Bryan Garner’s book Legal Writing in Plain English).
A very basic checklist is below.
Think about readability:
- How complex are your words? Can you remove or reword complex words and jargon you have identified in your terminology list? (Note: I think it is sometimes ok to use jargon…but only if you do it intentionally and define the jargon so that your reader can understand it).
- How long are your sentences? Can you shorten them to 15–25 words per sentence?
- Can you use bulleted lists or tables to aid readability?
Think about structure:
- How long are your paragraphs? Can you shorten them or break different ideas up into separate paragraphs?
- Do you use headings? Can you change or add informative headings so that the reader can “skim” to find what they need?
- Are you using ALL CAPS or a lot of bold? ALL CAPS is actually not very readable at all and can seem like shouting. Use bold or underline instead and do it with intention.
- Do you have a lot of numbering? Can you reduce numbering to only section numbers or even remove numbering all together? This usually makes the content seem less intimidating to readers.
Overall:
- Do you have any framing or introductory content? Do you need to orient the reader in any way to what you are talking about?
- Is your tone consistent throughout the policy?
- How long is the overall policy? Can you try to reduce the length by 25–50%?
Step 5: Read the policy a fifth time out loud pretending you are a high schooler (or a 5th grader)
Somehow reading things out loud lets our brains work in a different way. We hear things that our eyes don’t catch when reading on the page (computer or printed out). See what questions you still have or if something doesn’t land right.
Most importantly, remember your reader.
One of my teachers on plain language, Frances Gordon from the consultancy firm Simplified, once told me (and I’m paraphrasing here): If you nothing else, try to write for your reader, your audience. If you can do this, you can forget all of the question drafts, terminology lists, and checklists.
