Using GAMP Methodology to Validate Environmental Monitoring System Software

The next step is to find a system that meets the requirements in your URS. Use the URS as a reference to evaluate each potential CMS for alignment with your Quality Management System (QMS). Consider additional constraints such as acquisition budget, long-term cost of ownership, and your firm’s validation capabilities. For example, can you manage installation and qualification in-house, or will you need vendor or contractor support?

Your goal is to create a shortlist of candidate systems for deeper evaluation. Vendor audits can take two forms:

1. Audit the vendor’s quality system and facility to assess their commitment to quality.

2. Audit the CMS itself using your traceability matrix. Make a copy for each system, then compare its capabilities against your requirements.

Often, the most significant differentiator between systems will be the software type, as defined by GAMP guidance.

The ISPE’s GAMP guidelines classify software into five categories; for monitoring systems, the key types are:

Category 3: Off-the-shelf (GAMP 4: “Standard,” GAMP 5: “Non-configured”) – Ready to use “plug-and-play” software with only run-time configuration (e.g., setting report headers, default printers, or user types). No changes to business processes or custom coding.

Category 4: Configured (GAMP 4: “Configured software,” GAMP 5: “Configured products”) – Requires setup beyond run-time to align with business processes, such as custom drop-down menus or specific report formats. Uses standard, supplier-tested code—no new code is written.

Category 5: Custom (GAMP 4: “Custom software,” GAMP 5: “Custom products”) – Involves new code, from fully bespoke applications to small VBA macros in Excel. All new code must be tested by the user, as it has not been validated by the supplier.

These categories help estimate the effort and cost of validation, and clarify how a new system will integrate into your quality processes.

The URS and FS will rarely match exactly, and updating the traceability matrix helps confirm which requirements are met and which are not. Not all requirements carry equal weight—some are essential, others merely “nice to have.” Work with stakeholders to prioritize them, and update the URS to note any unmet requirements along with documented workarounds.

At this stage, finalize your system selection. Remember: the chosen software type—Category 3, 4, or 5—directly impacts validation effort. Category 3 (“off-the-shelf”) typically requires no additional specifications, allowing you to proceed directly to test document development (Step 7). Category 4 and 5 systems demand more documentation before testing. Most monitoring systems fall under Category 4, while Category 5 often involves multiple devices from different suppliers with custom code for integration.

Tip: Validation resources scale with system complexity—plan accordingly.

Detailed Specification (DS) documents describe how the system will be configured or programmed to perform the functions defined in the Functional Specification (FS). These documents are not needed for Category 3 systems, which are already in final form.

Category 4 (Configured Systems)
The DS is called a Configuration Specification (CS). It details how the system will be set up to align with business processes—such as parameter settings, menu options, and report formats. Configuration typically occurs on-site after installation and may be performed by the vendor.

Once specifications are finalized, testing document development can begin. This is required for all system categories and must address every GMP-related item in the URS, FS, and CS. Use risk assessment to focus on true GMP functions—your S.M.A.R.T. requirements will help identify what must be tested versus what can be excluded.

Enter each testing protocol into the traceability matrix to confirm coverage. For example, if your URS specifies a 10-minute alarm delay, add “Alarm Delay Testing” to the matrix to verify correct configuration and function.

Your Traceability Matrix (TM) should be updated throughout the process, incorporating details from the URS, FS, CS, DS, and all test documents. During the final review, look for gaps or redundancies:

Tests without requirements – Determine if the test is truly needed.

Requirements without tests – Document why the requirement cannot be tested and specify the workaround.

Final Check:

• URS – Finalized and approved. All requirements are in the TM.
• FS – Finalized and approved. All functions are in the TM and linked to requirements.
• CS – Finalized and entered into the TM; each configurable function has a defined configuration.
• Test Protocols – Written, approved, and linked to the relevant requirements.
• Traceability Matrix – Complete, approved, and ready for execution.

Once confirmed, you’re ready to test.

Now the real work begins—executing the tests defined in your protocols. Use the Traceability Matrix as your master checklist to ensure that every requirement from the URS, FS, and CS is verified. Running the system in a live environment may uncover issues, ideally minor ones. Address these systematically:

Minor issues – Adjust configurations or refine procedures.

Requirement gaps – Revisit the URS to revise the requirement or document a workaround.

System defects – Contact the vendor for potential fixes or patches.

If a test fails due to a genuine software bug, the vendor may need to supply an updated build or patch. Any changes must be re-tested to confirm they resolve the issue without introducing new problems. Keep meticulous records of all test results, deviations, and corrective actions; these will be essential during audits.

Validation doesn’t end at go-live. Once the system is running smoothly, validated, and formally released, it must be maintained to ensure continued compliance, reliability, and performance throughout its life cycle. The GAMP methodology emphasizes that system stewardship continues until retirement, not just during implementation.

Ongoing maintenance activities should include:

SOPs – Keep operating procedures current, clear, and aligned with actual practice.

Training – Ensure all users are trained on current procedures, system updates, and best practices.

Calibration – Perform regular calibration of sensors and instruments to maintain accuracy.

Validation – Re-validate after significant changes or periodically, as per your quality system.

Change Control – Apply formal change control for any modifications, ensuring changes are documented, risk-assessed, tested, and approved before implementation.

Proactive maintenance not only extends system lifespan but also reduces audit risk and operational downtime. A well-maintained CMS remains inspection-ready at all times.