 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor of DataVersity. We would like to thank you for joining this month's installment of the Monthly DataVersity Webinar Series, the Chief Data Officers Agenda. This month, John Lathley and Tony Shaw are joined by Bill Tannenbaum who will discuss how CDOs should work with lawyers. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A in the bottom right hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights of questions via Twitter using hashtag CDODataStrategy. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and any additional information requested throughout the webinar. Then let me introduce to you our moderators for today, well-known industry analyst John Lathley is a business technology thought leader and recognized authority in all aspects of enterprise information management, with 30 years experience in planning, project management, improving IT organizations, and successful implementation of information systems. As president of IMQ Solutions, he leads a consultancy focused on improving a client's business results through information management and data governance. With John is Dataverse City's own CEO, Tony Shaw. Tony is of course responsible for the business strategy of the company and its subsidiaries including Dataverse City, all of which conduct educational conferences, training, and publishing activities focused on the area of enterprise data management. And with that, I will turn it over to Tony to get us started and introduce this month's guest speaker. Hello and welcome. Thank you very much, Shannon. Hello to John, my colleague, and welcome to everybody who's listening in today. The genesis of this particular presentation is actually a talk Bill Tenenbaum gave during the CEO vision conference in Washington, D.C., at the end of March. And we invited Bill to talk a little bit about governance and security and some of the legal issues involved there. And I think we're all, maybe with the exception of Bill, a little surprised at the level of discussion that was provoked amongst the audience of senior data management people. Certainly the presentation opened the eyes of many of the folks in the audience as to the range of issues that are impacting data management today, the range of legal issues that are impacting data management today. But also the number of ways in which having some greater awareness of those issues and the context of data in the legal environment today can enable chief data offices and strategists and designers even to add value to a number of important business functions and practices in contemporary commercial environments. So because of that, we invited Bill back to provide an extension of some of those topics during his presentations today. Bill will talk for about 40 minutes and then we'll have plenty of time for questions afterwards. Just as a procedural note, if you could make your questions out in the Q&A section in the bottom right-hand corner of the screen, that would be terrific. And offer those at any point during the presentation. We'll save most of them to the end, but I think Bill's willing for us to interrupt him, too, as we go along. So let me introduce Bill at this point. Bill Tannenbaum is the head of K-Scholars Intellectual Property and Technology Transactions Group. K-Scholars, sorry. So Bill has something of a technical background. In addition to his legal training, and he was, in fact, named Lawyer of the Year in Information Technology Year by the best lawyers publication in 2013. He's a past president of the International Technology Law Association. Practice focuses primarily on IP and technology, including transactions and litigation, strategic counseling, and one of the things that is particularly relevant to our presentation today is his expertise in the use and commercialization of data as an asset. Bill is vice president of the Society for Information Management, and because of his technical background, he also works very closely with CIOs, Chief Technology Officers, Chief Information Security Officers, and Chief Data Officers. So Bill, thank you very much for joining us today. Looking forward to your presentation, and I will turn it over to you. Well, thank you very much, Tony. It's certainly my pleasure to be here, and I do want to affirm that I'm glad to take questions as we move through the presentation. My topic is on kind of the hidden legal issues that CDOs need to deal with, and where and how CDOs should play a role in what would otherwise be an IT contract that their company is entering into. Since I am a lawyer, I do need to start with a disclaimer. So here goes my disclaimer, which is what I have to say today. It does not constitute the opinions of my firm, Kay Scholar. It does not constitute the opinions of any of Kay Scholar's clients, and it does not constitute my own opinions. I'd like to start with setting the stage by defining some of the types of data that CDOs have to deal with in order so I can follow the kind of paradigm I want to use, which is the business driver should be driving the legal issues. And with respect to IP, and particularly IP, you should know that once you decide on your business objective, IP is flexible enough so that you can use intellectual property licenses to end up where your business wants to go. So that's another way of saying that IP is not a tail that wags the dog, but it's a tool to accomplish your business objectives. For our purposes today, I'm going to discuss enterprise data in the context of data that is used within a company, primarily for its own internal operations. At the speech Tony mentioned, another speaker said that she worked for a company that consisted primarily of financial advisors. So kind of a core question for that company is how many financial advisors do we have? And the problem that was identified was that businesses throughout the organization took different metrics on deciding who was counted as a financial advisor. Some financial advisors were deemed not to count because they didn't have enough assets under control or enough of their own clients. And the point was the organization didn't really know because different parts of the organization used different metrics. So that's an example of problems in enterprise data. And it's also a problem when you look outward at your customers because there's a question of R-U-U. Some companies are starting to combine their brick-and-mortar customers with their online customers for fairly obvious reasons that people shop through both channels. But if the company is set up with very siloed data, then it's missing an opportunity to combine that data and use it to develop better products, which is a subject I'll get to later. And the data question becomes, how are you identifying a customer? And if you're identifying them using different measurement criteria, whether they're in the store or online, then you're not going to have an accurate sense of how many you have and probably more difficult to figure out who shops through both channels. So that's the enterprise data that I want to focus on that obviously leads to a lot of data from a lot of sources, and big data is kind of the overarching terminology for this. It traditionally is defined in terms of the 3Vs, which are volume, velocity, and variety. Well, I apologize for interrupting. I'm not seeing the slides move. Are you changing the slides? Yeah, I'm not ready for the second one, but I will get there shortly. Okay, it's okay there. And so I'll just continue on so that the fourth aspect of this is intensity, and that's the really new thing that can be measured by monitoring social media. You can decide whether customers are very, very interested in something or whether your employees have problems with your travel policy or the like. The data also comes not only from your own sources, but from sources where you buy it from, from the Internet of Things, from what's volunteered by your customers. There is also data that needs to be used, and this is a legal point when there's an investigation being conducted of your company by a regulatory agency or an attorney general. So you need to have that data, and people will look to the CTO to get that data organized. And the last part of the data is the data that's not used as enterprise data for internal purposes, but data that you want to consider an asset and monetize. And the last comment I'll make before I advance the next slide is the role between the CTO and the CIO. And for most purposes, there is a division and there is a difference. The IT infrastructure is generally not the responsibility of the chief data officer. So another way to look at this is there's content and there's infrastructure, and the CIO is responsible for the pipes and the CTO. It's responsible for interpreting the water that flows out of the pipes. And of course, it's not a strict division because in order to do what you need to do from a data point of view, you do need to have the support of your IT infrastructure. One of the big problems the companies face, of course, is database breaches, which exposes them not only to legal liability, but to reputational harm. And this is something that CDOs need to be aware of because it's both a potential problem for them and an area that they're potentially responsible for. So as the slide indicates, the study indicated that about two-thirds of significant database breaches were actually caused by third parties, IT providers, and either mistakes that they made, innocent or otherwise, or limitations to the technology that they use. So one of the thrusts of my discussion will be, you know, taking care that outsourcing or hiring a technology provider is not going to be the avenue that leads to your data leaking out and liability for a database breach. So where does the CDO fit in the context of the risk of third parties causing your breach? There's usually a problem that the... especially in the outsourcing or technology services operations of a company, that the CDO is not involved in the process. Many of these processes start with a request for a proposal that goes out to the vendors. In many cases, especially where procurement is heavily involved as opposed to strategic outsourcing management, the RFP scoring will focus on the lowest price, which tends to make it expensive for a provider to provide good data security, which means there's more incentive to aim at the low price than there is to bake in security into the product. Even if security is given attention in choosing the vendors, the RFP needs to focus on data security as one of the measures that's scored. And without the involvement of the CDO, there's probably going to be a lack of sensitivity to making this an important qualification for selecting the vendor. Assuming that the contract has now gone forward, one of the recommendations that I make is that in addition to the account manager and the equivalent responsible party on the customer side, since we're dealing with data, we need to have data managers on both sides of the fence who have the relevant skills and expertise, particularly on how data works and the IT that supports it, and some knowledge of the legal risks that are going to arise out of this. In most outsourcing agreements, there is a difference between the deal team and the operations team. And the deal team is the set of people who negotiate the contracts. And after the contracts are negotiated, these professional negotiators and outside lawyers go away, and the internal operations team takes over running the process. Because there's a difference, I recommend that the customer allow the potential outside vendor providing data services to have access to the operations team. The legal advantage of this to the CDO is that the vendor will have a good insight into both the strengths and the weaknesses of a company's operations. And that will lead to perhaps sharing information to fine-tune the services. If the operations teams are good, there will be a better price because the vendor doesn't have to build in a buffer for unknown contingencies. Moving on to the multi-vendor part of the next bullet point, I think CDOs need to be aware that it's smart to use a vendor management organization where different vendors are put in different categories and different categories are handed differently. So at the top of this pyramid would be the strategic providers or vendors. And below that would be vendors who are important, but not part of the strategic operations. Below that would be the infrastructure providers. And then below that would be the kind of commodity providers. And I'll say that cloud services that can fit in all of these categories, so you need to be aware of how new technology does this. And from a data point of view, if you go to an outside provider using cloud, you often get the data science built into that operation. So that's something to keep in mind. But as you go through vendor management and try and allocate the time and negotiation effort that you spend on these contracts, it's important to follow the hierarchy that I outlined and make sure that on your strategic vendors you're getting the kind of cooperation you need for data. And one of the big issues, of course, is that in any of these operations, and particularly with the speed with which big data and concomitant data analytics are progressing, what you do next year will be something you didn't know that you could do. So you need a strategic partner that's a little bit extra-legal and that you are going to find a way to trust and to work together to make the adjustments to improve the services based on, as I said, something that isn't known at the time you enter into the agreement. So the final point on this slide is when you have a database breach resulting from an outside provider, often it's because the insights of the CTO were not built into the process or the company didn't pay enough attention to what those insights were. So both those problems need to be addressed. On the next slide, I'm going to focus on where the CTO fits in making sure that the contracts are doing the job they need to do. So let's start with the contracts that the company already has. There's two aspects to this. One is data security and one is data mining and enterprise use. The problem will be, in many cases, that the older contracts from a security point of view use older technology in the face of newer threats, which means that the technology can't handle the threats, and since the technology can't handle the threats, then the obligations of the vendors to address those threats is going to be limited by the technology that they're entitled to use, but not better technology. From a data mining point of view, it's a similar problem, but it's more a business limitation than legal liability. But the business problem is that the technology is not set up to enable the kind of analytics that today's technology would provide. So going back to the 63% of the problems being caused by IT limitations in the vendor side, you need to do essentially a gap analysis of what your company needs, both from a security and analytics point of view, and then as the next point says, you can remediate this through renegotiation. In some cases, it's fairly easy because the agreements have shorter terms than they used to, and they're coming up for renewal. In today's economic environment, you can go and say they need to be reopened, and that usually results in getting greater protections for something, eliminating some things from the scope that you've decided you don't need anymore, and making a price adjustment that accounts for what's in and what's out. So an example of something that might change is just to pick an easy IT example. If you outsourced a help desk and spent a lot of money on it and now replaced it by what amounts to a voicemail system, well, you can reduce the scope of help desk operations in the course of renegotiating the agreement. Vendors are more concerned with margins than revenue, so you need to be focused on that and not get waylaid by that. The new contracts provide an opportunity to kind of use the same lessons that you would use in existing contract analyses. So you would do the same kind of gap analysis between what you want to have happen and making sure it's in the new contract. And this goes back to the point on the last slide that this is the great opportunity for the CDOs to be involved in a meaningful way and make a contribution to the whole process, starting with the RFP and other issues that I addressed in talking about the last slide. Let me move on now to the next topic, which is privacy. The title of this is Privacy is Contextual. And I'm going to set the stage by saying for purposes of this discussion, privacy is kind of a shorthand. But what we're really talking about is personal information. Information that's not personal, but confidential to a company because it relates not to individuals but to company plans and trade secrets. And so with those two things in mind, we go to the fundamental issue, which is who sees what information and for what purposes. And that's what makes it in my mind a contextual issue because who sees what information for what purposes are three variables that are going to change depending on what the purpose is. And different information is necessary and different access is necessary to that information or allowable for that information depending on the purpose. So one size fits all does not work. An example would be a pharmacy or other company that is setting up an ancillary hearing clinic on the theory that people will come, have their hearing tested, and walk next door and buy a hearing aid in the concomitant services that go with supporting it. In order to do that hearing aid medical examination, some prior medical history will need to be provided. The problem is that there's no reason and a customer's last patient in this context will not want his entire medical history disclosed when it's irrelevant to determining what the hearing problem is. And what's the problem? The problem is it's not binary. It shouldn't be all or nothing. It should be contextual. And how are we going to get there? Well, there's too much information stored in too many electronics, semi, or completely automated systems for human beings to go in and sort out what's relevant. And that's going to drive us to using software agents to make this decision. And that's where the IT comes in, and the CDO needs to cooperate with the CIO and make sure that the software is smart enough to make those decisions. One of the issues that'll come up is whether there's going to be customized software that's going to be added to a standard offering. And the businessman solution is if I'm paying for custom software, I should own it. I want to very quickly say that I think that should be rethought and it shouldn't be an automatic position. And you should go back to figuring out what the business drivers are for creating the software in the first place. So if the standalone custom software can really have monetary value, then that's an argument for having the customer own it. If, however, it can't be used by itself and there's no plan on monetizing it, then there's an argument and a strong one that it should be owned by the provider, by the vendor. And there are various legal advantages of that. If it gets folded into the vendor's standard offerings, then the vendor will support it, will put the A team on it, will protect it with indemnities and representations, and that takes a big load off the CDO's responsibility for making sure that the data gets analyzed because the software is in good shape. On the next slide, I'm going to address intellectual property. And this is always the question with data, which is, who owns it? And the short answer is it's from an intellectual property point of view not the complete answer. There's patent, copyright, and trade secret protection. Trade secret protection is pretty easy. If you declare it a secret, you have to keep it secret and then it's yours. From a patent perspective, the algorithm that does the analytics may or may not be patentable. From a copyright perspective, that would protect the databases, but not necessarily the underlying facts. The underlying facts must be what's protected. In my experience, when you have a fairly complex operation, every entity that's involved in the operation thinks that it owns the data, and then you get into huge fights about who owns it when ownership is not really clear under the law in the first place. So I would propose a new paradigm that you focus on data sharing as opposed to purely deciding ownership and then going from there. So how would that work in a legal context? It would work that the companies say, whatever IP they own, they own, and we're not sorting out the fine lines between ownership. And then they're contributing by a license technology, by a license technique rather, a way to share that data, because using and sharing the data is actually more important than ownership. And the contract will be the vehicle that defines the scope of sharing and the obligations and the rights that go along with sharing. So now we get to the point where you're doing the data sharing, and yes, data is an asset, but because IP is limited, then you need to address this in a contract. So as the next point says, for lawyers, that means it's a private rather than a statutory arrangement. So your contract is really writing your own law, and that's perfectly fine, and that's what lawyers do for you. The intellectual property comes in when you do a derivative dataset that has a competitive advantage. That is something you're going to try and own, and a derivative dataset is easier to own from an intellectual property point of view than raw data, and from a contractual point of view, it's easy to make that work. Open source is a risk. For those of you who aren't familiar with it, open source carries the risk that you can use the open source software, but you can't build a proprietary system on top of it because open source requires you to make it available to the public for them to use. So different open source license agreements provide for different kinds of public use, and it's important to make sure that you pick the right version of that. I've already addressed customization, so I won't go through that. Joint ownership has the same issue, which is when it gets complicated in collaborative improvements, the parties will say, well, we'll just share the ownership. The important IP point here is that joint ownership under IP has unexpected consequences. The chief one is that the joint owner can license to your competitor without you having the right to stop that unless the contract goes otherwise, and therefore I think joint ownership carries some risks that need to be addressed. I have a question about compliance with the EU law or directive or equivalent laws. That's a very complicated issue, but in the context of compliance, the EU protection basically requires that nothing can be done without express consent of the data subjects. So that's a lot more restrictive than the terms of use than you see in U.S. type website agreements and things like that. You do need to comply. It's hard to make it the highest common denominator because that does limit things that you're free to do in the United States, and from a legal point of view, the problem will be that the marketing department wants to commingle all this data, and commingling restricted European data with unrestricted U.S. data creates a problem for compliance. So that's an issue we'll come back to if we have more time with everyone's understanding that it's a great question, but a very complicated one. Bill, can I interrupt you just a moment before you move on to this next slide? You talked about special conditions or circumstances around derivative data sets. Could you give an example of a derivative of what a derivative data set is or is not? So yes, I'd be glad to do that. So let's say that you have all this data out there that you've collected from, you know, your own customers' sales information. You've gone out and you've bought some information about those same customers so you know a little bit more about them and if they buy luxury goods or take a lot of travel or have kids, whatever it is you need to know. And then you're kind of combining that with what they are saying or what general information you're getting through social media and all the ways in which comments can be disseminated in today's world. So the data set would be taking all that information and saying that our business purpose is X. We want to provide this service or provide that product to a target demographic. And so you take that information, you filter it, and you end up with a subset of those people and a subset of attributes that you've called from all the possible attributes or at least all the available ones to the ones that really matter to you. And now you have a database that's very much focused on particular needs. From an intellectual property point of view, you've done something that makes that easier to own than just putting together a bunch of facts because in intellectual property terms you've put some structure and some purpose on why you're collecting stuff. So that's something that you can own and you would want to own it because it provides a competitive advantage. And that would mean that you're going to restrict third parties from using it. On the other hand, you may want to monetize it and sell it because it has value because it has done something important. So Tony, have I addressed that issue? Yes, certainly. Wouldn't mind being it comes up a bit later on, too. Okay, so let me go through the slides and then we can come back and revisit this. But I think the core point is that to make, you know, enterprise data useful, you have to turn it into some subset of all the flood of information that you have and including information that comes from the Internet of Things, where you're getting a lot of sensor-driven information and some of it isn't relevant for some purposes and is relevant for other purposes. And because, just to repeat what I said, having tailored data is what makes the data useful for you. That's where both the business intelligence is and maybe the artificial intelligence agents that apply to it. You want to create it and then protect it the best way you can. The point of focusing on data sets is that they're more susceptible to intellectual property protection than is the big hunk of data that forms the raw materials. So I'm going to move on now and welcome questions as I go. How long to keep data? This one I'll discuss relatively quickly in light of the time. Everybody is familiar with data retention policies that lawyers use to decide how long to keep data and how long not to keep data. From that point of view is that you don't want to have extra data hanging around in case there's a lawsuit, because it only provides a risk. The coming conflict is that I think the business side of the fence sees monetary value in keeping data longer than that ordinary provision. The data retention provision would be for litigation risk purposes. And so you have a conflict essentially between mitigating risk and maximizing revenue. And companies are sorting this out now and we're giving advice on it. It is how do you accommodate both goals without running undue risk and giving up an acceptable measure of revenue in order to mitigate some of that risk? So I think this is going to be a huge problem that companies haven't really focused on. And then we get back to the fact that it's contextual, that you don't need to keep all the big data that you have. Data itself has a life cycle and eventually you might keep it because it's not useful. And not all data that's useful needs to be kept. So you need to come up with some metrics and then again some software agents that get rid of this, all in discussion with regulatory compliance people. So that's another way of saying that CDOs just can't avoid the legal consequences of collecting these terrific data sets. Another point that I haven't made on this slide is where there's a value from a litigation point of view to getting rid of the data, there's also a value to keeping it because it can be exculpatory as well as incriminating. And that has to be taken into effect, into account when you try and decide what the legal risk really is. So now we're coming to another avenue of security breaches. And in my mind, bring your own device to work because it's really a little limited. It's really bring your own infrastructure to work because when employees think that their teenagers have a better IT system than their companies do, they're just going to use everything that they can get through their smartphone, whether it's an app or whether it's a Dropbox or something like that. And the nature of the internet is if you're not paying for a product, then you're the product. So that means a lot of information stored on some cloud service through your smartphone is probably going to be collected and used by the provider. And that becomes a risk to the company. So companies need to try and set some rules up and basically provide enough of an infrastructure so that it doesn't all have to bring your own because the company is providing the right kind of apps and kind of smartphones to do a good mixture between the flexibility that that world provides but the same security that the company provides. And at the extreme end, there can be a risk if your company is a critical infrastructure and you're a target for state actors or malicious criminals. And while it's great to get that information, it's not great to have that be a source of a security breach. Everyone talks about cloud. Cloud has passed the point where it can be considered to be a completely disruptive technology. It's not disruptive because it's here and it's here because smartphones won't work without it. And if the goal is to have data everywhere anytime, then cloud is probably going to be the way it's going to go. And everybody is aware of security issues in the cloud. My estimation is they'll probably be solved in great part and your cloud provider might actually provide better security than your existing IT provider does. But it's no longer disruptive and therefore it provides value in how to manipulate and collect data and it's something that should be embraced rather than avoided. And I've already talked about how smartphones are now the way in which a lot happens. To put a finer point on that, I would say that the movement from desktop PCs to handheld mobile devices is big an inflection point as the movement was between mainframe computers and desktop PCs. So my last slide focuses on what I view as the approach I'm working through and recommending to clients with respect to how do you deal with persistent attacks and what approach should you take in a world where you're constantly being probed or hacked in ways you may or may not know. A more traditional approach is to outline some SLAs, outline some penalties, and say that vendor has this responsibility and we're measuring it by SLAs and if they fail the SLAs then there's a penalty or a breach or some contractual harm the results for which there's a remedy and there's two limitations to that. Number one, the SLAs might not measure something which is a harmful breach. And number two, in the event of a breach what is your real goal? Your real goal is to stop it from happening now and to prevent it from happening in the future and learn what you need to learn because with these persistent state actors and criminals they will ultimately get in if they really, really want to. So I think a better approach is to model private agreements on what companies and critical infrastructures now do with the FBI. So if you're a big company that does defense work and you get hacked by China and most times you co-operate with the FBI or another agency and kind of work together to figure out who attacked you and how to stop it I think that idea can be ported over to private contracts and rather than have people fight about what a breach is and that that moment have the breach continue move more towards a theory that it's more important to allow the vendor to be honest about what did go wrong and use that as a joint set of information about how to improve it going forward. And my final point is that one of the big ways in which companies get hacked is through what's called whaling which is the IT department erects all these defenses and some senior executive who frankly is probably the least likely of all the employees to rigidly adhere to all the security practices gets an email and he gets an email with a grammatical error and I believe that the grammatical errors are not the result of somebody who doesn't know how to speak English but it's actually a business strategy and why do I say that? For somebody who's very IT savvy they're going to look at this and they're going to just disregard it and delete it in case it has some malware and just get it off of their system. For someone who is less fine tuned to that they're going to open it up. They're going to be sympathetic to a message that purports to come from a high school buddy who is trapped in Mexico and lost his passport and needs a thousand dollars to get home. So somebody who isn't aware of the IT and is kind of sympathetic to that will open it up and then the malware will come in. So I just want to caution people that in my mind that is a grammatical error constituting a business strategy and that's the real risk to the company. So with that Tony I'm going to stop consistent with our time for questions and turn it back over to you and to the audience and invite all the questions that people do have. John, why don't you jump in with your first question? Sure. My first one is going to pose a scenario which is fairly common to a lot of our listeners who are bringing up some type of data management or data governance program. And three things can happen. They discover some deficiency either through data profiling or a survey or something, but there is a deficiency that could be interpreted as a legal risk. Corporate legal does one of three things. They say, oh my gosh, that's horrible. Please destroy all evidence of that. We here at ACME or space lease sprockets are perfect. We don't do things wrong. We don't want anything in writing. The second thing is they say, well, you better fix it and keep us in the loop as to how you fix it because that is legitimate risk and we want you to make sure it's fixed. The third thing is, oh my gosh, that's terribly horrible. We want to take over your data governance program and make it part of our legal department. What are those three scenarios? Do you see being preferred these days? Or which ones do you have a particular issue with? Well, I think the preferred one is to find a way to effectively combine those people in the legal office or in the compliance office, which are concerned with risk. From their point of view, compliance is not optional. So that means you have to work backwards from those requirements and make sure that the data system works with that. And I lost a little bit about the other two scenarios, so if I can ask you to kind of summarize those again, I want to tailor my response. Sure, and I'll use the handset to we might have lost something in the speakerphone. The first scenario is the most interesting one where you are told, well, whatever you found out, don't write it down and don't worry about it. We don't make those kinds of mistakes here at Space Lease Brockets. So it's essentially don't build your program around fixing that problem because we don't acknowledge that's a problem. We won't put that in writing that we have a problem. The second problem is please go ahead and fix it. We acknowledge your risk and keep us in the loop so we can make sure that it is in compliance and that here's to law. The third one, which has actually happened, I've seen happen, is legal takes over data governance and says that's our project. There's enough risk here that we need to actually drive the data processes in conjunction with whoever has the top data job. So those are the quick review. Those are the three again. Okay, so on the last one, the lawyers can't do it unless they really understand the data, the marketing, and the technology. And it's always easy to be so risk adverse that you undermine some of the potential upside. So I think siloing that completely and speaking as a lawyer without getting the input from the business and the IT people doesn't serve the company well. To go back to the first one about don't write anything down, as you suggested in your question, you can't learn from that. And you're essentially hiding rather than solving your problem. So there is attorney client privilege, which is something that can shield the disclosure of that information and you need to structure it and that's where you do need to involve the lawyers to do that. And then your next question is essentially how do you learn from this and how do you structure it? And to me it seems like kind of handling random notes without a paradigm for how to decide what it really means, where it fits within some structure is my way of saying you have to have some overlay and some kind of predefined hierarchy of issues so that you can assign the comments to those issues. You may learn from the comments that you have the wrong hierarchy. You know, big data needs to be turned into something structured to be useful and so does internal comments and how things are working. Okay, thank you. I have a few more here. Tony, I'll turn it back to you and I'll hold my turn till later. Okay, John, the audience is unusually quiet today maybe because it's a topic that they're less familiar with or maybe they're afraid to ask questions in public to discriminate them, I'm not sure. But let me jump in one that's a bit related to the last one that you asked, John, which is... I mean, we covered this somewhat back in D.C. where the question came up, you know, there's a lot of pressure to monetize data to come up with ways to convert data into a product or leverage it as an asset. And it just seems like there are some obvious questions from legal standpoint that are likely to come up from that type of business strategy. So, Bill, you had a short checklist of things that people need to be aware of if they're looking to monetize data. Could you touch on those? Sure. So this kind of goes back to one of the questions that I'm seeing in front of me, which is overlapping with the EU question. So before you can do something with data, you've got to check the law and see whether you're free to do it. And in many instances, you have to think ahead and you have to get consent to do it. Under EU law, there might just be an inherent limitation, which means you've got to segregate information from EU subjects from US or other subjects. So that's the first question is, you know, before you do anything with the data, do you have the right to do it? Then to monetize it, you can't monetize it unless you own it in such fashion that you can charge for it. And that's where it's a combination of IP protection with the stronger IP protection available to derivative data sets and treating it as an asset as a piece of property is defined in the contract. And then that would mean that the parties have to agree and agree may be the wrong word because you're going to walk in with a position or you're not going to do the deal where X data is owned by X company and you talk about what does monetize mean. So that gets back to the contextual point I'm trying to say, which is you don't have to give away data for all purposes for all time. And this is where IP and other licenses come in. That's the legal vehicle for saying you can take data and pay me for it and use it to do X, Y, but not Z and not ABCDE because you don't want it to be competitive, you don't want to water it down. And from a legal point of view, it's wrapping it in protection and then granting the right to use it, which is another way of saying license, in a way that you're not giving away all rights for all times because that means you effectively can't monetize it when you only have one customer for it. So that requires an understanding of what the business objectives are and legal skills to make it work. And underlying all this, I think in today's world everybody's a friend of me where they're both a competitor and a business partner. That complicates things. Lawyers see it all the time and work it out. But it is an issue, especially in kind of an uber world of data sharing where there's a lot of information gathered and you can sell information because you don't really need it to move people around town that somebody else will want to know how many people go to this restaurant during this period. And I'm just making this up, but maybe that's information that an uber-type company could sell because it doesn't really care or it doesn't mind sharing that information and it certainly doesn't mind monetizing it. Okay. As we move on, I just want to apologize. I can say there were no questions, but I guess they just weren't assigned to me. So Shannon has assigned them to me now and I can see them also. Oh, okay. I couldn't see any either. That's good. Yes, yes. So there were two or three questions along similar lines. I think we'll move past those just now. There's an interesting one that just came in. Can you give an example of effective data retention algorithms that strike a reasonable balance between litigation risk and business value? I think we're the work in progress then and that's why I was trying to highlight that it's an emerging issue. So is there an algorithm that'll do this? Yes and no. I mean, a lot of this is a business judgment call that's specific to your company. So if the IT department or more likely an outsourced provider can come up with that algorithm then that's a good thing and that's probably a workable thing and the only workable technique because just the volume of data precludes human sorting by it. I will say that there are lessons here. I'm sure everybody who's not a lawyer has heard of the term e-discovery. Under U.S. law, a lot of information has to be provided in the litigation and it was one thing when everything was kept in a file cabinet and paper. When everything is now kept in multiple computers and they're multiple copies of the same emails all over the place, e-discovery is a way to bring computer science to managing that. And so some of the techniques that are used in e-discovery can be used to kind of reverse engineer it and decide what you keep and what you don't keep. So that would be my short answer on that question. Okay. One that hopefully might be quick is is there any resource available for a global organization to understand the different data privacy jurisdictions that exist around the world? Yes, I mean there are publications. There are countries with no laws. Countries like the U.S. which has sectoral laws, which is different rules, apply it for different sectors. So health, financial information, information used by children under 13, those are the U.S. categories which have special rules. European rules are very strict. Canada's rules are kind of in the middle. Argentina has rules and other countries have rules. So there's two aspects of this. Yes, you can find books that kind of outline the rules. The real issue, however, though, is what's under consideration. And if you're going to build a compliance structure and spend a lot of money doing it, you know, how do you build in what's likely to happen in the future or at least some flexibility for how to deal with it? So at some level, the existing books are going to be incomplete because you need kind of the expertise of someone who can make a judgment as to what trends are developing. An example, the EU is trying to come up with rules about cloud computing and where data is stored. Some of the rules probably are completely workable in a technological sense and are completely consistent with what even your European companies will want to do. But you need to speak with someone who can make a judged evaluation of how that is likely to turn out or at least what you should do in anticipation of some form of that rule coming out. Okay. There's a couple of other questions about specific data sharing examples. I might ask you to comment on these later because we've spent some time on that already. And we can't cover every context to you. John, you said you had some other questions in different areas perhaps. Yeah. I'd like to go back to the data breach of statistics 63% caused by third-party providers. Could you provide an example of how third-party data has created a breach that I think some people might be interested in in an example of that? Because in my practice, I find third-party data and cloud software to be a real governance issue in almost every company we are in. So an example from that would be great. So this study is a little bit different. This study focuses mostly on kind of the target type of breach, whereas many people know the attack was not directly on target. I guess no pun intended. It was on the HVAC contractor, which for some reason had been given access to the important parts of the network. And over a period of years, the criminals kind of took the entry point from the subcontractor and worked their way up ultimately to the swipe machines where the credit cards were used and where the information was not encrypted for a very short period of time. So that's kind of the IT aspect. On the data aspect, I'm a little less sure on how to answer that to be frank. But what I would say is that data is usually bound up in some kind of electronic format. And the electronic format, if it's not good, will have its weakness. To move on to kind of the Internet of Things answer. So these Internet of Things are generating data and the data is being collected and then it's being acted upon, usually kind of automatically. And sometimes it's just being collected and it's going to turn into enterprise data, which is going to be filtered through an algorithm and used in the way I previously discussed. But from a breach point of view, the simple answer is if you can network something, you can hack that network. And there have been examples where people walk around and cars that have those near-field control systems to unlock them, well, they can be spoofed and someone can open your car and drive away with it. So is that data? Well, it's dated to the extent that it's an encrypted code that can be broken. So there's a line between what's a gizmo and what's a piece of data and in today's world that's not an easy line to draw. So I think the Internet of Things carries with it a risk not only of physical or logical security, but also taking information that the company wants to use for competitive advantage because someone can just get in and monitor it even if they don't actually steal it. Okay. One other example that I have experienced if I could add to that was a lot of companies buy data about their customers from third parties to help further expand the demographics and psychographic-type information. And in the process of that interface, sometimes they open up their environments to an invasion because you have to have a hole drilled through your firewall so that data can come in. But the other example of Target was exactly what I think people were looking for. Thank you. Thanks very much. Tony, I have another one. If we have time, if not, I'll kick it back to you. Yeah, we're really out of time. John, there was one contribution from Dara O'Brien in Ireland I wanted to mention before we go. In answer to one of the previously asked questions, he says there are 111 laws. This is with respect to the question about resource for identifying data privacy regulations around the world. DLA Piper has a global source book that has high-level summary of data privacy rules worldwide. That particular answer is in the Q&A, but it will be distributed with the chat summary that Shannon sends out in a couple of days. We are at our time, basically, so I think we should wrap it up here. I'll hand it back to Shannon in a moment, but I want to thank Bill Tannenbaum very much for joining us today. Great, we appreciate your time and expertise, Bill. Thank you for that. John Labley, for your perspectives, as always. My pleasure. We always get asked the question, will the slides be distributed? Yes, Shannon will look up that for you and send that with a link to the recording. So, Shannon, back to you. Thanks, Tony. And thank you, Bill, so much for joining us today. And, John, as well, while you're on the road, it's a great pleasure as always. Just as Tony mentioned, a reminder to everybody, I will be sending out a copy of the slide, or a link to the slides, a link to the recording, and the additional information requested and commented throughout the webinar today, within two business days. So, for this particular webinar, by end of day, Monday. And thanks to all of our attendees, as always, for engaging in everything we do and being so interactive with all these great questions. And that's it. Bill, thank you so much again for joining us and for this great presentation. And thanks, John and Tony, and I hope everyone has a great day. All right. Thanks, Shannon. Goodbye, everybody.