The Compliance Stack in Life Scienc...

21 CFR Part 11, GxP, HIPAA, GDPR, ICH, and the rest. What each framework covers, who it applies to, and what it actually requires from the product.

Most software categories sell on capability. Faster, smarter, cheaper, more accurate. Life sciences software sells on capability too, but only after passing through a layer that does not exist in most other markets. The compliance layer.

This layer is the reason a lab informatics platform with the same database engine as a fintech tool costs ten times more, takes eighteen months to deploy, and ships with a thousand-page validation package. It is the reason a perfectly good general-purpose AI chatbot is commercially unusable in pharma until it can show traceable, auditable provenance for every answer. It is the reason vendors that nail the compliance architecture early outpace better-funded competitors who treat it as a finishing-step feature.

For anyone evaluating, building, or selling life sciences software in 2026, the compliance stack is not optional knowledge. It determines what you can sell, who you can sell it to, and how long it will take.

This article maps the major frameworks. What each one covers, who it applies to, when it kicks in, and what it actually requires. The frameworks are grouped by what they regulate: records and signatures, quality systems, privacy, international harmonisation, security, medical devices. Each one targets a different risk surface, and most life sciences software has to address several at once.

Quick Reference: Which frameworks applies?

Most life sciences software products fall into more than one row.
The sections below cover each in detail.

Records and Signatures: 21 CFR Part 11

21 CFR Part 11 is a regulation issued by the US Food and Drug Administration in 1997. It covers electronic records and electronic signatures used in FDA-regulated activities. The premise is straightforward: if your business is required to keep paper records under FDA regulations, and you choose to keep them electronically instead, the electronic versions need to be at least as trustworthy as paper.

In practice, this is the single most influential regulation for life sciences software. Almost every product category that touches drug development, manufacturing, or clinical research has to be Part 11 compliant by design.

The core requirements:

Validated systems. The software must be tested and documented to perform as intended. Validation is not a one-time event. Every change requires re-validation.
Audit trails. Every creation, modification, or deletion of a record has to be captured automatically, with timestamp and user identity, and the audit trail must be tamper-proof. FDA's data integrity guidance (final 2018, building on the 2016 draft) draws an explicit line between "static" and "dynamic" records: a static PDF export is not sufficient. The audit trail must be preserved in a format that allows interaction with the record content, so reviewers and inspectors can reconstruct the full course of events with metadata intact. Vendors that ship only PDF export as their "audit trail capability" are producing a compliance artefact, not compliance.
Electronic signatures. If a signature is legally binding (approving a batch record, signing off on a clinical data lock, releasing a product to market), the system has to support two-component authentication and link the signature to the record permanently.
Access controls. Only authorised users can access records, and those permissions are themselves auditable.
Record retention and copy capability. Records must be readable and exportable for the duration of FDA's retention period, often decades.

Who needs it: Any vendor selling into FDA-regulated workflows. That is most of pharma, biotech, clinical research, and medical device manufacturing.

When it kicks in: The moment electronic records or signatures are used in a regulated activity. There is no minimum threshold.

Common categories where it is non-negotiable: ELN, EDC, LIMS, CTMS, eTMF, MES, QMS, regulatory information management, pharmacovigilance.

Common misconception: Part 11 is not a certification. There is no such thing as a "Part 11 certified" product. Vendors can claim Part 11 readiness, but compliance ultimately sits with the user. The software has to enable compliance, and the customer has to operate it compliantly.

Quality Systems: The GxP Family

GxP is shorthand for Good Practice quality guidelines. The "x" stands in for whatever activity is being regulated. The most common variants:

GLP (Good Laboratory Practice). Preclinical, non-clinical safety studies. Issued by FDA, OECD, and others.
GCP (Good Clinical Practice). Clinical trials involving human subjects. Defined by ICH E6, adopted by FDA, EMA, PMDA, and most regulators globally.
GMP (Good Manufacturing Practice). Pharmaceutical and biologics manufacturing. Codified in 21 CFR Parts 210 and 211 for FDA, EU GMP for Europe.
GDP (Good Distribution Practice). Storage, transport, and distribution of medicinal products.
GVP (Good Pharmacovigilance Practice). Monitoring drug safety after market authorisation.

These are not laws by themselves. They are quality system frameworks codified by regulators. Failure to follow them in regulated activity is what creates legal liability.

What software has to do depends on which Gx applies, but a few principles are universal across the family:

Data integrity. The ALCOA+ principles: data must be Attributable, Legible, Contemporaneous, Original, and Accurate, plus Complete, Consistent, Enduring, and Available.
Validation. Systems are formally qualified before use, and revalidated after material changes. The level of rigour scales with risk.
Change control. Modifications to validated systems are documented, reviewed, approved, and tested.
Training records. Users are trained on the system, and training is documented.
Deviation management. When something goes outside the controlled state, it is captured, investigated, and resolved on the record.

GxP and 21 CFR Part 11 overlap heavily in regulated US workflows. A GMP manufacturing system needs Part 11 controls because it produces electronic records under FDA jurisdiction, and it needs GMP controls because the activity is manufacturing. Vendors often describe themselves as supporting "GxP and Part 11" because in practice both apply.

A note on GAMP 5. The Good Automated Manufacturing Practice guide, published by ISPE and now in its Second Edition (July 2022), is not a regulation. It is the industry-standard framework for risk-based validation of computerised systems in GxP environments. Regulators do not require GAMP 5, but they recognise it, and most pharma quality teams use it as the default model for how validation should be scoped. The Second Edition explicitly aligns with modern realities: cloud computing, agile development, AI/ML, and the FDA's shift toward Computer Software Assurance (more on which below).

Risk-Based Validation: From CSV to CSA

For decades, "validation" in regulated software meant Computer System Validation (CSV): exhaustive scripted testing, thick documentation binders, and full revalidation after every meaningful change. The approach was thorough. It was also famously slow, expensive, and a known bottleneck for adopting new technology in pharma manufacturing and quality.

That is changing. On 24 September 2025, FDA's CDRH and CBER finalised the long-awaited guidance "Computer Software Assurance for Production and Quality System Software", followed by an updated version on 3 February 2026 aligning with the new Quality Management System Regulation (QMSR). The guidance formally endorses Computer Software Assurance (CSA) as the recommended approach for validating production and quality system software. Technically, the guidance applies to software used in medical device production and quality systems, not to SaMD or SiMD. Pharmaceutical manufacturers are not directly bound by it, but the risk-based principles are widely adopted across pharma QA as best practice, and the 2026 QMSR alignment accelerates that convergence.

What changes in practice:

Intended use first. Assurance starts from what the software is supposed to do, not from a generic checklist. The depth of testing is driven by the risk that the software's failure introduces.
Right-sized assurance. High-risk features (those that could lead to severe harm, automated batch release, safety-critical surveillance) get scripted or hybrid testing with full traceability. Low-risk features can be assured with exploratory testing and clear acceptance criteria. The total documentation burden shrinks.
Vendor evidence is leverageable. Buyers no longer need to recreate every test the vendor already performed. CSA encourages reuse of supplier-generated evidence where appropriate.
Cloud and continuous updates are explicitly addressed. The 2026 update incorporates NIST-based definitions of IaaS, PaaS, and SaaS, and the framework explicitly covers automation tools, analytics platforms, and AI/ML systems used in production or QMS.
Lifecycle, not event. Assurance is maintained continuously as the software evolves. This finally accommodates SaaS vendors that ship updates weekly.

CSA is not a free pass. The guidance still requires that high-process-risk features get rigorous, documented testing. What it removes is the requirement to apply that level of rigour to everything, regardless of risk.

For software buyers, CSA changes what to expect from vendors. Modern vendors should be able to articulate which features carry process risk, what assurance evidence they provide, and how their architecture supports continuous validation rather than freeze-and-revalidate cycles. Vendors still selling the old CSV model (long binders, every release a project) are increasingly hard to deploy in CSA-aligned quality systems.

The QMSR alignment is significant on its own. Effective 2 February 2026, FDA's Quality System Regulation (21 CFR Part 820) incorporates ISO 13485:2016 by reference. US and international device QMS expectations are now substantially harmonised, which will ripple into pharma over time.

Privacy: HIPAA and GDPR

Privacy regulations apply when software processes personal data. In life sciences, this most often means data about patients, study participants, or healthcare professionals.

HIPAA

The Health Insurance Portability and Accountability Act is a US federal law. The piece relevant to software is administered through three rules:

Privacy Rule. Defines who can use or disclose protected health information (PHI) and under what conditions.
Security Rule. Specifies administrative, physical, and technical safeguards for PHI in electronic form.
Breach Notification Rule. Requires notification to individuals, HHS, and sometimes the media in the event of a breach.

HIPAA applies to "covered entities" (providers, health plans, clearinghouses) and their "business associates" (any vendor handling PHI on their behalf). Most life sciences software vendors that touch identifiable patient data sign Business Associate Agreements (BAAs) with their customers.

Important nuance: clinical trial data that has been de-identified per the HIPAA Safe Harbor or Expert Determination methods is not PHI, and HIPAA does not apply. This is why traditional EDC platforms can operate without BAAs. Decentralized trial platforms that handle patient identifiers, telehealth visits, or wearables data typically do need them.

GDPR

The General Data Protection Regulation is an EU regulation in force since 2018. Its scope is broader than HIPAA: it covers all personal data of EU residents, not just health data. Health data falls under Article 9 as a "special category" with additional protections.

Key requirements relevant to software:

Lawful basis. Every processing activity needs a lawful basis. For clinical research, this is usually consent or scientific research interest under specific national derogations.
Data subject rights. Individuals can request access, rectification, erasure (with research exemptions), portability, and restriction.
Data protection by design. Privacy controls have to be built into the system architecture, not bolted on.
Data residency. Transfers outside the EU require specific safeguards (Standard Contractual Clauses, adequacy decisions, Binding Corporate Rules).
DPO and DPIA. Many controllers require a Data Protection Officer, and high-risk processing requires a Data Protection Impact Assessment.

For software vendors, GDPR creates real product decisions. Where is data hosted? Can a customer choose EU-only hosting? How are subject access requests handled inside the platform? These are increasingly buyer questions, not legal afterthoughts.

International Harmonisation: ICH

The International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use is an organisation that develops harmonised guidelines for drug development across regulators. ICH is not a regulator itself. Its guidelines become enforceable when individual regulators adopt them.

Most major regulators (FDA, EMA, PMDA, Health Canada, and more) have adopted the core ICH guidelines. For software, the relevant ones include:

ICH E6 (Good Clinical Practice). The global standard for ethical and scientific quality in clinical trials. The latest revision, E6(R3), modernises the framework around risk-based approaches and integrated technology.
ICH E2B. Standardised electronic format for individual case safety reports in pharmacovigilance.
ICH M2 / M8. Electronic Common Technical Document (eCTD) standards for regulatory submissions.
ICH Q9. Quality risk management principles, foundational to modern manufacturing software.
ICH E9. Statistical principles for clinical trials.

For software, ICH compliance usually means supporting standardised data formats, workflows, or risk frameworks that regulators expect to see in submissions. A clinical trial platform without ICH E6 alignment is hard to operate. A pharmacovigilance system that does not produce E2B-compliant case reports is unusable.

CDISC standards (SDTM, ADaM, SEND) operate in the same family of expectations. They are not strictly ICH, but they are required by FDA and PMDA for clinical study data submissions, and they overlap with ICH M11 (clinical study protocol template).

Security: ISO 27001 and SOC 2

These two are not life sciences specific. They are general information security frameworks. They show up in life sciences procurement because pharma security teams require them from any vendor with access to sensitive data.

ISO 27001

An international standard for Information Security Management Systems (ISMS). The current version is ISO 27001:2022. Certification is granted by accredited bodies after audit. The standard is risk-based: organisations identify their information assets, assess risks, and implement controls drawn from Annex A.

Pharma buyers increasingly treat ISO 27001 as table stakes for SaaS vendors handling clinical, manufacturing, or commercial data. Without it, procurement conversations stall.

SOC 2

A US-developed audit framework from the AICPA. It evaluates a service organisation's controls against five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. SOC 2 reports come in two types: Type I describes controls at a point in time, Type II evaluates them over a period (usually six to twelve months).

SOC 2 Type II is the version pharma security teams typically want to see. It demonstrates that controls have been operating effectively, not just that they exist on paper.

In practice, vendors selling globally pursue both. ISO 27001 satisfies European buyers and signals international rigour. SOC 2 satisfies US buyers and is often cheaper to maintain.

Medical Devices: ISO 13485, EU MDR, EU IVDR

When software is itself classified as a medical device, an entirely separate regulatory layer applies.

ISO 13485. The international quality management system standard for medical device manufacturers. Required as the QMS framework for any organisation seeking medical device approval.
EU MDR (Regulation 2017/745). Governs medical devices in the EU. Software as a Medical Device (SaMD) falls under this regulation when it has a medical purpose. Risk classes range from I (lowest) to III (highest), with Notified Body involvement required from Class IIa upwards.
EU IVDR (Regulation 2017/746). Governs in vitro diagnostics, including software used to interpret diagnostic results. Risk classes A through D.
FDA pathways for SaMD. The US uses 510(k), De Novo, and PMA pathways depending on classification and predicate availability.

This category is expanding rapidly. AI-driven diagnostic platforms, clinical decision support tools that influence treatment decisions, and certain digital therapeutics all fall into device territory. Vendors who built initially as research tools and then crossed into clinical decision support often discover late that they have triggered medical device classification, and the regulatory backlog is significant.

AI in Life Sciences Software: The EU AI Act

The EU Artificial Intelligence Act (Regulation 2024/1689) is the first comprehensive horizontal AI regulation in the world. For life sciences software vendors selling into Europe, it adds an entirely new compliance layer on top of MDR, IVDR, and the existing data protection regime.

The classification logic is straightforward and consequential: AI systems used as medical devices, or as safety components of medical devices that require Notified Body conformity assessment, are automatically classified as high-risk under the AI Act. This includes most AI-enabled SaMD: diagnostic algorithms, clinical decision support tools, AI-driven imaging, predictive monitoring systems.

What high-risk classification triggers:

Risk management system dedicated to AI-specific risks (algorithmic bias, model drift, adversarial robustness), maintained throughout the lifecycle.
Data governance. Training, validation, and test datasets must meet quality criteria, be representative of the intended population, and be assessed for bias.
Technical documentation. Detailed records of model architecture, training methodology, performance characteristics, and known limitations.
Transparency and instructions for use. Deployers must understand what the system does, its accuracy, its limitations, and how to interpret outputs.
Human oversight. AI systems must be designed so that human users can effectively oversee operation, including the ability to override outputs.
Accuracy, robustness, cybersecurity. Performance must be appropriate for intended use, with resilience to errors and adversarial inputs.
Post-market monitoring. Continuous monitoring of real-world performance, with reporting of serious incidents.

The 2026 timeline:

2 February 2025: prohibited AI practices and AI literacy requirements (Article 4) became applicable.
2 August 2025: obligations for general-purpose AI models took effect.
2 August 2026: most provisions for high-risk AI systems became applicable. This is the date that bites for AI systems listed in Annex III, and for AI literacy obligations across all providers and deployers.
2 August 2027: Article 6(1) provisions for AI systems embedded in products requiring third-party conformity assessment (CE-marked medical devices under MDR, IVDs under IVDR). This is the deadline that applies to most AI-enabled SaMD.

A "Digital Omnibus" simplification package proposed by the European Commission in February 2026 may extend several of these deadlines further, but as of this writing the original timelines remain the binding baseline for planning. AI literacy obligations under Article 4 are not affected by the Omnibus and apply from August 2026.

The practical consequence for vendors: AI-enabled SaMD now requires dual compliance. The MDR or IVDR file, including ISO 13485, IEC 62304, ISO 14971, and clinical evaluation. And the AI Act file, with its own data governance documentation, bias assessment, transparency artefacts, and post-market monitoring of model performance. The two can be integrated into a single quality system and a single Declaration of Conformity, but the obligations are distinct.

For US-based vendors planning EU market entry: AI Act compliance cannot be backloaded. Data governance and bias assessment requirements reach into how training datasets were assembled, often years before the product comes to market. Vendors that did not document data provenance and representativeness during model development face significant remediation work to enter the EU.

The US has chosen a different path. FDA continues to authorise AI/ML-enabled medical devices through existing pathways (510(k), De Novo, PMA), with the additional Predetermined Change Control Plan framework allowing certain model updates without re-submission. There is no equivalent to the AI Act's horizontal high-risk obligations. This means AI-enabled life sciences software faces meaningfully more compliance friction in Europe than in the US, at least for now.

Cybersecurity and Supply Chain: NIS2, CRA, and SBOM

Until recently, cybersecurity in life sciences software was treated as an information security topic, not a regulatory one. ISO 27001 and SOC 2 covered most of what buyers asked for. That has changed. From 2024 onwards, cybersecurity has become its own regulatory layer, with binding obligations, defined penalties, and direct executive accountability.

Three frameworks now sit at the centre of this layer.

NIS2 Directive

The NIS2 Directive (Regulation 2022/2555) is the EU's expanded cybersecurity law, replacing the original NIS Directive. It came into force in January 2023, with a transposition deadline of 17 October 2024. As of early 2026, roughly two thirds of EU member states had completed national transposition, with the remainder in advanced legislative stages.

The directive divides regulated organisations into two categories: essential entities (under stricter supervision) and important entities (subject to ex-post supervision). For life sciences, the classifications matter:

Essential entities include hospitals, laboratories, manufacturers of pharmaceutical products including vaccines, and entities producing critical medicines listed in shortage prevention frameworks.
Important entities include manufacturers of medical devices and in vitro diagnostics, manufacturers of basic pharmaceutical products, and biotech research facilities.

The directive applies to medium-sized and large companies (50+ employees or EUR 10 million+ turnover) operating in covered sectors, and extends to non-EU companies offering services in the EU.

What it requires:

Risk management measures. Article 21 mandates "appropriate and proportionate" technical, operational, and organisational measures across ten domains, including incident handling, supply chain security, vulnerability disclosure, cryptography, and access control.
Incident reporting. A 24-hour early warning, a 72-hour notification with initial assessment, and a final report within one month.
Supply chain security. Entities must assess and manage cybersecurity risks introduced by direct suppliers and service providers. This is what reaches downstream into software vendors that themselves may not be in scope but supply customers who are.
Governance accountability. Executive bodies are personally responsible for approving and overseeing cybersecurity risk management. Senior management can be held personally liable for non-compliance.

Penalties: up to EUR 10 million or 2% of global annual turnover for essential entities, up to EUR 7 million or 1.4% for important entities.

For software vendors selling into EU pharma or biotech, NIS2 changes the procurement conversation. Buyers now have to evidence that their supply chain meets cybersecurity standards. Vendors that cannot demonstrate this credibly become a procurement liability.

EU Cyber Resilience Act (CRA)

The Cyber Resilience Act (Regulation 2024/2847) entered into force on 10 December 2024. It is the first horizontal EU regulation imposing cybersecurity requirements directly on products with digital elements: hardware and software placed on the EU market.

Important nuance for life sciences: medical devices regulated under MDR or IVDR are explicitly excluded from the CRA, on the grounds that they are already covered by sector-specific regulation. The same exclusion applies to vehicles and aviation. This means a CE-marked SaMD diagnostic does not need separate CRA compliance.

But most life sciences software is not a medical device. Lab informatics platforms, manufacturing execution systems, ELN platforms, research tools, scientific informatics, commercial systems, and the vast majority of SaaS products serving pharma and biotech do fall within CRA scope. For those vendors, CRA introduces:

Security by design. Products must be designed and developed with cybersecurity built in, including secure default configurations.
Vulnerability handling. A documented process for identification, remediation, and disclosure throughout the product lifecycle.
Software Bill of Materials (SBOM). Required for technical documentation in machine-readable format.
Vulnerability and incident reporting. Manufacturers must report actively exploited vulnerabilities and severe security incidents to ENISA. The reporting obligation kicks in 11 September 2026 — earlier than full CRA application.
Five-year minimum security support period from market placement, or product lifetime if shorter.
CE marking under the CRA framework once full requirements apply on 11 December 2027.

Penalties: up to EUR 15 million or 2.5% of global annual turnover.

The 11 September 2026 vulnerability reporting deadline is operationally significant. Vendors that do not have an SBOM and a functioning vulnerability monitoring process by that date cannot meaningfully comply, because they will not know whether their products contain components affected by reported exploits.

Software Bill of Materials (SBOM)

An SBOM is a structured inventory of all software components in a product, including open-source libraries, third-party modules, transitive dependencies, and their versions and licences. The standard machine-readable formats are CycloneDX and SPDX.

SBOM has moved from best practice to legal requirement on both sides of the Atlantic, with different scope and timing.

United States. Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023 and effective from 29 March 2023, makes SBOMs a legal requirement for FDA "cyber devices" — devices with software that have the ability to connect, are validated by FDA, and contain software. Failure to provide an SBOM is a prohibited act under Section 301(q) of the FD&C Act. FDA may refuse to accept premarket submissions that lack adequate SBOM documentation. The February 2026 update to FDA cybersecurity guidance, aligned with QMSR, frames SBOM as part of configuration management under ISO 13485 rather than as a standalone compliance artefact.

For non-cyber medical devices, FDA strongly recommends SBOMs as part of cybersecurity documentation in premarket submissions. In practice, the recommendation is followed almost universally, because submissions without SBOMs face delays and additional review cycles.

European Union. Under the CRA, SBOMs become a binding requirement for all products with digital elements (with the medical device exclusion noted above). Full SBOM requirements apply from 11 December 2027, but vulnerability reporting from September 2026 effectively requires earlier readiness. Documentation must be retained for at least 10 years after market placement.

International. The IMDRF N73 guidance ("Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity") provides high-level best practices adopted across multiple regulators.

What an SBOM enables in practice: when a new vulnerability is published, organisations with SBOMs can query their inventory and know within minutes whether they are affected. Organisations without SBOMs spend days or weeks doing manual code archaeology. The Log4Shell vulnerability in 2021 made this contrast operationally clear, and was a major driver of subsequent regulatory action.

How These Three Interact

For a software vendor selling into EU pharma in 2026:

The pharma customer is likely an essential entity under NIS2 and is therefore obligated to manage supply chain cybersecurity risk. They will require evidence of vendor security maturity.
The vendor's own product may be subject to CRA if it is not a medical device, with vulnerability reporting kicking in September 2026 and full requirements by December 2027.
The vendor's product likely needs to ship with an SBOM, both to support the customer's NIS2 supply chain assessment and to meet CRA technical documentation requirements.
If the product is a medical device, CRA does not apply directly, but NIS2 supply chain expectations still flow through, and US Section 524B SBOM obligations may apply for FDA submissions.

The practical consequence: ISO 27001 and SOC 2, while still important, are no longer sufficient to evidence cybersecurity in regulated procurement. Buyers now ask about SBOM availability, vulnerability disclosure policy, security update commitments, and incident response capabilities. Vendors who cannot answer these questions credibly are increasingly excluded from serious procurement processes.

A Niche Worth Knowing: GCLP

Good Clinical Laboratory Practice is a guideline developed by the British Association of Research Quality Assurance and adopted internationally for clinical trial laboratories. It bridges GCP (clinical trial conduct) and GLP (lab quality). Niche, but important for any platform supporting clinical trial sample analysis.

How Compliance Maps to Product Categories

The frameworks above do not apply uniformly. Different software categories sit in different parts of the regulatory map.

A clinical trial management system has to address ICH E6, 21 CFR Part 11, plus HIPAA or GDPR depending on participant geography, plus NIS2 supply chain expectations from EU pharma customers. A LIMS in a GMP-regulated lab has to address GMP, Part 11, ISO 27001 if cloud-hosted, and increasingly CRA if it is not a medical device. A pharmacovigilance platform lives at the intersection of GVP, ICH E2B, Part 11, and global breach notification rules. A SaMD diagnostic platform layers ISO 13485, EU MDR or IVDR, the EU AI Act if AI-enabled, plus everything above if it operates in regulated workflows.

Compliance scope is one of the fastest signals of what a tool actually does. A vendor that lists 21 CFR Part 11, GxP, HIPAA, and ICH on its website is selling into clinical or commercial pharma operations. A vendor that lists ISO 27001 alone is probably selling an analytics or research tool that does not touch regulated records. A vendor that lists nothing is either pre-regulatory (research only) or has not done the work yet.

What the Market Looks Like

Across the 2,652 software tools tracked in the Life Sciences Digital database (April 2026), the distribution of compliance support is informative:

21 CFR Part 11: 43.8% of tools
GxP: 39.9%
HIPAA: 18.3%
GDPR: 15.4%
ICH: 12.4%
ISO 27001: 8.3%
SOC 2: 5.2%
ISO 13485: 4.4%
EU MDR: 2.9%
GCLP: 0.7%

Two patterns stand out.

The first is the gap between Part 11 / GxP and everything else. Roughly four in ten tools were architected for FDA-regulated electronic records. That is the largest single segment of the life sciences software market. The other six in ten target adjacent spaces: research, analytics, commercial, market intelligence.

The second is the relatively smaller HIPAA and GDPR figures. They reflect the structure of life sciences workflows. Most software in pharma, biotech, and lab operations does not touch identifiable patient data. Discovery, manufacturing, regulatory, scientific informatics: these handle structured molecular, chemical, and process data. Privacy regulations bind only when patients enter the picture, which happens in clinical trials, real-world evidence, decentralized trials, and patient engagement.

The medical device numbers (ISO 13485, EU MDR) are still small relative to the database, but they are the fastest-growing compliance segment, driven by AI diagnostics and clinical decision support entering regulated territory.

Practical Takeaways for Buyers

A few principles that hold up in practice:

Treat compliance scope as a fast filter. A vendor's compliance disclosures tell you more accurately than its homepage what part of the pipeline it was built for.
Be specific about what you actually need. "GxP-compliant" is meaningless without specifying which Gx and at what assurance level. Ask for the validation package, not the marketing claim.
For SaaS vendors, separate platform compliance from your own. The vendor demonstrates that its software can be operated compliantly. You demonstrate that you operate it compliantly. The line between these is responsibility you cannot delegate.
For Part 11 in particular, ask for a recent vendor audit report or independent assessment. Self-attestation is the floor, not the ceiling.
Watch for compliance theatre. Vendors who claim "Part 11, GxP, HIPAA, GDPR, ISO 27001, SOC 2" without distinguishing scope, status, or geography usually have not done the work in any of them.
International buyers should think early about data residency. EU customers are increasingly requiring EU-only hosting. US-only SaaS architectures create real procurement friction.
Ask for the SBOM and the vulnerability disclosure policy. Both are now standard procurement questions in regulated environments. Vendors who cannot produce an SBOM in CycloneDX or SPDX format, or who have no published process for handling vulnerability reports, are signalling cybersecurity immaturity that NIS2-bound buyers cannot accept.