GDPR Compliance

The new General Data Protection Regulation (GDPR) is set to replace the Data Protection Directive 95/46/ec effective May 25, 2018. The GDPR is directly applicable in each member state and will lead to a greater degree of data protection harmonization across EU nations.

Although many companies have already adopted privacy processes and procedures consistent with the Directive, the GDPR contains a number of new protections for EU data subjects and threatens significant fines and penalties for non-compliant data controllers and processors once it comes into force in the spring of 2018. It not only affects companies within the EU but those who trade or exchanges data with someone whose data might contain those of an EU citizen.

With new obligations on such matters as data subject consent, data anonymization, breach notification, trans-border data transfers, and appointment of data protection officers, to name a few, the GDPR requires companies handling EU citizens’ data to undertake major operational reform.

Data Processor, Data Controller and Data Subject

In its effort to protect and expand the rights of data subjects, the GDPR creates clear lines of accountability over data processing. This is especially evident in the way it delineates responsibilities between “controllers” and “processors” for handling personal data.

The GDPR expands significantly upon the controller’s responsibility for processing activities and sets out specific rules for allocating responsibility between the controller and processor.

The Regulation’s more detailed requirements for controller-processor contracts may compel some data controllers to reassess their vendor agreements to achieve compliance. Processors not only have additional duties under the GDPR, moreover, they also face enhanced liability for non-compliance or for acting outside the authority granted by a controller. Nonetheless, the burden for personal data protection under the GDPR still rests primarily with controllers.

The GDPR defines a controller as “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.” The controller, therefore, is the entity that makes decisions about processing activities, regardless of whether it actually carries out any processing operations.

Article 24 makes controllers responsible for ensuring that any processing activities are performed in compliance with the Regulation. Controllers must “implement appropriate technical and organisational measures” not only not only to ensure compliance, but also to be able to demonstrate the measures that they have in place.

Controllers also have specific responsibility for:

Carrying out data protection impact assessments when the type of processing is “likely to result in a high risk to the rights and freedoms of natural persons” and implementing appropriate technical safeguards.

Assuring the protection of data subject rights, such as erasure, reporting and notice requirements, and maintaining records of processing activities.

Duties to the supervisory authority, such as data breach notification and consultation prior to processing.

While the Regulation imposes these heightened requirements on controllers, it is important to note that it also relaxes one of the requirements that existed under the Directive. Controllers will no longer be required to register their processing activities with a Data Protection Authority (DPA) in each member state. Instead, the GDPR imposes strict requirements on controllers to maintain their own detailed records of processing.

Controllers are liable for the actions of the processors they select and responsible for compliance with the GDPR’s personal data processing principles. Under the GDPR, the term “processor” means a “natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.” In other words, while the controller is the entity that makes decisions about processing activities, the processor is any entity contracted by the controller for carrying out the processing.

BrightStarr is a data processor for Unily Clients, whereby the Client themselves are the data controller. The rights and responsibilities of BrightStarr and operational changes to comply with GDPR implemented by BrightStarr as a data processor are documented here. BrightStarr enlists Microsoft as a subprocessor as this is where client data is stored as per all client contracts.

Data Security and Breach Notifications

Personal data” is defined in both the Directive and the GDPR as “any information relating to an identified or identifiable natural person (“data subject”).” Under the GDPR, a “personal data breach” is “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.” This broad definition differs from that of most U.S. state data breach laws, for example, which typically are triggered only upon exposure of information that can lead to fraud or identity theft, such as financial account information.

When a data processor experiences a personal data breach, it must notify the controller but otherwise has no other notification or reporting obligation under the GDPR.

If the controller has determined that the personal data breach “is likely to result in a high risk to the rights and freedoms of individuals,” it must also communicate information regarding the personal data breach to the affected data subjects. Under Article 34, this must be done “without undue delay.”

The process BrightStarr follows in the event of a data breach is documented in the Information Security Incident Management policy.

Designation of Data Protection Officer

Data controllers and processors alike must designate a data protection officer to comply with the new EU General Data Protection Regulation. Under Article 37 of the GDPR, data protection officers must be appointed for all public authorities, and where the core activities of the controller or the processor involve “regular and systematic monitoring of data subjects on a large scale” or where the entity conducts large-scale processing of “special categories of personal data” (such as that revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, and the like, defined in Article 9).

Although not strictly required by BrightStarr, this decision has been taken to appoint a Data Protection Officer (James Heathcote) who had direct access to the Board by way of reporting to the Chief Technology Officer (Sam Hassani). The Data Protection Officer (DPO) has expert knowledge of data protection law and practices.

The data protection officer’s tasks include but are not limited to:

Informing and advising the controller or processor and its employees of their obligations to comply with the GDPR and other data protection laws.

Advising with regard to data protection impact assessments when required under Article 35.

Working and cooperating with the controller’s or processor’s designated supervisory authority and serving as the contact point for the supervisory authority on issues relating to the processing of personal data.

Being available for inquiries from data subjects on issues relating to data protection practices, withdrawal of consent, the right to be forgotten, and related rights.

Data Subject Consent

Consent remains a lawful basis to transfer personal data under the GDPR; however, the definition of consent is significantly restricted. Where Directive 95/46/EC allowed controllers to rely on implicit and “opt-out” consent in some circumstances, the GDPR requires the data subject to signal agreement by “a statement or a clear affirmative action.”

Consent is handled by the Data Controller (BrightStarr’s clients) and therefore no provisions have been made by BrightStarr to handle data subject consent requests. Requests from the data controller can however be made to remove a client’s data upon request.

Cross Border Data Transfers

The GDPR permits personal data transfers to a third country or international organization subject to compliance with set conditions, including conditions for onward transfer. Similar to the framework set forth in the Directive, the GDPR allows for data transfers to countries whose legal regime is deemed by the European Commission to provide for an “adequate” level of personal data protection. In the absence of an adequacy decision, however, transfers are also allowed outside non-EU states under certain circumstances, such as by use of standard contractual clauses or binding corporate rules (BCRs). Derogations are also permitted under limited additional circumstances.

BrightStarr will only host client data in data centres agreed with the client in advance. Beyond this, no data is transferred within Unily to other countries.

Profiling

The GDPR contains many restrictions on automated data processing – and decisions based upon such processing – to the extent they can be characterized as profiling.

Under Article 4(4), data processing may be characterized as “profiling” when it involves (a) automated processing of personal data; and (b) using that personal data to evaluate certain personal aspects relating to a natural person. Specific examples include analyzing or predicting “aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements.”

This definition implicitly excludes data processing that is not “automated.”

Further elaboration of this definition may be found in the Recitals, where the GDPR establishes its jurisdiction over non-EU controllers provided they are “monitoring the behaviour of [EU] data subjects as far as their behaviour takes places within the European Union.” Processing activity involves data subject “monitoring” when “individuals are tracked on the Internet including potential subsequent use of data processing techniques which consist of profiling an individual, particularly in order to take decisions concerning her or him or for analysing or predicting her or his personal preferences, behaviours and attitudes.” This definition suggests that profiling is not equivalent to tracking, but instead is something more, involving the intention to take decisions regarding a data subject or predict the subject’s behaviors and preferences.

Although Unily’s data processing activities do not fall under this category, specific trends within Unily Analytics may be analysed in the future e.g. the journey of pages visited within an Intranet site, but no automated decisions are then based on this. This data is simply provided to the data controller.

That said all user data in Unily Analytics is pseudonymised so any data processing activity carried out cannot be directly linked back to the data subject. More details on this in the pseudonymization section.

Pseudonymization

The concept of personally identifying information lies at the core of the GDPR. Any “personal data,” which is defined as “information relating to an identified or identifiable natural person ‘data subject’,” falls within the scope of the Regulation. The Regulation does not apply, however, to data that “does not relate to an identified or identifiable natural person or to data rendered anonymous in such a way that the data subject is no longer identifiable.”

The GDPR introduces a new concept in European data protection law – “pseudonymization” – for a process rendering data neither anonymous nor directly identifying. Pseudonymization is the separation of data from direct identifiers so that linkage to an identity is not possible without additional information that is held separately. Pseudonymization, therefore, may significantly reduce the risks associated with data processing, while also maintaining the data’s utility. Although pseudonymous data is not exempt from the Regulation altogether, the GDPR relaxes several requirements on controllers that use the technique.

To illustrate the concept of reidentification risk, it is important to distinguish between direct and indirect identifiers. The International Organization for Standardization (ISO) defines direct identifiers as “data that can be used to identify a person without additional information or with cross-linking through other information that is in the public domain.” They are data points that correspond directly to a person’s identity, such as a name, social security number or contact information.

Indirect identifiers are data that do not identify an individual in isolation but may reveal individual identities if combined with additional data points. For example, one frequently-cited study found that 87 percent of Americans can be uniquely identified by combining three indirect identifiers: date of birth, gender and ZIP code. In other words, while no individual can be singled out based on just a date of birth, when combined with gender and ZIP code, the lens focuses on a specific identity.

Pseudonymization involves removing or obscuring direct identifiers and, in some cases, certain indirect identifiers that could combine to reveal a person’s identity. These data points are then held in a separate database that could be linked to the de-identified database through the use of a key, such as a random identification number or some other pseudonym.

As a result of this process, pseudonymized data, unlike anonymous data, faces the risk of reidentification in two ways. First, a data breach may permit an attacker to obtain the key or otherwise link the pseudonymized data set to individual identities. Alternatively, even if the key is not revealed, a malicious actor may be able to identify individuals by combining indirect identifiers in the pseudonymous database with other available information.

The GDPR addresses the first concern in Recital 75, which instructs controllers to implement appropriate safeguards to prevent the “unauthorized reversal of pseudonymization.” To mitigate the risk, controllers should have in place appropriate technical (e.g., encryption, hashing or tokenization) and organizational (e.g., agreements, policies, privacy by design) measures separating pseudonymous data from an identification key.

In Recital 26, the GDPR recognizes the second type of reidentification risk by considering whether a method of reidentification is “reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly.” Such an analysis is necessarily contextual and “account should be taken of all the objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments.”

All user data in Unily Analytics is pseudonymised so any data processing activity carried out cannot be directly linked back to the data subject. All other user data stored in Unily’s content database does not have specific fields pseudonymised but all data stored is encrypted. No additional processing activities take place (other than updates/removals as instructed by the data controller) on data stored in Unily’s content database.

Rights to be forgotten and Data Portability

The GDPR introduces two new rights. First, the regulation codifies a right to be forgotten. This right allows individuals to request the deletion of personal data, and, where the controller has publicized the data, to require other controllers to also comply with the request. Under Article 17, controllers must erase personal data “without undue delay” if the data is no longer needed, the data subject objects to the processing, or the processing was unlawful.

Second, the right to data portability requires controllers to provide personal data to the data subject in a commonly used format and to transfer that data to another controller if the data subject so requests. The right to data portability applies only when processing was originally based on the user’s consent or on a contract. It does not apply to processing based on a public interest or the controller’s legitimate interests.

The GDPR also augments the existing rights of data subjects to receive notice about processing activities, gain access to the information that is being processed, and to have the controller rectify inaccuracies. The data subject’s right to object to processing is broader than under the Directive, moreover, allowing her to object to processing at any time, unless the controller has compelling legitimate grounds.

To keep up with the augmented rights under the regulation, data controllers will have to implement processes for handling and documenting requests from data subjects.

As a Data Processor, BrightStarr will support the Data controller in these requests and to share details as required around data processing activities.

Frequently Asked Questions

What Personal Data is processed?

First name, last name, work email, work phone, mobile, job title, department, location, IP address, Browser agent, device type, profile image, twitterID, LinkedInID, userID. These fields could be augmented with additional fields as specified by the Data Controller as part of configuration of the product. Please note any user identifiable fields are pseudonymized.

What is the purpose of processing Personal Data?

Personal data is stored in Unily to allow users to create User Profile pages about themselves and display this information within the company directory. Users have full visibility of this data and can modify it themselves.

In addition to this personal data is used to track usage of Unily through the Analytics capabilities.

Does BrightStarr maintain a central record of processing activities to demonstrate the performance of those activities in compliance with data protection legislation (currently DPA, post May 2018 GDPR)?

Data is stored within a Microsoft Azure Datacentre in the same legal boundary as the data controllers Microsoft Office 365/Azure Active Directory tenant. Additionally, DR copies of the data is Geo-replicated to a Microsoft Azure Datacentre within the same judicial data boundary.

Are all manual files stored within the organisation, or is third-party data storage used?

Manual files are stored such as signed contracts within BrightStarr headquarters in secure\fire proof storage.

In what format, or in what medium, is Personal Data in Unily backed up or archived?

Data is backed up electronically (Microsoft SQL Azure Point in Time backups with 14 day retention period) stored in the Microsoft Data centre the client’s instance of Unily is provisioned in. Please refer to the Unily HLA for more details.

What penetration tests form part of the security process for Unily? Please also advise how frequently the tests are performed, and what are the latest results?

BrightStarr have external automated security and vulnerability tests executed monthly. Data controllers are invited to perform penetration tests at their discretion by notifying BrightStarr. BrightStarr then work in collaboration with third parties and the data controller to review any concerns if raised, and addressed.

What is the process for keeping up to date with software fixes and patches?

Servers and management client devices are managed using Microsoft Intune and Microsoft OMS. Servers are patched within 14 days of the release of critical and recommended updates from Microsoft and AV updates are installed immediately upon release of definitions.

Who has access to Personal Data within BrightStarr? Who has access to such data from outside the organisation?

Members of the Operations Engineering Team and Support team, authorised project team members. Third parties do not have access to the data controller’s data.

What policies and procedures are in place to detect and deal with data breaches?

Disciplinary processes are outlined in the event of data breaches as part of our commitment to ISO 27001 in our Human Resources - Security Policy which provides details and is made available to all staff through our internal Intranet. The Information Security Incident Management policy defines how we handle data breaches.

How does BrightStarr check that there has been no unauthorised internal access to Personal Data? Please detail your data audit facilities and mechanisms which are in force.

BrightStarr utilise a secure encrypted password vault which is fully audited and hides credentials from end users. Access to data controllers credentials are recorded with originating IP, end user, computer and date and time.

If the client requires, how will BrightStarr destroy Personal Data?

Data is stored in Microsoft Azure, upon request, Microsoft Azure SQL Databases and Microsoft Azure Storage accounts are deleted. Microsoft take the responsibility on ensuring the safety of the data upon instruction to delete. Data backups expire after 14 days as per our retention policy. If additional wiping is required, this can be implemented upon request. BrightStarr action the deletion, Microsoft provide the technologies to implement the deletion.

Are any of BrightStarr’s data processing activities for clients Personal Data carried out by third parties (sub-processors)? Please list and describe all such activities.

Microsoft data centres are used to host data. Microsoft updated their terms in March 2017 to reflect the changes required for the GDPR.BrightStarr conduct a Cloud Service Provider assessment and Third Party due diligence assessment on any vendor we utilise (including Microsoft), this includes due diligence; financial history, market opinion and any accreditations or awards held.

Is there any transfer of clients Personal Data either cross-departmentally, and/or to third parties outside of BrightStarr?

Data is not transferred to third parties by BrightStarr unless authorised by the data controller. Where any lawful requests are made by government or law enforcement agencies, we redirect the third party request to the data controller.

Where such data is transferred outside the EEA, what measures are in force to ensure compliance with the Eighth Data Protection Principle? (E.g. EU Model Clauses, binding corporate rules)

Data is only transferred outside the EEA when the destination territory ensures adequate levels of protection for the rights and freedoms of data subjects in relation to the processing of personal data. Furthermore, we would always gain approval from the data controller and may only be processed for the specified lawful purposes for which the data was originally obtained.

Does BrightStarr provide data protection and GDPR training to the employees in it’s organisation? If so, please describe the nature and frequency of this training, where the training is given, and name those persons responsible for providing the training.

BrightStarr provide continual updates via our company intranet on new developments or changes to practises. Furthermore, we perform annual online training, which is mandatory for all staff to fulfil. Third party consultants have recently conducted training specific to ISO:27001. Furthermore GDPR awareness sessions will be provided to all staff prior to May 2018. Staff records are maintained to identify training requirements.