Getting Your Privacy Policy Off The Ground
I’ve been critical of those collecting personal data on their site who don’t offer a privacy policy. The common defense has been “we can’t afford a lawyer.” I’m here to tell you that even if you can’t afford a lawyer you should still have a policy available to users notifying them of what you intend on doing with their data. In this post I’m going to walk you through an inventory method that will give you a solid framework from which you can build a policy.
Note: I am not a lawyer and therefore you should not take what I say as legal advice. You are responsible for the accuracy of your own privacy policy.
Create an Inventory
The process of creating a privacy policy starts with what is probably going to be the most difficult step: You must inventory all of the current and future uses of the personal data you are going to collect, store and/or process. If you are banking on using your users’ profile information or habits to serve targeted ads, collecting a birthdate so you can comply with COPPA, storing the IP address of your users, or setting a cookie for website analytics you need to include this in your policy. Creating a data inventory will highlight the places and activities where personal information is collected, used and stored.
The final inventory itself doesn’t have to be anything over-formal or laid out in a print-ready format—It will never be public. A simple spreadsheet with columns for the type of data, the purpose(s) it will be used for, and how you will collect it is enough to start with. You will likely want to add which items are required by the user and which are optional, what the user can opt-into, whether the user can delete a particular piece of information, and how long it will be stored as well.
In this post I’m going to break down this inventory process into manageable steps. The order in which you tackle these steps is up to you and will be different for each organization. However, I’ve tried to organize them in an order where each consecutive step builds on the last. To help identify the requirements involved in each step I’ve preceded them with a question. If answering the question is too difficult feel free to skip that step to keep the ball rolling and circle back to it later.
The Steps
Where are the places in your organization that you collect personal information?
To properly document all of the pieces of personal information you are collecting you need to consider all of the places you will be collecting it. Account creation for a service is an easy one, but have you considered your website logging? Does it log IP addresses? How about customers who may call in, or business cards you collect at conferences? If the information you collect ends up in a repository containing personal information you should write it down in this step.
What personal information are you collecting? (e.g. Email addresses, first and last name)
With a solid understanding of all of the places you’re collecting data, you can now start to detail all of the pieces of information you are collecting from each location. This includes names, addresses, phone numbers, IP addresses, etc. but may also include personal preferences and other psychographic and demographic data. Anything that you could use, even if only in combination with something else, to identify the individual is, by definition, personally identifiable information (PII). All PII should be documented in this step regardless of how trivial you feel it is.
Why are you collecting each piece of personal information and for what other purposes will you use it? (e.g. Marketing purposes, sales, product improvement, feature enhancement.)
Once you have compiled a comprehensive list of the information you are collecting, it’s time to document why you are collecting it and the purposes it serves for the organization. If you are collecting the user’s birth date because you need to comply with COPPA that’s something you need to note, but if you are also using that to send a “happy birthday” message you must note that as well.
It is a good idea to place each “reason for collection” on a separate line on your list. This will help you later in the inventory process. If email address is used for sending communications as well as authentication credentials make sure each reason gets noted on a separate entry. This step will likely take a considerable amount of time and involve more than one individual’s input. The marketing manager may have many items to add that a project manager would not have considered.
What kind of access/control does the user have over the information you have about them? Can they delete or change any of the stored personal information, or even delete it altogether?
With a clear picture of the data you are collecting and why you are collecting it, it’s now time to consider which items on your list are required and which are optional. There are some details we all have to collect, and some that aren’t required to deliver the service but may enhance the service’s features or play an important role in long-term marketing and sales plans. You need to make a distinction between data you must collect versus what you want to collect. And once you’ve collected a piece of information is it unchangeable? Can the user update it on their own or can they remove it from the system?
The choices here will be difficult. Go through each reason for collecting personal information and note whether you really want to require it from the user or not. Generally, if the core of the user experience doesn’t change based on a piece of information provided that information isn’t required. If you need the customer’s postal code to properly target ads you might deem it a requirement, but if the user wants to opt-out of targeted advertising and you want to give them that option it is not technically a requirement.
How long are you going to store the information you are collecting?
Next it’s time to consider how long you plan to store the information you collect. If you need to collect a new user’s birth date for COPPA compliance then you must, but is there any reason to store it? If you have technical controls in place that assure the user attested to being fourteen years or older, what is the purpose of storing that data? If you are collecting email addresses for the sole purpose of sending optional communications and the user doesn’t want to receive those communications, do you need to store it? What about activation codes. How long should you keep those in your database? When the user closes an account are you going to continue to keep this information? Why? You may get a specific as you need in this step. Sometimes it is enough just to have the options for “transient” and “permanent.” Others will want more fine-grained options.
Do you share the information with others? Are you doing any ad tracking or web based analytics? (e.g. Web beacons in emails, click-through on display ads)
You’re not only responsible for the information you collect and store through the services you build and manage, but you are also responsible for the information that any authorized third-party services are collecting as well. Do you use an outside analytics service like Google Analytics? Do you use an email service provider? Are these services collecting personal information or is it only anonymous data? You need to read each service’s privacy policy and terms of service to find this out. This is a good time to re-evaluate whether their policies are in line with yours and whether you need to use each particular service provider.
What steps do you take to secure the information you hold? Encryption? Hashing? Are you PCI compliant?
The person in charge of information security should be able to complete this part of the inventory rather quickly. It is important to note for the personal information being stored, how it is protected. Is it in plain-text in a file on a server, or stored in a database protected with access control mechanisms. Is it stored in the database encrypted with a symmetric algorithm or is it hashed? This part of the inventory should match your information security policy and if you don’t have an information security policy in place you should use this process as an excuse to start one.
Special Considerations
If you’ve done your due diligence and gone through each of the steps included here, you’re in great shape. You should have a very clear picture of what you’re collecting, the purposes for which it is being used and how you’re storing it. However, you’re not quite done yet. There are couple of special items to take into consideration.
Are you collecting location data?
Make sure you get explicit permission to collect this type of data. People are very sensitive to giving over that level of data and there are unique laws and regulations around this type of data.
Who in your organization should be contacted with questions about privacy issues?
Some states and jurisdictions require contact information to be made public. Assign it to someone, or a group of people, and create an email address for queries. Also, it would be a good idea to publish a physical address as well.
Wrapping It Up
Having gone through the inventory process, now is an excellent time to reassess what you’re collecting and if it is all necessary. Eliminate the unnecessary items. That will lower your exposure to a data breach and simplify your operations—not to mention that it follows privacy best practices. It’s also a great time to get a privacy lawyer involved if you don’t already have one. However, if you are so inclined, you have all the information about your operations to start compiling a policy on your own.
I understand, and you should to, that any lawyer who is reading this is going to cringe at any recommendation to “cut and paste” a privacy policy together—which I am about to do—but please keep in mind that what I’m trying to do here is help organizations gain a holistic understanding of the considerations that go into a policy and provide context. In addition, it’s my opinion that something is better than nothing: If a regulator comes knocking at your door with an indictment you’re in a much more defensible position having tried to comply with the law rather than stating you’re just too poor to lawyer-up.
It is important to remember as you create a policy that you must do as you say. It’s not ideal if you aren’t transparent to your users and neglect to tell them how you handle their personal information but it is literally criminal to promise something in your privacy policy and not comply with it. So as you compile your policy text err on the side of caution: It is better to say nothing, then to say something you can’t or won’t do.
You’ll notice that I said “compile” rather than “write” in the previous paragraph. That’s intentional. I will point you to places online where you can legally grab the text you need. You should only need to format and edit the resulting policy. The less you write the better.
A great place to grab a privacy policy is to start with something that is open-licensed. That is, it is legal to copy and reuse. Creative Commons is one such license and it happens that the Creative Commons organization has its own, comprehensive, privacy policy that is Creative Commons licensed. Wikimedia has another [excellent one](http://jnorthrop.me/2012/04/3/getting-your-privacy-policy-ground/(http://wikimediafoundation.org/wiki/Privacy_policy) you are free to repurpose.
If neither of those suit you there are more to be found searching online. In addition, there are many online policy generators and one service I am aware of that has a nicely formatted easy-to-create policy. I have not tried any of the free generators as most require the user to hand over contact information, but that might be worth exploring. Or, if you don’t mind paying a recurring fee you can check out iubenda. The policy this service generates is attractive and easy to read.
This post tries to cover so much material that there is probably enough for an entire book so it stays high-level and moves very quickly but I hope it at least reduces some barriers to creating a policy and provides enough guidance to get you started in the right direction. I understand those who are just getting started building a business face many hurdles to overcome and a privacy policy is not a user-building or revenue-generating activity but it is so much easier to tackle this issue early. Doing it late in the game will require much more effort and risks creating big distraction when things just get rolling. So take a couple of days, go through the steps I’ve outlined, and get the process started.