Computer Software Assurance for Standalone Lab Instruments: Right-Sizing the Testing

What Is in Force for Lab Instrument Software Today

Before deciding how much to test, a lab needs a clear picture of which documents carry legal weight and which are guidance, drafts, or industry practice. Teams often treat all of them as equal, and that is where much of the over-testing and under-testing starts. Here is the status as of late October 2026, checked against the primary documents.

FDA’s CSA Guidance: Final, but Written for Devices

FDA’s guidance titled “Computer Software Assurance for Production and Quality Management System Software” was issued on February 3, 2026. It supersedes the version issued on September 24, 2025.¹ It was prepared by CDRH and CBER, in consultation with CDER and other offices, and its scope statement covers computers and automated data processing systems used as part of production or the quality management system “for medical devices.” Its legal anchor is the device Quality Management System Regulation, which incorporates ISO 13485:2016 into 21 CFR Part 820 and, as the guidance notes, took effect on February 2, 2026.¹

That has two plain consequences for a pharma or biotech QC lab. First, CSA is not a drug CGMP requirement, and an FDA drug investigator will not cite you for failing to follow it. Second, the guidance is still the clearest statement FDA has published on how to scale software assurance to risk, and CDER was consulted on it. Drug companies use it by analogy, and that is a reasonable thing to do as long as the drug predicate rules are still met. The guidance itself is nonbinding: it says the word “should” in agency guidance means something is suggested or recommended, not required.¹

The parts that matter most for instruments are the risk framework, the definitions of unscripted testing, the statement that manufacturers can start from a vendor’s own development and validation work, and Table 1, which sets out what the record should contain for each type of testing. We use all four later in this article.

The Drug CGMP Rules That Apply to Your Lab

For a drug QC lab, the core CGMP text is short and has not changed in years. Part 11 also applies to the electronic records and signatures the instrument software creates. Section 211.68(a) allows automatic, mechanical, and electronic equipment, including computers, and requires that it be “routinely calibrated, inspected, or checked according to a written program designed to assure proper performance.” Section 211.68(b) requires controls so that only authorized personnel change records, requires input and output checks, and says “The degree and frequency of input/output verification shall be based on the complexity and reliability of the computer or related system.” It also requires backup that is “exact and complete” and “secure from alteration, inadvertent erasures, or loss.”²

Section 211.160(b)(4) requires calibration of instruments at suitable intervals under a written program with limits for accuracy and precision, and says instruments not meeting established specifications shall not be used.³ Section 211.194(a) requires laboratory records to include complete data from all tests, and (a)(4) adds “all graphs, charts, and spectra from laboratory instrumentation.” Section 211.194(d) requires complete records of the periodic calibration.⁴

Note the phrase in 211.68(b): complexity and reliability. The regulation has always allowed checks to scale with the system. A risk-based approach to lab instrument software is not a new freedom granted by CSA. It is how the drug rule was written. FDA’s data integrity Q&A guidance for drug CGMP makes the same point in its answer on workflow validation: “The extent of validation studies should be commensurate with the risk posed by the automated system.”⁵

USP <1058>: The 2017 Text Is Still the Official One

USP general chapter <1058>, Analytical Instrument Qualification, is the reference most QC labs use to decide how to qualify an instrument. The current version was published in the First Supplement to USP 40 and became effective on August 1, 2017.⁶ It keeps the three-group model (Groups A, B, and C) and, compared with the 2008 text, it integrates instrument qualification with software validation, makes users responsible for specifying their own needs, and maps its software types more closely to GAMP 5.⁶

A complete revision was published for comment in Pharmacopeial Forum 51(2) in March 2025, with comments accepted until May 31, 2025.⁷⁸ The draft renames the chapter “Analytical Instrument and System Qualification” (AISQ), places the familiar DQ, IQ, OQ, and PQ stages inside a three-stage life cycle (specification and selection; installation, performance qualification, and validation; ongoing performance verification), and adds sections on risk assessment, calibration, change control, and roles.⁷ According to R.D. McDowall’s review of the draft, it also splits the groups into subtypes, A1 and A2, B1 to B3, and C1 to C3.⁹

We could not find any USP announcement of an official date for the revised chapter as of this writing. Until USP publishes one, the 2017 text is the chapter in effect, and procedures should cite it. The draft is still useful reading now, because the direction it takes (life cycle thinking, risk assessment that sets the extent of work, ongoing verification) matches what CSA and GAMP already say.

GAMP and the European View

ISPE’s GAMP 5 Guide, Second Edition, is the industry framework most companies use for computerized systems, and FDA’s CSA guidance lists it in a footnote as a resource on current testing methods.¹¹⁰ For labs specifically, ISPE’s GAMP Good Practice Guide on GxP Compliant Laboratory Computerized Systems is still in its Second Edition, published in October 2012.¹¹ In Europe, EudraLex lists the January 2011 Annex 11 as current; the revised Annex 11 is still a draft. The 2011 text says decisions on “the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system.”¹² PIC/S PI 041-1, the PIC/S data integrity guidance dated July 1, 2021, is written to support GMP and GDP inspectors and is the most specific of these documents on simple and standalone systems.¹³

Why Standalone Instruments Get Tested Wrong

Standalone instruments fall between two departments. To the lab, a pH meter is equipment, managed by the metrology or calibration group. To IT, a PC under a bench that is not on the domain is not their system. To validation, the instrument arrives with a vendor IQ/OQ binder, so it looks done. Nobody owns the question of whether the software and the data are under control.

The Over-Testing Pattern

Over-testing usually comes from a validation procedure written for large systems and applied without adjustment. A UV-Vis spectrophotometer with vendor software gets a full user requirements specification, a functional specification copied from the vendor brochure, a traceability matrix, and scripted tests for every function on every menu, each with a screenshot. The vendor’s OQ is then repeated by the user because the procedure says the user must execute OQ. None of this extra work finds defects, because the functions tested are the vendor’s standard functions that thousands of other labs run every day.

The effort is not only wasted. It pushes the lab to delay new instruments, to keep old ones running past support, and to resist software updates because each update means another round of scripts. Those habits create their own compliance risk.

The Under-Testing Pattern

Under-testing is the more serious failure, and it is the one FDA writes about. A few examples from published warning letters show how consistent it is.

• In a September 2025 warning letter to Persōn & Covey, Inc., FDA described a spectrophotometer used for an active ingredient assay where “System Administrator” was the only user type in the instrument software, laboratory staff shared a common password for Windows and the software, and audit trails were not independently reviewed.¹⁴ The same section describes a bulk intermediate that failed the active ingredient test four times before it was released for further processing on a later passing result.
• In a June 2024 letter to Landy International, FDA said a stand-alone GC computer system lacked an audit trail and individual log-ins, investigators found “numerous analysis reports, test methods, raw data calibration, and system directories” in the computer’s recycling bin, and staff “used a shared password, located in an unsecured drawer” to access the software.¹⁵
• In a June 2019 letter to Akorn, FDA found that data could be deleted and altered on instruments including an FTIR, a total organic carbon analyzer, and a particle size analyzer, that chemists had full administrator access to the Windows folder on the FTIR computer, and that “standalone laboratory instruments were not backed up.”¹⁶
• In a May 2026 letter to Laboratorios Jaloma, FDA said a GC instrument “was not adequately qualified because you failed to validate the control software or enable audit trails,” that file dates were inaccurate, and that the firm did not back up data on the GC computer.¹⁷

None of these findings is about a missing test script. Each is about a basic control that was never set up or never checked: unique accounts, an audit trail switched on, a backup, an accurate clock. A lab that spends its validation effort on scripted functional tests of vendor menus, and none on these controls, has its priorities reversed.

The Common Root Cause

Both patterns come from treating the instrument as a single thing that is either “validated” or “not validated.” CSA, Annex 11, and the drug data integrity guidance all push the other way: look at intended use, look at the functions you depend on, and look at the record. When you do that, two things happen at once. Most of the functional testing disappears, and a short list of controls becomes non-negotiable.

Two Questions That Classify Any Instrument

A practical classification for standalone instruments needs to be simple enough that a lab supervisor and a QA reviewer reach the same answer in a few minutes. We use two questions. The first is about the software. The second is about the record and the decision it supports.

Question 1: How Complex Is the Software?

USP <1058> groups and GAMP software categories describe complexity from different starting points, and they line up reasonably well.

• USP Group A covers standard apparatus with no measurement function that needs calibration, where conformance is confirmed by observing that it works. The AISQ draft splits this into apparatus with no metrological function (A1) and apparatus that needs no user calibration (A2).⁹ There is no software to assure in any meaningful sense.
• USP Group B covers instruments with firmware that measure or control a parameter and need calibration, which typically includes balances, pH meters, and many titrators. Under the 2017 chapter, firmware can be assured indirectly through qualification of the instrument, embedded calculations the lab relies on are verified, and any user-defined programs are specified, built, and tested.⁶
• USP Group C covers instrument systems controlled by separate software, usually on a PC: UV-Vis with vendor software, plate readers, FTIR, and chromatography systems. The 2017 chapter splits Group C software into nonconfigurable, configurable, and configurable with custom additions, which correspond closely to GAMP Categories 3, 4, and 5.⁶

One rule from the 2017 chapter matters more than the group labels: the intended use of the instrument decides the group, not the instrument type. The chapter dropped its list of example instruments for exactly this reason.⁶ A balance used only to check approximate fill weights in a non-GxP development lab and a balance that weighs reference standards for release assays are the same model, with different groups in practice.

Question 2: What Record Does It Create, and What Decision Depends on It?

This is the question labs skip, and it is the one regulators care about most. Three record types cover almost every standalone instrument.

• A printout or direct reading is the original record. FDA’s data integrity guidance says that during data acquisition “pH meters and balances may create a paper printout or static record as the original record,” and in that case the printout or a true copy must be kept.⁵ PIC/S PI 041-1 describes the same case for very simple systems that do not store data, and expects the printout to be signed, dated, and labeled with sample or batch identity and attached to the testing record.¹³
• A static electronic record is stored by the instrument or its PC. The instrument keeps results in memory or in files, and the lab may export them. The electronic file may be the original record, which brings backup and access control into scope.
• A dynamic record can be reprocessed. FDA uses the FT-IR spectral file as its example: it can be reprocessed, so a printout “would not satisfy CGMP requirements to retain original records or true copies.”⁵ Chromatography data, plate reader raw reads that feed curve fits, and spectral data in general fall here.

Then ask what decision depends on the record. A result used for batch release or stability carries more weight than an in-process check that a later test will confirm, and both carry more than a reading taken in a development lab that never feeds a GxP decision. This mirrors the CSA guidance’s distinction between functions that “Measure, inspect, analyze and/or determine acceptability of product or process with limited or no additional human awareness or review” (high process risk) and functions that collect data for monitoring and review (generally not high process risk).¹

Putting the Two Answers Together: Four Assurance Tiers

Combining the two questions gives four tiers. This is our working model, not a regulatory category; it is a way of writing down a risk decision so that it is consistent from one instrument to the next.

There is a fifth outcome that belongs in the same procedure: the instrument is not used for any GxP purpose. The CSA guidance recommends that manufacturers “document their decision-making process” for whether software is used as part of production or the quality system.¹ A one-line record that a plate reader in a discovery lab never produces GxP data, with a periodic check that its use has not changed, prevents a later argument with an auditor.

A Sample Risk Table for Common Lab Instruments

The table below shows how typical standalone instruments in a drug QC lab tend to classify. It is illustrative. The same model can fall in a different tier at your site because the intended use, configuration, or record is different. Treat each row as a starting hypothesis that the instrument owner and QA confirm.

How to Read the Table

Two patterns stand out. The first is that moving a balance or pH meter from a printer to a PC moves it up two tiers, even though the weighing itself is unchanged. The measurement risk is the same. The record risk is not, because the original record is now an electronic file on a PC that someone has to protect.

The second is that the tier is driven by the record and the decision more than by the instrument’s price or size. A plate reader is a modest instrument, but if its curve-fit template calculates a potency result for release, the template is configuration that directly produces a reported value. The CSA guidance makes the same distinction with a spreadsheet: basic input functions used to document readings may need nothing beyond vendor and installation activities, but custom formulas that calculate statistics used in the quality system “might” need additional validation by the manufacturer.¹ A curve-fit template is a custom formula in this sense.

What the Table Leaves Out on Purpose

The table does not list functional tests of standard vendor features such as wavelength scanning, peak detection, or report printing. Those are covered by the vendor’s development and testing and by the instrument OQ. What the table does list is the set of things only your lab can check: your configuration, your templates and methods, your users, your data path, and your records.

Using the Vendor’s IQ/OQ Without Handing Over Your Judgment

Every major instrument vendor sells IQ/OQ services, and for most standalone instruments the vendor’s engineer is better placed to run them than the lab is. The regulatory texts are clear that you can use this work. They are equally clear that you remain responsible for deciding whether it is enough.

What the Sources Allow

The CSA guidance says that, through established purchasing controls, a manufacturer “could incorporate the software development practices, validation work, and electronic information already performed by developers of the software as the starting point and determine what additional activities may be needed,” and that “For some lower-risk software features, functions, and operations, this may be all the assurance that is needed by the manufacturer.”¹ Annex 11 says “Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled,” and that the need for a supplier audit should be based on risk.¹² McDowall’s reading of the 2017 USP chapter is that it expects suppliers to write specifications users can compare with their needs, and requires a technical agreement between user and supplier for support and maintenance of Group B instruments and Group C systems.⁶

Industry practice still lags. Authors writing in ISPE’s Pharmaceutical Engineering in 2024 called vendor risk management, audits, and inspection programs “significant industry gaps,” while noting that a documented vendor audit in good standing can reduce testing of out-of-the-box functions.¹⁸

What to Check in a Vendor IQ/OQ Package

Reviewing a vendor protocol is a short exercise if you know what to look for. These are the checks we find most often decide whether the package is usable as is.

• Ranges match your use. A wavelength accuracy test at points far from your assay wavelengths, or a balance test that does not cover the minimum weight you weigh, does not demonstrate fitness for your intended use.
• Acceptance criteria are stated before execution. A protocol that records results and then declares them acceptable is a report, not a test.
• The software version tested is the version installed. Vendors update instrument software often. The IQ should record the version and the OQ should be run on it.
• Configuration happened before OQ. If the vendor engineer runs OQ on a default configuration and the lab then sets up users, methods, and templates, the OQ did not test what you use.
• Raw data from the OQ is retained. A summary certificate without the underlying readings leaves you unable to show what was measured.
• The engineer’s qualifications and the reference standards used are recorded and traceable. This is basic, and it is often missing.

What the Vendor Will Never Test

A vendor OQ confirms the instrument performs to its specification. It does not confirm that your lab has set it up correctly for your work. The gap is predictable and almost always the same list: user accounts and roles as you configured them, whether the audit trail is on and covers the events you need, your methods and templates, your calculations, where data files are saved and whether analysts can delete them, backup and restore, and the PC clock. These items are where the warning letters above found problems, and they are where the user’s own testing belongs.

Where Unscripted and Exploratory Testing Fits

Once the vendor package is accepted, the remaining testing for most standalone instruments is small. The question is what form it should take. The CSA guidance gives labs more room here than many procedures allow.

The Testing Types FDA Describes

The guidance defines unscripted testing as “Dynamic testing in which the tester’s actions are not prescribed by written instructions in a test case.” It includes scenario testing (also called ad hoc testing), and experience-based testing, which covers error guessing (tests built from knowledge of past failures or common failure modes) and exploratory testing (tests the tester designs and runs on the spot, based on knowledge of the system and earlier results).¹ Scripted testing is testing in which test cases are recorded and then executed, and the guidance says the detail of each test case depends on the risk.¹

The guidance does not tie testing types to risk levels in a fixed way. It says high process risk functions may call for scripted testing or a mix of scripted and unscripted, and functions that are not high risk may be tested with unscripted methods, but it also says that unscripted testing “may be better suited” even for some high-risk functions and that scripted, automated tests may suit lower-risk ones.¹ The choice is a judgment, and the record should show the reasoning.

How the Testing Types Map to the Tiers

Error Guessing on a Standalone Instrument PC

Error guessing is especially well suited to standalone instruments, because the failure modes are well known and published. An experienced tester can work through a list like this in an hour or two on a Tier 3 system, logged in as a routine analyst:

• Try to delete, rename, or move a result file through the application and through Windows Explorer.
• Try to change the Windows date and time, or the instrument software clock.
• Try to turn off the audit trail or change its settings.
• Try to save a result to a USB drive or a local folder outside the configured path.
• Reprocess or recalculate a saved result and check whether the original is kept and the change is in the audit trail.
• Edit a method or template and check whether the change is recorded and whether the old version is retained.
• Enter a wrong password repeatedly and check whether the account locks.
• Look for a generic or shared account still enabled on the PC.

Most items on that list trace back to a failure described in one of the warning letters above. Others, such as USB use and failed logins, come from the access and security expectations in PIC/S PI 041-1, which asks for USB ports to be controlled and for systems to log successful and unsuccessful login attempts.¹³ Account lockout is ordinary good practice. Testing these items is a direct check on the failure modes inspectors look for.

What the Record Should Look Like

Unscripted testing still needs a record. FDA’s Table 1 says the record for exploratory testing includes the intended use, the result of the risk analysis, a summary of the objectives tested, issues found, a conclusion on acceptability with resolution of issues, who did the testing and when, and review and approval where appropriate. For exploratory testing the plan is high-level objectives with pass and fail criteria, and “no step-by-step procedure is necessary.”¹ The guidance also recommends using digital records such as system logs and audit trails, rather than screenshots, where the software already keeps them.¹

When Scripted Testing Is Still the Right Choice

None of this means scripted testing goes away. Scripted tests are the better choice where the same test will be rerun after every software update, where a calculation needs a defined reference data set and an exact expected result, and where a Tier 4 control (for example, that reintegration of a chromatogram keeps the original and records the reason) must be shown the same way every time. Scripting the few tests that need repeatability, and leaving the rest unscripted, is what keeps the testing proportionate.

Data Integrity Controls on a Standalone PC

Right-sizing the testing does not right-size the controls. A Tier 3 UV-Vis may need only a short exploratory test, but its PC needs the same core data integrity controls as any GxP computer. This section sets out what those controls are for an instrument that will stay standalone, at least for now. Moving instrument data onto a network is the better long-term answer for many of these systems, and we cover that architecture in a separate article on chromatography data integration linked at the end; the focus here is what you can set up and verify on the PC you have.

User Accounts and Roles

Every person who uses the instrument needs a unique account, on both Windows and the instrument software if they are separate. FDA’s explanation is direct: “When login credentials are shared, a unique individual cannot be identified through the login and the system would not conform to the CGMP requirements in parts 211 and 212.”⁵ The same guidance says “The system administrator role, including any rights to alter files and settings, should be assigned to personnel independent from those responsible for the record content,” and recommends keeping a list of authorized individuals for each system.⁵

PIC/S PI 041-1 sets a floor that is easy to remember: “As a minimum, simple systems should have normal and admin users.” It also says normal users should not have access to critical aspects of the system, such as system clocks and file deletion functions, and that users with elevated rights should not normally do routine work tasks on the system.¹³ On a standalone PC, that usually means a local administrator account held by IT or a system owner outside the testing group, analyst accounts with no rights to delete files or change the clock, and a supervisor role for method and template changes.

Audit Trails

If the instrument software has an audit trail, turn it on, configure it to capture the events that matter (result creation, reprocessing, method and template changes, deletions), and test that it does. Annex 11 says audit trails should be considered on a risk basis, should record the reason for changes or deletions of GMP-relevant data, and should be “regularly reviewed.”¹² FDA’s drug guidance says that where the regulations set a review frequency for the data, such as review before batch release, the audit trail review follows the same frequency; otherwise the frequency is set by risk assessment.⁵

For a Tier 3 or Tier 4 instrument whose results support release, that means the audit trail is reviewed as part of the result review, not in a separate quarterly exercise. For a Tier 2 instrument with limited logging, the review may be a periodic check that nothing unexpected appears. If the software has no audit trail at all and the record is electronic, that is a gap to close through an upgrade, a different record format, or a documented risk acceptance with compensating controls; it is not something testing can fix.

Clocks

Time stamps are only as good as the clock that produces them, and on a standalone PC nothing corrects the clock automatically. The Jaloma letter cites inaccurate file creation and modification dates on a GC computer.¹⁷ PIC/S PI 041-1 expects access to system clocks to be restricted to authorized personnel.¹³ McDowall’s long-standing advice for standalone spectrometry systems is to set and check the clock manually against a reliable time source, record each check, and adjust the check frequency based on how much the clock drifts.¹⁹ A monthly documented check is a simple control that most labs can add to the instrument’s routine checks.

Data Transfer and Backup

Section 211.68(b) requires backup that is exact, complete, and secure from alteration, erasure, or loss.² Annex 11 adds that the integrity and accuracy of backup data and the ability to restore it should be checked during validation and monitored periodically.¹² PIC/S PI 041-1 points out that temporary storage on a local instrument computer before transfer creates a chance for data to be deleted or changed, calls this a particular risk for standalone systems, and says well-designed and qualified automated transfer is more reliable than manual transfer.¹³

For a standalone instrument this means three things to verify. Where does the software save data, and can analysts change that path? How does the data get off the PC (scheduled copy to a server share, a vendor backup utility, or manual export), and is that copy complete, including metadata and audit trail? And has anyone restored a backup and opened the files in the instrument software to prove it works? The restore test is the item most often missing, and it is the one that shows whether backup exists in practice.

Printouts Versus Electronic Records

A standalone instrument often prints a result that the analyst signs and files, and the lab treats the printout as the record. For Tier 1 instruments that is correct, provided the printout carries what the record needs. For anything that stores dynamic data, it is not. FDA’s guidance is explicit that a printout of a dynamic record such as an FT-IR spectral file “would not satisfy CGMP requirements to retain original records or true copies.”⁵ Section 211.194(a)(4) requires the record to include spectra from laboratory instrumentation.⁴ Decide for each instrument which record is the original and write that decision into the instrument’s procedure.

Keeping the Effort Right-Sized After Go-Live

A tiered approach only holds if it is maintained. Instruments change: firmware updates arrive, software versions change, a new method moves a balance from in-process checks to reference standard weighing, or a lab connects a pH meter to a PC. Each of these can move the instrument to a different tier.

Change Control That Asks the Tier Question

Add one question to the change control form for lab instruments: does this change alter the software type, the record type, or the decision the result supports? If the answer is no, a software update on a Tier 3 instrument may need only confirmation that the vendor’s release notes do not affect the functions you rely on, a rerun of the scripted calculation tests, and a quick check that accounts and audit trail settings survived the update. If the answer is yes, reclassify and test to the new tier. The CSA guidance describes assurance as establishing and maintaining a validated state across the software’s life cycle, and it applies the same risk analysis to software changes.¹

Periodic Review Proportionate to Tier

Periodic review is where under-tested instruments are usually found. A short annual review for Tier 3 and Tier 4 systems (user list against current staff, audit trail settings, a sample of audit trail reviews, backup and restore evidence, clock check records, and open deviations) catches drift before an inspector does. Tier 1 and Tier 2 instruments can be covered by the calibration program and a lighter check that their use and record type have not changed. Calibration itself remains a requirement under 211.160(b)(4) regardless of tier.³

Preparing for the AISQ Revision Without Rewriting Twice

If the AISQ revision becomes official in something close to its draft form, its third stage, ongoing performance verification, will put more weight on the post-go-live checks described above, and the subgrouping of A, B, and C will give labs a finer scale for the first question in our model.⁷⁹ The safe course is to write your procedure around the 2017 chapter and the principles the draft shares with CSA and Annex 11 (intended use, risk-based extent of work, life cycle), and to keep the group labels in one table that can be updated when USP publishes a final text.

Measuring Whether It Worked

Three simple measures tell you whether the approach is doing what it should. The first is the elapsed time from instrument delivery to release for GxP use, which should fall for Tier 1 and Tier 2 instruments. The second is the number of instruments with every Tier 3 and Tier 4 control verified, which should rise toward the full count. The third is the number of data integrity findings on standalone instruments in internal audits, which should fall. If the first measure improves and the other two do not, the lab has cut testing without adding controls, which is the wrong trade.

Conclusion

Computer software assurance for lab instruments is less about new testing methods than about putting effort in the right place. The drug regulations have always scaled checks to the complexity and reliability of the system. FDA’s 2026 CSA guidance, read by analogy, adds a clear framework for intended use, testing types, and records. USP <1058>, still official in its 2017 form, supplies the instrument groups. Asking two questions (how complex is the software, and what record does it create for which decision) turns those sources into four tiers that a lab can apply in minutes. Most standalone instruments then need far less functional testing than they get today, and a small number of PC-based systems need controls that, according to the warning letters, many labs still do not have.

Sakara Digital works with pharma and biotech organizations on risk-based validation and data integrity for laboratory and quality systems. If you are reviewing how your lab qualifies standalone instruments, or preparing for an inspection where the instrument inventory will be examined, and want an independent perspective on where to start, we are happy to have that conversation.

For Further Reading