Six Contexts that Frame Data Protection Policy Governance
Data protection policies are complex and often confusing. Knowing these six contexts that frame data protection can help you clarify your policies.
- By David Loshin
- August 18, 2021
Individuals are increasingly concerned about data privacy, and businesses are starting to listen. In addition to acknowledging the reputational and compliance risks associated with inadvertent exposure or data breaches of individuals’ personal and private information, businesses are realizing customers’ emerging ire over the use and sale of their personal data. With additional concerns about the increasing number and volume of data breaches, it is not surprising that governmental intervention is increasing, with a growing inventory of global laws and corresponding regulations intended to address the need to secure and protect individuals’ personal and private data.
Of course, this plethora of mandated data privacy policies creates a potentially intractable challenge when an organization initiates its data governance program, centering on the distinction and delineation of private and personal data that require protection and the methods for enforcing data security. Once you start thinking about the need for protecting “private” data, it is an easy extrapolation to include any type of data that might be deemed “sensitive,” -- requiring the assertion of some controls guarding against unauthorized access to data requiring controlled access.
Three distinct challenges confound data practitioners:
- The complexity of interpreting the directives included within any specific external mandate (such as a privacy law or an industry standard) into specifications of data sensitivity requires knowledge of both the business domain and information management
- The need for managing the methods by which many variant external policies are defined and differentiated according to a collection of specifications and their associated contexts
- The practical aspects of establishing an operational framework for complying with mandated data protections within those contexts
These challenges are best illustrated with an example. The California Consumer Protection Act (CCPA) provides a broad and inclusive specification of “personal information” (see section (o)(1)):
“Personal information” means information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household. Personal information includes, but is not limited to, the following if it identifies, relates to, describes, is reasonably capable of being associated with, or could be reasonably linked, directly or indirectly, with a particular consumer or household … .”
This is then followed by a list of classes of data (including but certainly not limited to name, address, driver’s license number, biometrics information, personal property records.
Alternatively, if we look at the more recently passed Virginia Consumer Data Protection Act, we have a much simpler definition of “personal data”:
“Personal data” means any information that is linked or reasonably linkable to an identified or identifiable natural person. "Personal data" does not include de-identified data or publicly available information.
The differences between these two definitions inject ambiguity into the concept of enabling general protection of sensitive information. In the CCPA case we have a verbose high-level definition along with detailed specifications that can be organized into a semantic taxonomy. In the Virginia case, though, the more succinct definition actually casts a wider net because it says that “any” information linked or linkable to an identifiable person qualifies as “personal data” with the implication that such data are subject to compliance with the rights and obligations defined in the law.
What is becoming apparent is that multiple contexts influence the ways an organization protects its sensitive data. These contexts require greater corporate depth in data policy governance than is traditionally deployed using typical techniques such as role-based access control.
You might think that an obvious solution would be to try to find the “common denominator” by classifying any data item as sensitive if that data qualifies under any directive’s definition as requiring protection. From an information management perspective, this might be the simplest approach, but from the data professionals’ perspective, this could be dreadful. Preventing data professionals from being able to access the data they need to perform their reports and analyses paralyzes the analytics process. Therefore, considering the contexts that frame data policies (and their governance) will help to reduce the constraints and enable data democratization under the appropriate circumstances.
Common themes pervade the different specifications that imply some fundamental standards associated with the data values themselves. In the U.S., a good example is the Social Security number because its use is overloaded among a variety of business and financial applications that render its exposure a clear risk to identity theft. These are examples of what could be called the data context -- sensitivity is presumed as a function of the data element’s concept and presumed use and exploitation.
That being said, you might already see the first potential problem: data classified as “personal” within one law or regulation is not classified as such in another. There is additional ambiguity in the use of different terms (“personal” versus “private” versus “sensitive,” etc.) in the different scenarios, which confounds understanding the scope of data protection. We can refer to this as the source context imposing constraints on what data concepts are subject to sensitivity classification based on the directive which defines the sensitivity categorization.
Compliance is further complicated by the exemptions from protection that are necessary for an organization’s business processes to proceed. For example, an individual consumer’s address might qualify as sensitive data to be protected. However, if a company needs that address to deliver an ordered product to the consumer, someone needs to access that location data to produce a label for shipping the product. In other words, we can incorporate the operations context to additionally frame the ways that data protection policies are specified.
Data protections may also be mandated to apply to individual data subjects based on where they physically reside. For example, the Virginia law defines a "Consumer" as “a natural person who is a resident of the Commonwealth ... .” This stipulates that the individuals covered under the directive is limited to residents of the Commonwealth of Virginia. Similarly, the California law is limited to California residents; the European General Regulation on Data Privacy (GDPR) is focused on residents of the EU. This means that the definition of data privacy protection policies may also be dependent on a geographic context.
Additionally, there may be situations in which there are time-related limitations to enforcement of data protection. A good example is the 1998 U.S. Children’s Online Privacy Protection Act (COPPA), which asserts policies regarding collecting information from individuals under the age of 13. That implies that as soon as the individual’s age is greater than 13, the requirements for data protection change. Other scenarios might indicate a specific duration for data protection, such as an embargo of corporate data until a press release has been distributed to the media. This is what we might refer to as a temporal context for data protection.
In the spirit of data democratization, policies governing the protection of sensitive information should be appropriately scoped so that anyone whose position does not restrict them from viewing specific data sets should be allowed to access the data. This is another way of saying the goal of a data privacy protection program is to enable data accessibility, not limit it. This suggests one more context: the role context of the data professional, in which the individual (or system) is classified according to the role’s expected privileges.
- The data context of commonly acknowledged sensitive information concepts
- The source context associated with the sources of the protection directives
- The operations context that distinguishes situations for allowed use of sensitive data
- The geographic context associated with the physical location of the data subject and the data processor
- The temporal context that sets the timeframe for protection
- The role context associated with the communities of data consumers