## 2 Materials and Methods
### Educational Warehouse
#### 2.1.1 Basic System Architecture
It can also be managed securely by employing secure connections, such as Secure Shell (SSH), Secure Socket Layer (SSL) or Virtual Private Network (VPN). Regarding data management, data registries can be transferred entirely and removed from their origin, just as data from users that have not offered or consented to processing their data can be excluded as well. In the LMS or EdTech, the educational warehouse administrators may not have management competencies. However, they may demand the same good practices to ensure PICSDMPD or other more convenient ones. For instance, in the Moodle LMS, some of the authors managed to encrypt the user table since most of the personal data reside there and used a set of views that allow decryption or encryption at convenience. This measure can be complemented by ensuring students' anonymity through second identities with the Protected Users plugin [32], thus not exporting data that can be used to identify people. The entire database can also be encrypted with a double user control system where not even the administrator can access or decrypt the data. Some of the authors of this paper conceived such a system and named it AuthChecker [35]; simple authentications, private and permissioned Application Program Interfaces (API), and Learning Tools Interoperability (LTI) technologies are recommended to ensure data access by manually specified roles. * LRS: This is the module where data are stored. It contains all that software and hardware needed to store the data in the original format or as the result of transformations and analyses. The private and secure nature of data can be guaranteed by defining temporary and regulated accesses, with users generated by a previous contract with the institution; by storing encrypted data; by or applying change control protocols (integrations through high-level log systems, definition of non-editable data, etc. ), among other practices. * DIV: This module analyses and visualizes information internally. It contains all the software and hardware in charge of performing the institution's analytical approaches and the data visualization tools. Information given to those systems can be pseudo-anonymized or anonymized. Their response, being equally masked, can be integrated into the LRS module as far as no correlation of data with real identities is guaranteed. Modularity allows LRS to be hosted locally while DIV resides in cloud computing, making it necessary to encrypt the roaming data or to even use private connections such as SSH, SSL or VPN. * DAI: This module controls access to data according to legal regulations. It contains all the software and hardware that permits internal solutions and other educational institutions, government and administrations, partners and third-party collaborators to access data under a private and regulated regime. At the same time, it could serve as open data for public benefit. It manages access to the information securely. A set of essential, contractual permissions can be defined automatically in the user creation process. This is the case of accessing one's action history or the acceptance or rejection of data transfer agreements. Each user profile may request an extension of its capabilities under a manual review process; this process may generate a set of legal bonds that will detail the relationship between the user and the system. The reviewers, i.e., the data privacy officer in the case of GDPR, may reject the request. A set of permissions that do not require an extensive legal bond can also be offered using under-request automatic approval procedures, allowing easy access to research data and collaboration for open data consortiums. Stakeholders play an essential role in the design of the architecture of the system. They somehow help to shape it in terms of data access.