Collaborating on Privacy Compliance Policies
As more jurisdictions add privacy regulations, developers need to incorporate privacy compliance capabilities to online forms, data integrations, and internal processes. To do this effectively, you must understand how to engage with key stakeholders to assist with policy development and drafting technical requirements. To illustrate, let’s begin with a story.
A chief marketing officer (CMO) and an attorney walk into a conference room to talk about the new privacy laws and how their company should respond. The attorney says, “To minimize our risk, we should collect as little information as possible, store it for as little time as possible, and then delete it.” The CMO responds, “If we do as you suggest, we cannot deliver the user experience the customer demands, send leads to sales, and drive revenue. Instead, we must collect as much information as possible and keep it for as long as possible.”
As you gather requirements, how do you find common ground when these two objectives seem to be complete opposites? The legal team’s mission is protecting the company from risk and the accompanying financial penalties, which can be substantial. On the other hand, marketing will struggle to market and promote the company’s products if they don’t have accurate customer and prospect data. Without this information, marketing cannot deliver the best possible customer experience, stimulate and capture interest.
Privacy regulators included a solution for this situation by allowing companies to create privacy policies that work within the parameters outlined in the laws but tailored to a company’s specific use cases. And then enforce those policies through technology, processes, and training. If companies receive privacy complaints, using the technical solution developed and adhering to internal processes can help avoid penalties as long as they are reasonable.
Working with Stakeholders
Data Entry Points and Use Cases
Regardless of where data enters your company, your privacy policies should define how to use personal information while helping you stay compliant with a myriad of different laws and regulations. Depending on the jurisdiction, privacy laws may include very detailed rules for data collection, storage, and use. For example, a regulation may explicitly outline the type of data, and the length companies can store and use information. Or, as we discussed earlier, the regulation allows each company to establish appropriate policies when explicit consent is absent. These policies help companies work within the law, offering a framework for mitigating risk while enabling modern marketing and sales practices.
Let’s look at two examples:
Example 1: Widgets
You work for a company that sells widgets online. According to your sales team, the typical sales cycle takes 3-6 months from the initial contact to close. Your primary lead sources are web forms and emails. Your forms ask for the user’s country and state/province where appropriate and include a checkbox for consent allowing marketing communication via Email. And because you permit customers to contact you via Email, you classify them as implied consent. Your policy might specify any form submitted with consent is valid for three years or until revoked. Online form submissions without consent are only valid for six months. And for an incoming email without consent, your current policy permits email communication for one year before permission expires.
Example 2: Jet Engines
Your company is a diversified manufacturer with facilities around the world. One of your business units sells jet engines. Your typical sales cycle is two years. However, most jet engine buyers are repeat customers, purchasing every 3-5 years. When establishing your policy, you might allow communication for five years after each contact by Email or online form with consent.
Consider the many ways your company collects data from customers and prospects. For each interaction, depending on the user’s location, developers must understand what information is collected, and then must classify it correctly, so it maps to your policies.
Organizing Data for Policy Discussions
Let’s continue with our two examples. So far, we’ve identified two entry points: online forms and Email. Further, let’s specify the system where data is stored and processed. In our example, we’ll use a marketing automation platform that receives data from forms on your website, and a CRM. For our purposes, let’s say that both cases are from the same global company but different brands or business units.
Here’s how our example data looks in a table:
These examples are just a start. In our experience, it’s not unusual for companies to have 20 or more use cases. For example:
• Business card drop with/without consent at conference or trade show
• Conference attendee list with/without 3rd party consent
• Event registration with/without consent
• Content download with/without consent
Click here for a more complete list of potential Permission Types and Processing Purposes.
Establishing Time to Expiration
Even if a contact grants consent to use their personal information, it’s unlikely they intended that to be forever. And some regulations like CASL have specific retention periods. The best practice is to define how long before consent expires your company. A straightforward way to create a policy and establish an expiration period is to consider a typical sales cycle. And then, using this information, document a rationale for collecting, storing, and using the customer’s data. For example, a business card dropped into a jar at a trade show might have a time to live for one month. That is sufficient time to send a thank-you note for visiting your booth. Remember, these policies can serve as evidence supporting your company in the event of a complaint, so your policies must be reasonable.
Policies Across Multiple Jurisdictions
Today, privacy laws are not identical across multiple jurisdictions. As such, privacy policies will likely vary by country, each with potentially different rules. For example, within the current California Consumer Privacy Act (CCPA), businesses are not required to confirm OPT-IN before communication, only offer a convenient OPT-OUT option.
In contrast, for most Europeans, the General Data Protection Regulation (GDPR) requires OPT-IN for most cases. However, most agree that laws will become more uniform over time, including federal regulation within the US. Regardless, your best course of action is to plan for each jurisdiction, while carefully detailing where rules are different.
As a developer, you must identify each use case and create policies before you can translate that into code and processes. In most cases, collecting the user’s country and state/province enable you to identify the corresponding jurisdiction. Your systems of record will need to track the appropriate data for each use case and be open to auditing if the need arises.
Preparing for Policy Discussions
• Make a list of all data entry points for your company. These may include Email, web forms, phone calls, paper forms, mobile apps, in person, or even video. Other sources include data integrations and events.
• Identify the Permission Type. The purpose of permission collection. For example, “Communicate Electronically.”
• Define the processing purpose. Detail the entry point used to determine permission, including if you have consent or not. For example, “Form Submission with consent.”
• Specify the system collecting data: For auditing purposes, you should identify the data origin.
• Consider other data available at the entry point. Additional data available at the entry point might help in the event of a privacy complaint. For example, for web forms, you could capture the form name, form language, product name, respective business unit, or brand association. A business card dropped into a tradeshow contest might have the date, show name, location, contest name, rules, etc.
• Work with sales and marketing to discuss a typical sales cycle for each use case. Using this information, you can draft a narrative that articulates your rationale when writing a policy. It offers a starting point for determining how long communication is allowed along with the data retention period. For companies with diverse product offerings and business structures, your policies may differ by communication channels, product lines, and business units.
• Prepare your documentation and proposed policies. Compile your information in a spreadsheet or other document. Detail each use case, the data collected, the source system, proposed marketing or sales contact period, and retention policies. Write everything using easy to understand business terms.
Here is a link to an excel template as a starting point.
For developers, establishing privacy compliance policies and collaborating with the various stakeholders can feel challenging because the goals may appear to conflict. Start by considering your role in working with the data and ask probing questions to uncover the necessary data to comply with regulations. Identify the key stakeholders and work closely with those who work with the data. Learn and document how others interact with the data across its entire lifecycle. Draft your proposed policies and collaborate with stakeholders in a fact-based conversation about finalizing your policies. Then translate those policies into technical requirements.
Originally posted at https://4comply.io/privacy-compliance-policies-guide-for-developers/
Top comments (0)