Create an Inventory
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.
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)
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.
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.
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.
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.