When Your Ops System
Became a Validated System

Three regulatory changes in the last ten months expanded what counts as regulated software. QMSR now treats the quality system as one connected whole, and operations software that used to sit outside the inspection lens is inside it. If your team built its own ops platform, the validation burden lands on you.

For Medical Device Ops & Quality Leaders deviceflow.com

The acronyms, decoded

QSR (Quality System Regulation, 21 CFR Part 820): The US FDA regulation that governed medical device quality systems from 1996 until February 2, 2026. Included §820.70(i), which required validation of production and quality system software.

QMSR (Quality Management System Regulation): The regulation that replaced the QSR effective February 2, 2026. Incorporates ISO 13485:2016 by reference. Broader software validation scope, stronger enterprise-wide QMS framing, and tighter outsourcing and traceability expectations than the QSR it replaced.

ISO 13485:2016 — Clauses 4.1.6 and 7.5.6: The international standard for medical device quality management systems. Clause 4.1.6 requires validation of software used in the QMS. Clause 7.5.6 requires validation of software used in production and service provision. Both are now in US scope via QMSR.

CSV (Computer System Validation): The traditional approach to validating regulated software. Document-heavy. Based on the V-Model: user requirements paired with verification/qualification steps (URS → IQ → OQ → PQ). Still the default expectation for many inspectors.

CSA (Computer Software Assurance): FDA guidance finalized in September 2025. Risk-based, critical thinking–first alternative to CSV. The final version explicitly applies to AI tools used in production or quality systems.

GAMP 5 (Good Automated Manufacturing Practice): ISPE's industry framework for validating computerized systems in regulated environments. Categorizes software by risk and configurability. Second edition published 2022. Updated AI guidance released July 2025.

GAMP Category 5: The highest-risk GAMP classification. Custom-developed software — including in-house code and outsourced bespoke applications — that performs regulated functions. Requires the full validation lifecycle.

PLM / QMS traceability: The audit trail that connects product lifecycle management records (design, engineering change orders, risk files) to quality management records (CAPA, complaints, audits). Under QMSR, inspectors expect to follow a single change across both. Separate, unlinked PLM and QMS systems create the kind of findings that take months to close.

Access provisions: The controls that determine who can read, edit, approve, or override records inside a regulated system — plus the audit trail over those actions. Required by 21 CFR Part 11 and EU GMP Annex 11. Under QMSR, extend into operations systems that feed traceability data.

Annex 11 / Annex 22 (EU GMP): Annex 11 governs computerized systems in EU GMP. Annex 22 is a new draft published July 2025 that specifically addresses artificial intelligence and machine learning in pharmaceutical manufacturing. The EU parallel to FDA's CSA.

21 CFR Part 11: FDA regulation covering electronic records and electronic signatures. Applies to any system of record used for regulated activity. Audit trails, access controls, and record integrity all trace back here.

ALCOA+ (data integrity): The acronym inspectors use when they test your records: Attributable, Legible, Contemporaneous, Original, Accurate — plus Complete, Consistent, Enduring, and Available. Built into Annex 11 and FDA's data integrity guidance.

01

Three things changed in the last ten months

Three regulatory updates hit in ten months. On their own, each one reads as narrow. Stack them together and they close a gap that custom-built ops systems have been sitting in for years — and most ops and quality leaders at device manufacturers didn't notice it happen.

July 2025 — ISPE published the GAMP Guide: Artificial Intelligence

ISPE dropped a 290-page guide on validating AI and machine-learning systems in regulated environments. It builds on GAMP 5 Second Edition (2022) and pushes the risk-based framework into new territory: data governance, model lifecycle, monitoring, and the specific ways adaptive systems break. Nothing in the guide lets AI off the hook. Part 11, Annex 11, and ALCOA+ still apply in full.

September 2025 — FDA finalized Computer Software Assurance (CSA)

The final CSA guidance traded decades of paper-heavy CSV habits for a risk-based approach that asks you to think first and document second. The final version added one line the draft didn't spell out: CSA applies to AI tools used as part of production or quality systems. That single sentence pulled AI-enabled ops software straight into FDA's validation expectations for the first time.

February 2, 2026 — QMSR replaced the QSR

The new rule pulls in ISO 13485:2016 by reference. Clause 4.1.6 ("validate the application of computer software used in the quality management system") and Clause 7.5.6 (same for production and service provision) now apply in the US. That language is broader and more specific than the old §820.70(i), and it catches a lot more of the software running a device commercial operation. QMSR also treats the quality system as one connected whole — not a set of separate workstreams, each with its own paperwork.

On their own, none of these changes are a big deal. Together, they say out loud what regulators have been hinting at for years: the software behind your operations gets inspected the same way as the software inside the device. And inspectors now have the playbook to do it.

02

Where the scope actually widened

The most common reaction we hear is "we already validate our QMS software — what actually changed?" Short answer: the scope of what counts as regulated software just got bigger. The longer answer is worth a minute.

What was already required

§820.70(i) has required you to validate production and QMS software since 1996. Device-manufacturing automation, MES systems, and formal eQMS platforms have been in scope for three decades. If your team is surprised that ops software is regulated, the surprise isn't that the rule is new. It's that enforcement finally caught up.

What QMSR + ISO 13485:2016 add

ISO 13485 doesn't use the §820.70(i) framing. It uses two clauses that, together, catch more software than the old production-focused wording:

Clause 4.1.6 — QMS software

Covers any software you use in the quality management system. Document control, training records, CAPA, complaints, audits, supplier management. You have to validate it, and the effort has to match the risk.

Clause 7.5.6 — Production and service software

Covers software you use in production and service provision. In commercial ops, that pulls in order processing, inventory tracking, consignment management, case coordination, and anything touching UDI, lot, or serial data.

And what CSA makes explicit

FDA's final CSA guidance is what finally closes the AI gap. It tells industry that the risk-based framework applies to AI tools "used as part of production or quality systems." Before September 2025, you could argue the rules hadn't caught up to the technology. After September 2025, that argument's gone. The guidance names it directly.

An ops system that reads purchase orders, routes charge sheets, tracks consigned inventory, or kicks off invoicing sits inside Clause 7.5.6. If any part of it uses AI, CSA applies on top. Section 03 covers the non-software expansions in the same rule.

03

What QMSR specifically asks you to show

QMSR isn't just a software validation rule. It redraws the lines around the quality system itself. Five expansions are tripping up manufacturers right now — each one pulls records, systems, or people into the inspection lens that used to sit outside it under QSR.

1. The QMS is one connected system, not several Design controls + quality ops, in the same frame

A lot of manufacturers used to run design controls as one workstream and quality operations as another. QMSR closes that gap. Inspectors expect to follow a single change — a CAPA, a design change, a complaint — all the way across the system and see every linked record along the way. Findings cluster at exactly the places where those workstreams don't connect. The records themselves are rarely missing. The links between them are.

2. Management review has teeth Inputs, outputs, evidence of engagement

ISO 13485:2016 spells out the inputs and outputs for management review in a way the QSR never did. A signed quarterly dashboard doesn't prove leadership is engaged. Inspectors want to see how executive decisions turn into priorities, CAPAs, and resource allocation — and how the loop actually closes. "Leadership reviewed and approved" is a claim. Inspectors want the trail that backs it up.

3. Outsourced activities come inside the system Quality agreements, audit rights, documented oversight

If a contract manufacturer, contract lab, or service provider handles any piece of design or production, your QMS has to cover that relationship explicitly. You need quality agreements. You need audit rights. You need documented oversight. For companies leaning on CMOs or CROs, this is often the biggest source of surprise findings — you outsourced the activity, but the quality obligation never left you.

4. Traceability spans PLM and QMS ECO → risk file → CAPA → design records → complaint

An engineering change order should trace to the risk file, to the CAPA that triggered it, to the design records it modifies, to the complaint that started the chain. When your PLM and QMS sit in separate systems with no link between them, you can't show that trace — even if every record exists somewhere. The spike in demand for integrated PLM and QMS since February isn't vendor marketing. It's companies reacting to what inspectors started asking for. The teams struggling hardest in the first round of QMSR inspections are the ones running separate PLM and QMS with no good link between them.

5. Audit access extends into operations systems Full access provisions inside order, inventory, case, and billing systems

This one trips up more ops leaders than any other. Under QSR, a lot of operations systems — order management, inventory, charge-sheet handling, consignment tracking — sat outside the inspection lens. Under QMSR, the moment those systems feed traceability for UDI, lot, serial, complaint, or recall data, they're in scope. Inspectors can follow the chain from a complaint record straight into the ops system that generated the shipment. Full access provisions — who can read, who can edit, who approves overrides, and who audits the access itself — now apply inside systems people used to call "just operations." If your ops system doesn't carry its own Part 11–grade audit trail, the inspection trail dead-ends there. And the finding lands on the quality system that should have required it.

Same thread runs through all five expansions. Individual records aren't usually what's missing. The links between them are. Most QMSR findings don't say "you didn't document this" — they say "show me how this connects to that." Connecting the dots is where inspections now live.

04

GAMP Category 5: the classification you inherit

Once the dust settles on a regulatory shift, the question that matters is: where does your system land? GAMP 5 sorts software into four categories by risk. Each one carries a different validation depth. Custom-built ops software lands in the most demanding category by default.

Category 1 — Infrastructure

Operating systems, databases, middleware. Validated via standard qualification of the platform.

Category 3 — Non-configured COTS

Off-the-shelf software used as delivered. Vendor-supplied validation package carried over with risk-based user-side verification.

Category 4 — Configured COTS

Off-the-shelf platform configured for your processes. Vendor validation covers the core; configuration-specific qualification is on you.

Category 5

Custom-developed software

In-house code, outsourced bespoke applications, significantly modified open-source frameworks. The full validation lifecycle applies. No vendor package to rely on. You own every artifact.

04

Why vibe-coded ops systems land in Category 5

ISPE is specific on this point. Your system is Category 5 if your team "develops new features or rewrites significant portions" of the software — even if you started with an open-source framework. That description covers nearly every in-house ops tool we've seen: a Python script parsing emails into your ERP, a SharePoint app tracking trunk stock, a no-code platform stretched with custom integrations, an AI-assisted prototype somebody stitched together over a weekend.

The framework underneath doesn't lower your category. If the business logic is custom — and for an ops system, it always is — you're in Category 5.

The AI overlay

AI-enabled systems sit inside Category 5, with an extra layer of expectations from the ISPE GAMP AI Guide: data governance, model-lifecycle documentation, and monitoring. The guide calls out stochastic behavior and model opacity as new risk factors. Input data profiling, drift monitoring, re-training protocols, and defined escalation paths for model failure are named artifacts now — not engineering nice-to-haves.

Category 5 isn't a judgment on the engineering. A well-built Category 5 system can be excellent software. Good code just changes how much the validation work has to fix. It doesn't shrink what the validation package has to contain.

05

What Cat 5 validation actually requires

Validation isn't a single document. It's a lifecycle. GAMP 5's V-Model pairs every requirement with a verification step, documented end-to-end and kept current for the whole operating life of the system. CSA lets you match the effort to the risk — but the artifacts still have to exist.

The artifacts you will produce

User Requirements Specification (URS) Who uses it, what it does, under what conditions

You write this before the code. It traces to every downstream artifact. A missing URS is the single most common reason validation packages fail inspection.

Functional and Design Specifications (FS / DS) How it meets each requirement

The engineering docs that link your requirements to architectural choices. For AI-enabled systems, that includes data strategy, model selection, and guardrails.

Installation / Operational / Performance Qualification (IQ / OQ / PQ) Built right, works right, works in your environment

Protocols and executed evidence. IQ checks installation. OQ checks that the system performs under controlled conditions. PQ checks performance against real operational loads and real users. Signed, dated, and every deviation documented.

Requirements Traceability Matrix (RTM) Every URS line mapped to a qualification test

The document an auditor asks for first. If a requirement doesn't trace to a test, you didn't validate it.

Access provisions — Part 11 / Annex 11 grade Role-based access, approval workflows, audit trail over the access itself

Role-based access with named approvers. The system logs every record create, edit, or delete with user, timestamp, and reason. Electronic signatures capture every override. The access log itself stays read-only and tamper-evident. Under QMSR, this bar applies to any ops system in scope — which, as Section 03 covers, now includes the ones feeding UDI, lot, serial, complaint, or recall data.

Change control, backup/restore, CAPA Ongoing operational controls, not one-time artifacts

Validation doesn't stop at go-live. Every change to the system runs through change control. Every failure triggers a CAPA. Every record has to meet ALCOA+. GAMP flags all three as non-negotiables for AI-enabled systems in particular.

Supplier qualification Who built the code, and is their SDLC trustworthy

For Category 4 (configured COTS), the vendor's development process carries the supplier qualification load for you. For Category 5, if the vendor is your own team, you have to document your own SDLC, code review, testing, and release controls the same way a real vendor would.

50–100%

More validation effort than COTS

ISPE GAMP 5 categories guidance, 2024

~80%

Of AI projects fail to reach production

RAND Corporation, 2024

30 yrs

Ops software has been in FDA scope since 1996

21 CFR §820.70(i)

06

Build-vs-buy, reframed

Build-vs-buy usually comes down to cost and feature-fit. Validation changes the math. When you build your own regulated system, you're not picking the cheaper option — you're taking on two jobs, software vendor and operator, each with its own regulatory load.

When you buy a validated system

Category 4 (configured COTS) lets you rely on the vendor's validation package. The vendor owns SDLC, change control, release testing, access-control architecture, and supplier qualification for the core product. You own configuration, training, operational procedures, and the role-based access decisions inside your tenant. The load splits, and you inherit proof someone built the base correctly.

When you build your own system

No vendor to rely on. You produce the SDLC evidence. You qualify yourself as a supplier. You document every code change, model update, re-trained dataset, and deployment. Every artifact a vendor would ship, you produce. Every control an inspector would ask the vendor about, you answer for.

The cost most build decisions miss isn't engineering. It's the validation and quality overhead that never stops. GAMP is explicit: Category 5 systems take 50–100% more validation effort than equivalent COTS deployments. Annual overhead, not a one-time spend.

The real question isn't "do we have the engineering talent?" It's "do we have the QA, validation, change control, and access-provision muscle to own a Category 5 system for its full operational life?" For most commercial teams running lean on both engineering and quality, the honest answer is no.

The middle path that doesn't exist

"Build now, validate later" is the common response. It's also the one that fails at inspection. GAMP's prospective validation principle is explicit: validation activities have to trace back to requirements captured before development. Retroactive validation looks retrospective — and inspectors notice.

07

What we learned validating with a customer in April 2026

In April 2026, we ran a customer-driven QMS validation of Deviceflow alongside a manufacturer customer preparing for their first FDA inspection under QMSR. It was the first time we produced the full package in a live regulatory context — not as a theoretical exercise. Three things only became obvious once we were in it.

Validation is a package, not a document

The binder is twenty-plus artifacts: URS, FS, DS, IQ/OQ/PQ protocols and executed evidence, RTM, release notes, change control records, supplier qualification package, access-control matrices and audit-trail exports, data integrity controls, model-lifecycle docs for the AI components, backup and recovery procedures, incident response playbooks, and training records. Each artifact has to reference the others and trace back to a requirement. One broken link ties up the whole package.

The vendor package actually carries weight

CSA and GAMP both let the customer rely on the vendor's validation package. For our customer, that meant we produced the SDLC evidence — they didn't. We qualified the platform. They qualified the configuration, the training, the operational procedures, and the access provisions they set up inside their own environment. Their validation load came out to a fraction of what Category 5 would have required if they'd built the same system in-house.

07

Where the inspection actually focused

Traceability across PLM and QMS was the pressure point

The customer's inspectors zeroed in on how a CAPA traced back to an engineering change, and how a complaint record traced forward into the shipment data in their ops system. That trace has to be one linked record chain — not three screenshots from three different systems. The ops data we feed had to show up in the same audit-trail frame as their design and quality records. The inspection focused on how things connected, not the individual pieces.

The AI overlay isn't optional

GAMP AI guidance names monitoring, model change control, and data governance as ongoing obligations. Our package covers model-version control, input data profiling, drift monitoring, and a defined re-training protocol. None of these are "nice to have." They're the artifacts an inspector looks for the moment a system includes any AI component.

The customer's upside

Compliance wasn't the only benefit. The customer got a validated platform with a supplier-produced package they could point to during inspection. They kept their internal quality team focused on device-level validation, where their expertise belongs. The ops automation didn't pull QA time away from the device itself. That split is what matters when headcount is tight.

The hardest part of the inspection wasn't producing any single artifact. It was keeping the links alive between them — from requirement through qualification, from change control through audit trail, from complaint through ops record. A validated package holds together because of its cross-references. That's where inspection pressure lands.

08

The decision framework

Walk through these eight questions before your team commits to building — or before you sign off on a proposal to build. A quality auditor will ask the same questions. We've just translated them into operational language.

1. Who owns the URS? Named individual, documented before code

Your user requirements have to exist in writing before any development starts. The owner has to be a named person inside the quality organization — not the engineer writing the code.

2. Who performs IQ/OQ/PQ, and against what protocol? Independent of the developer

The person running qualification can't be the same person who built the feature. Document the protocol, execute it, log the deviations, and route them through CAPA.

3. How does change control work on day 91? Defined SOP, named approvers

Every deployment after go-live counts as a change. Who approves it? Who re-qualifies the affected components? Where does the record live? Without a real SOP, your validated state doesn't survive the first bug fix.

4. Supplier qualification — of yourselves Internal SDLC evidence

If the "vendor" is your internal team, your SDLC becomes the qualification package. You need code review evidence, test coverage, release procedures, and incident response. Without that package, you can't qualify yourself as a supplier.

5. Access provisions — to Part 11 / Annex 11 grade Role-based access, approval workflows, tamper-evident audit trail

Who can read. Who can edit. Who approves overrides. Who audits the access itself. Under QMSR, all of this applies to any ops system feeding UDI, lot, serial, complaint, or recall data. If your self-built system doesn't log every create, edit, and delete with user, timestamp, and reason, the inspection trail dead-ends there.

6. Traceability across PLM and QMS One linked chain across engineering, quality, and ops records

An ECO should tie to the risk file, the CAPA, the design records, the complaint, and the shipment data in your ops system — all in one linked chain. If the answer to "show me how this connects" is "let me open three systems," your trace isn't inspection-ready.

7. Model and data governance — if AI is involved Model versioning, drift monitoring, data lineage

The GAMP AI Guide names all three explicitly. They sit on top of the Cat 5 baseline — not in place of it.

8. Who owns the package at year three? Named QA/validation owner in the org chart

Validation packages fall apart when their owners leave. "Who owns this in three years?" is the question that separates systems that stay validated from systems that drift into the next inspection finding.

If fewer than six of these questions have a clear answer, the honest call is to buy a Category 4 platform whose vendor has already done the Category 5 work for you.

Sources

Regulatory text, ISPE guidance, and FDA publications cited

Primary regulatory sources

US FDA. "Medical Devices; Quality System Regulation Amendments." Final rule, 89 FR 7496, February 2, 2024. Effective date February 2, 2026. Incorporates ISO 13485:2016 by reference.
ISO 13485:2016 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clauses 4.1.6 (QMS software validation), 5.6 (management review), 7.4 (purchasing and outsourced processes), and 7.5.6 (production and service software validation).
21 CFR §820.70(i) — Automated processes. Pre-QMSR validation requirement for production and QMS software, effective 1997.
21 CFR Part 11 — Electronic Records; Electronic Signatures. Access provisions, audit trail, and record integrity foundation for all computerized systems used in regulated activity.

FDA guidance

US FDA. "Computer Software Assurance for Production and Quality System Software." Final guidance, September 2025. Explicitly applies to AI tools used as part of production or quality systems.

ISPE GAMP guidance

ISPE. "GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems." Second Edition, 2022.
ISPE. "GAMP Guide: Artificial Intelligence." Released July 2025. 290 pages covering data governance, model lifecycle, and AI-specific risk assessment.
ISPE GAMP 5 category guidance, 2024 — "organizations often allocate 50–100% more effort for Cat 5 validation versus a COTS project of similar size."

EU GMP reference

European Commission. EU GMP Annex 11 — Computerised Systems. Revised draft 2025. Foundation for access provisions and audit trail requirements in computerized systems used in GxP.
European Commission. EU GMP Annex 22 — Artificial Intelligence. Draft published 7 July 2025, public consultation closed 7 October 2025.

Industry context

McKinsey & Company. "The economic potential of generative AI: The next productivity frontier," 2023 — estimates $60–110 billion in annual value potential for pharma.
RAND Corporation. "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed," 2024 — documents an AI project failure rate above 80%.
Deviceflow customer validation package, April 2026. Internal reference — customer-driven QMS validation completed for a manufacturer customer preparing for FDA inspection under QMSR.

Next Steps

Ops automation that ships with a validation package

See the validation package before you evaluate the software.

Send us your quality agreement template and your list of validated systems. We will walk you through Deviceflow's validation package — URS, IQ/OQ/PQ protocols, RTM, supplier qualification, access provisions, audit-trail exports, and AI model-lifecycle documentation — and show you what the customer actually has to produce on their side.

1

Share your quality agreement

Your current template. Your existing supplier qualification criteria.

2

Walk the package

We review our validation package against your criteria and identify gaps.

3

Leave with a plan

A split of what we own vs. what your team owns for your configuration.

hello@deviceflow.com deviceflow.com

When Your Ops SystemBecame a Validated System

Contents