In this series of articles about the CCPA, we’ve been talking about how the new privacy Act affects businesses in California (and businesses outside the state if they handle the data of California residents). We’ve seen that consumers now have seven key rights, and that businesses need to change the way they handle personal information in order to meet those rights.
We hope that along the way we’ve provided a clear and condensed summary of the Act, but I’ll be honest with you because I’ve read every word of it: it isn’t a well-written Act.
The reason is that it was fast-tracked through the State Senate and Assembly in just seven days in June 2018 to avoid a much stricter state-wide ballot initiative automatically becoming law. As a consequence, it’s vague on what businesses need to do to be compliant.
While the California Attorney General’s office (CAG) has published draft text for the regulations which will enforce the CCPA, they’re similarly hazy. In fact, the Initial Statement of Reasons (ISOR) for the proposed adoption of the CCPA issued by the CAG states: “By providing clear direction to businesses on how to inform consumers of their rights and how to handle their requests, the regulations will make it easier for consumers to protect their rights.”
My issue with this is that while businesses are being told how and when to talk to customers, neither the Act, nor the text of the regulation from CAG, provides an outline of what processes need to be put in place to make it happen and become compliant.
It’s a bit like buying a Star Wars Millennium Falcon Model Kit, only to find out when you open the box that they forgot to put the assembly instructions inside. You know what it should look like because there’s a picture on the box, but you have to work out for yourself how the 900 parts actually fit together.
That’s the purpose of this final post in the series: to outline the three areas your business will need to focus on in order to be compliant:
- Catalog your data so that you know what data you have, where it is, and which category each piece of data falls into.
- Introduce policies to manage your data in order to meet requests for information and the deletion of data on an ongoing basis.
- Protect your data by introducing security procedures and practices in order to avoid the “unauthorized access and exfiltration, theft or disclosure” that can result in a civil action.
Catalog your data
The first step is to find, identify, classify and catalog your data, which may sound easy but think about it for just a moment. Do you know where all of your data is? Do you know when it was collected, for what reason, and what’s happened to it since?
Truth is that data within businesses tends to leak into lots of different places. Copies of the production database may be in use in development and testing, for example. A remote sales office could have a copy of a customer database open to every employee. There might be legacy databases used for Business Intelligence purposes. Backups may not be encrypted and could be in multiple locations with no controls over access – the list goes on.
Only by creating a record of every database, and every instance of it, will you gain a real understanding of where the data flowing through their business is stored and processed, and who has access to it. You can then consolidate the storage of data to as few locations as possible, so that access can be restricted and, more importantly, you can pinpoint where any and every record is.
Once you have that knowledge, you can start the cataloging exercise itself. Some of the data will be standard personal data like names and addresses, job titles and telephone numbers. Other data could be more sensitive like a person’s racial or ethnic origin, or details about health or sexual orientation.
All of this data needs to be identified with a taxonomy that can be used to clearly and consistently label the categories the separate pieces of data fall into. For businesses that use SQL Server, Microsoft created a useful taxonomy for SQL Server Management Studio (SSMS) from 17.5 onwards. With a taxonomy like this in place, columns can be tagged to identify what category of data they contain, and therefore which columns need to be protected.
The point here isn’t just to catalog the current data your business is using. It’s to put in place a method that enables the cataloging of new data that is collected so it can be protected – and it can be searched for and found easily.
When different categories and pieces of data are simple to find, complying with those apparently onerous requests from consumers to provide data or delete it becomes business as usual.
That’s certainly what the Professional Association for SQL Server found when it went through its own data catalog exercise in its initiative to achieve compliance with the GDPR as well the CCPA. While the native feature in SSMS was a useful first step, a more robust data catalog solution was needed that would automate the cataloging of new data and integrate with reporting solutions like PowerBI and SSRS to demonstrate compliance.
You can find out more about their initiative in our case study, The crucial role a data catalog plays in Compliant Database DevOps at PASS.
Introduce policies to manage your data
Those that refer to how categories are applied to data and how businesses handle information and deletion requests are the ones where that first step of cataloging data really pays off. By identifying what data you have and where, and applying categories to columns, you’ll be in a position to:
- Disclose the information you hold about consumers on request, including the categories of data.
- Delete the records of consumers who make such a request, and be reassured that all of the personal information held about them has been removed.
- Automate the cataloging of new data that is gathered so that your data management policy is consistent, repeatable, and auditable.
Protect your data
Once you know where your data is and what kind of data it is, steps can also be put in place to protect it. The key here is to give access only to individuals who have permission to view, modify or delete personal data that is relevant to their job role.
The reason lies in section 1798.150 of the CCPA which says “Any consumer whose nonencrypted and nonredacted personal information … is subject to an unauthorized access and exfiltration, theft or disclosure as a result of the business’ violation of the duty to implement and maintain reasonable security procedures and practices … may institute a civil action.” [My italics]
This is supported by The Standardized Regulatory Impact Assessment of the CCPA issued by the California Attorney General’s Office (CAG), which states: “New data management systems that ensure privacy standards will need to be developed along with new techniques to extract useful information from data with obscured identifying personal information.”
I particularly like the bit where it also says that this could benefit businesses: “If the CCPA increases consumers’ trust of data protections it could actually increase the amount of data that consumers are willing to share with firms.” [Their italics.]
The key here is to mask your data using techniques that encrypt or pseudonymize it so that there are demonstratable security procedures and practices in place. The added bonus is that if there is an error and data is leaked or exposed, it won’t be in breach of the CCPA because it is masked.
Once again, PASS is a good example. As the flag-bearer for the SQL Server community, it knew it had to demonstrate exceptional business practice when it came to protecting the data of its membership base of Microsoft data platform professionals.
Like many businesses, however, it uses copies of the production database in development and testing, and the database contains the kind of personal information that needs to be protected under the GDPR and the CCPA.
As part of a wider initiative to introduce DevOps to its database development process, it resolved the issue by masking the data in copies of its production database and dramatically reducing the time it takes to provision those copies to developers. More details about how and why they did are in our case study, The benefits of adopting Compliant Database DevOps at PASS.
What are the take-aways?
Complying with the CCPA is going to be a chore for many businesses, but it’s a necessary one to avoid fines as well as the potential damage to their reputations.
Half the task, like updating privacy policies and maintaining a record of information requests for two years, is administrative and you may well need specialist advice to ensure your business is compliant.
The other half – the cataloging of data and the securing of data with measures like encryption – is one that will need to be managed by the IT team. Here, third party tools will be a big help, both in the initial implementation phase and the ongoing requirement to be compliant.
Want to know more?
- Part 1: The businesses the CCPA applies to and the penalties for non-compliance
- Part 2: The rights the CCPA grants to California consumers, and what constitutes ‘personal information’
- Part 3: The requirements the CCPA imposes on businesses
For future reference, we’ve also combined them in a comprehensive CCPA whitepaper that you can download and share with colleagues.
Also in Blog
In 2017 we launched our first report into the State of Database DevOps and have repeated it year-on-year. The responses from thousands of database professionals have given us unique insights into how ...
Also in Audit & Compliance
Many business solutions are migrating to the cloud due to the flexibility, scalability, and cost-saving features it offers. However, while moving to the cloud, data, systems and services can be ex...
Also about California Consumer Privacy Act
In this series of blog posts, we’re taking a long and detailed look at the CCPA to explain what it really means for businesses. Part 1 talked about which businesses need to comply with it and the fi...
Also about CCPA
With the CCPA now enacted, although enforcement doesn’t start until July 1, customers are waking up and starting to ask questions about it. In part 1 of this series, my colleague Ryan Easley wrote a...