What an employer can legally ask to monitor about user activity I work for a Belgian company as systems engineer, and I'm asked by the HR department to give them logs of a specific user's activity. This is about a concern they have when it comes to this user's activity while working from home (VPN). I'm aware the employer can't ask to audit a user activity without him being notified (I do not know the legal process/laws for this). We've got tools such as Netwrix Auditor that could even get us a video of user's activity if enabled (currently disabled because we are unaware of the legal aspects, plus it takes a lot of storage). My question is : what can my employer ask me to audit/monitor ? What is the legal process if the employer want to know details about a user's activity (European/Belgian laws)? What should I sign or ask prior to begin the investigation, so I'm somewhat protected as employee ? In the meantime, can I simply give them Active Directory logons events, from the VPN IP pool, for that user ? Or is that already too much from a legal point of view ? Thanks for your help !
Belgium enacted an implementing law, the Act of 30th July 2018 on the protection of natural persons with regard to the processing of personal data. This, along with the GDPR, are the key legislative references that relate to your question. On 5th September 2017 the ECHR judged that it "considers that States should ensure that, when an employer takes measures to monitor employees' communications, these measures are accompanied by adequate and sufficient safeguards against abuse". This case set a precedent relevant to employee monitoring in Belgium. This is most definitely a data protection or privacy law matter and the DPO should be consulted. If they have to do research, that shouldn't be your concern as that is their job. The company must support the DPO in what they need to do that job, as such is literally written into the GDPR. Furthermore, in this case it would, by my evaluation, be necessary to conduct a Data Protection Impact Assessment (DPIA) for the monitoring activity, and if one has been done, it should document the recommendations and requirements or what is already in place. You as an individual may also ask a question of the Data Protection Authority: (NL) https://www.gegevensbeschermingsautoriteit.be/verzoek-klacht-indienen (FR) https://www.autoriteprotectiondonnees.be/introduire-une-requete-une-plainte You might ask them about your position and liability as an employee, but I would be more concerned, if I were you, with verifying that your actions are above board rather than trying to cover your ass just in case they aren't. Do the right thing, even if that means questioning the direction you've been given. AD logons still identify the person logging on, and may include source IP, which is specifically listed in the GDPR as within the scope of 'personal data'. So while there may be a legitimate need to process such data, it needs to be gone about in the right way. Actions taken by an employee are taken by the organisation in terms of processing personal data, so whatever you are asked or ordered to do, will be done by the company. If you are being offered no legal justification for doing so, you might document the direction you are given and question it respectfully, pointing out that if found to be unlawful, it is the company that would be in trouble, all while knowing that should there be for example an unfair dismissal, you have a record of who asked you to do what, how you challenged or questioned it, and what was the outcome.
I don't think you would be responsible for whether your software is used in a GDPR-compliant manner. For GDPR compliance, it is important who the data controller is. The data controller is whoever determines the purposes and means of a personal data processing activity, i.e. the why and how. The data controller alone is responsible for their GDPR compliance. When a data controller wants to run some software, it's the data controller's responsibility to ensure that this software is used in a GDPR-compliant manner (or possibly not at all). Determining purposes and means of processing When someone other than the developer runs a software, the question is who might be a controller: you as the developer, they as the operator, or neither, or both? The operator is clearly a controller: they determine a purpose for data processing (e.g. to manage staff) and have determined means to perform that processing (e.g. to use the software). The developer may or may not be a controller. Clearly, the developer has made choices about how the processing of personal data will be performed, i.e. has determined some means of processing. E.g. the developer has developed a particular architecture, chosen a way to store personal data, and has implemented some security measures. But determining some means is not sufficient to be a data controller, see discussion below. Has the developer participated in determining the purposes of processing? I think this will depend on the specific functionality provided by the software in question. If the software just does what it says and processes the data for the operator's purposes, everything should be fine. If the software also processes data for the developer's purposes, that developer might be a controller. For example, if analytics or crash reports are collected by the developer, that would be a clear indication that the developer would be a (joint) controller. So depending on specific factors, the operator might be the sole controller, or the operator and developer might be joint controllers. Essential vs non-essential means What about the developer determining some means? When does this make the developer a joint controller? The EDPB has created a theory of essential vs non-essential means: 40. As regards the determination of means, a distinction can be made between essential and non-essential means. “Essential means” are traditionally and inherently reserved to the controller. While non-essential means can also be determined by the processor, essential means are to be determined by the controller. “Essential means” are means that are closely linked to the purpose and the scope of the processing, such as the type of personal data which are processed (“which data shall be processed?”), the duration of the processing (“for how long shall they be processed?”), the categories of recipients (“who shall have access to them?”) and the categories of data subjects (“whose personal data are being processed?”). Together with the purpose of processing, the essential means are also closely linked to the question of whether the processing is lawful, necessary and proportionate. “Non-essential means” concern more practical aspects of implementation, such as the choice for a particular type of hard- or software or the detailed security measures which may be left to the processor to decide on. – EDPB guidelines 07/2020 on the concepts of controller and processor in the GDPR, added formatting for legibility Looking through that list of essential means, some might be determined by a software's developer, but I wouldn't expect this to be the case for this kind of open source software. types of personal data: the software certainly sets a framework for processing specific kinds of personal data, e.g. by providing database fields for names, contact details, and schedules. But ultimately, the developer does not control which data is actually collected and filled into those fields – the developer does not cause specific kinds of personal data to be processed with the system. duration of processing: unless the software is programmed with a fixed retention schedule, it should be impossible to argue that the developer has determined the duration of processing. Even then, it would also be the operator who has determined this duration to be appropriate, rather than editing the open-source software to change the duration. But typically, no such retention schedule is enforced, and retention would depend solely on the operator (who can use an admin interface or a database console to erase old records). categories of recipients: typically, the developer does not determine to whom the data in the system will be given. But if the system sends data to third parties by itself, this might change. For example, if the system is pre-configured to store data in an existing cloud database instance, or to a specific analytics server, the developer might be acting as a controller. Here, good software engineering and legal risk minimization coincide. Best practices for web apps state that account credentials and connection strings shouldn't be hardcoded or committed to a repository, and should instead be provided externally (e.g. via environment variables). categories of data subjects: this depends solely on how the software is used. The developer has no way to determine whose data the operator will enter into the system. If the developer isn't a controller, might they be a data processor instead? In a GDPR context, a data processor is whoever processes personal data on behalf of a controller. The developer is clearly not a processor in this scenario because both the “processing” and “on behalf” criteria fail. The developer has no access to the data in the operator's instance, so cannot process the personal data. There is no direct relationship between the developer and the operator. The operator has not delegated authority to the developer so that the developer would be acting “on behalf” of the operator. There is a legal relationship between the two roles (the developer has licensed the software to the operator) but that is entirely irrelevant in a data protection context. The GDPR isn't directly about cookies While the GDPR does cover how personal data can be processed with cookies, the famous “cookie law” is actually separate: those cookie consent requirements stem from EU member state's implementations of the ePrivacy directive. Instead of talking about “controllers”, ePrivacy has concepts such as the “provider of an information society service”. While this role fits perfectly to an operator/provider who runs a web app in a publicly accessible manner, it does not fit a developer who merely makes some source code available. Is the developer even subject to the GDPR? The GDPR can only apply to data controllers and processor who process personal data. As discussed above, the developer is probably not processing personal data at all. Even if the developer were processing personal data, it is questionable if GDPR would apply assuming the developer has no “establishment” in the EU (e.g. an office). Then, the question would be whether those processing activities are either related to offering goods or services to data subjects in Europe, or whether the processing activities involve monitoring the behavior of people who are physically in Europe. Unless the developer is actively targeting European businesses with marketing for this software, the answer is very likely “no”. Could the operator sue the developer for providing software that isn't GDPR-compliant? The operator can sue anyone for any reason, but is probably not going to win. As discussed, the operator is a data controller. They are responsible for ensuring that their purposes and means are GDPR-compliant. That involves selecting suitable software. The data controller would be neglecting their own responsibilities if they just download some random software and start feeding personal data into it. Things might be different if the operator specifically advertises GDPR compliance features but you're not going to do that. It's also worth noting that common open source licenses like the Apache License 2.0 include a warranty and liability disclaimer. To which degree they protect the developer ultimately depends on national laws, but they make it difficult for the operator to make a legal argument that they're entitled to a GDPR-compliant product. See also the related question: Do warranty disclaimers in software licenses carry any legal weight? What can you do? First, don't worry too much. Given how much bad software there is on the internet, surprisingly few developer get into legal trouble for writing source code that's buggy or missing some features. Second, consider choosing a license for your project that includes a reasonable warranty/liability disclaimer. Third, make the state of your project clear in your README file. If someone knows that this is alpha-quality software and that no compliance features were implemented, it's their own fault if they actually use that software.
HIPAA imposes obligations on some people, but not all people. In the case of security and privacy questions, you would consult 45 CFR Part 164. A patient's actions are not subject to government sanctions, so a patient can provide or decline to provide email addresses following their own judgment. A healthcare or insurance provider would be required to securely keep PII under wraps. The regulations also do not impose obligations on unknowing potentially involved third-parties, i.e. no obligation is imposed on Google to know that an individual is using a Gmail account to transmit PII-related information. The medical provider has an obligation to store and transmit such information securely, which would mean for example that they do not send insecure plain text emails saying &quot;Sally Jones at 12345 67th Ave SW was treated for a loathsome disease, we're coding that as 0102, and we want $500&quot;. That obligation is passed on to employees via employment-contractual obligations, for example that may dictate what computer or software you can use to do the job. If the provider passes the buck to the employee (and I assume that the employee is just an employee), they have violated the security rule. In that case, they may be attempting to mitigate the consequences of their actions or at least check if there were identifiable violations of the privacy rule. In the scenario where SmithMed provides all of the infrastructure needed to bill insurance companies, it is not a HIPAA violation to inspect computer logs, email etc. to verify that the employee has been complying with security and privacy policies. It would likewise not be a HIPAA violation to inspect third-party accounts (Gmail etc) to determine whether there has been a security / privacy rule violation. That is as far as HIPAA takes you. Whether or not the ex-employee has an obligation to turn over their email account information is mostly determined by the employment contract, but it is highly unlikely that any such contract has a &quot;gimme your personal email on termination&quot; clause. It is not inconceivable that the employee negligently used their personal account rather than opening a new billing-job only account. Also depending on the email service provider, it may well be a violation of the terms of service to hand over your account information. (Instead, for a certain email provider, the company is expected to set up and pay for a company account). Those are considerations bearing on possible legal impediments to turning over the email information. Needless to say, don't share passwords etc. because that exposes you legally, but that is not about HIPAA.
34 CFR Subpart D covers this topic ("Under what conditions is prior consent not required to disclose information?"). This includes The disclosure is to other school officials, including teachers, within the agency or institution whom the agency or institution has determined to have legitimate educational interests so that raises the question of whether there is a legitimate educational interest. Additionally, the question is raised as to the status of an SRO (they are not teachers). Disclosure is allowed to A contractor, consultant, volunteer, or other party to whom an agency or institution has outsourced institutional services or functions may be considered a school official under this paragraph provided... the conditions being that the person Performs an institutional service or function for which the agency or institution would otherwise use employees; Is under the direct control of the agency or institution with respect to the use and maintenance of education records; and Is subject to the requirements of §99.33(a) governing the use and redisclosure of personally identifiable information from education records I would take this model memorandum as the most likely agreement, though your district may have a totally different memo where SROs are purely security guards. An SRO is to advance the program objective which include "Education of children regarding the role of laws, courts, and Police in society", which is the hook into "legitimate educational interest". This nothwitstanding the part that says that they "are police officers and not school teachers, school administrators, nor school counselors. The officers will assist teachers with classroom presentations on relative topics when requested and able" (there is no principle that only teachers, administrators, or counselors can have a legitimate educational interest). This model memo does not say anything that indicates that the conditions "Is under the direct control" and "Is subject to the requirements of §99.33(a)" are true, but those conditions could be satisfied external to the MOU. There are some additional exceptions of the "if required by law" type, such as a state law "adopted before November 19, 1974, if the allowed reporting or disclosure concerns the juvenile justice system and the system's ability to effectively serve the student whose records are released"; or, after that date, is "subject to the requirements of §99.38" which refers you to §99.31(a)(5)(i)(B). If that is confusing, here are the two self-referring sections: §99.38(a) If reporting or disclosure allowed by State statute concerns the juvenile justice system and the system's ability to effectively serve, prior to adjudication, the student whose records are released, an educational agency or institution may disclose education records under §99.31(a)(5)(i)(B). §99.31(a)(5)(i)(B). The disclosure is to State and local officials or authorities to whom this information is specifically...Allowed to be reported or disclosed pursuant to State statute adopted after November 19, 1974, subject to the requirements of §99.38. So state law is one possibility; "legitimate educational interest" is a remote possiblity. Massachussetts law does include governmental third party disclosures: 603 CMR 23.07(4)(c) A school may release information regarding a student upon receipt of a request from the Department of Social Services, a probation officer, a justice of any court, or the Department of Youth Services under the provisions of M.G.L. c. 119, sections 51B, 57, 69 and 69A respectively. That does not directly apply to local police, but it is possible that a police officer is operating as a probation officer or an agent of the Department of Youth Services. Under paragraph (e), A school may disclose information regarding a student to appropriate parties in connection with a health or safety emergency if knowledge of the information is necessary to protect the health or safety of the student or other individuals. This includes, but is not limited to, disclosures to the local police department Mass. law allows the possibility of treating a police officer as "authorized school personnel" if they are "providing services to the student under an agreement between the school committee and a service provider, and who are working directly with the student in an administrative, teaching counseling, and/or diagnostic capacity" – which is not completely out of the question but is a bit of a stretch (especially in the context of a blanket statement "we share records", not "we may share yours, if you get special counseling"). Tne law also says "Any such personnel who are not employed directly by the school committee shall have access only to the student record information that is required for them to perform their duties", so sharing of all records would not be allowed.
As the comment by Ron Beyer mentions when a company wants to impose such restrictions they are normally done through non-compete, non-solicitation, and non-disclosure agreements, as well as via trade secret law. Note the word &quot;agreements&quot;. &quot;Restrictions on working in the field&quot; are simply a form of non-compete agreements. A company cannot, legally, simply impose such agreements on its employees. It can require an employee to sign such an agreement as a condition of employment, and it can often require such an agreement from a departing employee as a condition of a severance payment. Exactly what is covered by such an agreement depends on its terms, and those vary widely. In most US states there are limits on the scope and duration of such an agreement. In some states the restrictions can be broad and of fairly long duration, in others they must be narrow and of fairly short duration. An agreement that goes beyond a given state's limits will not be enforceable in court, if the defendant brings that fact up. Trade secret law can prevent an employee from disclosing the trade secrets of a former employer to a new employer, or indeed to anyone else. But that does not prevent a former employee from getting a new job in the field, as long as the employee does not disclose any trade secrets. If an employee has signed, or is asked to sign, such an agreement, it is a good idea to consult a lawyer with employment law experience. If the state is known, I could edit this answer to include the limits, if any, on such agreements in that state.
Asking as such is hardly ever illegal. Any stranger can ask you to pick up their kids from school, like you always can tell them where to go. What I guess you are actually asking is whether the PI can require you to do it. No they probably cannot: it would have nothing to do with the matter of your contract or nature of your professional relationship with them. However, if they are in the position of power, they will have discretion in making decisions that will affect you. Whereas you legally can tell them where to get off, it might be good idea to attempt some interpersonal workplace tactics first.
Anyone who processes personal data using electronic means or with some filing system is a data controller, as long as they fall within the GDPR's territorial scope, they're not doing the processing on behalf of another data controller, and they're not only doing the processing for purely personal or household purposes. In todays world, it's almost certain that electronic means are involved. And establishing a rental contract generally involves some personal data. We can also assume that both parties are in the UK, and that both are acting on their own behalf. So this leaves the household exception. Larry the landlord will not be covered by the household exception since they're using the personal data for a business purpose. Larry is a data controller. If Tim the tenant is renting a place to live in himself, he's probably acting for purely personal or household purposes and would not be a data controller. If Tim the tenant is renting space for his office, for a church, or for a chessclub in which he is a member, he's no longer acting for purely personal or household means. Depending on context, Tim or Tim's organization may be a data controller. The ICO's guidance on controllers and processors has a checklist “Are we a controller?” that lists common factors establishing controllership. On another page, they write: Wherever personal data is used for purposes other than personal or household processing, the organisation behind it is a controller. Personal or household processing means the personal data you’d usually have in your home, such as family photo albums, friends’ addresses and notes on the fridge, none of which would be covered by data protection laws unless there was another connection to a professional or commercial activity.
"The company you are working for ..." Stop. We're done. An employer owns the IP created by an employee in the course of their employment: the hackathon is in the course of your employment.