Healthcare is one of the most frequently targeted sectors in the world. Medical records are valuable, sensitive, and in many cases impossible to undo once in the wrong hands. In June 2024, patient data was stolen from Synnovis, a laboratory services provider for NHS hospitals in London, and later published online. In February 2024, Change Healthcare in the US was breached via a Citrix environment without multi-factor authentication, exposing the medical information of 100 million people. In August 2025, an attack on Clinical Diagnostics (formerly Eurofins) affected close to a million participants in Dutch national screening programmes. And in April 2026, ChipSoft, the supplier of the HiX EPD system to more than 70 per cent of Dutch hospitals, confirmed that patient data had been exfiltrated following an attack by the hacking group Embargo. 

What all these incidents have in common: once any party that healthcare organisations depend on is compromised, the consequences spread across the entire network. These examples come from the broader healthcare sector, but the question they raise is directly relevant to clinical research and data security: how is your research environment set up if a software supplier fails or comes under attack? 

1. What do you require from the supplier your research depends on? 

In clinical research, many critical processes often run through software: study management, data collection, document filing, patient consent. It makes sense to consolidate these with one party, so everything is connected and data does not end up scattered across separate systems. But that makes the choice of that supplier all the more important. If that supplier fails or is attacked, the consequences for data availability, study continuity, and regulatory compliance can be significant. Ask yourself: on what grounds did you choose your software supplier, and when did you last review that choice? 

2. What does your supplier’s certification actually tell you? 

Certifications such as ISO 27001, GDPR compliance, and NHS DSPT provide insight into how seriously an organisation takes information security. ChipSoft held the relevant certifications and was the dominant supplier to Dutch hospital care. Yet a ransomware attack still reached them. That illustrates an important point: certification does not eliminate the risk, but it is a minimum standard that demonstrates a supplier is externally verified on its security processes. It is one of the things you can check, alongside asking how a supplier handles incidents in practice. 

3. Do you know where your research data are stored? 

Sponsors and researchers using a CTMS or EDC platform are data controllers for the study data stored within it. Do you know where your data are stored and under which legal framework? Is the server located in Europe, and if so, with which hosting partner? What does your data processing agreement say about the location of the data? ResearchManager operates its own data centres in Europe and offers data storage in regions worldwide through Microsoft Azure. Which region applies depends on the agreement with your organisation. The responsibility to verify and document this rests with you as data controller. 

4. What does your data processing agreement say about incident notification? 

A data processing agreement with clear provisions on incident notification is not a formality: it is an operational safeguard. In the Clinical Diagnostics incident, Z-CERT had to step in to notify healthcare organisations itself, because the supplier failed to do so. Under GDPR, a 72-hour notification requirement applies. Do you know what your data processing agreement says, and how quickly you would be informed if an incident occurred? 

When a software supplier goes down, the consequences for data availability, access, and trust are immediate. That is why security within ResearchManager is designed as a coherent set of controls rather than a collection of separate measures. 

Access control 

Access to study and patient data is managed on the basis of roles and responsibilities, so users can only access the information they need. 

Audit logging and traceability 

Actions within the platform are traceable through audit logging, keeping changes, exports, and user activities verifiable at all times. 

Risk management and supplier assessment 

Risks are assessed periodically, and suppliers and hosting partners are tested against security requirements. 

Continuity and incident response 

Processes are in place for incident management, change control, and business continuity, so that operational impact is kept as limited as possible when an incident occurs. 

External certification and compliance: 

• ISO 27001 and NEN 7510 certified: annual external audit 

• GDPR compliant: data processing agreements, data minimisation 

• NHS DSPT certified: required for use within UK healthcare organisations 

• Data storage via own data centres in Europe and Microsoft Azure: region configurable per organisation 

• Incident response protocol: aligned with GDPR 72-hour notification requirement 

Ask yourself and your suppliers the following questions: 

• Does my supplier hold a current ISO 27001 certificate? When was the last external audit? 

• Is there a data processing agreement that includes provisions for breach notification within 72 hours? 

• Where are my research data stored, and under which legal framework? 

• What is the contingency plan if the software becomes unavailable or is attacked? 

• How quickly would I be notified of a security incident, and by whom? 

Want to know how ResearchManager answers these questions? Get in touch and we will be happy to explain how our suite is built to remain secure, compliant, and available.