When deploying any application that holds customer or user data, both data compliance and data privacy are important areas to consider. Yet these two areas of data management are sometimes misunderstood. This article will shed some light on the differences between data compliance and data privacy.
What Is Data Compliance?
Data compliance refers to the requirement to meet certain legal obligations around the collecting, processing, and storing of data.
Companies with customers in Europe, for example, must comply with the General Data Protection Regulation (GDPR). This is a legal framework that gives consumers the right to see what data a company holds about them, to object to the company’s processing of that data, and to require the company to erase it. Similarly, companies with customers in California must comply with California Consumer Privacy Act (CCPA).
In addition to GDPR/CCPA, examples of other compliance frameworks include the Health Insurance Portability and Accountability Act (HIPAA), the SOC 2 auditing framework and the ISO/IEC 27001 standard. This may include a set of policies, procedures, and auditing established by the company to ensure data compliance.
Data privacy relates to keeping sensitive data private and confidential. Where data compliance is the legal aspect of data management, keeping data private is a practical/technical concern. A privacy program’s goal is to advocate for privacy of data and ensuring only authorized users can view data on a need to know basis. It includes elements beyond what a typical compliance program has.
Data privacy typically applies to any personally identifiable information (PII), which is any data that can be used to identify someone. Social security numbers, email addresses, IP addresses and so on can be considered PII. Companies striving for data privacy need to put measures in place to protect the confidentiality of this data, even if not required for compliance, thus advocating for the privacy of individuals to whom the data relates. Data privacy ensures mechanisms are put in place to ensure only authorized people have access to data.
One misconception around data compliance and data privacy is that a company can’t store its data with any third-party tools and thus must resort to “in-house” solutions. This isn’t the case. A third-party tool may have robust access-control and security in place which has been rigorously audited under third-party frameworks like SOC 2 and ISO/IEC 27001 — whereas an “in-house” datastore may allow access to many employees through a common root password without any robust audit logging could be far from compliant.
Instead, engineers must evaluate tooling (whether internal or external) to ensure the correct mechanisms are in place to meet security and data compliance standards. Probability of data breach can go up if a company does not apply the same rigor of security to internal tooling as it does external tools.
GDPR, SOC 2, and other frameworks are legal and operational frameworks. While they heavily impact engineering, these frameworks affect the entire operations of a company from legal, sales, and support. If a company needs to work with another business, it is legal paperwork that will pave the way for them to do so. Setting up a “secure” environment in AWS does not mean you are compliant with SOC 2. Storing your data in an “in-house” database does not mean you are compliant with GDPR as there are operational procedures required for teams like support and sales.
To comply with GDPR, two companies may sign a legal document typically called a “Data Processing Addendum,” which defines how data is processed and protected between the different parties. It will define who is the data controller, who is the data processor, how the data is processed, SLAs and procedures during a breach, and so on. The agreement should cover all data that could be classed as PII and ensure that it follows the requirements of the relevant compliance legislation.
Sticking with GDPR as our example, that means there needs to be a process in place for meeting the requirements around individuals accessing, objecting to, and demanding the deletion of their data (regardless of where it’s stored).
Just because you comply with GDPR or SOC 2 doesn’t necessarily mean data is private, regardless if the data is stored in a third-party tool or in your in-house solution. Data privacy is the art of going “above and beyond” compliance frameworks to do everything you can to ensure privacy of customer data.
There are a couple of different approaches to ensure data privacy. For example, the Moesif platform has a feature called privacy rule which enables you to restrict access to certain fields on a need to know basis using Role-Based Access Control (RBAC). For example, you can create a privacy rule ensuring a technical support staff cannot view or inspect sensitive HTTP headers or PHI (Protected Health Information) — whereas an analyst may need additional access fields for reporting purposes.
A second way you can keep data private is through client-side encryption, which is a recent trend to reduce the risk of data breach and improve data privacy posture. Client-side encryption enables you to encrypt data using a set of rotated encryption keys that very few of your employees have access to. Engineers who maintain the underlying data infrastructure and processing pipeline, but do not have a business need to see the actual data would not be able to as long as they don’t have access to encryption keys.
Data compliance and data privacy are important and serious topics that impact anyone at an organization touching sensitive or customer data. Legal, operations, and engineering should work together to ensure compliance. In addition, companies should strive for further data privacy beyond what is required by compliance frameworks. This can be done for data ethics or to reduce exposure in event of a data breach. Understanding the difference between the two is the first step in feeling less stressed by the whole subject — which hopefully this article has helped you do!