Should a Controller commissioning an application receive, together with the application, documentation from the software development company relating to its compliance with Art. 25 GDPR?

ANSWER

The obligation to hold documentation relating to data protection by design rests with the controller. The software development company may –

and indeed should – be involved in data protection by design (particularly in aspects related to security); however, it may not have full knowledge of the purposes and means of processing personal data planned by the controller.

The starting point for implementing data protection by default should be a detailed mapping of the sequence of steps constituting the process to be carried out within the designed application, for example (in simplified form, with reference to the process of processing personal data in connection with workplace bullying cases):

1. reporting of a bullying case,
2. verification of the report by the anti-bullying committee,
3. decision on how to proceed with the report:
   • discontinuation
   • disciplinary proceedings
   • reporting a suspected criminal offence,
4. archiving of documents,
5. disposal of documents.

Each of the above processing operations should then be assessed against the capacity to ensure the data protection principles (Art. 5 GDPR) and the rights (Arts. 12–22 GDPR)

and freedoms (EU Charter of Fundamental Rights) of data subjects. In particular, the assessment of data protection principles and the fulfilment of data subjects’ rights should be carried out by the controller and in accordance with its guidelines, as developers may not be aware of, among other things, the legal grounds on which the controller intends to base processing, the retention periods planned, or any potential transfers of data to third countries.

The software development company should, however, play an active role in the context of security mechanisms implemented. EDPB Guideline 4/2019 indicates in this regard that, in providing IT solutions, software manufacturers should use their expertise to build trust and ‘guide’ their clients at the design stage in creating solutions that respect the rights and freedoms of data subjects.

This in turn means that the design of products and services should facilitate meeting the needs of data controllers. Furthermore, processors and application manufacturers should play an active role in assisting the controller to fulfil the requirement to take account of the ‘state of the art’

and to notify the controller of any changes that may affect the effectiveness of the measures applied. EDPB also recommends that controllers guarantee the assistance of the processor/software manufacturer in fulfilling this obligation through the contracts concluded.

With regard specifically to IT system functionality requirements, a certain ‘standard’ that applications should meet is indicated below; this is not an exhaustive list.

Functionalities relating to the exercise of data subjects’ rights

1. Recording information relating to consent given (where consent is the basis of processing) within system logs:
   1. Who gave consent and what was its content?
   2. When was it given?
   3. What information did the data subject receive when submitting the declaration of consent?
   4. What information was provided about the manner of giving consent?
   5. Was consent withdrawn, and if so, when?
2. Ability to include the information clause (Art. 13 GDPR) when collecting personal data directly from the data subject.
3. Capacity for active retention, i.e. defining time limits after which specified records will be deleted from the system (and from backups).
4. Capacity to delete records relating to individual natural persons
   
   (Art. 17 GDPR).
5. Capacity to restrict individual data records, so that processing is limited solely to physical storage (Art. 18 GDPR).
6. Capacity to export a database containing personal data to CSV format.
7. Capacity to block certain records in the context of ongoing marketing activities (right to object, right to withdraw consent).
8. Recording the date of first entry of data into the system.
9. Recording the identifier of the user entering personal data into the system.
10. Recording the identifier of the user performing individual operations on personal data.
11. Recording the source of data, where data is collected from a person other than the data subject.
12. Recording information about data recipients.

Security functionalities

1. Not displaying system or application identifiers until the login procedure has been successfully completed.
2. Displaying a general warning during login that access to the system is permitted only for authorised users.
3. Not displaying, during login, any help messages that could assist an unauthorised user.
4. Accepting only complete input information necessary for login. In the event of an error, the system should not indicate which part of the data is correct or incorrect.
5. Protection against brute-force login attempts using all possible combinations.
6. Recording failed and successful login attempts.
7. Generating a security event if a potential attempted or successful breach of login security is detected.
8. Displaying the following information upon successful completion of the login procedure:
   • date and time of the last successful login to the system,
   • details of failed login attempts that occurred since the last successful attempt.
9. Masking the display of passwords as they are entered.
10. Prevention of transmission of passwords in plain text over the network.
11. Terminating inactive sessions after a defined period of user inactivity.
12. Enforcing the use of individual user identifiers and passwords to ensure accountability.
13. Enforcing the selection of passwords of adequate quality.
14. Requiring users to change their password on first login.
15. Requiring periodic password changes and changes where necessary.
16. Maintaining a record of previously used user passwords and preventing their reuse.
17. Preventing passwords from being displayed on screen during entry.
18. Storing password files in a location separate from the application system data.
19. Storing and transmitting passwords in a protected form.