 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor of Data Diversity. We would like to thank you for joining this month's installment of the Monthly DAMA International Webinar Series. The Webinar Series is designed to give our Enterprise Data World Conference attendees education year-round. We are excited about the upcoming Enterprise Data World 2016 to be held in San Diego, California, April 17th through the 22nd. We've already had a lot of inquiries about that, so be sure to save the date. Today's Webinar is being presented by a longtime EDW speaker and Dama member, Derigo Bryan, and he will be discussing data privacy in the DM box. No need to reinvent the wheel. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the Webinar. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share our highlights to questions by Twitter using hashtag Dama. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the Webinar. Now, let me formally introduce today's speaker. Derig is the Managing Director at Castlebridge Associates. He is an experienced information governance, information quality, and data privacy expert combining detailed legal knowledge with almost two decades' hands-on experience in data integration, governance, and regulatory operations. With his firm, Castlebridge Associates, he provides training and advisory services on data privacy, information governance, and information quality to a range of organizations. He currently serves as the Dama International Privacy Officer. And with that, I will turn the presentation over to him to get us started. Hello and welcome. Hi, Shannon. How are you? Good evening to everybody on the Webinar. The purpose of this Webinar and this evening is to introduce some of the concepts in the DIMBOC wheel to people and help you understand how this privacy thing that's becoming very important and is now very high on everyone's agenda is not really anything new when we strip it back and look at what it is we have to do to act in a compliant manner, and even that going beyond basic compliance to look at acting in an ethical way around data and how we manage it. So we're going to talk about today, very simply going to introduce, talking about why data privacy is important. So to put this in context, this Webinar is distilled down out of a two-day course. So we're not going to give you everything you need to know about data privacy in the DIMBOC in the next hour. We're going to give you some starting points. The key starting point is about understanding how and why this is an important issue now. So you can have some sound bites to bring back to your peers to explain why this Webinar was a valuable use of your time this afternoon or this evening. We're going to talk about where data privacy is in the DIMBOC. Now, we're not going to cover the entire DIMBOC. We're going to take three or four segments of the DIMBOC wheel and discuss them. We're going to introduce some additional concepts from the data privacy world. We're going to relate them back to what we talked about in the context of DIMBOC. Then we're going to introduce at the very end, we have a little bit of time, concept of ethical information management, which is an emerging concept in the context of data privacy. The European Data Protection Supervisor is one of the lead regulators in Europe, has issued a paper on ethics in big data and it's something we need to be looking at going forward. So I thought I'd introduce it as well because, again, it ties back to the DIMBOC discussion. So without further ado, let's start talking about where things are in the DIMBOC and why data privacy is important. So data privacy is important for a couple of reasons. One of the key reasons why this is a big issue is that history has shown that sacrificing a right to privacy can have dire consequences. When the CEO of Apple, when the CEO of Microsoft, when CEOs of numerous companies are beginning to actually see this as an issue for their customers and an issue for the bottom line, that's something we need to start taking seriously, but it's something we've always really had to take seriously because when we don't respect people's, the privacy of people's data, when we are amassing large amounts of data, it creates a risk that we might cross the creepy line in a far less than wholesome way. In terms of legislative trends internationally, we're looking at about 111 data privacy laws worldwide by the end of this year. By data privacy law, I mean a state or federal level piece of legislation. So a national level piece of legislation or legislation across a federation or a trading block. So the various laws that exist in the US for data privacy don't feature here. And there are a number of them, that's one of the issues in the US. There's been a sectoral approach taken to legislating for privacy, which means you have a lot of legislation in different states and in different industry sectors, some of which contradicts other legislation and it can be difficult to get a handle on it. But internationally, the trend is towards a single national principles-based model for privacy legislation, which can then be applied on a principles basis across different sectors. So in Europe, we have the European Data Protection Directive, Sympathy Replace for Regulation, for example, and that's one piece of legislation. A key point about this trend, this upper trend where the last bulk of the privacy laws that exist in the world have been passed in the last 15 years is that the model that's been adopted generally across the world is based on the EU model. It's based on the principles and practices that have developed out of the data privacy laws in the European Union. A variety of reasons for that, one of them being very commercial about it, is the European Trading Block is at 700 million people. And if you want to do business with European companies, you do need to be at least aware of European data privacy laws and if countries want to have data transfer to them, they need to be able to demonstrate the adequacy of their protections. There's a whole host of reasons why this will be the case. But the key point here is that there's an emerging commonality of principles between Asia Pacific, Europe, and indeed the US, albeit not necessarily legislative for in the same way. In that context we need to be thinking about the outcomes more so than the specific legislation, the outcomes that we're trying to achieve. What we're looking at with privacy is an information or a process outcome and an expectation that the customer has of that. So what privacy is for them and what they expect to happen to their data and how we engineer and architect our organizations in the context of this multiple box model for strategic business information technology manager or tactical management or the operational use of data all affects how we are able to comply with the expectations that customers have and give them the outcomes they want. So in that case we can start to see how privacy starts to encroach into the world of data quality. And I always tell my clients to think about this as a quality system for data. In the same way as information quality is. In terms of talking about the core principles and what the expectations are that customers might have and the frameworks and principles we need to talk about in that context, I just mapped out a couple of core principles here. The ones in white on black are the EU principles from the current EU legislation. And we have here at the requirement to obtain data fairly for a specified lawful purpose requirement to not process data for a purpose which is incompatible with the purpose which is obtained or requirement to keep it accurate enough to date, etc. Those principles exist in similar forms that can be found in guidelines from the OECD for cross-border data transfers and protection of privacy. And the Association of Chartered Accountants. So an accountancy body in the US and Canada has developed fair information processing principles for personal data. Now the United Kingdom is asking you if data is an asset. You can always tell them well accountants have decided it's important to define standards for processing it which means it probably is. In terms of what's coming down the pipeline internationally, we talked about how the European model has been followed. The European Union is about to finalize its data protection regulation. We're expecting that end of next month, early January. This is a one-slide summary of what's coming down the pipeline. What we are looking at is the eight core principles about obtaining data fairly, processing it for a specified lawful purpose, not incompatible with processing, keeping it safe and secure, keeping it accurate enough to date. Not having to make sure the data is adequate, not excessive, et cetera, and retaining it for no longer than is necessary. Those principles that we're going to touch on again in the course of this tutorial, this webinar, they're there. We also have an increased focus on accountability. So the accountability principle is a key one that we see going forward. And there's a very clear principle on transparency as well. So these principles are becoming much more robustly stated in the regulation. They're always there, but they're much clearer. And it's all been done in the context of the Charter of Fundamental Rights in Europe. Now, Europe recognizes data privacy as a fundamental human right. And the United Nations has recently begun to follow the suit in terms of developing a framework for recognizing data privacy rights. So that's what kind of why it's important. And in terms of what's coming down the pipeline, in Europe, we're looking at a principles-driven model, which will be based on a risk-based framework. So it won't be prescriptively much more what do you think yourself about and how good or bad your ability to respect privacy is. And there will be increased penalties. And one of the key points about the increased penalties and why this is important for US-based organizations or any organization not based on the EU, is that if you are selling into Europe or if you are engaged in monitoring of people who are living in the European Union, you will need to comply with EU privacy laws. So that extra-territorial effect is coming. And over the past couple of years, while this regulation is going through its drafting, I present on this a few times in the US. And I hear people say, oh, that's unfair. You can't do that. And I just say, survey is up to me. I'm sorry, fixed point in time, nothing we can do. The extra-territorial effect of regulation is a reality. It's something we have to live with. And it's why organizations need to be looking at what's happening in different jurisdictions to understand how that might affect what they need to be doing. In terms of mitigating your penalties, which are being expressed as a percentage of global turnover, so you're looking at up to 5% of global turnover or 100 million euros as a penalty, which, Jebra, is the greater. Well, you can mitigate those risks by having a focus on governance. Focus on governance means having a data protection officer, having good documentation of your processes and policies for processing personal data, and being able to demonstrate evidence of the effectiveness of those controls and of those processes. So this is a wonderful framework, a wonderful set of requirements, all of which come with pretty substantial penalties for not having them in place. And when we present this and talk to people about this in the context of privacy, I think, well, why does it matter? Well, the reaction when we look at the potential penalties is usually something like the lady in the middle there pulling your hair out and being stressed about it. However, I think the other things we need to consider are the potential brand implications for an organization of having a data privacy breach. I'm not talking here about a security breach. I'm talking about bigger than that, security being just one of the eight principles. We have the risk of regulatory penalty or incarceration. In some jurisdictions, you can go to prison for getting this wrong. It's not a financial penalty. It is a financial penalty and a potential prison time in some jurisdictions. And in the European Union, if you have breached data privacy law as a result of the consent, connivance or negligence of an officer or director of an organization or a buddy corporate, that individual officer or director can be held personally liable as well. So it's important to bear in mind that these things matter for a variety of reasons. It's not just a nice to have another level of high type of concept. In the law of nature, bottom line, if you look at recent data breaches we've had internationally, Target or in the UK, we've had TalkTalk recently, it hits bottom line performance. We've had TalkTalk had over 30% hit on its share price because of data security breach. Let's not forget about the risk of incarceration, the ROI for the new generation. As Peter Akin calls it, you have a significant risk of going to jail or being penalized if you get this wrong. So given that we have a risk of getting it wrong, what do we need to do? Given that this is a complex area with lots of issues, lots of challenges around it, how do we take what we already know and calm people down and help them figure out what we need to do to solve these challenges and meet or exceed the expectations of our customers? Well, the DINBOC gives us a framework where we can start to look at these things. And because we're dealing with information and data, we're not doing anything radical new when we look at privacy. If you consider privacy as being the output and the outcome of a set of processes, procedures, practices and structures that are being put in place for the management of technology and the information in support of business goals, well, it's just another requirement at the end of the day, albeit a really, really important one that we can't understate. So the DINBOC we are going to talk today about data quality, data governance, data development, and a little bit about data architecture in the course of today. One thing I would say about the DINBOC wheel is I would ask everyone to remember to respect copyright when you are citing the DINBOC wheel. It is a copyrighted thing, it's copyrighted data. It's available on Creative Commons license and data members can download the DINBOC wheel and related material from the DINBOC website. But if you're using it for commercial purposes, you do need to ask permission from DINBOC for that. So in terms of data quality management, we identify privacy as being the output of processes for managing data. How well we are meeting the expectation of privacy that people have is just one aspect of data quality. When we look at data quality in the DINBOC wheel, we are looking at how data quality is related to data protection. I was a lawyer by training, I studied law for four years in UC law school, and one thing we were trained was always go back to the fundamental documents. So I'm telling people how data privacy is related to data protection or is related to data quality. I always go back to the underlying EU directive where we have principles for data quality, which are the principles that are set out, the eight principles. We can see them all down here in section in heading B there. They're defined as principles for data quality. And from a legal lawyer point of view, that's where I stopped talking. But hey, I'm a data governance guy, so I'm going to keep going because there's a whole lot more to it than that. When we look at the eight principles in data privacy law in Europe, and considering these as general principles for data privacy worldwide, we can see a mapping between data governance and data quality issues quite clearly between them. So when we highlight these from a data quality perspective, we have personal data, so we can not go complete them where necessary kept up to date. That's a very clear set of requirements for data quality. There are things that we know from a data quality perspective, and there are things that we know we can measure. The challenge is where NEST is free, which puts things in the context of a process, a set of objectives. Keeping data for no longer than necessary for the purpose for which we need it. And the right of access also raises an information quality, characteristic information quality factor as well, because individuals are entitled to get a copy of the data that is held about under various data privacy laws. So if you look in South Africa, you look in Europe, you look in other jurisdictions, someone can write to you and ask you for a copy of their data. And they need to be given it in an intelligible form, which means that only it doesn't have to make sense of the accurate and not have any incorrect information, but any abbreviations, any field names, things like that need to be understandable and intelligible. So that raises a number of quality issues. When we look at data quality in the DINBOC, this is taken from the activity diagram in the DINBOC handbook. And if you haven't bought the DINBOC handbook, it's worth getting even the DINBOC 1-1 while waiting for DINBOC 2. There's a lot of really good stuff in there, and these activity diagrams are very useful for framing discussions. Because when we look at what data quality is, it's the planning implementation and control activities that apply quality management techniques to measuring, assessing, improving, and ensuring the fitness of data for use. In terms of the goals, what we're trying to do is to measure and improve the quality of data. Now, the quality of data is its fitness for purpose, whether how well it meets or exceeds the expectation of the customer who's looking to use that data. So we're back to the information and process outcomes I illustrated earlier on. That's about defining requirements for integrating data quality into the system development lifecycle. So it's about building in quality into how you build your systems and build your processes. We think about privacy and the privacy requirements as being quality requirements. Well, certainly, we can see a strong overlap between the business requirements. Oh, the business requirements for data and privacy. The data requirements require accuracy, completeness, timeliness, relevance, adequacy, et cetera. Data policy is a standard. It's how you cascade those things down into how you're working in the organization. And then things like metrics. So if you think back to the discussion at the very beginning of the general data protection regulation, we're talking about the need to have evidence of the effective operation of your processes, well, that means you have to start measuring something. And if you're measuring something, well, you're looking to do some sort of data quality control ultimately because you're measuring the performance of the process. Ultimately, you're looking at errors and requirement violations. So looking for defect, looking for conformance to expectations. These are things you're going to measure from a data quality perspective. And once you understand what the privacy component is, in all of these things, you can apply the principles we already know about in data quality to managing those issues. It's not new. We don't need to reinvent the wheel. Here's an example. Under e-data privacy, electronic privacy regulations, electronic marketing laws, you have to use consent within 12 months before you lose it. So with a client a few years ago, we did this analysis where we looked at the number of months since last contact, since the last marketing contact they'd had with their customers. And we identified that there was a percentage of their customer base that they were never going to be able to contact again. They would have to go and re-consent them and incur the cost of re-acquiring them. But there was another 30% that were between 10 and 12 months since their last marketing contact. Now, it took this organization up to two months to produce a marketing campaign, which means these were a red flag. They had to contact them with something because they were at risk of losing a significant amount of business value. So you need to associate a business value element to a data quality issue and tie that to a process root cause, which was we're not marketing to these people enough. Well, then you're doing data quality improvement and we just simply applied metrics to the process. In terms of data development in the DIMBOK wheel and how that applies to data privacy, well, this is where we look into the wonderful, wonderful world of keeping data accurately complete and up to date. So what's the flow of data in the organization? How are we managing integration and structuring of the data? Whether the data is adequate, relevant, not excessive, but also the question of right of access. Where is the data? How is it structured? How do you get that out quickly for people when you've got a 40-day window at most to comply? And what can we do from a data development and the data modeling point of view to help support those objectives? When we look at data development in the DIMBOK, it's about designing, implementing, and maintaining solutions to meet the data needs of the enterprise. Part of the data need of the enterprise is to be able to comply with requests or copies of data from individuals who are entitled to a copy of their data. Part of the data need is to ensure the data is adequate, relevant, and not excessive. So you're not capturing more data than you need to actually have the data that you require. The goals are to identify and define data requirements, design the data structures, to maintain the solution components, and to make sure that you conform to architecture and standards as appropriate. And then you've got integrity, security, usability, and maintainability of structured data assets. So there's an element of security coming into the design here, so designing security into your data model and data structures. So again, your business needs, goals, and strategies are architecting everything, so we meet the privacy expectation that exists. Data modeling plays a hand in this in terms of understanding your requirements, in terms of analyzing and building your conceptual models, logical models, and physical models. In terms of designing the information products and the access, how people get access to that data and how you control access to that data. Very important. And then the standards you apply to the doing of the modeling, designing of your models, how you do your validation and checking of data models so that you don't have overloaded fields with more than one fact to be recorded in them, so that you've identified what fields contain personal data or sensitive personal data, and therefore might require encryption, which might affect how you design the model. And then going and building it is the other element of it. At a simple level, manage and model and maintain your data affects privacy. Here's a simple flow through the information aspects of life cycles. We're skipping the planning, we're skipping the disposing of data, and we're not obtaining, storing and sharing. So here's a web form that's taken from an actual client, and they take the data from that web form and they put it in the database, and it was a web form where people were signing up to receive or not receive information from the client and it was the difference between people getting unsolicited email or getting the message they actually wanted. And that comes down to the modeling of the form in terms of designing how the data is being captured, designing how the data is being stored, and then designing the process for it being used. So here's an example of zooming in on the bottom of the form where we found some of the major issues of this client. The first download here is the telephone number. Again, going back to the electronic privacy regulations in Europe, landline numbers, fixed line numbers, they're not doubt. You're fair game if you're in a phone book. But if you're a mobile number, if it's a cell phone number, that requires up-did consent. So here they have a single field capturing a telephone number field, a telephone number which can be either or, either landline or cell phone. Then they ask, how do you like to keep in touch? Please don't contact me, please don't send me information. These are opt-outs for something that requires an opt-in. This causes a problem because during our audit of this client we put our details into the form, we ticked the boxes to opt-out and then we were spammed. So the client failed their audit. The root cause being, I would suspect in the database when they were doing the extracts, someone looked at the field that said yes and interpret that as being an opt-in. It's the classic yes-no junk mail field problem because of a lack of data design and a lack of documentation of that design. When we look at something as simple as a marketing suppression or a purpose suppression flag in a data model or something as simple as phone, email and postal, you need to understand the purposes for which the data is going to be used and then determine what the rules are to record those purposes and how people will use that data. So in your marketing structures you may want to be having clear opt-ins, clear opt-outs, clear opt-ins, clear opt-outs for different categories of purpose. Again, I always recommend clients pick one. Make it simple for your data modeler. Data modelers are people too. But it goes to things like delivering service. That's another distinct purpose. Not everyone in the organization needs to have access to the contact number that's provided for the flat-screen TV delivery guide so that the phone needs to tell you your flat-screen TV delivery outside your home. But the marketing department might need that information. The delivery guy might need that information and you may have other purposes like warranty contacts, things like that where you're capturing other data for other purposes and it's really important to think about how you're doing data development and data modeling around that so the right information is used for the right process to deliver the right process outcomes and information outcomes so that you don't stand on people's toes from a privacy perspective. This is the case of death. I love seeing this from a data developer data modeling perspective on forms. You've asked someone to fill out loads of information about themselves on the form and then at the very end you say please stick this box in your life it's not to contact you, which I interpret as thank you very much, you just wasted my time. Because what you're doing here is you're applying the update on either a party or an account level entity and you're having to opt everything out for everything which is why the purpose is really important from a data development point of view it's one of the key elements of requirement you need to drill into when you're looking at privacy. What's the purpose of the data? What's being used for? How are we structuring that in the model? Here's an example of how data modeling can help with privacy impact assessments and understanding how data is and can be used. This is what we did for a client and they were a political organization doing canvassing, there's a community awareness organization doing electoral canvassing, electoral awareness. They had information about the statistical outcome of balance so they had done a sampling in the way the balance was held manually and in public they were able to have a tally of the results coming out of different loader boxes. They knew where the constituents were from the electoral register and they knew the types of voting that were going on, the types of ballots that were taking place. They knew that people had voted because they had access to marked registers legally. They knew what canvassing was going on on a door-to-door basis, what opinions people were expressing. What we modeled this, we showed the client that they were very, very close to not just breaching privacy laws but also breaching constitutional protections on the secrecy of the ballot because if they were able to drill down to the level of an individual and they could identify with a reasonably good level of statistical accuracy how they had voted that was a bad thing and as a result the client has re-engineered their whole process for how they're getting data and has been very aware of how they need to put different gates in and different levels of access at different points in time and segregate the access to data through their processes to avoid significant privacy implications they wouldn't have spotted that if we hadn't modeled the data and again it's a really bad data model but it was enough for them to realize and for us to demonstrate how they were getting really close to doing some really, really bad stuff. So, data architecture let's not forget about data architecture. Data architecture is really important because it's the identifying and defining the data needs of the enterprise and designing the master blueprints to meet those needs. What do you do? A wonderfully broad way of describing what data architecture is. The goals make sure you vision a foresight to provide high quality data. Remember, we're talking about quality data in the context of how well are we meeting the expectation around privacy. Our inputs, goals, strategies, architecture, processes, oh processes are very important these processes are the why the hell are we doing this what is the objective? Data has to be captured and unprocessed for a specified purpose. That's a really important element of your process architecture. Metadata and all of these elements have an important part to play and then the outputs are the information value chain being one element of your output. This is useful because you might have to ask for data earlier than you actually need it in a process in order for you to be able to efficiently execute the process. For example, if it's a funding application for student loan. You may need bank account information earlier in the process so that you have it available when things are time sensitive at the end. But then you have to look at how you architect things from a security point of view and a process point of view to make sure people only see that data when they need it. When we look at everything from a data architecture perspective it kind of fits in pretty much everywhere in our view of the 8th data protection principles. It's about fair processing, it's about specified purposes, it's about making sure the purposes are compatible with what you said you were going to be doing, making sure it is adequate, relevant, non-accessive security comes in here as well and it also affects the right of access because you need to know where the data is to be able to give the data back. Exactly, framework is a great way of looking at this and what I've done at the risk of John smacking me in the head the next time he sees me is I've messed with his ontology and I've simplified the diagram a little bit for our purposes. So what we're looking at here is a mashup between the Zachman framework and a UML diagram in Michelle Denady's wonderful book, the Privacy Engineers Manifesto, or we're looking at the what, how, where, who, when and why of the data you're processing. And when we start looking at these concepts at the different levels in the organization, the different perspectives that we have, well at the executive level we're looking at specified data for a specified purpose, which is the what and the how. We're looking at the timing, what triggers the need, so what is the actual reason we need this data and how do we balance our motivation. It's not enough to look for the data because you'll want to, you've got to have a reason why you need it. You're going to have a need that you're, your motivation that you're supporting. When we drill down to the business manager level we're getting more into data classification in context, so looking at what type of data are you actually dealing with, is it medical data which is sensitive personal data, are you looking at opinion membership? Are you looking at just general name and address type data about people? And bear in mind that personal data is very broadly defined, particularly in the European context, there's been any data which can identify an individual or single amount. So it's about looking at what you're working with and how well can you narrow that down to identifying an individual. What are the processes you're looking at to execute those purposes? They need to be considered from the framework and we can light everything up across the board at each level to be quite honest with you because we get into the architectural level, we're looking at logical schemas, back to a wonderful role of data development, we're looking at process maps and the data flow diagrams again, the information value chain element of the data development part. But then we can look at things like the responsibility representation, how we represent the roles, accountabilities and penalties in the organization for not doing data right. So that element of governance starting to creep in as we architect the organization's approach to managing personal data and personal data privacy. Location is an important one. I've highlighted this in the vertical because of the recent changes in EU law in relation to cross-border data transfer and also increasing focus internationally on where data is and the various pieces of legislation internationally that require, for example, in some states copies of data to be kept within the jurisdiction even if you are processing data internationally. So the Russian Federation requires certain data to be kept locally. In Europe, if you're a US company that was doing business in Europe and you were relying on safe harbor out of the 6th of October, it doesn't exist despite what the Department of Commerce in the US want to believe. It is God, it does not exist. So again understanding where your data is, how your data has been transferred is really important if you are looking at data export issues. So where is your data stored? And one of the rules that applies to that storage where it is in the world but also where you're sending it from to your target jurisdiction is important. And this affects cloud. This is a really big issue from a cloud computing point of view, but any sort of data exports, data storage, outsourced data processing falls under this category as well. That's really important. So finally we get to talk about data governance in the context of privacy in the DIMBOK wheel. Governance is where kind of where rubber hits the road a little bit because again in the DIMBOK wheel it pulls everything together and it's the center of the universe. And it fits in pretty much everywhere. Every component of the principles has some element of governance because there are decisions being taken and needed how to find models as Glenn Thomas says to decide what to decide and how to decide what to decide. So it fits in across the board in terms of the eight principles. Even in some of the access request process there's governance required around that to make sure you give the right data out to the right people. So what is data governance in the DIMBOK? When we look at the DIMBOK, again it's a big thing in the DIMBOK. Fitting on a slide is a challenge. Definition is the exercise of authority and control, planning, monitoring and enforcement over the management of data assets. Let's drop in management of personal data assets and straight away we have a definition of personal data governance. We have a definition to an extent of the activities we need to do from a data privacy perspective. In terms of goals, we're talking about defining, approving and communicating strategies, policy, standards, architecture, procedures and metrics. So again, pulling things together and pushing the med and communicating the med into the organization. Managing and resolving data related issues and understanding and promoting the value of data assets, these are all key goals. Again, we're not going to dwell too long on these diagrams because they're in the DIMBOK, but it's important to understand how they relate to privacy. Privacy is a business goal. Not going to jail is a really a business strategy, not handing over 5% of global turnover and penalties. Every fortnight is also a very good business strategy, values to data needs and data issues and it's driven by regulatory requirements. And we're looking at applying and control components of governance here. Both of these influence how well we are managing privacy in the organization. For example, looking at your stewardship structures and the data governance roles and organizational structures you have so that people know what to do with information and how to manage it and they know what not to do. Coordinating activities, managing and resolving issues, monitoring and ensuring regulatory compliance, key core functions of data governance. In terms of functions of privacy perspective, one of the things you can do from a data governance point of view is start coordinating policies and standards around privacy. Now, if you're coming from a European context and you're only dealing with data in one jurisdiction that's easy. If you're working across jurisdictions, ISO 29100 is very good because it contains core definitions of the key concepts, the core actors and the core processes that you need to be going through. But at a minimum you need to make sure your staff are trained. It's actually a legal requirement in some European jurisdictions and it will be a legal requirement under the draft data protection regulation to make sure your staff know what the heck they're doing. Again, under HIPAA staff have to be trained. When there are various jurisdictional laws and sectoral laws, staff have to be trained. That's what makes sure that happens. You make sure that happens in part by acting as an honest broker, helping to resolve issues and being the functions of the organization that's been described to me from the data privacy perspective. Where people can come to you with their issues and come to you with what they're planning and you help them figure out how to do it in a way that doesn't reach everyone's privacy rights in half. You're seeing going to jail or going to heck in a hand basket. And then making sure key controls are in place and are actually operating. When we look at stewardship for privacy I define this as model we have in Casper which is called model. We talk about doers, definers, inciters and coordinators operating at the strategic operational level in the organization. And we define them not by where they are in the organization but by their role in information and what they're doing with them. This is actually a really, really sensible way of doing it from a privacy point of view because privacy doesn't sit in IT. Privacy doesn't sit in legal. Privacy needs to have a holistic approach taken to it in terms of its governance because different aspects and different segments of the dinbock wheel will affect your privacy posture going forward. Again, going on Dennerty and Finnerin we have this model for governance and stewardship. They produce this mind map diagram and they're both privacy engineering. The privacy engineers manifesto. What we have here are the requirements stewards, the data collection stewards, the data use stewards and the data governance requirements stewards. And I just tagged them as being deciders, definers, doer definers, and coordinators. Over here we have the people who are usually traditionally in the legal department up at the top left-hand corner defining the purposes, the formal rules and regulations that need to be considered and feeding that into the governance structure. You have your data collection stewards, the people who are working with data on a day-to-day basis who need to understand what they're doing with it and work with it. And then you've got how you actually put people in the position of being able to use data with user experience requirements, reporting requirements and generally how we design things so that people actually want to work with them so they don't work around them and put everything in a spreadsheet and send it out by email which is just quite possibly the worst thing you could ever do from a privacy perspective. And then down at the bottom right-hand corner we have the requirements stewards. We're a coordination role and this is the data privacy function in the organization which is the officer in chief data protection officer. This is a key role that's coming forward in a lot of jurisdictions now, the data protection officer who is accountable for the system for governance under the draft data protection regulation which we're expecting to see in a few weeks' time. That data protection officer is either going to be on the executive board by law or will have to report directly to an executive. So it's C-level or close to C-level reports and they also must be fully independent in the performance of their function which is pretty cool because that gives you a lot of strength and power and there's a caveat to that though which is that you have to have particular technical and business skills and understand technology, understand data privacy laws but one of the sweet news for everyone is that there's a statutory 10-year element to it which is that under the EU data privacy regulation the data protection officer once they're appointed has to be in the job for a defined period of time in the legislation and that threshold is being defined at the moment and we've finalized but the only thing you can be sacked for is not doing your data protection officer well and the key part of your data protection officer role is of course making sure the governance is in place, making sure that the quality metrics or privacy are in place, making sure the architecture supports privacy and making sure that the databases and data management systems on your data development is privacy supportive and that's just those elements of the DIMBOK wheel, we're not getting to talk about metadata management, reference data management, document account management, security or all that other good stuff today. So very brief final concepts. Privacy by design is a new concept that's kind of emerging or has emerged recently in the privacy space with the philosophy of systems engineering that takes privacy into account throughout the whole requirements engineering of systems engineering process. There are seven guiding principles for building privacy in to how you design systems. But I'm a little bit cynical, it's just quality management applied to privacy with privacy being a critical quality characteristic because ultimately it's the classic deming quote you can't inspect quality into a product, the quality is already there by the time it's inspected. So privacy by design is useful and it's a very useful way philosophy to bring into things like your data development, your design of data models, your design of architecture, your design of your information security functions, etc. But it's not a be all and end all thing in itself. Key principles here, and again you can google privacy by design and find these principles yourselves, key one thing is proactive not reactive, so again designing your data models designing your metrics, designing your support privacy, privacy by defaults, privacy embedded into your processes and functions, not as an afterthought, how can you bring those principles into your data development through the dim block. End to end security, and a key one down here is the idea of user privacy, keeping it centered on the user keeping it centered on the customer. That's essential, that brings it back to the idea of the information and process outcome and the customer's expectation of privacy that we talked about way earlier. I'll talk at the beginning of this webinar how you need to align and architect your data development development to your data architecture, data quality, data governance, etc. to support that, and we can do that using the existing frameworks of the dim block. In terms of privacy engineering, another new term the disability ensures gathering an application of privacy requirements has the same importance as other functional requirements, so again the processes to make sure that the privacy requirement is as important as other things is a key element. So it's about moving it into the systems development life cycle, which is a key element of the data development to main in the dim block. Privacy engineering is what I call the glue that makes privacy by design operative and operational. It's just basic engineering principles and quality engineering principles apply to information that privacy involves quality characteristics. A quick diagram illustrating the high level concepts of privacy engineering. You've got the goals of the individual and the goals of the enterprise at the top. It becomes policy, which feeds requirements, which becomes policy procedures, privacy awareness training and then develop mechanisms to support privacy, which exists in the context of quality assurance framework and is subject to continuous improvement or should be in your organization. That's what you're trying to build which is classic quality management applied to information as an asset and the mechanisms and tools we need to do that are all defined in the dim block. So ethical information management, while we have a few minutes left to introduce this concept my company produced a white paper on this a few weeks ago. What we have as we move forward with privacy legislation is always going to be the floor, not the ceiling. It's going to be the minimum standard that a regulator expects. It will be the minimum standard that your customers expect. Increasingly, we're going to have to start looking at how we manage information more ethically and there are two strands to this. There is the ethic of society. Society's ethic influences the customer, influences the company and the organization through the feedback of the customer. When people complain to your call center or to your IT teams or to your marketing teams those complaints are gold dust letting me know how well you're working in terms of the ethic of society. Regulations and laws come in at the top in terms of how you're strategically managing things and how you influence your governance structures for business information and technology so that you're compliant with those laws and regulations. They're also coming through standards and code ISO 29100 similar standards being at the technical management level in terms of your architecture and planning for how you meet these ethical standards that society is looking for. Of course, the organization itself influences ethics too, has its own ethics and its own way of doing things. Google famously doesn't want to cross the creepy line so they keep moving. The creepy line they don't want, they don't be evil or in the past their routers don't be evil. Organizations influence society through lobbying, they influence society through the contribution to standard practices and standard practice frameworks. Increasingly and quite significantly organizations influence the customer's perspective on their societal ethic by educating people. This goes back to the idea of obtaining data fairly. Telling people what you're going to do with their data, being open and upfront about it and explaining to people how that is going to work is one of the most powerful ways of aligning your organizational ethic with society's ethic to make sure that you're consistently meeting or exceeding the expectations people have of the process and information outcomes that your organization is going to be delivering in the context of privacy. It's really important that you take the time and effort to try and figure that out and strike that balance and DIMBOK gives you a framework where at least you can be having those discussions in a structured way, albeit in the context of a particular domain. How do we do data modeling in a way that's ethical? We can start asking questions in our development of our data models and asking why over and over again to help us improve the quality of those models. Why do we have that data? What are we doing with that data? Who is going to access that data? Can we encrypt this data? Do we need to encrypt this data? What happens if we encrypt this data? Is there a trade-off between which might be your organization's internal ethic and keeping it safe, which might be society's ethic? These are things we need to be balancing going forward. Okay. With that, ladies and gentlemen, thank you very much for your attention. Any questions? Thank you so much for this great presentation and informative presentation, certainly very important. Of course, the most popular question that we receive is people who use the slides in the recording. I will send a follow-up email within two business days by end of day Thursday with links to the slides, links to the recording and anything else requested throughout the webinar. We've got a couple questions coming in for you. As a consumer, when you provide data sharing explicit consent, e.g. for marketing activities, opt-in for a group and this group later on acquire another company, is your consent extended implicitly to this company under EU regulations? It depends on the terms on the specific terms and conditions of the basis under which you originally gave that data, so your consent may carry over. Then again, I've advised a number of organizations who've been doing mergers and acquisitions and often, again, going back to the idea of the ethical approach, if you're buying a company and you're buying their assets, talking to their customers is often a very good idea. There have been a couple of cases, litigation cases in Europe and in Ireland in particular around companies that have done into liquidation that there were being wound up and their assets were being bought and how communication to the customer should have been done or needed to be done and it often was down ultimately to talking to the customer. In that context, if you are the customer of an organization who has bought another organization that from a legal perspective the consent issue doesn't really arise but if you're a customer of the organization that has been bought then certainly some communication would be useful to let you know what's happening and to give an opportunity to refresh any permissions you may have given in the past. And again, when I'm finding with clients, we're open and upfront and transparent with people. We'll find with clients but also we've got a lot of research data on it as well. Despite what people would say it actually pays to be open and transparent your conversion rates are a lot higher for getting people to sign up and for getting people to roll over their permission to be marketed to if you are just absolutely upfront with people about what's going on. Very nice. Now one of the most important questions of course is where can I obtain a copy of the DMBock? You can buy the DMBock on Amazon and you can buy it through the demo website as well. And we also have a copy of it on the University Bookstore and any word on the DMBock 2.0? I am not part of the DMBock 2 process. I know that there is a series of reviews ongoing at the moment to make sure that it's ready for prime time and I am not party to those discussions so I can comment on them unfortunately. We're always inquiring. I know it's an exciting project coming through. It's pretty quiet out there. Please go ahead and submit your questions if you have any. What is the one area you covered it a lot of course but what's really the one area that most people are getting in trouble? The area that causes most problems at this point from the organization we're advising is people don't stop and consider the life cycle of information. So the plan obtained, store, share, maintain, apply, dispose, life cycle is a critical component in terms of how you think about what you're doing. And in that context then it's going back to the example I gave earlier on of how you design things like your forms, how you design your processes, how you design your data modeling so that you don't paint yourself into a corner and you're not able to do stuff with data that is perfectly valid but also that you don't run with scissors and do something horrendously stupid with your data when you thought you could but you couldn't. An example I would give is a client we audited a few years ago who had invested in a name value pair database architecture which was perfect for analytics and they were using it in their marketing function and from an analytic perspective it was fine. It was a very nice fast way of doing their analytics however they were using it to drive their permission and consent for marketing as well but it was almost impossible to audit it and it didn't have audit trail, it didn't have necessarily the level of robustness we would want from an update maintenance so when customers were changing their preferences the interface between the web frontend and this name value pair system kept breaking down so they were getting problems in terms of the accuracy of their marketing suppression data which meant they were having to suspend marketing campaigns on an ongoing basis which was costing them a heck of a lot of money and the root cause of that was they didn't sit down to think about what they needed for different things and they were using the wrong technology for the right problem. Does that make sense? Yes, absolutely. Everyone's pretty quiet today I think so that's the end of the questions but again just a reminder I will be sending out a follow-up email within two business days containing links to the slides, links to the recording of the session and Derek thank you so much for taking the time to give this great presentation while you're traveling. Actually we got one more question coming in just let me squeeze it in here more and more as our organization outsources application system development we seem to be losing the ability to enforce data confidentiality designations and protections. How do we address this? Can this aspect of data design get this aspect of data design under the same control? That is a governance issue and your requirement there is your contracts under YULO if you're using an outsource partner or anyone who's processing data on your behalf who has access to your data you are required to have a contract which binds them at a minimum to having the appropriate organization on technical controls to protect the security of the data under the draft data protection regulation when it comes out any of those processors who are working with your data who step outside the bounds of what you can ask them to do they will in turn be liable as data controllers so they're facing 5% of global turnover penalties but this comes down to your contract going back to the idea of there being multiple actors in different perspectives from a governance perspective this is where legal need to get their pencils out and they need to write in some very very strong we're going to take your heads off if you screw this up closes into contracts and we do that for clients we do as a service for clients for our clients we have standard data processing agreements that are part of their outsourcing to who is doing development work for them or actually working with data and providing managed outsourced services around data and they're pretty much we will take your house if you screw up and we negotiate back from there the problem we've had historically is that this has not been seen as a critical issue and it isn't necessarily given the attention it requires in traditional procurement processes and that is a major weakness and a major risk in organizations but it's the one data management when the lawyers are actually the right people to have in the room very good again I so just going to wrap it up and say thank you so much again especially since you're traveling and though I know you're always traveling but certainly I would that with the time difference really appreciate your time today for this great presentation again very informative and very important information to know I'm welcome and thanks for attendees for everything that you've been engaged in and for attending today especially I'm going to give a shout out to our Australian friends who get up in the wee hours of the morning to attend these sessions I hope everyone has a great day