Voice of the DBA

Tag: GDPR

  • What Data is Really Needed?

    The GDPR took effect in May of this year, at least with regards to enforcement. A few days after the May 25 date, a German court ruled against ICANN, the company that registers domain names on the Internet and manages the global WHOIS database. The case revolves around the information collected when you register a domain. ICANN wants multiple contacts, which they’ve required for decades. However, a company in Germany that is a partner, argued that the additional technical and administrative contacts were not required for fulfilling the business that both ICANN and EPAG (the German registrar) are engaged in. ICANN Is appealing the ruling, citing the need for clarification of what this means with regard to the law.

    This is interesting to me, because a) it concerns data, and b) there is an interesting argument here to be made about what data is needed for a business purpose. I could see this being argued successfully either way, and not just in court. As a domain holder, does the registrar really need multiple different sets of personal information from me? Arguably, this is a convenience for them, one that is based on tradition. However, one could argue the other way.

    It is a little scary that a court, with no expertise in some industry (Internet domain registration, in this case), will decide if there is an actual business need. After all, can a lawyer or judge really understand what data a business needs in their daily activities?

    Maybe, maybe not, but I do think this forces businesses to actually stop and think about what data they collect, have a justification, and document that. That’s a good thing, because often I find business people just asking to collect data without any idea what they’ll do with the information. I also find technical people collecting data, not maliciously, but often to anticipate what might be asked of a system, or because they want to avoid rework and just decide to collect everything they can.

    Data is precious, and while I don’t want to put many limits on what data businesses can collect, I also don’t want to them be able to collect anything, not disclose what they’ve collected, and not secure it properly. Having some limits, or at least forcing them to consider the risk of holding old, useless data, is likely a good thing for all of us.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Storage that Expires

    Whether you like the idea of the GDPR (and the new California law), I’m sure you agree that these laws will likely change our data handling in business. Even if they are weakened through legal challenges, many companies have already started to comply and change some of their practices.

    I’ve written about the GDPR plenty of times this year, and I like the law. I hope the law stands strong and resists most challenges. While I’m sure there will be plenty of spurious or silly requests and complaints, I do think these laws are asking for the good data handling practices that most data professionals have advocated for years. These include not only security but also integrity. How often have many of us advocated for corrections to problematic data and been told no? How many times have we complained about security practices?

    One area that I think has been neglected too long in most industries is the area of retention. Most companies I’ve worked for have retained data indefinitely, without any thought or policy. In my mind, we ought to explicitly think about how long we hold data, and remove older data that isn’t needed for our organization’s operation. I feel more strongly about this over time as we find that data beaches become more and more prevalent.

    Azure has started a preview of immutable storage, essentially WORM (Write Once, Read Many) drives as an Azure container. I’ve used WORM storage, but it’s often been viewed as a way of keeping information forever. that can change with this new Azure storage, as you can set a lifecycle management period. The blobs will be removed after this time, which removes one management headache from administrators.

    I could see quite a few uses for this type of storage. If it’s inexpensive enough, what about storing backups here? We could have policies set to remove files after some limited period. I’m sure there are plenty of other uses for storage the is immutable, but also contains lifecycle management options. What creative use would you have for this type of expiring WORM storage?

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • AI Regulators

    With the GDPR now being enforced in the European Union, there are plenty of companies that are getting concerned about the potential fines from regulatory authorities if they aren’t complying with the law, or at least, making an attempt. There certainly is leeway for regulators to adjust fines or give warnings if a company is making efforts to comply. This has likely contributed to the work inside many organizations to move towards compliance.

    There are likely some companies that might not worry, since there are relatively few regulatory employees and many companies. There are lots of complaints coming in, which could easily overwhelms the relatively small staff in each EU country. Complaints might not be investigated in a timely manner or even lost because of the workload. The problem will likely get worse as more consumers complain about data processing practices. I don’t expect regulatory authority staffing to increase, so I’m sure only the most aggregious or complained about companies will get caught.

    There is one way to help amplify the capabilities of the relatively small staffs reviewing complaints. There are researchers in the EU Institute in Florence that are are working with consumer organizations to create AI programs that can help by performing some of the work. The initial thrust is to evaluate privacy policies of companies. If there are issues, the software doesn’t assess a fine, but it does alert a human to perform additional checks.

    In one sense, this is exactly what computers can do well. They amplify the capabilities of humans by doing a piece of the work. We can build systems, whether traditional programmed ones or AI based applications, that handle a piece of the work that requires lots of human labor. Once initial evaluations are made, a human can review the work and make more refined judgments.

    The danger, to me, is that humans will be lazy. They’ll start to trust the AI systems as authorities and use less of their own judgment, mostly because it’s just easier. I could see these systems evolve over time to actually train humans involuntarily. New employees would initially trust the AI results, learning from the AI rather than teaching it and constantly evaluating its effectiveness.

    I think AI can really help improve the way that we accomplish work in many ways, but it should be regularly audited and approached with some skepticism. There certainly needs to be some sort of supervisory group overseeing the program that isn’t involved in the outcome. We should be sure that the goals and results from any AI system continue to be focused on what we want to achieve, and that we transparently define those goals for anyone impacted. Otherwise we might end up having AIs evolve in ways that are counter to the original purpose.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Are you GDPR Ready?

    The GDPR is being enforced as of yesterday. It’s been a law for two years, but fines are now going to be assessed for violations. If you’re like me, you’ve been getting a lot of different types of privacy policy updates, new opt-in requests in email, some notices in email with the burden on you to opt-out, and more. A few people joked about how many they’ve been getting, and certainly I’ve seen no shortage of updates. I’ve even seem some updates to services that don’t allow access to content, such as YouTube, without clicking some accept button.

    It’s interesting to see the various approaches being taken. Last week in London, Redgate held a SQL Privacy Summit and I was honored to host a panel discussion from various industry experts. They had different takes on the GDPR, though most of these people were pro-GDPR, happy that some proper data handling was being enforced. That’s the attitude that many DBAs in know in the EU, as they now have some legal reasoning why we should implement better data handling and security practices.

    However, I’ve also seen that there are different interpretations of how to deal with data. Do you need to ask all customers to opt-in? Can you continue to use data in development and test environments? Can you process data as you already have if you disclose what you’re doing? Is the burden on the company or the data subject? I’m sure we’ll see various decisions and rulings from regulatory authorities across the next year as data subjects complain and companies try to do the minimum level of work.

    The idea of data being somewhat co-owned by a business and an individual is fascinating  I see both sides, and I certainly would like to have some rights over data about me. I definitely think my address, my date of birth, and more should be secured and companies that use my data should have some liability if it’s disclosed. I’m not sure about rights over how it’s used, but that’s certainly a discussion that’s coming.

    I’ve already seen one organization file suit over access to data, because they’re being forced to consent to handling that they disagree with. That is going to be something I watch carefully. Can a company change their terms arbitrarily, ask me to consent in a take-it-or-leave-it fashion, and withhold access to data? Do I own my messages and data stored in services? Is it co-owned?

    Like it or not, the GDPR is forcing us to have some discussions and debates about digital information, which is good.

    We’re mostly ready at Redgate, and certainly continuing to do work. Ultimately, our reading of the GDPR (with some backing from auditors), is that we don’t have to be perfect today, but we need to be making an effort and be able to prove that we are doing so. So on a day after the GDPR went into enforcement, what are you doing? Do you think you’re ready?

    Steve Jones