Data privacy is among the most regulated areas of technology. Unfortunately, the concept is as vague as it is vital when it comes to exactly how to implement data privacy controls for the enterprise. Data privacy regulations remain notoriously difficult to put into practice compared to data security, which is supported by a growing constellation of standards and frameworks and other security best practices.
Download this free ebook and rethink your data management practices with the help of:
- Setting standards, establishing goals, and reducing risk
- Guidelines for approaching obfuscating and deleting data elements and subjects
- Considerations for third-party data access and a road map for accountability
Privacy Regulation Assumes Technology It Does Not Name
Security regulation is full of references to technical controls. Privacy regulation is written as though compliance can be achieved with policies, contracts and training. The CCPA and GDPR were both drafted to enforce enterprise compliance, and neither addresses the role automation has to play in delivering it.
That gap is the technologist’s problem to solve, and it starts with the data management practices underneath the policy.
Why Limited DSAR Responses Are Unsustainable
Most companies answer a data subject access request by searching a handful of known repositories. Regulation allows some flexibility about effort, and current practice stretches it.
Three things are closing that gap. Breach notifications reveal to individuals what a company actually held, which can expose an earlier response as incomplete. Breaches also trigger regulator audits that examine DSAR handling directly. And data subjects are better informed than they were, and increasingly willing to challenge a response that looks conveniently thin.
Matching Identities Across Tables
A database identifies a person by a key, and other tables refer to that person through it. In theory one customer identifier links contact details, transactions and survey responses cleanly.
In practice databases hold thousands of tables built by different people at different times, each concerned with connecting only the tables they needed. Primary and foreign keys were never mapped to one another, so the same person exists under several identifiers with nothing tying them together. A subject access request then has no single thread to follow.
Naming Data Elements So They Can Be Understood
Machine learning can work out that a column of eight digits holds a date. Nothing can work out whether that date is an account creation, a last transaction or a last contact, without a header that says so.
Column names were historically written for the handful of administrators expected to read them. Privacy regulation changes who has to understand a schema, which makes clear naming a compliance requirement rather than a courtesy.
Orphaned Identities
Every organization holds records about people it cannot connect to any processing activity or privacy commitment. Documents added by employees using company systems for personal purposes, information received in error, and data inherited through systems nobody now owns.
Orphaned identities are a genuine exposure, because they are personal data the organization is accountable for and cannot describe. Finding them is a discovery problem; deciding what to do with them is a retention decision that has usually never been made.
Obfuscation and Deletion Are Not Interchangeable
Masking and redaction reduce what a record reveals while keeping it usable. Deletion removes it and removes the obligation with it. Which is right depends on whether the organization still has a lawful reason to hold the data, and the answer is often no.
The same applies to third parties. Data shared with a processor remains the controller’s responsibility, so the account of what exists has to extend to what was sent out, to whom, and under what terms.