At our last TAG meeting, IT Services Director Jim Franceschelli and Information Security Director Adam Edwards invited faculty feedback on their Identity Finder Proposal on Automated Scans. For those just joining us, Identity Finder software scans your (Windows) computer for sensitive, unsecured Personally Identifiable Information (PII). The Information Security Office and IT Client Services are jointly proposing implementation of weekly, automated, required Identity Finder scans (see the proposal for details). During the meeting, TAG members shared some concerns about scheduling and performance effects. After the meeting, we received additional concerns from Bryan Burnham (Psychology), a member of the Institutional Review Board, that Identity Finder scans of machines storing human research subject data or client files (from a counseling practice, for example) would breach subject confidentiality. Concerns are paraphrased here:
There are privacy issues related to data collected on human research subjects that must be considered before automated Identity Finder scans of machines can occur. Specifically, we (IRBs, DRBs, PIs – primary investigators) ensure complete and total privacy of our human research subjects’ data, especially sensitive information (names, emails, Royal IDs, social security numbers), some of which is undoubtedly stored on computer hard drives. [The same is true for client files maintained by counselors or clinicians.]
“Subject confidentiality” means that knowledge of a person’s participation in a research study is between the human subject and only the PI. That is, a subject is guaranteed by the PI that knowledge of their participation as well as their personal and sensitive data will not be open or available to any third party – meaning anyone not associated with the research project. The automated Identity Finder scans would, in effect, view confidential human research subject data and client information that, by definition, cannot be viewed by others.
It should be noted that the Identity Finder reports that the Information Security office receives are redacted, showing a masked version of a potentially problematic file and the location where it was found, and are only accessible to the Information Security Director (Adam) and the Information Security Engineer (Scott Finlon). However, Bryan noted that the scan itself is the issue: third parties (including other University divisions/employees and University-owned software) are not allowed to access or see confidential subject information.
Bryan, Jeremy, Kristen, Adam, and Scott got together on Friday to get a better understanding of this issue and what options there might be for general campus implementation of automated Identity Finder scans without violating subject confidentiality.
We discussed a few options that IR and TAG could consider for Identity Finder, each with varying advantages/disadvantages. A significant complication, however, is that at this point we don’t know how many researchers on campus have this kind of data, where it’s stored (faculty, staff, student, and/or lab machines? cloud storage?), and whether it’s encrypted or otherwise protected against security breaches (malicious or inadvertent). Bryan stressed that researchers are responsible for their own data and for ensuring subject confidentiality, and neither the IRB nor the University can impose or require specific data management practices, at least under current IRB policies.
Scott noted that the Identity Finder question is only the top layer of broader issues of privacy, security, and digital records management on campus, and that research data stored on a researcher’s hard drive or in cloud storage could be vulnerable to external attack. Both Adam and Scott mentioned that Identity Finder, used appropriately, could help researchers protect subject confidentiality by locating vulnerable information and prompting the researcher to take further steps towards securing it. We agreed, though, that educating researchers about data security and encouraging more secure data management practices (encryption, password protection, etc) will be a longer, more involved, and more inclusive conversation – but a conversation that needs to happen nonetheless.
Next steps: Bryan will bring this discussion to the IRB at their April 16th meeting for additional input and will share any relevant guidelines from grant agencies (e.g., Department of Health & Human Services), and his and others’ own digital data management practices. Adam and Scott will reach out to Identity Finder and other university security offices re: how others have handled this issue. They are willing to continue discussing accommodations for researchers storing sensitive data, if we can find all of them or somehow get them to self-identify. TAG might be able to help survey the faculty on this question (yes/no/unsure) – multiple outlets should be used to try to catch everyone’s attention. The IRB, ORSP, and TAG may want to coordinate a faculty forum on this topic.
We’re still early on in this discussion, so please contact TAG if you have any insight, concerns, or questions that we might not have considered yet.
