We are continuously receiving a number of questions from customers and users.
We have decided that as soon as we have met the same type of questions several times, we'll put it in FAQ.
So far, there are the following:
The customer asks:
Some have asked us if we could not set a deadline, so we, as a Data Processor, report personal data breach out of max. 24 hours. Currently there is "no undue delay".
We answer:
No, we neither can nor will. This is because of a misreading of Article 33 of the Personal Data Regulation itself (see below). The data processor must report without undue delay. And Data Managers must report within 72 hours, but the two time frames are not inclusive, but each has its own sphere. Data administrators have 72 hours from the moment the Data Processor has informed!
The case is:
Here is the text: The EU's Personal Data Regulation, Article 33
Notification of breach of personal data protection to the supervisory authority.
The customer asks:
Is it a shared data responsibility with Musskema.dk, since Musskema.dk itself processes data by, for example, sending anonymous data for research at Aarhus University?
We answer:
No, not at all.
The Subscription Terms and Conditions of Business state the following:
Musskema.dk reserves the right, in conjunction with university researchers, to use statistical data in 100% anonymized form for scientific purposes. This is an option that we have always included in our terms of business and it follows the following principles:
Musskema.dk makes a data extract that is 100% anonymous and can not identify a particular customer or group, as data extracts are selected only on the following parameters:
If a customer does not wish to be included in such a benchmark, one can be exempted by contacting Musskema.dk. Then, the customer will neither participate nor be able to make use of this benchmark.
The short answer is then:
The customer asks:
Missing something, especially in the "Reporting of security breaches" section. Musskema.dk does not provide any contractual assurances that we are able to lift the 72-hour requirement relative to a data burst from them, as Musskema.dk does not guarantee the information kind. 33 and 34 require.
We answer:
No, nothing is missing. Both parts are clearly contained. And Musskema.dk provides the necessary and necessary guarantees.
Please be aware that the data controller's deadline for the max. 72 hours will first count from the notification received from the data processor. Since the data processor must notify without undue delay, and since the data processor merely finds that there has been a violation, this will in practice provide very limited options for staying from the data processor to be aware of the violation for notification to be given.
In Musskema.dk's data processing agreement, it follows that the data processor is required to assist the data controller in fulfilling its obligations under Articles 33 and 34.
Therefore, there are necessary guarantees that Muskema assists in lifting the data controller's obligations.
Additional documentation:
Report on page 496 states that:
As stated in the wording of the provision, the data controller's obligation to report personal data breach to the supervisory authority is activated after the data controller has become aware of a breach of personal data security. A simple presumption that a breach of personal data security has occurred or a simple detection of an incident is not considered sufficient to regard a breach of personal data security as being "done" within the meaning of the regulation. Such a simple presumption may, however, cause the data controller to consider processing security, cf. Article 32 of the Regulation.
In assessing whether a breach has occurred, it must be assumed that particular attention should be paid to the information referred to in Article 33 (1) of the Regulation. 3, is available to the provider.
And on page 497:
As regards the cases where the data controller has left the processing of personal data to a data processor, reference is made to Article 33 (1) of the Regulation. 2, which is discussed in more detail below.
The Ministry of Justice's Executive Order does not, therefore, link the data controller's deadline and a data processor's deadline together.
These sections are repeated in the manual issued by the Data Inspectorate regarding violations of personal data security.
Article 29 group has stated in their WP250 breach of personal data security on page 13:
Article 33(2) makes it clear that if a processor is used by a controller and the processor becomes aware of a breach of the personal data it is processing on behalf of the controller, it must notify the controller “without undue delay”. It should be noted that the processor does not need to first assess the likelihood of risk arising from a breach before notifying the controller; it is the controller that must make this assessment on becoming aware of the breach. The processor just needs to establish whether a breach has occurred and then notify the controller. The controller uses the processor to achieve its purposes; therefore, in principle, the controller should be considered as “aware” once the processor has informed it of the breach. The obligation on the processor to notify its controller allows the controller to address the breach and to determine whether or not it is required to notify the supervisory authority in accordance with Article 33(1) and the affected individuals in accordance with Article 34(1). The controller might also want to investigate the breach, as the processor might not be in a position to know all the relevant facts relating to the matter, for example, if a copy or backup of personal data destroyed or lost by the processor is still held by the controller. This may affect whether the controller would then need to notify.
Regardless of what the Data Inspectorate states in their presentation on a data processor agreement, the data controller's deadline is counted only after the notification has been received from the data processor. Since the data processor must notify without undue delay, and since the data processor merely finds that there has been a violation, this will in practice provide very limited options for staying from the data processor to be aware of the violation for notification to be given.
It follows that the data processor is required to assist the data controller in fulfilling its obligations under Articles 33 and 34.
It is therefore clearly contained the necessary guarantees that Muskema assists in lifting the data controller's obligations.
The customer asks:
Where and how do you approve the Data Processing Agreement?
We answer:
The customer asks:
The Article 28 (1) of the Regulation, 3a states that the data processor may only process personal data after documented instructions from the data controller, what does that mean? Should there be a special document for that?
We answer:
No, it is not necessary because we can not predict all conceivable situations, but when it happens, it must be documented / documentable.
Specific: If a manager or employee has a technical issue in the dialogue questionnaire and contacting Support for help and Support can not solve this task for the customer without having access to the questionnaire, Support can only do this, if that manager / employee enters his / her profile and gives Support this access at a check mark that can be removed immediately after the problem is resolved. However, this instruction is "documented" in the system.
The instructions are contained in the terms of the "Scope of processing Activities" section, where is stated that upon Customer's acceptance of the Data Terms of Service, the Customer instructs the Musskema to process Customer's personal information for the delivery of the Musskema.dk cloud service on the terms set forth in the Subscription Agreement and these Data Processing Terms.
In the data processing conditions itself, there is a section about the nature and purpose of the treatment, including states: In addition, it may be agreed between the parties that the nature of the treatments also includes the provision of services that entail processing of Customer's information. It points to the possibility that the customer can give Musskema.dk instructions to take care of, for example, an anonymous well being survey for the customer. Then the Data Processor acts on clear instructions from Data Controller in the given situation.
That's how it should be considered.
The customer asks:
It is stated in Musskema.dk's Data Processor Agreement that when an employee is deleted by the customer's system, the employee is deleted after 14 days while entered data, appointments and scores are stored in the manager's archive for 5 years. Is it legal with the 5 years?
We answer:
Yes, it is legal to store staff records for +5 years according to the Data Inspectorate's practice, and the manager's archive is an archive that only the leader in question has access to, and it is to be regarded as an "extended feature" of the Employee Folder.
The customer asks:
What risk assessment is based on the security level in the system? And is it taken into account that the system may potentially contain health information?
We answer:
The risk assessment has included an assessment of the sources of risk, the vulnerabilities that may exist in the system and how this threat picture can lead to an event that can be characterized as a violation of personal data protection, in accordance with the Data Protection Regulation nature. 4 (12). The probability and severity of a break is then assessed to determine the overall risk image.
There are clear instructions from Musskema.dk to the users that there is no need to enter health information into our system. Musskema.dk is not just something similar to a medical journal system - but it can be used for a very good dialogue about what creates and reduces absenteeism. It is a dialogue system.
The customer asks:
How is data delivered / deleted if Musskema.dk goes bankrupt? Who is the beneficiary?
We answer:
If Musskema.dk goes bankrupt, a curator will be appointed to handle the estate. The curator / bankruptcy estate replaces Musskema.dk and has an inherent interest in delivering or deleting data.
The customer asks:
If the penalty issuing authority determines a division of responsibility, is that what is followed or is it an internal decision of the same? Limitation of Liability is not entirely clear.
We answer:
As a starting point, the division of responsibility contained in the fine settlement is followed by nature. 83 - which would be consistent with the principles by nature. 82 also. To the extent a party with reference to the guarantees, etc. What is contained in the agreement means that the final distribution of responsibilities must be different, this may be pursued, but in that case it will ultimately be a court decision.
The customer asks:
Is it possible to get access to read the sub data processors agreements?
We answer:
There is, as a rule, no access to read the sub data processors agreements. In connection with the execution of supervision of Musskema.dk, Musskema.dk may choose to display those parts of the sub data processors agreements that do not contain commercial terms or such technical specifications that may compromise total security. In addition, Musskema.dk will issue the Executive Board statements and, to a certain extent, statements of assurance regarding the sub-processing agreements that are integrated into the annual statement of assurance (From Deloitte).
The customer asks:
Should there be a physical signature of the Data Processing Agreement?
We answer:
The customer asks:
Why ISAE 3000?
We answer:
Together with Deloitte, Musskema.dk has chosen ISAE 3000 as the best and most comprehensive European standard for our area. And individual customers can see the latest update on their profile. It will be updated annually.
The overall difference between ISAE 3000 and other similar ones eg ISAE 3402 lies in the fact that ISAE 3402 applies when the statement and the controls included in the statement deal with financial reporting. If Musskema.dk's product was ex. to supply Axapta, then the statement would have to be used by our client's accountants to use for the accounting of our clients. In that case, it should be an ISAE 3402.
But that's not how our product works.
ISAE 3000 can be used for anything other than financial reporting, including for example reporting on checks on personal data that Deloitte has made with us. But generally, it can be used for anything that does not process financial information, ex. service desk systems, portals etc.
That said, there are overlaps in the controls. Area B of our statement addresses general IT controls, which will often also be covered by an ISAE 3402 statement. However, the ISAE 3402 declaration will often have even more IT controls, but it will not contain any personal data.
The extent to which one or the other type of declaration must be provided depends on the service provided. If our customers want to report on whether Musskema.dk complies with the data processing agreement and protects the customers' personal data, then ISAE 3000 is the right one. If we were now a data center, or otherwise run the customer's IT systems, ISAE 3402 might be better.
That is why we have chosen ISAE 3000.
The customer asks:
Should employees give consent for anonymous graphical data to be drawn?
We answer:
No, the employee should not. And the employee can't demand it either.
Legally, there is no legal basis to make that claim.
Because anonymization can occur, statistical information can also be extracted as long as it is not possible to identify the person from the information.
“To the extent that […] employee development interviews are held in the private labor market, ordinary information may be processed with the consent or on the basis of Article 6 (2). In the case of sensitive information, only the express consent of the employee may, in principle, be processed. However, it may also be a matter of processing information for other purposes, e.g. Article 9 (2) of the Regulation 2 (f) (determination etc. of legal requirements). "
The company can therefore process personal data in connection with EDP based on a balance of interests.
Therefore, it will not in principle be a consent-based treatment or treatment that can only be done based on consent.
Lawyers discuss making statistical information based on personal data. First, the lawyers conclude that the anonymization of personal data is not at all a processing, as it lacks meaning in relation to the basic principle of the nature of the Regulation 5 on storage restriction. The regulation directly states in the preamble that processing of anonymized data falls outside the scope of the regulation. (Peter Blume has argued that viewpoint).
Other lawyers state that anonymization is always within the scope of the original treatment, since it in turn supports the principle of retention of storage.
Finally, other lawyers find that anonymization is always compatible with the original purpose and that treatment can therefore be done.
Musskema.dk has usually recommended the two first mentioned angles on the case.
Danish