Recommend public reporting of incidents and near misses

[manics]

✅ Checklist

• This pull request has a meaningful title.
• If your changes are not yet ready to merge, you have marked this pull request as a draft pull request.

☑️ Maintainers' checklist

• This pull request has had the appropriate labels assigned
• This pull request has been added to the SATRE backlog project board
• This pull request has been assigned to one or more maintainers

⤴️ Summary

Recommends that TREs with public data should make available reports on incidents, near misses, and what was been done as a result

🌂 Related issues

Closes #256

🙋 Acknowledging contributors

• All contributors to this pull request are already named in the table of contributors in the README file.
• The following people should be added to the table of contributors in the README file:

[JimMadge]

Not super confident if my suggestions are the right thing, but I was trying to

• Not introduce a new importance
• Make the statement a bit stronger, everyone should be honest
• Keep the particular emphasis on public trust/responsibility

[manics]

Seems fine to me! Though note I've introduced Mandatory (for TREs with public sector data), otherwise Optional in #272, I can't think of a good alternative since we want the status to be clear, which rules out putting the for TREs with public sector data somewhere else.

[craddm]

Not super confident if my suggestions are the right thing, but I was trying to

• Not introduce a new importance
• Make the statement a bit stronger, everyone should be honest
• Keep the particular emphasis on public trust/responsibility

I think it's good to emphasise public trust where applicable, but isn't it possible to be honest without publicly reporting near misses etc, at least in a commercial setting, where internal reporting might suffice?

[JimMadge]

I think it's good to emphasise public trust where applicable, but isn't it possible to be honest without publicly reporting near misses etc, at least in a commercial setting, where internal reporting might suffice?

I think perhaps only in the case when there are no stakeholders other than the TRE organisation. I'm not sure I see why a TRE operator making profit should change our position.

[manics]

Ideally I'd like to replace all mentions of "public" with "public where public data is held; data owners where private/commercial data is held", but that's too complicated.

[JimMadge]

Ideally I'd like to replace all mentions of "public" with "public where public data is held; data owners where private/commercial data is held", but that's too complicated.

Yes, maybe we need to add a term and define it?

I can see why we are more concerned when the data is about members of the public. However, I also think it is responsible for TREs selling a service to companies to be clear about their security (maybe the issue is public disclosure there?).

[manics]

I think this is something best dealt with in future when we take account of different types of TREs (e.g. opensafely vs desktop), and data tiers- we can have a section for commercial/private TREs.

Coming up with a term now would fix the issue, but Public Involvement and Engagement is a well known term, and trying to include non-public/commercial/private would end up diluting it.

[craddm]

I'm good with leaving as is

[Katie-RDS]

The reporting on close calls and issues was a collab cafe discussion that wasn't limited to public sector data holders but I agree it's only that holds as very mandatory for public sector data and for other types and commercial it's relevant people. Could be summarised as 'disclosed to relevant parties - where TREs hold public sector data this would need to publicly published'

It's an important part in the transparency element

[edwardchalstrey1]

Note: we need to add this statement in the Turing eval