1. Executive Summary

During review of the computerized system audit trail, it was observed that the Alarm Acknowledgement event does not contain or display the identity/user details of the individual who acknowledged the alarm.

Because alarm acknowledgement constitutes an electronic action performed by a user, the ability to attribute the action to a specific authorized individual is an important Data Integrity control where the alarm is GxP-relevant.

The primary ALCOA+ principle potentially affected is Attributable. The deficiency may also affect Complete, Consistent, Accurate and Available principles depending on the extent to which the missing user information prevents reconstruction of the event.

The compliance impact should be determined through a documented, risk-based assessment considering the criticality of the alarm, the GxP impact of the associated process, the existence of alternative attribution mechanisms, and the system’s validated intended functionality.

Preliminary assessment: Potential Data Integrity Gap – Major, subject to confirmation of the system architecture, GxP relevance of the alarm, and availability of alternative evidence demonstrating user attribution.

This should not be automatically classified as Critical solely because the user name is absent from the report.

2. Scope and Assumptions

This assessment concerns a computerized GxP system in which:

• An alarm is generated by the system.
• An authorized user acknowledges the alarm.
• The audit trail records the alarm acknowledgement event.
• The audit-trail report does not display the user identity associated with the acknowledgement.
• The underlying system may or may not retain the user identity separately.

Additionally, the assessment assumes the alarm may be linked to a GxP‑controlled process, equipment, facility, utility, environmental condition, or system.

The following must be confirmed before finalizing the compliance conclusion:

1. System name and version.
2. Intended use.
3. GxP classification.
4. Alarm criticality.
5. Whether unique user authentication is implemented.
6. Whether the user identity is stored in the database/system logs.
7. Whether user identity is available through another validated report.
8. Whether the audit trail was included in CSV/validation testing.
9. Whether the observed behavior is consistent with the approved system specification.
10. Whether the alarm acknowledgement is itself considered a GxP record/event.

3. Applicable Regulatory Expectations

3.1 ALCOA+ – Attributable

The most directly relevant requirement is Attributable.

A reviewer should be able to establish who performed the electronic action.

For the alarm acknowledgement event, the expected traceability would generally be:

Alarm generated → Alarm identified → Authorized user acknowledges alarm → User identity recorded → Date/time recorded → Event retained and available for review

If the system records the acknowledgement but does not identify the person who performed the action, attribution may be compromised.

3.2 EU GMP Annex 11

EU GMP Annex 11 requires consideration, based on risk assessment, of system-generated audit trails for GMP-relevant changes and deletions. It also states that audit trails should be available, convertible to a generally intelligible form and regularly reviewed.

Therefore, where alarm acknowledgement is a GMP-relevant electronic activity, the audit-trail capability should support meaningful reconstruction of the event.

3.3 FDA 21 CFR Part 11

FDA’s Part 11 framework applies to electronic records maintained under applicable predicate-rule requirements. FDA’s guidance emphasizes risk-based consideration of audit trails and controls necessary to ensure the reliability and trustworthiness of electronic records.

The assessment should therefore determine whether the missing user attribution compromises the reliability or trustworthiness of the electronic record.

3.4 MHRA GxP Data Integrity Guidance

MHRA emphasizes the importance of attribution and the ability to reconstruct activities from retained electronic data and audit trails.

Therefore, the organization should establish whether the individual responsible for acknowledging the alarm can be reliably identified from the complete electronic record.

4. ALCOA+ Assessment

5. Detailed Data Integrity Gap Assessment

Finding

Observation:

The audit-trail report records an Alarm Acknowledgement event; however, the report does not provide the user details of the individual who performed the acknowledgement.

Expected State

The system should provide sufficient information to reconstruct the alarm event, including, as applicable:

• Alarm/event identification
• Date
• Time
• User identification
• Action performed
• Alarm status
• Relevant equipment/process identifier
• Reason/comment where required
• Any subsequent modification or action
• Appropriate audit-trail metadata

Actual State

The audit-trail report does not identify the user who acknowledged the alarm.

Potential Gap

The inability to associate the acknowledgement with an identifiable authorized individual creates a potential weakness in attribution and reconstruction of the electronic record.

6. Risk Assessment

Potential Failure Scenario

A critical GxP alarm is generated.

An individual acknowledges the alarm.

The system records:

Alarm Acknowledged – 10:32:15

but does not identify:

Acknowledged by: User XYZ

If the user identity cannot be established through any other reliable and validated source, the organization may be unable to demonstrate:

• Who performed the action.
• Whether the person was authorized.
• Whether the action was performed by trained personnel.
• Whether the alarm was appropriately responded to.
• Whether the event can be reliably reconstructed during an investigation or inspection.

Severity

Potentially Major

Severity may become Critical if:

• The alarm is directly related to critical product quality attributes.
• The alarm indicates a condition capable of affecting patient safety.
• The alarm relates to critical process parameters.
• The alarm is associated with a critical utility/environmental condition.
• Failure to identify the user prevents investigation of a potentially significant deviation.
• The system permits untraceable acknowledgement of critical alarms.

Probability

To be determined from:

• Frequency of occurrence.
• Number of users.
• System architecture.
• Authentication controls.
• Frequency of alarm acknowledgement.
• Existing compensating controls.

Detectability

Potentially Low to Moderate, depending on whether the user can be reconstructed from other validated records.

Preliminary Overall Risk

Major – subject to confirmation of GxP criticality and availability of alternative attribution evidence.

7. Critical Distinction – Report Limitation vs. True Data Integrity Failure

This is the most important part of the investigation.

Scenario A – User exists in the source system

If the underlying system stores:

Alarm ID + Timestamp + User ID + Acknowledgement

but the standard audit-trail report does not display the User ID, the issue may primarily be a:

Reporting/configuration deficiency.

The risk may be reduced if a validated method exists to retrieve and verify the user identity.

Scenario B – User exists in another validated system

For example:

Alarm acknowledgement → timestamp → workstation → authenticated user/session log

If the relationship is reliable, validated and routinely maintained, this may constitute a compensating control, subject to documented justification.

Scenario C – User identity is not retained anywhere

If the system records:

Alarm Acknowledged – 10:32:15

with no reliable means of determining who performed the acknowledgement, this represents a significantly more serious:

Data Integrity and audit-trail attribution deficiency.

8. Questions to Establish Actual Compliance Status

The following questions should be answered before final classification:

1. Does every user have a unique user ID?
2. Are shared accounts prohibited?
3. Does the system authenticate users before alarm acknowledgement?
4. Is the authenticated user ID stored in the database?
5. Does the alarm history contain user information?
6. Does another system log contain the user identity?
7. Can the user identity be reconstructed using validated system records?
8. Is the user identity included in the raw audit trail but excluded from the report?
9. Is the report itself a validated report?
10. Was alarm acknowledgement identified as a GxP-relevant event during validation?
11. Was user attribution tested during CSV?
12. Is the behavior documented in the URS/FRS?
13. Is the behavior documented as a known system limitation?
14. Is the system supplier aware of the limitation?
15. Is there a vendor-supported remediation?
16. Are critical alarms subject to manual review?
17. Is alarm acknowledgement linked to a deviation/investigation process?
18. Can the acknowledgement be correlated with operator login records?
19. Are system clocks synchronized?
20. Can historical alarm acknowledgements be reconstructed reliably?

9. Regulatory Inspection Questions

An inspector could ask:

10. Required Evidence

The following evidence should be collected:

System evidence

• Screenshot of audit-trail report.
• Screenshot of alarm history.
• Raw audit-trail extract.
• User-management configuration.
• Authentication configuration.
• Database schema/data dictionary, where appropriate.
• System-generated logs.
• Alarm configuration.
• User/session logs.
• System architecture.

Validation evidence

• URS
• Functional Specification
• Configuration Specification
• Risk Assessment
• Traceability Matrix
• IQ/OQ/PQ or equivalent validation documentation
• Audit-trail test cases
• User-access test cases
• Security testing
• Alarm testing
• Periodic review records

Quality-system evidence

• SOP for alarm management.
• SOP for audit-trail review.
• Data Integrity Risk Assessment.
• Deviation records.
• CAPA records.
• Change-control records.
• Supplier/vendor assessment.
• Periodic evaluation.

11. Recommended Remediation

Immediate

1. Determine whether the user identity exists in the underlying system.
2. Preserve relevant historical audit-trail and system records.
3. Establish whether historical alarm acknowledgements can be reconstructed.
4. Perform a documented GxP/Data Integrity risk assessment.
5. Determine whether critical alarms are affected.
6. Evaluate whether a deviation should be initiated.

Short Term

If user attribution exists but is not displayed:

• Configure the validated audit-trail report to display user identification; or
• Implement another validated method for retrieving the user identity.
• Update validation documentation.
• Perform appropriate testing.
• Update the Data Integrity risk assessment.
• Update audit-trail review procedures if required.

Long Term

If the system cannot retain user attribution:

• Engage the system vendor.
• Raise a formal supplier/system deficiency.
• Implement a validated technical solution.
• Evaluate system upgrade/replacement if necessary.
• Establish interim compensating controls.
• Assess historical records for potential impact.

12. CAPA Recommendation

Potential CAPA – Root Cause

Potential root cause:
The computerized system/report configuration does not provide sufficient user attribution for the Alarm Acknowledgement event, or the user attribution information is not included in the available validated audit-trail output.

Corrective Action

Determine and document the source of the user attribution information and implement a validated solution that enables reliable identification of the individual performing the alarm acknowledgement.

Preventive Action

Review comparable GxP events within the system to determine whether other critical actions also lack user attribution.

The review should include:

• Alarm acknowledgement
• Alarm suppression
• Alarm shelving
• Alarm configuration changes
• Setpoint changes
• Parameter changes
• User-management activities
• Critical process interventions
• System configuration changes

13. Priority Classification

14. Overall GxP Compliance Conclusion

Based on the stated condition alone:

The absence of user identification for an Alarm Acknowledgement event represents a potential GxP Data Integrity deficiency because the event may not be fully attributable to an identifiable individual.

However, the final compliance classification should not be based solely on the audit-trail report display.

The first investigation step should establish whether the user identity is actually absent from the underlying electronic record or is simply absent from the specific audit-trail report.

Recommended decision logic

User ID exists in validated source record and can be reliably reconstructed
→ Potentially Minor/Major reporting or configuration deficiency, depending on risk.

User ID exists but requires non-validated/manual reconstruction
→ Major Data Integrity/control deficiency should be considered.

User ID is not retained anywhere and the acknowledgement cannot be attributed
→ Major to potentially Critical Data Integrity deficiency, depending on the GxP criticality of the alarm and its impact on product quality/patient safety.

Therefore, the recommended preliminary conclusion is:

“Potential Major GxP Data Integrity Gap – Attribution of Alarm Acknowledgement requires further assessment. Final classification shall be based on alarm criticality, availability of complete source metadata, user authentication controls, validated alternative attribution mechanisms, and the ability to reconstruct the event throughout the data-retention period.”

This approach is consistent with the risk-based treatment of audit trails reflected in EU GMP Annex 11, FDA Part 11 guidance, and MHRA GxP Data Integrity expectations

About the Author:
Ramesh Palav is a pharmaceutical GxP, Computerized System Validation (CSV), and Data Integrity professional with experience in quality and compliance of computerized systems. He writes on GxP compliance, Data Integrity, CSV, 21 CFR Part 11, EU GMP Annex 11, and practical approaches to pharmaceutical quality systems.