In case you thought software license compliance wasn’t complex, confusing, or expensive enough already–say hello to GDPR, Europe’s well-intentioned approach to maximizing complexity, confusion, and cost in the name of personal data privacy and security.
What is GDPR?
GDPR stands for “General Data Protection Regulation.” It’s a new EU law with implications that reach far beyond the borders of the old world. The main purpose is to give Europeans more control over how their personal information is used by anyone who might come into possession of it. The most obvious category is an employer or university – but it also includes software companies, websites, and other online services. Its scope is not limited to information collected for administration, marketing or data mining – and with the amount of data out in the world today you can imagine how broadly scoped this law is. And because it applies to anyone, anywhere in the world, who transmits, stores, or otherwise processes the personal data of people located in the European Union, it even impacts organizations that do not typically fall under the jurisdiction of the EU government; whether they realize it or not.
What does it mean to “process personal data?”
The law defines personal data as “any information relating to an identified or identifiable natural person… such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.” Not only does the law require anyone storing, transmitting or processing such data to get consent, but it also requires that said processing be “necessary” for a “legitimate” purpose. It’s not until you see that “processing” is defined as “any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction,” that you can finally appreciate just how all-encompassing the law really is.
It seems absurd, but based on the letter of the law, a photographer would not only need to get your consent to erase a picture he accidentally took of you walking down the street in Paris (if said picture could potentially be used to identify you by, say, Facebook’s facial recognition), but even the act of erasing would still require a necessary and legitimate purpose! And let’s not even mention enforcement (the fines are huge).
Luckily, I don’t think the EU intends to fine us all millions of dollars for taking random pictures of the Eiffel Tower (though apparently they could). And fortunately, there seem to be two roads to the other side of GDPR: navigate through the cumbersome, complex, and confusing details, or simply go around them. In other words: set up processes and procedures that will allow you to get consent, prove necessity, and securely process personal data (the expensive route), or make sure that any data you collect cannot be used to identify its subject (i.e., anonymize it).
K2 and GDPR
From one perspective, GDPR runs contrary to the very core of Software Asset Management – which inherently involves gathering and analyzing user data; but that doesn’t mean that Sassafras is unprepared. There are two areas in particular that we wanted to talk about it in this article: data that gets sent back to Sassafras, and data collected and stored on your local KeyServer.
Data Transmission to Sassafras
As far as data transmittal between a remote KeyServer and Sassafras is concerned, our client software, KeyAccess, does not upload any data or communicate version status information to us. All communication from the KeyAccess client goes directly to your onsite KeyServer process.
With the Product Recognition Service enabled in your KeyServer, only product data is aggregated, summarized, anonymized, and then submitted to the Sassafras PRS service for normalization into a product record (which is then returned to your KeyServer); but this transaction does not include any data about individual computers or users. In other words: Sassafras does not and never has collected any personal data from the computers or users on your network.
Local KeyServer Data Collection
With regard to data collected, stored, and transmitted on your local network between KeyAccess, KeyServer, and KeyReporter, we are happy to report that, because K2 was engineered to maintain compliance with German privacy laws—which are what much of GDPR was based on—your KeyServer can easily be configured in a way that maintains strict compliance with GDPR requirements. Settings that allow you to anonymize the computer and user names of end users make the users unidentifiable, therefore avoiding many of the law’s stringent and complex requirements.
Without turning these settings on, it will still be possible to use KeyServer in compliance with GDPR, but remember that certain requirements, discussed above, regarding consent and notification about data being collected, how and why it is used and stored, etc., will, at the moment, have to be managed outside of KeyServer. We are considering ways that we might be able to incorporate these aspects of compliance into KeyServer in the future, but these decisions will be made based on user requests and feedback.
Conclusion
The practice of Software Asset Management is deeply affected by GDPR, as a lot of user data goes into computing license usage and consumption. However, because we suspect that the Software Asset Management industry as a whole will move toward anonymization of personal data, which is not critical to effective asset management, rather than dealing with the overhead of consent, data management, breach notification, not to mention the significant legal and financial risk associated with storing and transmitting unnecessary private data.
Subscribe
