The software of an Environmental Monitoring System is the part that produces the record — and therefore the part most inspection questions land on. Who can change a limit, who can invalidate a data point, how you demonstrate a value has not been altered, who reviews the audit trail and against what criteria, where the data from five years ago is and who can still read it: these are questions about software configuration and management, not about the quality of the measuring instruments.
The underlying rule is that data integrity is designed in, not added on. Roles, permissions, traceability and retention must be defined before configuration: once the system is in operation, every structural correction requires change control, re-verification and often work on data already produced. The second rule is to distinguish precisely between what is a regulatory requirement applicable to your context and what is a company choice: conflating the two leads to spending where it is not needed and discovering gaps where it was.
Why software is the most exposed part of the system
A computerised environmental monitoring system concentrates three functions that, on paper, would be separate: it acquires the data, processes and stores it, and enables its review. Whoever controls the software potentially controls all three. It is this concentration that makes controls over access, segregation of duties and change traceability necessary.
The second reason is duration. Instruments get replaced; data remains for the whole applicable retention period, and must stay readable and reconstructable even when the system that generated it no longer exists. Decisions taken today about formats, exportability and archiving determine whether, years from now, it will be possible to answer a question about a batch made today.
The regulatory frame: what actually applies
| Level | What it establishes regarding EMS software |
|---|---|
| Regulatory requirement (EudraLex Volume 4, Annex 11 — January 2011 revision) | This is the applicable version. It applies to computerised systems used in GMP activities and sets expectations on validation, supplier management, security and access management, audit trail, change control, backup and archiving, incident management, continuity and periodic evaluation. |
| Consultation text (ongoing Annex 11 revision) | Not an applicable requirement. It may be considered to orient design choices intended to last, provided it is explicitly declared as forward-looking. It must never be used as an acceptance criterion in qualification, nor cited as an obligation. |
| Regulatory requirement (21 CFR Part 11, FDA) | Applies to electronic records and electronic signatures within the scope of FDA-regulated products and their predicate rules. Its applicability to your system must be determined and documented: it is not automatic for a site not supplying the US market. |
| Regulatory requirement (EudraLex Volume 4, Annex 15) | Sets out the qualification and validation framework, applicable also to the computerised component. |
| Expectation / guidance (PIC/S data integrity guidance, authority guidance, ICH Q9(R1)) | Clarify expectations on completeness, attributability, legibility, contemporaneousness, originality and accuracy of data, and on the risk-based approach to managing it. |
| Industry good practice | Software categorisation models and structured approaches to computerised system validation widely used in the sector. These are recognised methodologies, not regulatory prescriptions. |
| GuideGxP operational recommendation | Produce a written applicability assessment — which requirements apply to the system, why, and which do not — approved before configuration. It is the document that makes every subsequent choice defensible. |
Technical guidance
User roles and segregation of duties
The role matrix must be defined before configuration, not inherited from the supplier's default profiles. The principles:
- Unique identification: every user has personal, non-shared credentials; generic departmental accounts are among the most common findings.
- Least privilege: each role has only the permissions its function requires.
- Segregation of duties: whoever configures the system should not be the same person who reviews the records it produces; whoever operates should not be able to change the parameters governing their own work.
- System administration: administrative privileges should be assigned to a small number of people, preferably outside the function that operationally uses the system, with their activity logged.
- Account life cycle: creation, modification, suspension and deactivation must follow a defined process, linked to personnel movements.
- Supplier access: temporary, authorised case by case, logged and revoked at the end of the intervention.
Audit trail: content and review
A useful audit trail answers four questions for every relevant event: who, what, when and why. What to verify at specification and qualification stage:
- coverage of relevant events: creation, modification and invalidation of records, configuration and limit changes, alarm handling, access events;
- impossibility of being disabled or altered by users, administrators included;
- presence of a reason for change wherever change is permitted;
- legibility in an understandable form without supplier tools;
- the ability to filter and review efficiently: an audit trail that is technically complete but not reviewable in practice does not fulfil its purpose;
- retention for the whole period required for the records it relates to.
Audit trail review must be planned with a risk-based approach: which events are reviewed, by whom, at what frequency and with what evidence of the review. The frequency does not follow from a general rule but from the criticality of the data and the business process, and must be justified in writing.
Electronic records, signatures and data management
- Definition of the raw record: establishing what constitutes the original data and where it resides is the precondition for every subsequent control.
- Metadata: the record is not only the value; it includes the information that allows it to be interpreted and reconstructed.
- Electronic signatures: where used, the operations requiring them, the meaning of the signature and the associated controls must be defined. Where the context does not require them, the decision not to use them must be documented.
- Handling anomalous data: the ability to exclude or annotate a data point must be governed by procedure, with a recorded justification and full traceability. Deletion of raw data is not a function to configure.
- Exports and reports: these must be verified as part of qualification; a report that presents data incompletely or misleadingly is a system problem, not a usage problem.
Configuration, customisation and validation
Validation effort depends on how far the system departs from the standard product. A system configured using parameters foreseen by the supplier carries a different effort from a system with customer-specific development. The operating criterion: every configured or developed element must be documented, justified and verified, and the configuration documentation must be kept current as part of the system, not filed away at project close.
Supplier assessment — development capability, version management, support, available documentation — is part of the framework and must be documented; its outcome legitimately influences the depth of the verification you perform yourself.
Retention, archiving and migration
- Retention period: defined consistently with the requirements applicable to the records the data relates to.
- Legibility over time: the archive format must remain interpretable even if the system is decommissioned; exclusive dependency on a proprietary format is a risk to be assessed explicitly.
- Migration: every transfer of historical data requires a plan, criteria for verifying completeness and accuracy, and evidence of the outcome.
- Exit strategy: how data is accessed after the contract or support ends is a question for the tender stage, not for decommissioning.
Periodic review of the computerised system
The system must be reviewed periodically to confirm it remains in a state of control: changes made, incidents recorded, deviations, outcome of audit trail reviews, access management, support and obsolescence status, restore tests performed. Periodic review is not a repeat of qualification: it is documented verification that the assumptions on which qualification rested still hold.
Working tool: data-integrity-oriented configuration checklist
| Area | To define before configuration | Expected evidence |
|---|---|---|
| Access | Approved role-permission matrix | Approved document and verified matching configuration |
| Access | Account life cycle management process | Procedure and records |
| Audit trail | List of logged events | OQ verification on each event type |
| Audit trail | Risk-based review plan | Procedure with justified frequency and review records |
| Data | Definition of raw record and metadata | System document |
| Data | Rules for handling anomalous data | Procedure and in-system traceability |
| Limits and alarms | Who may change them and with what authorisation | Permission configuration and change logging |
| Reports | Planned reports and their verification | OQ verification against source data |
| Retention | Period, format and location | Documented policy |
| Restore | Restore test in the real configuration | Test report |
| Supplier | Documented assessment | Assessment report |
| Applicability | Which requirements apply and why | Approved applicability assessment |
A practical scenario
At a site we will call Site Delta — realistic but fictional — the project team configures the EMS using the supplier's default user profiles, so as not to delay go-live. The profile intended for shift supervisors includes, for operational convenience, the ability to change alarm limits.
Qualification closes without findings: the system does exactly what it was configured to do. The problem surfaces at the first periodic review, when the audit trail shows limit changes made by operational personnel during processing. None of those changes was irregular under the configuration; all of them were incompatible with the principle of separating those who operate from those who set the parameters governing operation.
The correction — redefining the role matrix, reconfiguring permissions, re-verifying, retrospectively assessing the changes already made and documenting their impact — takes far more effort than defining the matrix before configuration would have. It is the classic case where time saved at the start is repaid with interest.
Common mistakes and red flags
- Adopting the supplier's default user profiles. They reflect a generic organisational assumption, not the site's segregation of duties.
- Shared or generic accounts. They make attributability impossible, and attributability is the first of the data integrity principles.
- Audit trail enabled but never reviewed. Logging without review produces no control; the absence of a justified review plan is a frequent finding.
- Citing the Annex 11 revision as an applicable requirement. The applicable version remains the January 2011 one; a consultation text is not an obligation.
- Assuming Part 11 always applies. Applicability must be determined and documented; assuming it without analysis leads to unjustified controls, denying it without analysis leads to gaps.
- Not defining the raw record. Without that definition, every discussion about integrity and retention stays ambiguous.
- Configuring the ability to delete data. Anomalous data is handled through traced annotation, not removal.
- Neglecting exportability and migration. These are what make replacing the system costly or impossible years later.
- Treating periodic review as a formality. It is the instrument through which you demonstrate the system is still in a state of control.
How to document
- Applicability assessment: which requirements apply to the system and why, which do not and on what reasoning.
- Approved role-permission matrix with the rationale for segregation of duties.
- Configuration specification maintained as a living document.
- Audit trail review plan with justified frequency and assigned responsibilities.
- Definition of raw record, metadata and retention period.
- Supplier assessment and its influence on the verification strategy.
- Qualification report for the computerised component, traceable to the requirements.
- Periodic review records and resulting actions.
Key takeaways
- Data integrity is designed before configuration: afterwards, every correction costs far more.
- The applicable version of Annex 11 is the January 2011 revision; a consultation text is not a requirement.
- Part 11 applicability must be determined and documented, not assumed.
- An audit trail that cannot practically be reviewed does not fulfil its purpose.
- Segregation of duties is an organisational choice translated into configuration, not the other way round.
- Exportability, archiving and exit strategy are negotiated at tender, not at decommissioning.
Frequently asked questions
Which version of Annex 11 applies?
The January 2011 revision remains the applicable version. A consultation text may be considered to orient long-lasting choices, but it must always be declared as such and cannot be used as an acceptance criterion in qualification.
Does 21 CFR Part 11 apply to our EMS?
It depends on context: it applies to electronic records and signatures within the scope of FDA-regulated products and their predicate rules. The determination must be made case by case and documented in an approved applicability assessment.
How often should the audit trail be reviewed?
There is no universal frequency. It must be defined with a risk-based approach, according to the criticality of the data and the process, and justified in writing together with the scope of review and the responsibilities.
Can departmental accounts be used where several operators alternate?
Not if records must be attributable to a person. Attributability is one of the fundamental data integrity principles; operational needs for speed are solved with technical authentication solutions, not by sharing credentials.
Who should be able to change alarm limits?
Not those operating under those limits. The specific choice depends on the organisation, but the principle of separating execution from parameter setting must be respected and documented in the role matrix.
What happens to the data when the system is replaced?
It must remain readable and reconstructable for the whole retention period. The options — migration to the new system, archiving in an independent format, keeping the old system read-only — must be assessed under a documented plan. The topic connects to replacing existing systems, covered in the article on retrofitting an EMS.
Regulatory and technical references
- EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (European Commission): Annex 11 (January 2011 revision), Annex 15 (in operation from 1 October 2015), Annex 1 (applicable from 25 August 2024).
- 21 CFR Part 11 — Electronic Records; Electronic Signatures (eCFR).
- PIC/S — Guides and Guidance Documents, including guidance on data integrity in regulated environments.
- ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.
Continue the project journey
This article is part of the GuideGxP Environmental Monitoring Systems pathway, which follows the life cycle of an EMS project from requirements definition through to operational management.
- Upstream: the system URS and the network and power infrastructure.
- Downstream: FAT, SAT, IQ, OQ and PQ of the system and operational management.
- GuideGxP regulatory foundations: data integrity, ALCOA+ and audit readiness under Annex 11.
Want analysis like this straight to your inbox? Subscribe to The Pragmatic GMP, the GuideGxP newsletter for professionals working daily with GMP, qualification and data integrity.
