The GDPR automation process is designed in the base on the legal framework and the best practices that the regulation recommends to comply. The main scope of automation of GDPR is to help our corporate customers to better align themselves with the new EU regulation of the GDPR. The first step in the design of the data management process is discovering the data, relationships, and rules of business logic. So as the spine of this system will serve the organization module. This module will store data starting from basic information such as their name, headquarters address, website, contact person and other detailed information related to the GDPR legal framework.
For further information, the GDPR legal framework Article 30 places a legal requirement on organizations to maintain a record of processing activities under their responsibility, and make it available to the relevant supervisory authority on request. For this purpose is needed a module, processing activities. The module processing activities will represent the register of all the databases treated by the organization. The set of data that they process and store into their organization will be only a record which will contain all the databases or data treated.
All the processed data by the organization are analyzed and classified into categories like human resource data, research and development data, clients/suppliers data or other particular data. The personal data categories module will contain all the data categories that one company process. In other words, all the databases are divided into n personal data categories, which is a one to many relationships. One personal data category class will contain the databases that are being processed, for example, the human resources data categories will contain employees, health, CV candidates information, etc.
To speed up the data retrieval process the register of databases is denormalized in function to the generation of the automatic templating system and also used in other modules that will be presented in the following section. The denormalization of data, in this case, will improve the retrieval of the data from different modules related and through them we will be able to create expressions and workflows to merge data from related modules more easily.
In terms of business logic is important to properly define them because it gives a framework not only about the responsibility classes but also through them we define the access control of data for each employee that is included in one of these personal data categories and eventually all the data that the respective categories can see, edit, store, process or cancel.
The module Employee will represent all the employees of the organizations that have agreed to do the compliance regulations with us. In this case, employees are the dependents connected with the organization's account. So the relation organization-employee is one too many relationships. The article 37, 24, 32 of the regulation places legal requirements into appointing internal/ external figures for roles of DPO, system administrator or data controllers. The employee module is logically designed also to save information about the roles and responsibilities of the employee that are represented with checkboxes inside the module.
The module employee is expected to save also the access control level of data that one particular employee is supposed to access. So between personal data categories and employees exits a one to one relationship which means that to one dependent is mandatory to appoint only one personal data category. Using the denormalization of databases On save, a workflow is triggered, and in the background will save the name of the personal data categories for this employee.
Third-party module is used to store the external data processors subjects who do a specific activity in the organization as an outsourcer, for example, a company that offers service to the client as a financial advisor or information technology consulting services. So one organization can have n-third parties records connected with her which is a one to many relationships. The third-party module is designed also to be connected with the main processing activities record of the organization for the purpose to define the databases that this third party have access to the process, see, modify or delete
ER Diagram
Threats Measure module is logically designed to store information regarding the security measures undertaken by an organization. This module has a one to one relationship with the Threats module, a module created to classify into threats categories each measure applied. Measures are created as multi-selector fields who contain information about physical measures at the office, the protection measures of information systems, personal working station threats measures and threats measures on data accessing. Using system validation and CRM functionalities all the threat measures will be divided into different categories of threats and mapped to the corresponding text area fields in the module Threats.
Cities Module is a new module developed that will store all the headquarters of the main organization. It will have a 1 to many relationships which means that one organization can have one or more headquarters. Also, the cities modules will be connected with the module's physical areas.
The records created in the physical area module will store information for each room or server located in one specific headquarters of the organization. This module is designed to save information even for all databases that are accessible and the measures applied to the type of physical area. The system will create three types of physical area rooms, servers, and cloud services.
Gendoc Modules
The module Merge Labels is a specified created module that determines the related information you can merge inside the template, as field labels. This extension ins will list all available fields for each module described above and their internal name so they can easily be used into OpenOffice template documents.
Generate Documents module is created to generate different types of documents for a specific organization. The generation of documents it is based on GDPR automated templates and each document has his unique template.