Nexus sees the EU's general data protection regulation (GDPR) as an important step forward in streamlining and unifying data protection requirements across the EU. We also see it as a great opportunity for us to strengthen our clear commitment to data protection principles and practices. It is as well fully in line with our recent ISO 27001 certificationcertification in Sweden.  

Nexus strives to make it as easy as possible for our customers to comply with the requirements of GDPR, which will begin on May 25, 2018. Therefore, a number of new features are included in the latest and upcoming versions of Nexus PRIME. We will also continuously review the functionality of Nexus PRIME in terms of GDPR.

Implemented functionality

The following functionality is implemented in PRIME 3.7, to help you to be compliant with GDPR:

Traceability

The User Self Service Portal (USSP) in PRIME can be configured so that the user can login and see all his personal data. Also a PDF report can be configured so that all relevant information can be printed out on demand by an operator via PRIME Explorer.

Availability

Access to any data in PRIME always requires an authentication on the runtime system (PRIME Explorer or PRIME USSP). PRIME offers different methods for authentication, like basic password authentication to an internal database or to external user repositories like LDAP/Active Directory but also more sophisticated strong authentication with multiple factors, for example, with smart cards/certificate or SSO via SAML.

The access rights are restricted via corresponding roles in the system. The standard roles can be adapted and extended according to the customers’ needs, so operators/users will only see data that they are responsible for/have the need to access. The limitation of access to user data is done via permissions search filters and visible processes.

Correction

PRIME is typically not a standalone solution but integrates with a number of subsystems/data sources in the customers’ environment (for example, HR systems, User Repositories, PACS systems, Follow-me Print, Canteen, Library etc.). Therefore it is important to define which system is the leading system for which data object. For user data typically a User Repository (HR, AD etc.) is the leading system. Therefore the correction of users should be triggered by this User Repository towards PRIME. In the same way PRIME will have to trigger correction of card information based on an agreed rule set towards corresponding sub systems.

The connected systems as well as the rule set for correction has to be identified, defined and agreed upon.

Security

All runtime data of PRIME is stored in the PRIME database. No data at all is stored on the PRIME clients. On the PRIME server, a small number of configuration files is stored, to define the overall behavior of the environment, for example, log level of the error log, and also the connection URL to the database. The database connection file can be scrambled so that the login credentials to the database are not visible for the Server Administrator.

The runtime data in the PRIME database is mainly stored in plain text. PRIME in general provides the possibility to encrypt data fields, for example, for sensitive data like PINs or passwords. The encryption itself is based on a hybrid algorithm (RSA/AES).

The encryption certificates will either be stored on the application server or optionally in a Hardware Security Module (HSM).

Furthermore, the customer can also activate encryption mechanisms that are provided on the database layer (for example, MS SQL or Oracle).

Removal

PRIME provides functionalities to delete data objects: a process can be configured for manual deletion (by an operator in PRIME Explorer). Rule-based deletion can also be done by Timer processes.

PRIME integrates with a number of subsystems/data sources in the customers’ environment, for example, HR systems, User Repositories and PACS systems. Therefore it is important to define which system is the leading system for which data object. For user data typically a User Repository (HR, AD etc.) is the leading system. Therefore the deletion of users should be triggered by this User Repository towards PRIME. In the same way PRIME will have to trigger deletion of card information based on an agreed rule set towards corresponding sub systems.

Object history can not be deleted today. The history will not be visible anymore on the user interface as soon as the corresponding object (for example, Person or Card) is deleted, but the history is still present in the database. The reason for this is the chained signature: if single history records would be deleted, the signature would be corrupt. Nexus is currently working on a staged signing/deletion of the signature. This means that a new signing thread is started on a regular basis (for example, once a year), so that step by step the history can be removed. 

Important notice

A major part of GDPR is about internal routines. Organizations are responsible for personal data, regardless of whether it is a HR system, CRM system, security system, PACS system, real estate system or other. Each organization must ensure that staff handle personal data properly. This includes, among other things, having a legal basis for processing personal data, keeping track of the personal data being processed and the context in which to handle only the information necessary for the purpose expressed, deleting data when no longer required, and to inform and, where necessary, obtain consent from registered persons.

Please also observe that the GDPR acknowledges that data protection rights are not absolute and must be balanced proportionately with other rights – including the “freedom to conduct a business”. For more information on the ability of EU member states to introduce exemptions, see the section on derogations and special conditions.

As a regulation, the GDPR will be directly effective in EU member states without the need for implementing legislation. However, on numerous occasions, the GDPR does allow member states to legislate on data protection matters. This includes occasions where the processing of personal data is required to comply with a legal obligation, relates to a public interest task or is carried out by a body with official authority. Numerous articles also state that their provisions may be further specified or restricted by member state law. Processing of employee data is another significant area where member states may take divergent approaches. Organizations working in sectors where special rules often apply, for example health and financial services, should: (1) consider if they would benefit from such special rules, which would particularize or liberalize the GDPR; and (2) advocate these accordingly. They should also watch for member states seeking to introduce special rules, which may prove restrictive or inconsistent across member states.