GRC has advocated for greater focus and consideration of cybersecurity controls within healthcare environments. This goes beyond just traditional IT, communications and computing.
Our prior blogs have defined the threats and controls that need to be considered for connected medical devices and “Internet of Things” devices within the medical world. Our advice has always been to ensure “security by design” by manufacturers and explicit (risk assessed) definitions of security, privacy and availability requirements as part of procurements.
We are therefore pleased to note that the European Union Agency for Cybersecurity has published Procurement Guidelines for Cybersecurity in Hospitals. The guide outlines good practices and recommendations for including cybersecurity as part of hospital procurement processes.
Of note, the guide outlines typical threats faced by hospital asset procurements (e.g. supply chain risks, malicious threats and system failure) and puts forward cybersecurity controls across the procurement lifecycle. On a practical side, the guide also suggests the types of evidence that could be sought to assure provider compliance.
The report is aimed at healthcare professionals who hold technical positions in hospitals, i.e. Chief-level executives: CIO , CISO, CTO, IT teams as well as procurement officers in healthcare organisations. Per our prior blogs, it should also be of interest to medical device manufacturers and providers of hospital products (medical devices, clinical information systems, networking equipment, cloud services, etc.). Internal audit, clinical and corporate risk managers, and Audit & Risk Committees can also benefit from this guide.
Although the guide is EU based, it makes good sense to incorporate these suggestions as part of Australian based hospital procurement processes.
However this should extend beyond just cybersecurity. Procurement should also incorporate privacy and availability requirements.
Procured items should only be deployed into operational environments once controls have been stringently tested and validated. Even then, an Incident Response Plan should be in place in the event that controls fail.