Last week, the PHP project released emergency fixes for PHP2Shell, two critical flaws that let attackers take control of an unpatched web server without logging in. In the days since, the reaction across clinical research has followed two very different patterns.
Teams running software on their own servers have spent the week finding out which applications use PHP, who installed them and whether anyone had applied the update. Teams using managed platforms have mostly done something simpler: asked their provider for written confirmation, then checked the answer.
That contrast is worth looking at closely. Not to declare a winner, but because the choice between self-hosted and managed software decides who carries the security workload when something like PHP2Shell happens. And as this week has shown, that is not a theoretical question.
Two models, one responsibility
Self-hosted means the software runs on infrastructure your organisation owns or controls, usually managed by your own IT department. You decide where the servers sit, when updates are applied and who has access.
Managed SaaS means the provider hosts, maintains and secures the platform, and your team accesses it through a browser. Updates, monitoring and backups are part of the service.
The responsibility for protecting study data never disappears in either model. It is either held in-house or shared with a provider under contract. The difference lies in where the day-to-day work sits, and how visible it is.
What happens when a critical flaw appears
Every serious vulnerability triggers the same chain of tasks, whichever model you use:
- Find out. Someone has to notice the alert, ideally within hours.
- Locate. Identify every system affected, including the ones nobody remembers installing.
- Test. Check that the update will not break the application or the data it holds.
- Apply. Install the fix, or take the system offline until you can.
- Investigate. Review logs for signs that someone got in before the patch.
- Document. Record what was done and when, for auditors, sponsors and ethics committees.
With self-hosted software, every one of those steps falls to your IT team, alongside everything else they are responsible for. With managed software, the provider carries steps one to five, and your job is to confirm they did so and keep the evidence.
The chain matters because PHP2Shell showed how short the window can be. Attack attempts were detected before the official fix was even released, and exploit code became public within a day.
Where self-hosting makes sense
Self-hosting is not a mistake, and for some organisations it is the right choice:
- Full control. You decide exactly where the data sits and who can reach the infrastructure.
- Existing capacity. Large hospitals and universities often have mature IT and security teams already patching hundreds of systems.
- Customisation. Some groups need deep integration with local systems that is easier on their own servers.
- Cost structure. Where infrastructure and staff already exist, the marginal cost can be low.
The trade-off is that security depends on internal processes working every time. The risk is rarely the technology itself. It is the research tool installed by one group years ago, maintained by someone who has since moved on, and missing from the IT inventory.
Where managed SaaS works well
A managed platform shifts the operational load to a provider whose core job is keeping that platform running and secure:
- Dedicated attention. Patching and monitoring one platform at scale, not one application among hundreds.
- Speed. A single update protects every study and every customer at once.
- Continuity. Backups, monitoring and disaster recovery are built into the service.
- Less burden on research teams. Investigators and data managers can focus on the study, not the server.
The trade-off is dependency. You rely on the provider’s response, so their commitments need to be clear, written into the contract and verifiable. «Trust us» is not a security policy.
Outsourcing the work is not outsourcing the responsibility
There is one point both models share, and it is often misunderstood. Choosing a managed platform does not hand over your regulatory responsibility.
Under the GDPR, the organisation running the study remains the data controller, and the provider acts as a processor on its behalf. If a breach occurs, the controller still has to notify the supervisory authority within 72 hours. Good Clinical Practice guidelines also expect sponsors to oversee the computerised systems and vendors involved in their trials.
In practice, that means managed SaaS changes how you exercise control, not whether you do. Instead of patching servers, you review contracts, request evidence and ask the right questions at the right time.
Questions to ask, whichever model you choose
If you run your own systems, put these to your IT team. If you use a provider, put them to the provider, and ask for the answers in writing.
- Who applies security updates, and within what timeframe for critical flaws?
- Who monitors the system for suspicious activity, and how often?
- Where is the data hosted, and under which jurisdiction?
- How and when will we be told about an incident?
- Which external audits or certifications cover the platform?
- How is the system validated after an update?
- If we leave, how do we get our data back, and in what format?
If any answer is «we’re not sure», that is the place to start, regardless of what happened with PHP2Shell.
Where Xolomon stands
Xolomon is a managed platform. It is built on Microsoft technology (.NET) and hosted on Azure, on servers within the European Union, which is why PHP2Shell did not affect it. We still reviewed every system we run, including our corporate website, which does use PHP and holds no clinical data.
We do not think managed is automatically the better choice for everyone. We do think every research team deserves clear answers to the questions above, from whoever is responsible for their data.
The takeaway
PHP2Shell will be patched and, in time, forgotten. The question it raised will not. In clinical research, where data has to stand up to scrutiny for years, the most important security feature is not a technology. It is knowing exactly who is responsible and being able to prove they acted in time.
