mjhjmtu

There is a trove of documents from Microsoft with advice on GDPR compliance, such as "Windows and the GDPR: Information for IT Administrators and Decision Makers" and has a pretty thorough explanation of what data moves where.

According to the document itself, it takes 17 minutes to read. I think you'll feel better after you've done so.

There's a lot of paranoia about Microsoft, some of it possibly justified, but the hard fact is that MS cannot afford to ignore the GDPR or, in the U.S., HIPAA.

I did read the answer in Information Security SE, and did not find it helpful; the quotation from MS has to do with disclosure of data as required by law or legal process.

Your university should have some sort of data privacy compliance office. You absolutely need to talk to them. Well-meaning advice from strangers on the internet is great for giving you an idea of what the issues are but there is potential legal liability for the university here and you must talk to the people whose job it is to manage these issues.

Make sure your advice is actually based on solid facts, and consider which are the most likely ways the data could leak out. Find out exactly what Windows 10 could report to Microsoft, and whether that is a real issue in your case.

Find out the actual regulations and laws about this in your country and maybe also university rules, if they exist. Being able to point to specific regulation is useful for such arguments.

In a typical academic settings, you probably don't have the means to really lock down stuff. I would focus on the most dangerous and common ways the computers could be compromised, Microsoft is far, far at the end of those worries in my opinion. I would mostly worry about the following cases:

• people taking the data home or on their private computers


• computers being compromised by malware


• computers, hard drives or USB drives being stolen or lost

You're focusing on a very remote and unlikely threat, that makes it much easier to dismiss your arguments. Focus on realistic and plausible threats, and be prepared to still fight an uphill battle.

The way I read your question is that you are not responsible for data protection but responsible for setting up Windows PCs. In that case I would share your concerns in an email to your group leader so that you have a (virtual) paper trail, and ask them whether they'd like you to set up the Windows PCs nevertheless or whether they'd like you to look for another solution.

Of course, if your actual responsibility is data protection and they are ignoring the very thing they've hired you for, you should probably start looking for another place to work.

What to do when being responsible for data protection in your lab, yet advice is ignored?

If you are really responsible, and if you live in a jurisdiction where data protection has "teeth" (i.e., EU/GDPR), then you have the power to shut down whatever uncompliant behaviour there is. You can basically do whatever (shut down PCs, turn off routers, etc.) - obviously this is the last ressort, not the first reaction, and before you do that, there are some other things you need to do: for example, inform your colleagues; write down guidelines; get the backing of your stakeholders, do informational/teaching sessions etc.

If you do not do all of that (or your colleagues deny any conformance), starting with the easy stuff, but eventually escalating, then you should really drop that role of "being responsible".

The GDPR actually defines specific roles related to data protection. Depending on where you live, your country might have other such definitions (or maybe none at all, but then you would probably not be asking this question). So if you happen to fulfill the role of Data Protection Officer, then you have the power and responsibility to act.

If all of this is not true, and you are simply a normal worker bee, then your actual responsibility is to a) do whatever your DPO says and requires and b) flag violations of law to your DPO or other stakeholders - if your DPO does not care, you might go further up the ladder, but frankly, whether to do that is your personal choice; if you make any transgressions visible to the persons actually in charge (keep a paper trail, maybe put your own supervisor in Cc etc.), then you personally should be fine.

EDIT: I was confused from the question's title which contains the word "responsible". In OP's specific case, only my last paragraph applies. I'll let the rest stand in case someone needs this who is actually "R" responsible (in the sense of RACI). OP, your best bet is to work on not being viewed responsible for something which you have no influence over. Talk with your superiour, and get their advice how to do that without burning bridges ("Hey coach, it seems like everybody thinks I'm our data security guy, but they have to get their stuff together themselves, I cannot babysit them..." etc.).

You have stated in the comments that you are in Europe, and are thus subject to the GDPR.

Since you are collecting sensitive information, there should be a formal process for the collection and management of that information, including what information is collected, for what purposes, how long it's kept, how it's protected, etc. All of this is required to be shared with anyone whose data you collect, before you do so.

There should also be a person who is actually officially responsible for this (the DPO), which should be listed in that statement.

Refer to that person. They are the person who is actually responsible, not you.

If you do not have those policies and procedures in place, then you should alert your manager to this fact and to the consequences it may have. Put it in writing, so your a** is covered.

If you think your institution is in breach of its obligations and won't do anything to address them, there's of course the option of reporting it to the relevant authorities, with all the consequences this may have for all parties involved (including you, of course — one cannot ignore how whistleblowers often end up).

To answer your question, explicitly asking "What to do when your advice is ignored", I highly suggest the CYA-acronym: Cover Your Ass.

As you are (I suppose) not in a management-role you most likely have limited means to actually enforce the advice you provide, but to prevent the blame rolling down you should take means to document your activities. Maybe the most important measure here is to leave a paper trail.

For example you could write an email to your supervisor:

Dear XY,

After some research on the matter I advice our Lab not to use Windows 10 because of concerns regarding Windows telemetry data. (...) Instead I advice to use XYZ by ABC.

With best regards, ...

This will not only serve as a proof for you, but might also make your manager consider this proposal more. If he/she realizes, that he now is responsible if things go down the drain - he might be less inclined to just ignore you.

Talk to the advisor. If he won't back you up, step out of the position.

It is very common that university lab groups don't really follow proper policies in safety, data security, confidentiality, software copyrights, etc. Industry is not perfect either but usually a lot more compliant than university lab groups.

I was safety "officer" for my lab group. Checking on standards, inspecting the eyewash periodically, etc. Found clear things we were doing wrong but advisor was not interested in backing me up (thought I was being too strict...but I came from an industry background and had seen people get hurt and was used to more attention.) We ended up having a fire in an area that I had already identified as deficient but with people who didn't want to fix stuff. I told the PI after that, that it was his lab and he needed to be responsible and I refused to be associated with lab safety given his attitude. (He said fine and someone else went and checked the eyewashes.)

Maybe you don't need to be as confrontational, but I would give very serious consideration to just refusing to perform the collateral duty when people don't take it seriously and the PI doesn't back you up.

I don't know about data protection but from what I have seen in safety, I suspect it is same problem. Safety has had extensive studies and writeups and academic labs have ~10 times the incidents of industrial research labs. I personally knew two people with grievous time lost incidents from solvent fires in uni lab (faces burned off and months in hospital) and never saw this in a large company CRD. Professors will occasionally blame the students but bottom line is PIs are not held accountable the way managers are in a company. Students are valued less than employees are, etc. And it's not going to change and hasn't for decades. So really you are better off just disassociating yourself. And keeping your own gear safe and compliant.

Should things for whatever reason go sour, I'd like to be on the safe side.

The question is what you want to protect against - a lawsuit directed at you, or being let go?

My suspicion (but I'm not a lawyer, obviously) is that there is very little danger of the former and close to no real protection against the latter.

The uncomfortable reality is that many people (in academia and outside) are not so much hiring an employee rather than buying insurance when filling roles such as for a data protection responsible (same with certain certifications in industry). They know (or at least strongly suspect) that what they do is not legal, don't want to change, and look for somebody who they can point to when things go south.

If any real legal trouble ever arises from the data protection issue, I fully suspect that it will be targeted at the university rather than individuals working there - and even if it is targeted at specific persons, it will be the managers in charge, not a lab technician with no authority to change the behavior of other employees. However, there is a very good chance that internally you will still be made the scapegoat (up to and including being let go), if for no other reason than that sh*t tends to roll downhill. In my experience with university management structures, no amount of paper trail can really protect you from this.

Of course you still should try as hard as you can to inform your lab on any relevant issues that you see, but given that you have no authority over them it will have to take the form of advise rather than strict rules. Being on good terms with the team (and having great soft skills) is probably your best bet of actually making a difference. It may also pay to be pragmatic here, and address big threats that don't require too much sacrifice from your team - the InfoSec Stack Exchange may be a very good resource to get information on what these might be (I suspect the usage of Windows is not one of these cases).

Note: there are jobs were you end up personally responsible for certain kinds of problems (functional safety in automotive is an example that comes to mind). However, these are typically characterized in that you need explicit qualifications to even be legally allowed to carry out this job. A company cannot just appoint a random engineer to now be legally responsible for safety certification. Part of the mandatory training for such jobs is also explicit information on what you end up responsible for, and what the expected course of action in case of non-compliance is.

If you're highly concerned about telemetry and information leakage, and you have the necessary rights to perform administrative tasks on the equipment your lab uses, I'd suggest a telemetry-blocking app, though I urge you to test and scrutinize it before any sort of deployment. Personally, I'm a fan of BlackBird, but be wary of its functionality-canceling effects (Location awareness, LAN etc.). Again, study and test such software beforehand.

But I want to mention another aspect of data protection, not in the sense of privacy, but of data integrity.

I would not in a million years be caught using Windows for data-sensitive work because I and many others have been the victims of Windows and its apps' (e.g. OneDrive) tendency to delete user files without notice (permanently, bypassing the Recycle Bin). See the 1809 update for a more recent example; there are plenty others.