GDPR:PowerPoint Presentation About the Records of Processing Activities
This free PowerPoint presentation learns:
- Why register your personal data processing activities
- 5 W's
- Business Process versus ICT-Systems
- A simplified business model
- What to register?
- Privacy Operational Life Cycle
- Examples of Controls
- Slide 1: This is where the description of the slide resides. The description can contain links and popup explanations or references to the relevant GDPR articles or Recitals.
Click on a slide to see it maximized in a new browser tab.
Move through the presentation by clicking the blue navigation buttons.
- Slide 2: Hi, I'm Johan van Soest, Certified Information Privacy Manager (CIPM), and currently working as a Data Protection Officer (DPO) for a worldwide producer, seller and logistics provider for household goods. Selling and shipping parcels directly to consumers from the EU makes the company a Controller and Processor handling Personal Data of EEA Data Subjects.
This is what is on the agenda for you...
- Slide 3: In order to demonstrate compliance with GDPR, the Controller or Processor should maintain records of Processing activities under its responsibility. To take account of the specific situation of micro, small and medium-sized enterprises, GDPR includes a derogation for organisations with fewer than 250 employees with regard to record-keeping. Article 30.5 GDPR further explains that if your organisation processes Personal Data that:
you are still required to register your processing activities even if you do not have more than 250 employees.
- is likely to result in a risk to the rights and freedoms of data subjects,
- is not occasional,
- includes special categories of data as referred to in Article 9(1) GDPR or Personal Data relating to criminal convictions and offences referred to in Article 10 GDPR,
Hint: You cannot trick the Data Protection Authorities by placing the Data Protection Officer in a small company to circumvent the number of employees.
Hint: What is considered Processing of Personal Data? Processing means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction (Article 4.2 GDPR)
- Slide 4: Each Controller and Processor is obliged to cooperate with the Supervisory Authority and make those records of processing activities, on request, available to it, so that it might serve for monitoring those processing operations. Not being able to provide an insight into the up to date records can be fined. (Recital 82)
The lower level fine can be up to €10 million, or 2% of the worldwide annual revenue of the prior financial year, whichever is higher (Article 83.4.a GDPR)
Remember that infringements of the data subjects' rights under Articles 12-22 GDPR or non-compliance with an order by a Supervisory Authority (Article 83.6 GDPR) are fined to the higher level of up to €20 million, or 4% of the worldwide annual revenue of the prior financial year, whichever is higher.
- Slide 5: A Controller will specify in its Data Processing Agreement with the Processor that it will do audits. One component of the audit are the records of processing activities. Though a Controller cannot impose fines, it may select another GDPR compliant Processor to reduce risks to the Personal Data it controls or raise a complaint at the Supervisory Authority.
- Slide 6: As a Controller you might need to inform the Supervisory Authority and the Data Subjects of a Data Leak within 72 hours (Article 33.1 GDPR). A Processor will need to inform the Controller without undue delay (Article 33.2 GDPR). The Records of processing activities can assist you in carrying out timely and correct notifications.
Hint: The GDPR is clearly in favour of encryption. For example, Article 34.3a GDPR, frees data controllers from having to notify affected Data Subjects (individuals) about a personal data breach if the controller has implemented protection measures, "in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption." Implement encryption in rest and encryption in transit where ever possible as this can save costly fines and claims after a data breach.
- Slide 7: Risc management is explained in more details later on.
- Slide 8: Before your customers hand you over their Personal Data to you as a Controller, your Privacy Statement must show them at least who you are, what processing is done with their Personal data and how long the data is retained (Article 13 GDPR). If you are unaware of the processes running in an organisation, it is nearly impossible to correctly prepare a Privacy Statement.
To conclude: Even if your company is not legally required to register Records of Processing Activities, it is an invaluable tool for incident and risc management and an information source for your Privacy Statement.
- Slide 9: This slide introduces the 5 W's that help you create an inventory of your processes.
Why ... is Personal Data processed? For example: Client administration, legal obligation and CCTV monitoring
- Slide 10: Whose ... Personal Data is processed? The different categories of persons. For example: Employees, Clients, Suppliers
- Slide 11:
- What ... Types of Personal Data is processed? For example: Name, address, e-mail, x-rays, IP-address, date of birth and criminal convictions. Be aware of the special categories of personal data (Article 9.1 GDPR).
- What ... is the source of the Personal Data? For example: Mailing list subscription, (web) order information or sourced data
- What ... is the legal base of processing? (Article 6.1 a..f GDPR). For example: Consent or performance of a contract
- Slide 12: When ... is the Personal Data obtained and how long will it be retained? Explain what is the reason for retaining data and not deleting and anonymising it.
- Slide 13: Where ... is the location of processing? Does it occur:
Is processing in house, manually or automated or out-sourced?
- in the EEA,
- countries or regions or companies deemed adequate by the European Union
- third countries.
- Slide 14: An example of a business process: the sales department denotes orders, manages customer information, validates stock levels and creates invoices.
- Slide 15: The ICT-Department might be providing warehouse, sales and bookkeeping systems next to file and e-mail servers.
- Slide 16: Any Processing done on ordered or structured Personal Data, even without using ICT-Systems, must be registered if Records of Processing Activities are required.
Reminder: Thinking about a project using Personal Data is regarded Processing and should be presented to the Data Processing Officer so he/she is not faced with a done deal.
- Slide 17: A business process model example
- Slide 18: A business process has input data...
- Slide 19: Output Data...
- Slide 20: May require several ICT-Systems...
- Slide 21: Or just one manual process
The next example will simplify the Business process in that it requires only one ICT-System.
- Slide 22: What to register in the Records of Processing activities? Using the model from the previous slide we can visualise what needs to be registered. Drawn is the Business Process containing only one ICT-System. Should your Business process contain more than one ICT-System and/or manual processes, make a drawing for every system or process in your PIMS (Personal Information Management System).
- Slide 23: A process must be clearly described (remember the 5 W's).
- What is the reason for this processing?
- Where is it located?
- Who is the business owner of this process. Finding the correct business owner is important to jointly define controls. More about controls later on.
- Number of datasets containing Personal Data. Should a data breach occur, you need to inform the Data Processing Authority about the scale of the Personal Data leaked.
- What is the type of Personal Data? Are there any Special Categories of Personal Data stored?
- Who can access the Personal Data. For example: If someone from outside the EEA can access the Personal Data, it is regarded a Transfer. When Personal Data is transferred from the EEA to Controllers, Processors or other recipients in third countries or to international organisations, the level of protection of natural persons ensured in the EEA by the GDPR should not be undermined, including in cases of onward transfers of personal data from the third country or international organisation to Controllers, Processors in the same or another third country or international organisation (Recital 101)
- Slide 24: Any Process gets data that it needs. For example: stock levels, article lists and pricing information.
- Slide 25: The GDPR only is interested in the Personal Data contained in the input data. If the Personal Data is received from a Controller, there is a Data Processing Agreement (DPA) that specifies what the categories of the Personal Data (PD) is as well as categories of Data Subjects (DS).
The legitimate base of processing (Article 6.1.a...f) should be described, as this cannot be changed over time. The information about the legitimate base of processing must be reflected in your Privacy Statement issued to your consumers/customers on for example your website (article 13 GDPR).
- Slide 26: Any process may produce output data such as efficiency figures, profit or loss.
- Slide 27: Again the GDPR only is interested in the Personal Data contained in the output data. Again of importance are: what are the categories of the Personal Data (PD), as well as categories of Data Subjects (DS). The legitimate base of processing must be the same as described in the input data. If the Personal Data will be processed by a Processor or sub-processor, a DPA is required. Special care must be taken whenever the Personal Data is transferred outside the EEA.
- Slide 28: Imagine: Whenever a system containing Personal Data is compromised or a binder of personnel records is stolen, a Data Leak or Data Breach must be reported. As GDPR requires a notification within 72 hours to the Supervisory Authority, a notification without undue delay after becoming aware of a personal data breach to the Controller (your client) and even a notification to the Data Subject, it is of utmost importance to know who and what to report to.
You don't want to damage your company's good reputation by having to print a newspaper advertisement or having your CEO appearing in the news bulletins stating "something happened and we do not know who it concerns.
- Slide 29: A process containing Personal Data must be able to support the Data Subject Access Requests (SAR). An answer to these requests must be provided within 30 days, so it is of utmost importance that is described beforehand how and what Personal Data can be reported, downloaded, changed and deleted. (Article 15..21 GDPR). Not being able to timely support the Data Subject Access Requests (SAR) are fined to the higher level of up to €20 million, or 4% of the worldwide annual revenue of the prior financial year, whichever is higher.
- Slide 30: Registration of access rights to the Process or System is required. Again this registration supports the Data Breach notification as well as improvements to the application security. Register:
An example why registration of the access rights is important in case of a Data Leak: An employee has access to the described system and with the access rights can download information about employees and their wages to a notebook (This is also a process that needs to be described). When the notebook is stolen (i.e. the data leak), the notebook can contain Personal Data about the employees from this system and must be reported to the Data Processing Authority.
- what users or usergroups can access the system or the data contained in the system?
- what are their access rights. Can they read or write/modify data or do they administer the system?
- how is the access secured? Special categories of Personal Data could be requiring a two-factor authentication (TFA) or biometric tool to securely enable access.
- Slide 31: Article 32 GDPR requires that Personal Data is to be protected at the current state of the art. This requires processes to be running using up to date and supported software. This way systems are hardened against hackers exploiting bugs to get access to the Data. The systems and their components must be (monitored and) managed so they are timely updated.
- Slide 32: Whenever and where-ever Personal Data is gathered, there must be described how long it will be retained. Think of the Privacy Statement again. There can also be legal requirements for storing financial information for example. The guideline must be: if the process does not require the Personal Data anymore, it should be deleted. If that is not possible there must be a legitimate base to store the Personal Data. Otherwise anonymization or pseudonymization of the Personal Data can be implemented.
- Slide 33: GDPR indirectly requires auditing of Personal Data mutations as it requires the complete life cycle of Personal Data to be confidential, integer and available (Article 32.1.b GDPR). Audit logs prove:
- who created, changed or deleted Personal Data records or files.
- Who (hacker) or what (virus or ransomware) tried to access the Personal Data but failed or succeeded.
- If data was restored from a back-up.
- if a hardware based data corruption is detected.
- that systems running their own security were not shut down and remained available. This is important because the software can protect it's data, but when the software and server is shut down the data might be accessed on a hardware level bypassing the software based protection.
Hint: this can be resolved by using encryption on the data!
- Slide 34: Audit logs may also contain Personal Data. It is important to describe the users or usergroups that can access, modify or delete the audit logs. The system should log the persons that access and delete the audit log.
- Slide 35: Why is GDPR requiring so much work to register the records of Processing activities? Indeed GDPR requires in their records of Processing activities a lot of information. Much of it is based on the good practice of the ISO27001 and ISO27002 standards and GDPR merely adds the notion of handling Personal Data. The diagram shows the required documentation of ISO27001 in blue and GDPR in green. So most of the documentation, and probably more, can readily be obtained from the Security Officer. As a Data Protection Officer you will only need to add the GDPR requirements as an additional layer. This is also reflected in the ISO27701 standard introduced in August 2019.
- Slide 36: OK, You have spoken with the Security Officer got his documentation and now we have a document with all our Personal Data processing in our company with those nice diagrams ... collecting dust. Once in a while a colleague asks you about his/hers idea of another processing of Personal Data and you add that to the document. A few slides ago the notion of a life cycle of Personal Data was introduced. It is great to have that document waiting for the Supervisory Authority or Controller to show up for the audit, however this document is a great tool to improve on securing the Personal Data of the EEA Data Subjects.
- Slide 37: To reduce the processing risks for the Data Subjects that trust you with their data, you have to implement controls that enable you to improve on the processing every management cycle. For example: In your Data Processing Agreements you describe several security measures to be implemented by your processor. Go check, you have audit rights, if these are implemented correctly or can be improved. More examples of controls on the following slides.
- Slide 38: Implement a Privacy Operational Life Cycle for your privacy program. You can use the well known Deming Cycle of Continuous Improvement (Plan, Do, Check and Act) with consolidation or opt for the full Privacy Operational Life Cycle, using the details of privacy program governance to implement the operations management aspects of privacy through a four-phased Privacy Operational Life Cycle approach: (Assess, Protect, Sustain, Respond) The Privacy Operational Life Cycle is focused on refining and improving privacy processes, rather than a one-time effort.
How to improve every cycle? For example a control can be that a system is using encryption to store (Personal) Data. An encryption method, DES for example, is not regarded as state of the art anymore and must be replaced by a better encryption standard. Your records of Processing activities based on the ISOISO27001 standard show the systems using DES that need to be upgraded.
- Slide 39: Implementing the Privacy Operational Life Cycle continues to improve the privacy of the EEA citizens.
- Slide 40: The next slides show examples of controls that can be implemented on a process. These are only a examples which are neither comprehensive nor exhaustive .
By minimizing the Personal Data that you are processing you limit the risk for Data Subjects in case of a Data Breach. Check if the Personal Data gathered are just enough to complete the processing. If the processing changes, check if you are not asking too much Personal Data.
- Slide 41: This control is a bit more difficult as it requires knowledge of other legislation such as fiscal reporting. Delete Personal Data as soon as legally possible because Personal Data that is not present in a system cannot leak. Should you need data for reporting such as KPI's or Business intelligence (BI), anonymise the Personal Data or do not import it. If Personal Data can not be deleted or anonymized yet, consider pseudonymization of the Personal Data in operational systems.
- Slide 42: Check where you are transferring Personal Data to. For example: since the last check the partner organisation (sub-processor) might have relocated its data centre, started using cloud services or is merged with or acquired by another company. Is the partner still operating in the EEA or deemed adequate by the EU? Perhaps Binding Corporate Rules (BCR) or Standard Contractual Clauses must be implemented (third country)
- Slide 43: Check on the categories of Personal Data. For example: Is the system still using or started using medical information? Have you started processing Personal Data of minors and now are required to get consent that is verifiable given or authorised by the holder of parental responsibility over the child? (Article 8 GDPR)
- Slide 44: Though not allowed, the legitimate base of data processing can be changed. Then you must verify if you need to inform the Data Subjects and if you can still use the Personal Data of the Data Subjects.
- Slide 45: Are the systems still running fully supported and patched software versions. The Security Officer can provide you this information.
- Slide 46: An important control. People will ask IT for extra rights to do their job, however if they change jobs within the company they will not inform IT that they possibly do not need these rights any more. How many security accounts in a company are still present even when employees have left the company? Also check if employees received access to systems by mistake.
- Slide 47: Check if your Data Processing Agreements are still up to date. GDPR requires to implement a Data Processing Agreement with your sub-processor that is even strict or stricter than the ones you received by your controllers. If this is not the case, your company could end up paying the fine the Controller receives when there is a Data Breach at your sub-processor!
- Slide 48: Disclaimer. Please read carefully.
- Slide 49:Thank you for watching.
Please vote and share your opinion on this presentation on Twitter.
| Topic created|| : ||13-03-2019|
| Topic last edited|| : ||28-08-2019|
Scripts and programming examples disclaimer
Unless stated otherwise, the script sources and programming examples provided are copyrighted freeware.
You may modify them, as long as a reference to the original code and hyperlink to the source page is included in the modified code and documentation.
However, it is not allowed to publish (copies of) scripts and programming examples on your own site, blog, vlog, or distribute them on paper or any other medium, without prior written consent.
Many of the techniques used in these scripts, including but not limited to modifying the registry or system files and settings, impose a risk of rendering the Operating System inoperable and loss of data.
Make sure you have verified full backups and the associated restore software available before running any script or programming example.
Use these scripts and programming examples entirely at your own risk. All liability claims against the author in relation to material or non-material losses caused by the use, misuse or non-use of the information provided, or the use of incorrect or incomplete information, are excluded. All content is subject to change and provided without obligation.