This series by the team at Sentinel examines the rationale and benefits of building a culture of privacy in your organization by highlighting five organizational drivers that, in combination, can result in lasting change. In this second article, we’ll provide a look at how a culture of privacy can help you reach your legal compliance goals and some tips on how to implement one within your organization.
For companies that deal with personal information, which is most companies these days, privacy compliance is a complicated endeavor, fraught with risks, particularly for businesses that operate in multiple jurisdictions. While most maturing privacy programs start by just considering legal requirements and restrictions on how personal information is used, doing privacy well requires a broader perspective.
One way that privacy gets hard is when your business operates in multiple jurisdictions. How do you comply with different privacy laws when they have slightly different definitions of PI? Or when they’ve all got a right to access, but with different requirements for what PI to include? What if some privacy laws are more specific in how you must respond, for instance mandating that you provide response by post, or whether you may require a login to assert the right?
Taking an approach where every unique nuance of every law needs to be complied with to the maximum extent possible is a prescription for always chasing the next thing to come along, rather than taking a strategic approach to understanding and delivering against the common features in a mature and measurable way.
Given these differences across jurisdictions, there are choices to be made about how best to resource your privacy programs, finding efficiencies where possible. And because privacy laws generally contain significant ambiguity, you’ve got to weigh risks and benefits, ultimately aiming to tell a good privacy story in the event that regulators come asking for you to defend how your complying with their law.
Doing privacy well
There are no easy answers to the question “how do we do privacy well?” In every business I’ve worked with, the volume of PI (and data in general) has grown organically over the years as the businesses themselves have grown. And if you’re not keeping a close eye on the PI you collect and why you use it, it gets very difficult to do privacy well.
While most modern privacy laws share a set of common privacy concepts and principles, the details will bite you in backside if you get them wrong. For instance, it’s not enough for your legal team to simply say that you comply with access requests by providing all the PI that you have in your data stores. Or that deletion requests simply result in destroying all relevant PI wherever it resides.
In terms of legal compliance, a culture of privacy means you look for commonalities among the relevant privacy laws, engage stakeholders and make an informed judgment call to achieve the best fit, in good faith, considering the resources at your disposal, your business’s technical and organizational maturity, the risk of the PI you process and the value of that PI to your business.
Most organizations haven’t been forced into developing a fully matured infrastructure and processes to deal with future privacy laws, even if the relevant privacy concepts are well known. The majority are trying to deal with what the now and don’t have time to consider what is coming down the track, resulting in more stress and tactical decisions to meet constrained deadlines.
All too often this has resulted in privacy programs growing more organically than architecturally. In a culture of privacy, the focus is on building a right-sized, well architected privacy program designed to deliver against not only today’s requirements, but the likely things coming down the track (ePrivacy Regulation at some point will pass).
Considering the velocity with which privacy laws and regulator scrutiny happen now, building one-off features for every privacy law isn’t desirable, or sustainable. In an organization with a culture of privacy, you identify the most important concepts and principles, and build your privacy program in a way that is flexible enough to handle the specifics where and as necessary. Wouldn’t complying with the do-not-sell requirements of CCPA have been a lot easier if you had a complete and up to date, query-able list of every vendor and third party that you share PI with? And that’s not the only good reason to have that type of information up to date.
Finding the commonalities
For this article, let’s just consider two of the most prominent privacy laws: GDPR and CCPA. GDPR is the more comprehensive of the two and comes with a wellspring of supporting documentation and regulator history. It’s somewhat well-understood at this point, and even as it was coming into effect, we could make pretty good guesses as to how to comply. CCPA, on the other hand, is a bit more haphazard and less developed, with no real documented history to tell us how it’ll be interpreted by regulators or the courts. The regulations are in flux, and enforcement hasn’t happened yet, so we don’t know what regulators will focus on (though we can all guess).
If you’ve already invested heavily in GDPR, you likely don’t want to repeat that investment for CCPA and any other privacy law that comes down the pike. Reusing what makes sense, tweaking those things that you can, allows you to adapt your previous investment to new obligations.
Take the right to access. Both GDPR and CCPA require that you respond to an access request. But these laws have slightly different definitions of PI. What to do? Well, if you’ve already identified and mapped all the PI you process in your products under EU jurisdiction, it’s likely you can adapt that mapping to meet your CCPA obligations with slight changes in specifics. While you may not be able to use your GDPR version of access response for CA residents, you can probably reuse 80 percent of what you’ve got.
Likewise, it would make no sense to completely rebuild your right to access infrastructure from scratch to meet the differing timeline obligations in GDPR (one month) and CCPA (45 days). You’ve already developed the core requirements for responding to those requests (you know where the relevant PI is, you know how to gather it into a report, you can generate and send the report, you can answer follow up questions to reports, etc.). It’s a lot less effort to create a separate ticket queue for CCPA and recalibrate your timers there than it is to build a CCPA-specific workflow. A culture of privacy enables you to reuse where it makes sense.
Lessons from security
We can look to security organizations and learn some lessons about how to efficiently dedicate resources in handling similar challenges (e.g., ensuring the confidentiality, availability, and integrity of PI). Security has industry standards that provide guidance on how to tackle threats, and leadership understands that to effectively secure their organization’s assets they need to commit people and money, measure against objective standards and adapt as necessary. Unfortunately, privacy hasn’t yet gotten to that point of maturity, notwithstanding the fact that those core privacy concepts and principles I alluded to earlier have been well documented for decades (i.e., the Fair Information Practice Principles). However, even in the absence of officially sanctioned privacy standards, you can review relevant privacy laws and determine commonalities, which in turn means you can identify efficiencies in how you approach privacy in your organization.
A culture of privacy approach means not letting the perfect be the enemy of the good. Good privacy practices mean you’re substantially meeting your obligations in good faith, considering the risks and resources at hand. While there may be gaps in your privacy program you’ve got a well thought out strategy for approaching privacy, well-developed requirements, competent staffing and leadership committed to continual improvement — in other words a culture of privacy.
Similarly, we know that security is never perfect, and that it’s only a matter of time until something bad happens. What’s important is that we’ve got the capability and mission to monitor for that and to mitigate at the earliest opportunity. Reasonable security doesn’t mean perfect security (which, again, doesn’t exist). Likewise, for privacy, reasonable should be the order of the day. Prioritization decisions will have to be made based on risk, and as with security, you’ve got to always be reviewing and adapting, continuing to build a better, though never perfect, privacy program.
You’ll likely never have the resources to build custom privacy programs for every privacy law you’re subject to. You’re most likely to mitigate the most privacy risk if you identify those commonalities, prioritize your efforts, and aim for continuous improvement. A culture of privacy enables you to mitigate privacy risk to the best of your ability. You can avoid reputation-damaging news stories, and users will have a better experience. And happy users are more likely to lead to happy regulators.
Photo by La-Rel Easter on Unsplash
