This is a ready-to-use operational qualification (OQ) protocol for a manufacturing execution system (MES) and the electronic batch record (EBR) it produces. It concentrates on the negative-path tests, the ones that prove the system stops the wrong thing from happening, because those are what an inspector probes and what a happy-path demonstration never covers. Replace every <<FILL: ...>> placeholder, route it through your validation lifecycle, and execute it after installation qualification is complete and approved. A filled specimen follows so you can see a completed test case. Confirm each cited regulation against the current source before you rely on it.
Approval page
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation) | <<FILL>> | ||
| Reviewer (Automation / MES engineering) | <<FILL>> | ||
| Reviewer (Manufacturing) | <<FILL>> | ||
| Approver (Quality Assurance) | <<FILL>> |
| Field | Entry |
|---|---|
| Protocol number | <<FILL: e.g. OQ-MES-001>> |
| Version | <<FILL: e.g. 1.0>> |
| System name / ID | <<FILL: SYSTEM NAME / ID>> |
| Software version under test | <<FILL: version>> |
| Environment | <<FILL: validation / qualification instance, not production>> |
1. Objective
Demonstrate through documented testing that the MES enforces the controls that make the EBR a trustworthy, contemporaneous, attributable record: sequence enforcement, in-line limit checking, re-authenticated electronic signatures, field-level audit trail with prior values, segregation of duties, and protection of signed data. The objective is met when every test case below passes with objective evidence, or every failure is documented, assessed, and resolved.
2. Scope
This protocol covers the MES functions that create and control the EBR for <<FILL: product / line / process in scope>>. It covers the negative paths and the audit-trail behavior; it does not re-test infrastructure covered by IQ or interface performance covered by <<FILL: interface protocol ID>>. The master batch record used for testing is <<FILL: MBR ID and version>>, a controlled test recipe representative of production.
3. System description
<<FILL: two to four sentences describing the MES platform, its role, the recipe/ISA-88 model used, the user roles configured, and the interfaces in scope (scales, SCADA/DCS, LIMS).>>
4. Prerequisites
- IQ complete and approved (
<<FILL: IQ protocol ID>>). - Test environment loaded with the controlled test MBR and representative master data.
- Test user accounts provisioned for each role (operator, verifier, supervisor, QA reviewer) with passwords held by the named testers only.
- Time source synchronized and verified.
- Blank forms, screenshot capture method, and a defined evidence-numbering scheme agreed.
5. Roles
| Role | Responsibility |
|---|---|
| Tester | Executes each step, records actual result, captures evidence, signs and dates. |
| Reviewer | Independently reviews executed test cases and evidence for completeness and correctness. |
| QA | Approves the protocol, adjudicates deviations, approves the summary. |
| System owner / SME | Provides the configured system, supports execution, owns resulting corrective actions. |
6. Acceptance criteria (protocol level)
All test cases pass, or every failed case has a documented deviation with an approved resolution and, where a fix is applied, a documented re-test. No test case may be marked pass without attached objective evidence (screenshot, exported audit-trail extract, or system report) showing the expected result.
7. Deviation handling
Record any discrepancy between expected and actual result as a numbered protocol deviation on the deviation log (section 10). Classify impact, determine root cause, resolve, and re-test the affected case. QA approves each deviation and the overall disposition. Do not proceed to production release of the system until all deviations are closed or risk-accepted with justification.
8. Test cases
Each case lists the control being proven, the steps, the expected result (the acceptance criterion for that case), and columns for actual result, pass/fail, tester, and date. Negative-path cases are written so the system is expected to BLOCK or TRAP the action.
TC-01 Out-of-sequence execution is blocked
| Item | Detail |
|---|---|
| Control | System-enforced step sequence (contemporaneity, ALCOA). |
| Steps | 1. Start the test batch. 2. Attempt to execute step <<FILL: N+2>> before completing step <<FILL: N>>. |
| Expected result | The system prevents execution of the later step and displays a message that the prior step is incomplete. No later-step data is accepted. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-02 Out-of-range entry is rejected at the field
| Item | Detail |
|---|---|
| Control | In-line limit check on a critical numeric field. |
| Steps | 1. Navigate to the weigh/dispense step with a target of <<FILL: value>> and tolerance <<FILL: +/- value>>. 2. Enter a value below the lower limit. 3. Enter a value above the upper limit. |
| Expected result | Both entries are rejected at the field with a clear message; neither is accepted or silently rounded. The rejection is captured. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-03 Signature requires re-authentication at the point of signing
| Item | Detail |
|---|---|
| Control | Electronic signature applied at the moment of the act (21 CFR Part 11; Annex 11). |
| Steps | 1. Log in as operator. 2. Complete a critical step and apply the performed-by signature. 3. Observe whether the system requires the credential again at the signature point rather than reusing the login session. |
| Expected result | The system requires re-authentication (at least the password, or the configured second factor) at the signature point, and records the signature meaning, user, date, and time. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-04 Field-level audit trail captures prior value and reason
| Item | Detail |
|---|---|
| Control | Field-level audit trail with prior-value capture (Annex 11 audit trail; ALCOA original/attributable). |
| Steps | 1. Enter an accepted value in a critical field. 2. Edit it to a new accepted value. 3. Provide the forced reason-for-change. 4. Retrieve the audit trail for that field. |
| Expected result | The audit trail shows the prior value, the new value, the user, the date and time, and the recorded reason. The prior value is retrievable, not overwritten. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-05 A signed field cannot be silently edited
| Item | Detail |
|---|---|
| Control | Protection of executed, signed data. |
| Steps | 1. Sign off a step. 2. Attempt to change a value in the signed step. |
| Expected result | The system either blocks the change, or requires a controlled correction that invalidates the affected signature, forces a reason, and writes a new audit-trail entry. In no case is the value changed with no trace. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-06 Segregation of duties is enforced by configuration
| Item | Detail |
|---|---|
| Control | The performer cannot also be the independent verifier of the same critical step. |
| Steps | 1. Complete a step requiring performed-by and verified-by signatures as the operator. 2. Attempt to apply the verified-by signature using the same operator account. |
| Expected result | The system prevents the same user from signing both roles on that step; a second, eligible user is required. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-07 The system clock cannot be changed by an ordinary user
| Item | Detail |
|---|---|
| Control | Time-stamp integrity. |
| Steps | 1. Log in as operator. 2. Attempt to change the system date/time or time zone from the application. |
| Expected result | The operator cannot change the clock. The time source is controlled and any privileged clock change is itself audit-trailed. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-08 The full EBR and its audit trail export in human-readable form
| Item | Detail |
|---|---|
| Control | Copies of records in human-readable form (21 CFR Part 11; complete batch record, 211.188). |
| Steps | 1. Complete the test batch. 2. Export the full EBR and its field-level audit trail for the batch. |
| Expected result | A reviewer receives the complete EBR plus audit trail for the named batch, legible, with all entries, signatures, and prior values present. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-09 A mid-batch interface failure is detected, not silently dropped
| Item | Detail |
|---|---|
| Control | Interface accuracy check (Annex 11). |
| Steps | 1. During a step that receives a value from <<FILL: scale / SCADA / LIMS>>, force the interface to fail or return an out-of-range value. |
| Expected result | The MES detects and flags the failed or invalid transfer (alarm, hold, or trapped error) rather than accepting a missing or default value. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
TC-10 Disabled or expired accounts cannot execute or sign
| Item | Detail |
|---|---|
| Control | Access control (Part 11 authority checks). |
| Steps | 1. Disable a test account. 2. Attempt to log in and sign with it. |
| Expected result | The disabled account cannot authenticate or sign. Attempted access is handled per policy. |
| Actual result | <<FILL>> |
| Pass / Fail | <<FILL>> |
| Tester / Date | <<FILL>> |
9. References
21 CFR 211.186 (master production record) and 211.188 (batch production record). 21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (computerised systems), including the audit-trail and accuracy-check expectations. ISPE GAMP 5 (Second Edition), risk-based validation lifecycle, for the OQ approach. Related reading: GxP manufacturing and laboratory systems.
Confirm the current version and clause numbers of each reference before issue.
10. Deviation log
| Deviation no. | Test case | Description | Impact | Resolution | Re-test result | QA approval |
|---|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
11. Summary and conclusion
| Field | Entry |
|---|---|
| Test cases executed | <<FILL: count>> |
| Passed | <<FILL>> |
| Failed | <<FILL>> |
| Deviations raised / closed | <<FILL>> |
| Conclusion | <<FILL: system meets / does not meet OQ acceptance criteria>> |
| Approved by (QA) | <<FILL: name, signature, date>> |
12. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Filled specimen
The following shows TC-02 executed for an example weigh-and-dispense step, so you can see the level of evidence expected. The system, values, and names are illustrative; replace them with your own.
| Item | Detail |
|---|---|
| Control | In-line limit check on the excipient weight field. |
| Steps | Target 50.0 kg, tolerance +/- 0.5 kg. Entered 49.2 kg, then 50.8 kg. |
| Expected result | Both rejected at the field with a message; neither accepted. |
| Actual result | 49.2 kg rejected (“below low limit 49.5 kg”); 50.8 kg rejected (“above high limit 50.5 kg”). Screenshots EV-OQ-MES-014 and 015 attached. Audit trail shows both rejected attempts. |
| Pass / Fail | Pass |
| Tester / Date | A. Patel, 22 July 2026 |
In this example the tester proved that the field rejects both a low and a high out-of-range value and that the rejected attempts are visible in the audit trail. A common weak execution tests only the low side, or accepts a screenshot of the message without confirming the rejected attempt was recorded. Testing both bounds and confirming the audit-trail entry is what makes the case defensible.
Common inspection findings this protocol prevents
- OQ that shows only happy-path execution and never proves the system blocks out-of-sequence or out-of-range actions.
- Signatures demonstrated once but never tested for re-authentication at the point of signing.
- Audit trail claimed adequate on the vendor’s word, with no test that retrieves a prior value.
- Signed fields editable with no trace, discovered only during a later investigation.
- Segregation of duties written in a policy but not enforced by the configuration.
How to adapt this protocol
- Set your protocol number, system ID, and software version on the approval page.
- Replace the generic step and field references in each test case with your actual test MBR steps, fields, and tolerances.
- Add product-specific negative paths your process needs (for example a forced yield-reconciliation failure or a material-status block).
- Point the interface case (TC-09) at your real interfaced source and its expected failure behavior.
- Confirm every regulation in section 9 against the current published version before issue, and route the protocol through your normal review and approval.