IT Services for Biotech and Medical Device Companies
Your instruments run software that cannot be patched on somebody else's schedule, and your records have to survive a question asked four years from now. Those two facts decide most of what your IT should look like.
The agreement a regulator expects you to have with us
Why this matters
What getting this wrong costs
2.5%
The upper end of what non-routine quality failures cost device manufacturers as a share of annual sales. Apply that to your own revenue and it stops being an abstraction.
58%
Share of FDA warning letters across a seven-year study that cited corrective and preventive action failures. That is a records and procedures problem before it is a manufacturing one.
19
Device quality-system warning letters issued by early September 2025, against 12 by the same point in 2024. They publish them, under your company name, where your customers can read them.
Cost and warning-letter share from Anderson and Tan, Industrial Engineering & Management 12(5), 2023, analyzing 2013 to 2019; the same study found roughly half of inspected device firms picked up at least one corrective action finding. The 2025 count is Hogan Lovells’ analysis of published FDA actions as at 4 September 2025. None of this is our data and all of it is free to check.
The room the science happens in
The lab is full of computers nobody calls computers
Every instrument has a machine bolted to it, and that machine is usually the oldest and least protected thing you own. None of what follows is unusual or a sign anybody did anything wrong. It is what a working lab looks like.
The instruments and what they run on
The machine attached to the instrument
A sequencer, a mass spectrometer or a plate reader arrives with a computer, and the vendor qualified one exact configuration on it. Change that configuration and you may have to qualify it again, at a cost that can approach what the instrument cost. So the machine sits there untouched for years, and that is usually the right call. The trouble starts with the network it sits on, because from there it can typically reach your file server and your mail.
What to do when you cannot patch it
You compensate, and you write down why. The instrument goes on its own network segment that reaches the two places it needs and nothing else. Removable media gets controlled, because that is how these machines tend to pick something up. Someone keeps a current list of what is on that segment and what version it runs. When an auditor or a customer asks why an unsupported operating system is on your network, the answer is a documented decision with controls around it, and that answer holds up. An undocumented one does not.
Test the alarm the way you test a restore
Freezer and environmental monitoring usually raises an alarm by sending a message. That makes the alarm a mail flow problem as much as a temperature problem, and mail flow changes without anyone thinking about the freezer. A tightened spam rule, a changed sender, an expired license on a monitoring account: any of those can silence an alarm without producing an error anywhere. We test the whole path end to end on a schedule, the same way a backup gets a test restore, because an alarm nobody receives is worse than no alarm at all.
The data coming off them
The bottleneck is rarely the analysis
A run finishes and the files have to get somewhere before anybody can work on them. That first hop, off the instrument and onto storage a scientist can reach, is where the waiting usually happens, and it is a network and storage question before it is a computing one. We measure it before recommending anything, because the answer changes completely depending on whether your files are many small ones or a few enormous ones, and buying the wrong thing is expensive in a way you notice for years.
Where the analysis belongs
Some of this belongs on a workstation under a desk, some on shared hardware, some in the cloud where you pay only for the hours you use. The honest answer depends on how often you run the work and how long a run takes, and we will tell you when the cloud is the more expensive option, because for steady predictable workloads it frequently is. What we will not do is move everything and let you discover the bill in month three.
Who can reach the science
Research groups collaborate, which means outside people get access, and access granted for one project tends to outlive it. Postdocs and visiting researchers leave. A shared drive accumulates a decade of work nobody has reviewed the permissions on. The two questions worth answering before a partner or an investor asks them: who can currently reach the data behind your lead program, and what happened to the access of the last person who left. Both should take minutes to answer, and in most labs they take days.
Records, and who answers for them
What the rules say, as opposed to what you have been sold
This industry is sold a great deal of compliance by people who have not read the guidance. Everything below is quoted or paraphrased from a published document with a date on it, and every one of them is free to read. Open whichever apply.
Part 11 is narrower than you have been told
In September 2003 the agency published a guidance narrowing how it reads Part 11, and that guidance is still current today. Two things in it matter. First, Part 11 bites only where an underlying rule already requires you to keep the record; the agency calls those predicate rules, and they live in the Act and in regulations other than Part 11 itself. Second, it applies where electronic records stand in place of paper. Where people generate printouts and rely on the paper to do the regulated work, the agency generally does not treat that as using electronic records instead of paper. It also stated it would exercise enforcement discretion over validation, computer-generated audit trails, record retention and copying, and over legacy systems that were running before 20 August 1997. What did not soften: records still have to be kept in line with those underlying rules. So the useful question is never whether a system is Part 11 compliant. It is which of your records a predicate rule requires, and whether those specific ones are protected properly.
Validation changed on 24 September 2025
On that date the agency finalized its guidance on Computer Software Assurance for production and quality system software. It supersedes the section of the old General Principles of Software Validation that covered automated process equipment and quality system software, and it moves to a risk-based approach: in the agency's own words, applying a risk-based approach to this software "would better focus manufacturers' assurance activities". In practice that means effort concentrated where a failure would reach a product or a patient, and much less ceremony elsewhere. It is under a year old. If your validation approach has not been revisited since, it is being run to a document the agency has replaced.
The four fields an audit trail has to record
The agency's October 2024 questions and answers guidance is clearer on this than most vendor material. An audit trail has to capture changes to a record, and specifically who made the change, what changed, when, and why. It also settles a question that generates a lot of wasted engineering: the trail is meant to capture deliberate actions such as saving or submitting data, and is not expected to record every keystroke. Knowing that saves money, because a system built to log everything costs more and produces a trail nobody can review.
Your agreement with an IT provider is a regulated document
This one applies specifically to clinical investigations, so it binds you if you are running trials. The same October 2024 guidance says the written agreement between a regulated company and its information technology service provider should set out scope, roles, responsibilities and a data access plan. It then goes further than most providers realize: where a provider has taken on regulatory responsibilities, or where there are data integrity concerns, the agency may inspect the provider. That is a meaningful thing to sign. We would rather have that conversation before an agreement exists than during an inspection, and if you already have a provider it is a fair question to put to them this week.
Making a product as well as running the science puts a second set of rules on you, and those cover the device itself.
They live on the robotics page: the quality regulation that changed in February 2026, plus the evidence a connected product must ship with.
The boundary, stated plainly
What we do, and what stays with your quality people
Plenty of providers in this industry blur this line, and it is the reason some of them get fired in the middle of an audit. Here is where ours sits.
Ours, and we will show you the artifacts
Network segmentation for the instruments and lab systems, with a diagram that matches what is plugged in today
A current inventory of every machine, its operating system and its version, including the ones that cannot be patched and the recorded reason each one stays
Access reviews with dates: who could reach which system, what changed, and when it changed
Backups with a test restore that was actually performed, timed and written down
Change records showing what was altered on which system, by whom, and what approval it had
The technical exhibits your quality team attaches to a submission or hands to an auditor, formatted the way they need it
Your quality function's, and we will not sign any of it
Deciding which of your records fall under a predicate rule, and therefore what Part 11 reaches
Writing and approving validation protocols, risk assessments and acceptance criteria
Determining intended use for each system, which is the judgment everything else hangs from
Signing the validation summary and owning it in front of an inspector
The quality management system itself, and the standard operating procedures under it
Deciding whether a system is fit for its purpose. We can tell you what it does; only they can say whether that is enough
Common questions
Can you make our systems Part 11 compliant?
Nobody can, and a provider who says yes is worth a second look. Compliance is a property of a system in its context and the way your people use it, so it is not something a piece of software or a supplier carries around on your behalf. We can narrow the problem until it is affordable. That starts by working out which of your records an underlying rule obliges you to keep, because that set is usually much smaller than the one you have been quoted for, and then making sure those specific records have the access control, the trail and the retention behind them that they need.
Our instrument runs an old version of Windows and the vendor will not support an upgrade. What now?
You keep it and you contain it, and this is a normal situation and not an embarrassing one. The machine moves onto its own segment that can reach only what the workflow needs. Removable media gets controlled, since a shared memory stick is the realistic infection route. Somebody maintains a list of these machines and what they run, and the reason for keeping each one is written down alongside the controls wrapped around it. Done that way, an unsupported operating system on your network becomes a documented decision, which is defensible. The version of this that fails an audit is the one nobody chose and nobody recorded.
Do you perform validation?
No. Validation rests on judgments about intended use and risk that your quality function has to make and defend, so it stays with them. We build and evidence the environment underneath it. In most audits the technical evidence is the slow part, and producing it in a form your quality team can hand straight over is where we earn our place.
What changed about software validation in 2025?
The Computer Software Assurance guidance was finalized on 24 September 2025 and it replaced the corresponding section of the older validation guidance. The shift is towards risk: heavy scrutiny where the consequences are real, and much less ceremony on a spreadsheet that schedules a meeting. For a lot of firms it means less documentation rather than more, which is an unusual direction for a regulator and is worth taking advantage of. Your quality team owns the response. We are useful for the inventory underneath it, since the exercise starts with knowing what software you have and what each piece touches.
We are running a clinical trial. Does that change what we need from an IT provider?
Yes, and it changes the paperwork between you and us specifically. The agency's October 2024 guidance on electronic systems in clinical investigations says the written agreement with an information technology service provider should cover scope, roles, responsibilities and a plan for data access. It also notes that a provider carrying regulatory duties, or one where data integrity is in question, may be inspected by the agency directly. Most managed service agreements say nothing about any of this. If you are running a trial, that is a gap worth closing before it is tested, and it is a reasonable thing to ask your current provider about today.
We build a device as well as doing research. Is that a different conversation?
Partly. Everything on this page about the lab, the records and the agreement still applies. What gets added is the product itself: the quality regulation that changed on 2 February 2026, and the software bill of materials and patching commitment a connected device now has to carry into a submission. Those obligations produce work in your build pipeline instead of your lab, so we treat them separately and they are covered on the robotics and device page. Firms that do both usually find the device side is where their IT is least ready, because it started as an engineering project rather than a regulated one.
Who can open your lead program's data today?
In most labs that takes days to answer. It should take minutes.
