search

opensafely / documentation

Documentation for the OpenSAFELY platform
https://docs.opensafely.org
Other
35 stars 6 forks source link

Process for reporting and handling confidentiality breaches #77

Closed annaschultze closed 3 years ago

annaschultze commented 3 years ago

This is only partly a documentation issue - but it struck me as I read the documentation that there's no information on what to do in case of an accidental breach. I think we should develop a process for this (there may well already be one), and include it in the documentation - particularly for external collaborators.

Not sure whether there are GDPR related deadlines for these as well (i.e., report any serious breach within 24 hours), and if yes we should also ensure that there are contact details for a DPO so that users can report this whenever it occurs. I think it'd be nice to perhaps include any reported breaches in some form of open website - the vast majority I presume would be very low risk (i.e., summary plot based on <5 people accidentally pushed to closed repo), but just for transparency.

annaschultze commented 3 years ago

And related to this, are we using Github EU servers? I feel like this might make things easier in case there is any accidental breach, as in that case at least data will not leave the EU.

wjchulme commented 3 years ago

This is a very important point, cc @amirmehrkar and @sebbacon may have thought about this in more detail already.

The most important thing is to report and remove the offending material, including from the git history. This isn't a entirely simple process and will presumably require developer support.

One thing to point out is that there's a new process for pushing released outputs here https://github.com/opensafely/output-publisher/blob/main/README.md which will be put into the documentation soon. It won't make unwanted releases impossible but it will certainly help and it makes the process easier in general. It doesn't help with the actual disclosivity checks and redactions.

annaschultze commented 3 years ago

Thanks! The new process for releasing results seems really useful, I should spend some time learning that as well. I think this will definitely help with accidentally copying or committing "wrong" files; but there's presumably also a risk that people just miss low numbers.

What spurred this was that I almost released a figure based on low numbers (but without any actual low numbers in it) when redacting quite a large number of tables/figures. There are definitely things I can do to reduce the risk of that happening further (for example, naming my outputs sensible things and not just number them), but it made me realise I wasn't sure how to report it/undo any accidental release - particularly if this happened at an off time when other people were unlikely to be working.

I'll raise this in the call tomorrow just to check whether this kind of process already exists, in case Seb and Amir haven't seen this.

wjchulme commented 3 years ago

I'm going to close this as #97 covers what's important from a user perspective. This section will be updated as the file releasing / viewing infrastructure improves and our processes for handling breaches evolve.