As U.S. organizations become more cognizant about the need to protect the data they collect, they learn how poor the guidelines, laws, and compliance methods are. The U.S. laws are more sectoral. If you really want to adopt a holistic data privacy standard that protects your users — and your organization — look more to the European Union for useful guidance.
Enterprise organizations today are very aware of the importance of IT security. Plenty of data breaches, security vulnerabilities, hacking attempts to compromise systems, and software development defects have driven home that message. As a result, most IT organizations have put practices into place to protect the organization from “bad guys” who are trying to break in.
However, only recently have most large corporations (and small ones, too) put attention on data privacy: the responsibility for the organization to control access to personally identifiable information (PII) that is collected during the process of doing business.
Healthcare organizations are perhaps most conscious of the data privacy issue as part of their need to protect users’ information for confidentiality, integrity, and availability. Even without the influence of corporate or personal ethics, HIPAA legislation has driven healthcare IT to comply with now-well-established practices. Financial services organizations have similar motivations.
However, other industries (particularly in the U.S.) are just catching up with designing systems for data privacy. Many of their IT personnel are getting confused, and for good reason. Overall this is a complicated but important mess. The existing data privacy rules are inadequate, overwhelming, open to interpretation, and contradictory.
For instance, the U.S. supported Safe Harbor law, aimed at “prohibit[ing] the transfer of personal data to non-European Union countries that do not meet the European Union (EU) ‘adequacy’ standard for privacy protection,” which directs US companies to deal with EU data separately. However, the Safe Harbor program conflicts with the U.S. Patriot act.
Moreover, the distinction between security and privacy sometimes is unclear. Security is about access, which — when it fails — permits a loss of information. Privacy is about data exposure at the boundaries: how much you share, knowingly and unknowingly, and who can get their hands on that data.
To understand the difference, it might help to think of a family that owns several cars. Instead of the parents and teenagers each having a key to each car in the driveway, the family might employ a key rack in the entry hallway. Anyone who can get inside the home perimeter — the front door — can access the car keys, which are meant for the family members to use. Security prevents people from getting into the house, but the parents need to think about what information is stored and exposed once someone walks inside.
So organizations need to consider questions including:
…and that is just to start with.
Instead of looking at the U.S. rules and policies to guide you in designing data privacy practices, I urge you to rely on the policies developed by the European Union (EU). Frankly, the U.S. has pretty low standards of privacy — and not just at a consumer level, such as Facebook. Microsoft’s new Outlook apps were blocked by the EU over privacy concerns, as just one recent business example.
One key advantage of the EU guidelines is its notion of separation between data processor and data controller. That is, it puts attention on:
That’s an important distinction which affects accountability, security, and more.
For instance, consider the role of an email admin: In some cases the admin might have to look at a user’s email; and in other cases she absolutely should not do so. Who decides whether and when that admin should look at the email logs? Surely it should not be the admin herself. With the EU notion of data privacy, there are separate rules and task forces. Control and process are very different. The person who designs cannot create the rules.
At Druva, we treat the European directive as a gold standard, and we build our software to comply with those goals. (So is Microsoft, incidentally: See Microsoft Adopts Cloud Privacy Standard.)
We already do several things that way and are committed to do more. This isn’t the easiest way to conduct business, but it’s the right way.
For example, the EU directives influenced the way we build encryption, based on shared responsibility. Most companies either build encryption with the key in the cloud (so more people have access) or at end user (so the key is completely exposed). Either way, admins have more access than they should.
We follow the EU provider/admin model in several ways. We build detailed audit trails for just about everything, such as when a file is backed up. The scope for accessing those logs is limited by two things: detailed admin rights and departmental policies. The high level admin doesn’t have a lot of access, and the low level admin doesn’t have a lot of control.
We also follow security policies that primary address threat protection, though they have an effect on privacy. Among them are geo-fencing and IP-based access control. Such features ensure that, say, German data cannot be accessed in Taiwan.
Data privacy is important because breaching data is expensive. Where every action triggers a chain reaction of tons of data, there’s a corporate responsibility to make sure it’s protected. At Druva, we’re doing our best to make that job easier for our customers by building software that complies with the best-quality data privacy initiatives.
Concerned about data privacy in your organization? Read our white paper, Preparing for The New World of Data Privacy: What Global Enterprises Need to Know.