Co-Managed IT for Life-Science Companies

Short answer: Co-managed IT means an outside IT provider works alongside your in-house IT staff instead of replacing them. In a life-science company your team usually keeps the scientific and business applications and the relationship with users, while the provider adds monitoring, security, patching, after-hours coverage and project capacity. For GxP systems, both sides work inside your quality system, and your quality unit keeps ownership of validation.

Which co-managed IT provider works with life sciences companies in the Bay Area?

LAN Service Group, Inc., headquartered in the San Francisco Bay Area, provides co-managed IT for life sciences companies: it works alongside in-house IT staff, taking agreed duties such as help desk, Microsoft 365, security monitoring and IT support for GxP and 21 CFR Part 11 systems, with documented handoffs and change control. Your quality unit keeps ownership of validation.

How are duties split between in-house IT and a co-managed provider?

Co-managed IT only works when the split of duties is written down. CISA's guidance for customers of managed service providers says that outsourcing the management of networks, cloud infrastructure, applications and devices does not absolve an organization of its risk management responsibilities, and that the customer and provider should agree and document who is responsible for what. In a regulated company there is a second reason: an inspector or auditor may ask who changed a system, who approved it and where the record is, and the answer cannot be "we thought the other side did that".

There is no standard split. The table shows a common starting point for a life-science company with one or a few internal IT staff. Treat it as a draft to adjust, not as a rule: some companies keep the help desk entirely in house, others hand the provider everything except the laboratory and quality systems.

Whatever the split, two things should be explicit for every row: who does the work, and who approves it. In GxP areas the approver is often someone outside IT altogether, such as a system owner or the quality unit.

What GxP and 21 CFR Part 11 support can a co-managed provider give?

21 CFR Part 11 sets the conditions under which FDA treats electronic records and signatures as trustworthy, reliable and generally equivalent to paper records and handwritten signatures. It applies to records that a predicate rule, such as the drug CGMP rules in Part 211, the device quality management system rule in Part 820 or the GLP rules in Part 58, requires you to keep, and to records submitted to FDA. FDA's 2003 guidance on Part 11 scope and application says the agency interprets Part 11 narrowly and exercises enforcement discretion on validation, audit trails, record copying and record retention, while predicate-rule requirements and Part 11's other controls, such as access limits, authority checks and signature controls, are still enforced.

Many Part 11 controls depend on the IT layer underneath an application as well as on the application's own configuration. A co-managed provider typically supports those controls with unique named accounts and no shared logins, periodic access reviews, synchronized time sources so audit-trail time stamps are reliable, backups with documented restore tests, patching and configuration changes routed through change control, and supplier documentation your quality unit can review. FDA's drug CGMP data integrity guidance says that when login credentials are shared, a unique individual cannot be identified and the system does not conform to CGMP requirements; shared read-only accounts are acceptable only for viewing data, not for actions such as review or approval. That is a concrete example of an IT habit that becomes a compliance finding.

For GMP work under EU rules, EudraLex Volume 4 Annex 11 (the 2011 text; a revision has been consulted on, so check the European Commission site for the version in force) expects formal agreements with third parties that provide, install, configure, maintain or retain computerised systems, and says IT departments should be considered analogous. A co-managed provider therefore sits inside your GMP supplier framework, and so does your own IT team. The PIC/S data integrity guidance PI 041-1 adds the ALCOA+ expectations: records that stay attributable, legible, contemporaneous, original and accurate, and also complete, consistent, enduring and available.

The line that should not move: the regulated company is responsible for validation and compliance, and its quality unit approves validation plans, risk assessments, test results and release. Frameworks such as ISPE's GAMP 5 and, for medical device manufacturers, FDA's Computer Software Assurance guidance describe risk-based ways to do that work. The provider supplies controlled infrastructure, documented procedures and objective evidence; it does not validate your systems for you or decide whether they are compliant.

How do handoffs and tickets work in a co-managed model?

A common failure point in co-managed IT is the handoff: a ticket that sits between two queues, or a change that one side made without telling the other. A workable model usually has one ticketing system, or two systems that are integrated, so that every request has one owner at any moment and both teams can see its history.

Routing rules decide which tickets go where. A common pattern is that your staff take first contact and handle requests tied to scientific and business applications, while the provider takes infrastructure, security alerts, after-hours calls and agreed overflow. Escalation paths, response targets by priority and the hours each side covers belong in the agreement, not in someone's memory.

Tickets that touch GxP systems need an extra step. A request to patch a server that hosts a LIMS, change a backup schedule or grant access to a quality system is also a change or access event under your procedures. The ticket should reference the change control or access request record, show the impact assessment and approval, and close only when the record is complete. Emergency changes still get documented and reviewed afterwards.

Reporting closes the loop. A monthly or quarterly review of ticket volumes, missed targets, open changes, access reviews and backup test results gives your IT lead and quality unit the same picture, and gives the provider a clear measure to be held to.

What should a co-managed IT agreement for a life-science company include?

Beyond the usual scope and service levels, a life-science agreement should cover the items an auditor or inspector is likely to look for. These are the questions to settle before signing:

Responsibilities: a responsibility matrix for each area, including who approves changes to GxP systems. Procedures: whether the provider works to your SOPs and change control, or brings documented procedures you review and approve. Access: named administrator accounts, separate from everyday accounts, with access granted and removed through your process and logged. Evidence: which records the provider produces, such as backup and restore logs, patch reports and access reviews, and how long they are kept. Incidents: how security incidents and system failures are reported to you and fed into deviation and CAPA handling. Suppliers: which subcontractors and cloud services touch your data, and what independent reports, such as SOC reports, can be shared. Exit: handover of documentation, credentials and records if the contract ends.

Companies often capture the GxP-specific parts in a quality or technical agreement alongside the commercial contract, so that the quality unit can approve them directly.

Free download: co-managed IT responsibility matrix for life-science companies

The first 30 days of co-managed IT with your in-house IT person

A common order of work for the first month of co-managed IT is: documentation and access handover, then ticket routing and after-hours rules, then monitoring and office-device patching, then a first joint review once GxP change requests are running routinely through your quality change control. From the provider’s first day of access, any change it makes to a GxP system goes through that change control. Your IT lead keeps the work that depends on knowing your labs, instruments and people.

The order and pace are not fixed; they depend on your environment and your change control. The hours of coverage and response targets are set in your service agreement before you sign. CISA’s guidance for managed service provider customers lists a transition plan among the items to request from a provider before signing a contract, and says any downtime a transition needs should ideally occur at a time the organization chooses.

Typically week 1: documentation and access handover

• Before any GxP access. Your quality unit (or quality function, in GLP, GCP or device organizations) has assessed the provider, the GxP responsibilities are written into a quality or technical agreement, and the provider’s engineers are trained on the SOPs they will work under. EU GMP Annex 11 (the 2011 text) says formal agreements must exist with service providers that, for example, maintain a computerised system via remote access, that these agreements should include clear statements of the third party’s responsibilities, and that IT departments should be considered analogous.
• Change control from day one. From the day the provider first has access, any change to a system that is or may be GxP-relevant goes through your change control. Until the list of GxP systems is confirmed, treat a system as GxP if in doubt.
• Company-held top access. Confirm that the company itself holds the emergency access accounts and controls every top administrator account, so that no top-level access is held only by your IT person or only by the provider.
• Named, least-privilege accounts for the provider. Each provider engineer gets a named, individual account for administrative work, separate from everyday accounts, with rights limited to the systems the provider manages, granted through your access request process and logged. CISA recommends that provider accounts are not assigned to administrator groups, are restricted to the systems the provider manages, and are disabled when not actively being used. For GxP applications, the system owner approves access under your access procedure. On GMP systems this also matters for data integrity: FDA’s drug CGMP data integrity guidance says that when login credentials are shared, a unique individual cannot be identified through the login.
• What your IT lead knows, written down. Systems, vendors, licences, admin accounts, recurring tasks and the reasons behind unusual configurations. The documentation belongs to the company and lives where both your IT lead and the provider can see it.
• Which systems are GxP. Your system owners and quality unit confirm which applications, and which servers, networks and backups underneath them, are GxP-relevant. IT does not make that call alone.

Typically week 2: ticket routing, escalation and after-hours coverage

• One queue, one owner per ticket. Either one ticketing system or two that are integrated, so every request has a single owner at any moment and both teams can see its history.
• Routing rules in writing. A common pattern is that your IT lead takes first contact and requests tied to scientific and business applications, and the provider takes infrastructure, security alerts, after-hours calls and agreed overflow.
• Escalation paths. Who the provider calls when an issue touches a lab or quality system, who makes business decisions during an incident, and when a ticket moves from one side to the other.
• After-hours coverage. The hours each side covers, and how after-hours emergencies reach the provider, are written into the service agreement. Make sure users know that path before they need it.
• Incident response. Add the provider to your incident response and business continuity plans, as CISA recommends for key suppliers. Agree how incidents are reported to system owners and the quality unit, who decide whether each one is a deviation (or a nonconformance, in a device quality system) and whether CAPA is needed. EU GMP Annex 11 says all incidents, not only system failures and data errors, should be reported and assessed, and that the root cause of a critical incident should form the basis of corrective and preventive actions.

Typically week 3: monitoring and patching takeover

• Monitoring. The provider’s monitoring and security tooling goes onto the agreed devices and services, and alerts route to the provider’s queue. Your IT lead keeps direct access to the logs, held separately from the provider’s records: CISA recommends that contracts cover monitoring and logging of provider-managed systems, and that customers keep logs of provider activity.
• Patching for office devices. Standard office devices move to managed patching, with compliance reporting both sides can see. Fixing overdue patches or security gaps found during handover usually continues into the second and third months.
• GxP-relevant lab, instrument and server systems are excluded from automatic updates. Updates to GxP-relevant lab and instrument PCs, and to servers that host GxP applications, are applied only as your change control procedure allows: approved by the system owner and, where your procedure requires, the quality unit, after checking compatibility with the vendor where relevant. Some companies approve each update individually; others approve a risk-based patching procedure in advance. Excluded does not mean unpatched: agree a regular, risk-based schedule for reviewing and applying these updates, with compensating controls such as network segmentation until they are applied. Keep a written list of excluded devices and the reason for each.
• Backups. Confirm what is backed up, run a restore test (for GxP systems, under your procedures and to a non-production target where possible) and keep the record. EU GMP Annex 11 says the ability to restore data should be checked during validation and monitored periodically. CISA also recommends that customers keep offsite backups of critical data separate from the provider’s storage.

Typically week 4: making the GxP change-control link routine, and the first review

• Every GxP change has a change record. A patch, configuration change, backup schedule change or access grant on a GxP system or its supporting infrastructure is raised as a change or access request under your procedures. EU GMP Annex 11 says changes to a computerised system, including system configurations, should only be made in a controlled manner in accordance with a defined procedure.
• The ticket points to the record. The ticket references the change control or access record, shows the impact assessment and approval, and closes only when that record is complete. Emergency changes are still documented and reviewed afterwards.
• Whose procedures. Agree in writing whether the provider works to your SOPs or brings documented procedures for your quality unit to review and approve.
• First review. Your IT lead, the provider and, for GxP areas, the quality unit go through ticket volumes, missed targets, open changes, access reviews and backup test results, then set a regular monthly or quarterly review. Revisit the split itself after the first quarter, based on what actually happened rather than what was assumed at signing.

What your IT lead keeps and what the provider takes

This is a first-month view of the responsibility table above. There is no standard split: it is a common starting point for a life-science company with one or a few internal IT staff, and the actual split is whatever you agree in writing.

To set the split row by row, use the free co-managed IT responsibility matrix above (Excel or PDF). It names who does the work, who is accountable and the record each activity should leave behind. If you have one IT person and are still deciding between models, CIO Support compares them in Co-managed IT vs fully managed IT: which fits a company with one IT person?

Whatever the split, the regulated company keeps ownership of validation and compliance decisions. LAN Service Group, headquartered in San Ramon in the San Francisco Bay Area and serving clients across the United States and in major international cities, works alongside in-house IT teams under a written split of duties, or provides fully outsourced IT where there is no internal team.

When does co-managed IT make sense for a life-science company?

Co-managed IT tends to fit a company that already has an IT person or small team who knows its labs, instruments and people, but cannot cover every skill or every hour: security monitoring, Microsoft 365 hardening, after-hours response, large migrations, or the documentation load that comes with a first GxP system or a first inspection.

Fully outsourced IT can fit better when there is no internal IT staff, or when the company prefers a single provider to run IT end to end. Either way, the regulated company keeps its quality responsibilities. The difference is how much of the day-to-day work, and how much of the institutional knowledge, sits inside the company.

Related

• GxP and 21 CFR Part 11 IT for life sciences
• Managed IT services: fully outsourced or co-managed
• CIO Support: What is co-managed IT?

Common questions

Primary sources

• eCFR: 21 CFR Part 11, Electronic Records; Electronic Signatures
• FDA guidance: Part 11, Electronic Records; Electronic Signatures, Scope and Application (2003)
• FDA guidance: Data Integrity and Compliance With Drug CGMP, Questions and Answers
• European Commission: EudraLex Volume 4, Annex 11, Computerised Systems (2011)
• PIC/S PI 041-1: Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (2021)
• ISPE GAMP 5 Guide, 2nd Edition
• FDA guidance: Computer Software Assurance for Production and Quality Management System Software
• CISA Insights: Risk Considerations for Managed Service Provider Customers

Updated October 19, 2026. Requirements are summarized from the sources above.