Is CCPA like GDPR?
When it comes to protecting personally identifiable information (PII), it might be tempting to think that if you’re compliant with GDPR, you’re pretty well covered. After all, GDPR was the biggest and most comprehensive set of data privacy rules to ever hit. But, you’d be wrong, especially since the California Consumer Privacy Act (CCPA) takes effect on January 1, 2020 and enforcement begins in July.
The CCPA is going to affect most large enterprises (annual gross revenue over $25 million) that do business in California or have customers in the state. It’s also likely that the CCPA will serve as a template for other states as they craft their data privacy laws.
CCPA data privacy regulations target the exposure of individual’s data, but what about all the other data that’s considered sensitive or proprietary to the business? It would be just as, if not more disastrous if trade secrets, financial figures or strategic plans were exfiltrated.
DBAs are at the front line when it comes to protecting the data that matters most to the organization—from intentional external threats and accidental or malicious internal threats alike. The corporate databases are going to carry the biggest risk of exposure of any kind of sensitive data.
Questions you might ask about protecting your data
So, is your IT department doing all it can to protect business data? Do you have a data risk management methodology in your organization? Who is ultimately responsible for managing this risk? As a DBA, how are you minimizing the risk associated with data breaches? How do you identify your organization’s sensitive data?
Identification is really the crux of the issue, since you can’t protect the data if you don’t know where it resides across your database environment. How do you determine which tables contain sensitive data? Are you relying on metadata, or can you actually mine the data itself for greater accuracy?
Once you've identified it, how will you protect it? It depends—if it's production data, you might use encryption or redaction. If it's not production data, you might mask it. What about auditing? Do you audit everything? How do you know what to audit? How do you find the right balance between security and performance when auditing?
Manually finding all the data that needs protection is time-consuming and risky. Don’t forget you may also have backups and cloud databases that contain sensitive or personal data. A better way to locate sensitive data is to automate its identification with a rules-based approach that samples the actual data, and doesn’t just rely on the metadata.
Use a trusted, familiar tool to protect your data
Last spring Toad® for Oracle announced a new feature, Sensitive Data Protection. This feature allows DBAs to use a familiar tool—Toad—to identify the critical data across your organization that you need to protect. It also lets developers know whether they're potentially exposing sensitive data via code, thereby enabling them to adopt privacy by design practices.
Watch this recent video to learn more about how the awareness and search capabilities of Toad for Oracle – Sensitive Data Protection can help your organization, where John Pocknell explains it all. You’ll see how you can identify and protect corporate data from within the familiar Toad interface.
Ready to try Toad for Oracle – Sensitive Data Protection? Get a free trial.
More useful resources
Product page: Visit our product page on Quest.com to learn how you can find and control sensitive data across all your Oracle databases.
Price Waterhouse Coopers: Your readiness roadmap for the California Consumer Privacy Act (CCPA)
Related Toad World® blog posts
Start a discussion about how GDPR and CCPA are impacting your workload
Visit Toad World often for free advice via our blogs, free interactive forums and free downloads. How is GDPR impacting your workload? Start a discussion about sensitive data protection.
Share on social media
If you think your colleagues would benefit from this blog, share it now on social media with the buttons located at the bottom of this blog post. Thanks!