PHP2Shell gave many research teams a crash course in how much they really know about the tools holding their study data. Here are the ten questions worth asking before your next study goes live, and what a good answer sounds like.
The PHP2Shell vulnerabilities forced organisations across Europe to check, in a hurry, which of their systems were exposed. Some teams had the answer within hours. Others are still working it out.
The difference rarely came down to technology. It came down to whether the right questions had been asked before anything went wrong: who updates the system, who watches it, and what happens when something breaks.
Those questions belong at the start of every study, when you choose the eCRF that will hold your data for years. Not in the middle of an emergency.
How to use this list
The questions apply whether your eCRF is self-hosted or provided as a managed service. If your own IT team runs it, ask them. If a vendor provides it, ask the vendor.
Three simple rules make the answers more useful:
- Ask for answers in writing. A conversation is a good start, but only a documented answer can be checked, audited and included in your vendor assessment.
- Ask for evidence, not adjectives. «Highly secure» means nothing. A patching timeframe, an audit report or a recovery test result does.
- Notice the hesitations. An answer of «we’d have to check» is not a failure, but it tells you where to look more closely.
The 10 questions
1. Who applies security updates, and how quickly for critical flaws?
Why it matters: PHP2Shell showed that attackers can move before a fix is even released. The time between a patch appearing and being installed is where most of the risk sits.
A good answer: a named team or role, a defined timeframe for critical vulnerabilities (typically hours or a few days, not weeks) and a recent example of that process in action.
2. What is the platform built on, and how do you track its components?
Why it matters: you cannot patch what you do not know you have. Modern software depends on dozens of underlying components, from programming languages to open-source libraries.
A good answer: a clear description of the technology stack and an up-to-date inventory of its dependencies. The real test is simple: could they tell you within hours whether PHP2Shell affected them?
3. Who monitors the system for suspicious activity, and when?
Why it matters: patching closes the door, but monitoring tells you whether someone got in first. Without it, an intrusion can go unnoticed for months.
A good answer: continuous monitoring with defined alerts, logs kept for a stated period, and a clear owner who responds out of hours.
4. Where is the data hosted, and how is it protected?
Why it matters: jurisdiction affects your obligations under the GDPR, and encryption determines what an attacker could actually read if they reached the data.
A good answer: the country or region where data is stored, a list of any subprocessors, details of any transfers outside the EU, and encryption both in transit and at rest.
5. How and when will you tell us about an incident?
Why it matters: if a breach involves personal data, the organisation responsible for the study has 72 hours to notify the supervisory authority. That clock does not wait for a vendor to finish investigating.
A good answer: a contractual notification timeframe comfortably shorter than 72 hours, a named contact, and a description of what information you will receive.
6. How is access controlled?
Why it matters: many incidents start not with a software flaw but with a stolen password or an account that should have been closed months ago.
A good answer: multi-factor authentication, role-based permissions by study and site, single sign-on where your organisation uses it, and a clear process for removing users who leave a study.
7. What happens to the audit trail and validation after an update?
Why it matters: regulators expect a complete, tamper-evident record of who changed what and when. A security update should never put that record or the system’s validated state at risk.
A good answer: a documented change control process, evidence that updates are tested before release, and an audit trail that meets FDA 21 CFR Part 11 and EU GMP Annex 11 expectations.
8. How often is data backed up, and when was recovery last tested?
Why it matters: a backup that has never been restored is a hope, not a plan. If a server is compromised or taken offline, recovery speed decides how long your study stands still.
A good answer: backup frequency, where backups are stored, how much data could be lost in the worst case, how long recovery takes, and the date of the last successful restore test.
9. What independent evidence can you share?
Why it matters: every provider describes its own security positively. Independent assessments are how you check those claims.
A good answer: recognised certifications such as ISO 27001, recent penetration test summaries carried out by an external firm, and a willingness to support your own audit.
10. If we leave, how do we get our data back?
Why it matters: clinical data must be retained for many years, often longer than any single contract lasts. Being locked into a system is a risk in itself.
A good answer: export in open, documented formats, including metadata and audit trail, a defined handover period, and confirmation of how the data is deleted afterwards.
How Xolomon answers these questions
We apply this same list to ourselves. Xolomon is a managed platform built on Microsoft technology (.NET) and hosted on Azure, on servers within the European Union, with daily backups and compliance with the GDPR, EMA guidelines and FDA 21 CFR Part 11. That is why PHP2Shell did not affect it.
If you are evaluating eCRF options, we are happy to answer all ten questions in writing, and we would encourage you to ask every other provider on your shortlist to do the same.
The bottom line
PHP2Shell will not be the last critical vulnerability to hit the software clinical research depends on. The teams that cope best with the next one will not necessarily have the most advanced tools. They will be the ones who already know who is responsible, how fast they act and how to prove it.
