Hi and welcome back to the IAAP CIPM. This is Course 6 and this is about documentation. My name is Rafael Brian. It'll be a pleasure to talk to you about documents. Now, you probably think there can't be anything more boring than just talk about different types of documents. But actually, I think this is where a lot of the problems start within organizations, especially when we start to talk about accountability. One of the things that privacy law, we start to talk about across the globe is accountability; documenting what you do. Actually being able to prove in evidence that you've complied with the law. We're going to start by looking at types of documentation. I want to cast your mind back to our case study; Med Force 1. I just want to think about exactly why writing a document and how to write a document might be useful. Now this sounds ridiculous, isn't it? It sounds counter-intuitive. Let's write a document on how to write a document. It sounds the height of absurdity, but if we don't document how we're going to document, everything else is going to fall apart. There's going to be no consistency in the way that we communicate. I think that's what documents are really about. I think less about the fact that I'm writing as much as I can or I'm thinking who is my audience and what I'm I trying to communicate to them and how am I communicating that in the most effective way? Often we forget, I think over time our understanding of documentation is changing and I would say for the worse. If things have got a lot more informal and whilst informality is not necessarily a bad thing, we've lost some of the definitions I think that actually make documentation useful. First, we're going to start by looking at the difference between a document and a record. I think documented information versus records management, I think is quite interesting place to start. Now, there are records management experts I highly recommend you go and talk to to actually manage your records. That's actually where we're going to find a lot of the personal data. Records, to me, is evidence. It's evidence that some process has been carried out. It's your customer file, your HR staff, your visitors' logbook, a call recording. To me, a record is an evidence that something has been carried out. It's a changeable, digital, or manual, live; could be structured, could be unstructured. But the idea is this is the thing that's going to be changed. That's going to be updated, that's going to show you exactly how we've carried out, what you've carried out, and this is evidence about how that has been carried out. How you do it however, that's going to be in our documented information. I find these documents are rarely changed or more static certainly. The idea is to communicate some information over to this set of stakeholders. I think it's pretty important to understand who those stakeholders are and what they need communicating to them. Now, I hate to do this because I know I've got mostly American audience on this. But one of the things I talk about with that American audience is, well, there's tension a little bit of Americanization that there tends to be the word policy being used for every document. There's nothing inherently wrong in that. I see things called privacy policies all the time, but are they really a policy? I think it's important to understand the difference between policies, procedures, standards, guidance, notices, and what the content should be for each one. Really the reason why this is included in the course is it's really about effectively communicating to different groups. If we go into confuser groups by having different content or mixed up content in different documents, people are going to get confused very easily. I think it's worth talking about the difference between different types of documents. There were more documents than this I'm sure. But I'd like to really start, we'll talk about the difference between a policy and a procedure. A policy, to me, it's a much misunderused term. In fact, Americanization of the word policy tends to mean all documents. Actually, we tend to call any document a policy, but I'm going to slightly differentiate from that and say that a policy is a specific type of document. Really, the policy should be signed off on by the senior management. That's what it is. It's an aspirational piece of work that really tells the business what the senior management wants. Now, a policy doesn't have to contain any detail. It doesn't have to tell you how will you do it. To me, it's a more aspirational document. It could be short, one-page document. Sometimes they can call a vision or mission statement. But the idea is it goes up on the wall and says this is our general approach. This is what we want to happen, probably it doesn't tell you how it does. You can delegate the how to lower levels of management. But all the management wants to say is, this is the end goal. This is what we want to occur. These are this aspiration. In terms of data protection or privacy policy, what I'd expect to see is not what we historically think of as a privacy policy, but a one-page statement that would go up on the wall that would say: we the management want to do good things, we the management will protect your privacy, we the management will train our staff, we the management will operate a privacy management system, we the management will comply with the law. It's that aspirational words. The words will. Then it's up to the management to then sit down 12-18 months from now and have those aspirations being completed. You have all those will statements being realized. I think when we think of a policy we start with the word will. Difference then to procedure. Procedure is then a much lower level document. To me, a procedure document is a process, it gives individuals a way of getting from A to B, completing request form or dealing with someone over the phone. To me, procedure documents are some sort of process, a way of getting from A to B. A set of steps. To me, procedure then instead of using that will aspirational term, well, you can't be aspirational. You've got to tell people exactly what you're doing and exactly the steps to take. It should be a shall or a must, a mandatory document. I find that's where the problem comes in, a lot of the way we communicate, is that we mix command words. I think that if we mix command words, we risk confusing the individual, we risk confusing the reader. There is a difference between an aspirational document, a mandatory document, and a non-mandatory document, not mandatory. It means you can take someone like a guidance document for example, this is your non-mandatory, it's optional. But then instead of shalls or musts, we see shoulds or mays. The idea is to separate those command words. We have documents with guidance which are non-mandatory. We have documents with mandatory words and documents with aspirational words. I say that's the difference from a policy or procedure and a guideline, you have your mandatory, your aspirational and your optional. The reason why we need to separate that is I think we need to be clear on what's an instruction, what's an idea, a concept or what's a nice to have. If we're mixing shoulds and shalls or woulds and coulds and it be nice if you and sometimes and you must within the same document, then I think your staff could run your term around you and go, we want clear? You didn't explain to me what was mandatory and what was optional and what I had to do and what was a nice to have. I think more formal way of documentation which you may consider a thing of the past, perhaps, will actually save you when it comes to things like shoot the stuff, we've done it or not? Should an individual have gone through a rigorous process or not? Should this have been a formal thing or an informal thing? The worst thing I see in data protection, and you will need to know this for the exam, is the difference between a privacy policy and a privacy notice. Now, everybody knows when they go and browse the Internet, we've seen the word privacy policy across the Internet. A privacy policy across the Internet and a privacy policy, they don't actually mean a privacy policy. I've already said a privacy policy is a management aspirational statement that says, we will train our staff, we will do good things in data protection, we will look after your rights. No. When you go on the website and you see a privacy policy, what they actually say is actually they do subject individual way of communicating to you how we process the data. Very different document. Very different document than what I said a privacy policy was, but everywhere you go on the Internet, you will see privacy policies out there that aren't privacy policies. They are actually what we call a privacy notice. Yeah, a privacy notice. Now this if you're in the GDPR land, this is your idea about being transparent. We'll talk a lot about being transparent when we get to individual rights later on. But the requirement is to be transparent, is to tell people how we are processing their personal data. No legal document of any kind. You're literally saying, look, we're collecting your personal data. We've got to be transparent about that. We're going to tell you why we're going to use it and what rights you have and all of the great stuff that you have. That's a privacy notice. I want to differentiate especially for the purpose of the exam, a privacy notice that's about you being transparent to the individual and a privacy policy that you as an organization telling your stakeholders, your general aspirational approach to how you're going to manage privacy. Two very different documents, but you will see privacy notices, cold privacy policies, in my opinion, erroneously across the Internet. I think I just want to finish this first section by talking about specific document types that you might need within a privacy program before we go on to how we actually manage the documentation in the next steps. Specific types of documents you might say, you will definitely need at the top, think about this as almost like a hierarchy. You will need a privacy policy at the top. As I said, this is your aspirational. We the management want to do good things in data protection. All things should flow from that document if you like. All of the other documents are just enabling you to achieve that policy. Underneath there you'll need your transparency statements or privacy notices. In another words, these are the information you give to the individuals. Tell them how you're going to process the data normally at the point of collection or soon after. You might need documentation around acceptable use. This is how you are going to make sure that individuals who do use your IT assets are using them in a way that is acceptable to you. Note you are not asking them if it is acceptable, you're not saying by citing this you accept that. All you are doing is saying, this is what is acceptable and what is not acceptable. A Cloud computing documents as well. We often see a Cloud computing acceptable use document these days. This is the problem that many people can go out and just sign up to three services on the Internet now, Survey Monkey or a Google Mail accounts and move personal data to places it wasn't supposed to be. You really have to be clear with your staff, who can't and who can commission your personal data into Cloud computing provider environments. You might need media documents. Who can deal with the media, who can go out and talk to the press, who is authorized to talk to weak sets of stakeholders? You need a risk documentation, a rights documentation about how you deal with rights or requests. You're going to need documentation around how you deal with your second parties, your vendors, your processes if you like. How you go about procuring a new service. Then dealing with the data itself, you're going to need all sorts of policies and procedures here. In data classification, handling, retention, disposal, information security you name it, anonymization encryption. The amount of documentation you have is going to be entirely scalable with the level of organization you have. Simple situation requires a simple solution and the opposite is also true. Large organization, you're going to require larger amounts of documentation. I think that's where we're going to go to in our next session. Our next session is about actually managing all that documentation that you produce. Thank you.
