FOR VALIDATION & QA TEAMS
For validation and QA teams
This page is written for the person who has to decide whether MYREX is a problem. It states what the product does mechanically, what stays yours and cannot be delegated, and where MYREX stops — in the middle of the page rather than the bottom, because you would find them anyway.
The necessary sentence, first rather than last.
No vendor can sell you a validated system. Validation is performed in your environment, against your intended use, and the conclusion carries your QA signature. What a vendor can honestly offer is a product designed in alignment with the relevant requirements and the willingness to support your validation with real mechanical detail. That is what this page is.
Why is a maintenance record a regulated record?
Because 21 CFR 211.182 says so. It requires a written record of major equipment cleaning, maintenance and use, carving out only “routine maintenance such as lubrication and adjustments.” Entries must be in chronological order. Where equipment is dedicated to one product and lots follow in numerical order and sequence, the regulation is explicit: the records of cleaning, maintenance and use shall be part of the batch record.
21 CFR 211.67
A maintenance and cleaning program — written procedures, assigned responsibility, schedules — and that its records be kept under 211.180 and 211.182.
21 CFR 211.182
The execution of that program is logged: chronological, dated, signed, with the date, time, product and lot of each batch processed.
21 CFR 211.180
Those records are retained for the batch retention period, kept readily available for inspection, and may be kept as original records or true copies.
So on a dedicated filling line, the equipment cleaning and maintenance log is part of the regulated record — not adjacent to it. That is why we treat MYREX as direct impact rather than arguing for a lower tier. This is also an area that is actively inspected: FDA warning letters cite 211.182 by number for failures to keep appropriate written records.
How does MYREX classify under a risk-based validation approach?
Direct impact, GAMP 5 Category 4, with risk-based scoping of test effort concentrated on record integrity, the audit trail, attestation, and the specific functions that gate line release — or, in current ISPE terms, a system whose critical aspects your risk assessment will identify. The operative direct-impact test for an information system is whether it produces, stores or reports data used to accept or reject product, or primary records and signings required by regulation. If MYREX is your system of record for 211.182 equipment logs, the second limb answers yes on its own.
A software category is an input, not a conclusion
GAMP 5 2nd Edition is explicit that the category is one factor, and that lifecycle activities scale with the GxP impact, complexity and novelty of the system — and with the criticality of the business process it supports.
Any bespoke element gets bespoke rigour
A custom report, a custom integration, or anything built specifically for you is a Category 5 element inside a Category 4 system. Declaring the whole system Category 4 when it contains custom code is a finding waiting to happen.
The useful question is not whether our system is critical
It is which of your assets are critical. That is a determination your site makes every day, and it is where the scoping effort actually pays.
What does MYREX actually record, mechanically?
Plainly, because this is the section your assessment will quote.
Identity
Sign-in is through Microsoft Entra External ID against your own directory. The identity on a record is the identity carried on the authenticated session. Tenant identity is taken from the validated token itself and never from a request.
Attestation
Completed work carries an attestation by an identified user. Each attestation records the user, a snapshot of their name frozen at the moment of signing, the meaning of the attestation, the record it refers to, and a server-computed timestamp. The attestation is written inside the same database transaction as the work it attests to, so the two commit or roll back together.
Audit trail
Maintenance records, attestations, and changes to procedure and work records are written to an audit trail. Each entry incorporates a SHA-256 hash of the entry before it, forming one chain per tenant. The chain is versioned, and verification recomputes each entry under the hash version recorded on that entry.
Verification
Both the audit trail and the attestation record expose a verification endpoint. Verification checks that the content hash recomputes and that each entry structurally links to the one immediately before it.
Export
The server-side audit export is a CSV carrying, on every row, the signature hash, the previous hash and the hash version, alongside timestamps in UTC and local time with the timezone. The chain can be recomputed from the file alone, without our application.
What does the audit trail not do?
This table is the most important thing on the page.
Detects alteration of an audit or attestation entry after the fact
Does not prevent alteration. Protection today is application convention plus detection — there are no database-level restrictions stopping a direct update by someone with database access.
Binds an attestation to the identity of the record attested
Does not bind an attestation to the contents of that record. The chain covers the record’s identity, not its values.
Records who the authenticated session belongs to
Does not prove who was physically at the device. There is no re-authentication at the moment of attesting.
Records an attestation by one identified user
Does not provide a second-person verification, countersignature or reviewer signing of any kind.
Covers maintenance records, attestations, and changes to procedure and work records
Does not cover every event in the system — administrative changes to user accounts and roles are recorded in the audit trail but sit outside the chain, and verification does not walk them.
Preserves entries — nothing in the application updates or deletes them
Does not enforce a retention period, archive, expire, apply a legal hold, or provide a defined export-on-exit mechanism. There is no retention capability in the product.
The limitation we lead with: there is no second-person verification
21 CFR 211.182 requires that the persons performing and double-checking equipment cleaning and maintenance each date and sign or initial the log. MYREX does not do the double-check. There is no countersignature, no reviewer field, no second signing of any kind. On equipment where your procedure requires a double-check, MYREX does not satisfy that requirement on its own today. Here is why we have not shipped one quickly, which matters more than the gap itself: our attestation binds to a record’s identity, not to its contents. A second signature layered on top of that would be theatre — two chained attestations over values that neither of them covers, which a verification group would find in about ten minutes. Content binding is the prerequisite. It lands first; the countersignature follows it. If a double-check is a hard requirement on the assets you have in mind, tell us early — that is useful information for us, and it is the kind of requirement that should shape a conversation at the start rather than surface halfway through one.
Is an attestation an electronic signature?
No, and we are deliberate about the word. 21 CFR Part 11 §11.200 expects the identity of the signer to be proven at the moment of signing, typically through two distinct identification components. MYREX records the identity already carried on the authenticated session — who the system currently believes you are, rather than who has just proved they are signing this. If an already-unlocked, already signed-in tablet changes hands, the system has no way to tell. Whether an attestation satisfies a particular predicate-rule signing requirement for you is a determination you make in your validation. We will give you the mechanical detail to make it, and we will not borrow the word in the meantime.
How does MYREX sit against the Part 11 audit trail expectation, and EU GMP Annex 11?
§11.10(e) expects secure, computer-generated, time-stamped audit trails that independently record operator entries and actions creating, modifying or deleting electronic records, and that audit trail documentation is retained at least as long as the underlying record. FDA’s 2003 Scope and Application guidance announces enforcement discretion over several Part 11 provisions including 11.10(e) — that does not mean audit trails are optional. Part 11 remains in effect, and FDA’s 2018 drug CGMP data integrity guidance treats audit trails as how an electronic system meets them. On retention: 11.10(e) expects the audit trail to be retained at least as long as the record, and we have no retention capability in the product — what that means for your records is a written answer for your environment, not a sentence on a web page. The in-force EU text is Annex 11, Revision 1, January 2011, operative since 30 June 2011. A revision, together with a revised Chapter 4 and a new draft Annex 22 on artificial intelligence, went out for stakeholder consultation from 7 July to 7 October 2025. That consultation is closed. Neither the revision nor Annex 22 has been adopted, and the Commission has published no adoption date. Against the in-force text: clause 9 expects a risk-based, system-generated record of GMP-relevant changes and deletions; clause 12.4 expects the system to record the identity of operators entering, changing, confirming or deleting data, with date and time. The draft strengthens audit trails materially — old and new value, the user’s role, and review by personnel independent of the reviewed activity. Two of those bear directly on limitations already listed on this page: the actor’s role is currently outside our hash chain, and independent review is the second-person question again. We are not going to describe a draft as a requirement, and we are not going to pretend it will not affect us.
What is audit trail review, and can MYREX support it?
Audit trail review is a defined activity in your SOPs, not a browsing session. FDA’s 2018 data integrity guidance: where a CGMP regulation specifies a review frequency for the data, apply that same frequency to the audit trail review; otherwise set it by process knowledge and risk assessment. Honest answer about MYREX today: the audit log screen supports free-text search and filtering by action, entity type and date range. It does not filter by asset, location or mark, and its filtering operates over the entries loaded in the browser so far rather than the whole record. For casual investigation that is adequate. For an activity your SOP calls audit trail review, it is not, and we would rather say so. The full record is available through the export, which is complete and re-verifiable. Review by location on the machine is the capability we most want to build — it is a thesis on this page, not a feature.
ALCOA+ and ALCOA++
The data integrity attributes GMP-side guidance uses are ALCOA+, nine attributes: attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, available — the list in PIC/S PI 041-1 and WHO TRS 1033 Annex 4. ALCOA++ adds traceable. It appears in EMA’s 2023 guideline on computerised systems and electronic data in clinical trials, and in the July 2025 consultation draft of the revised EU GMP Chapter 4, which has not been adopted. The in-force GMP guidance cited above uses ALCOA+.
Attributable
Entries carry the authenticated user’s identity from your own directory, with the name snapshotted at the time. Attribution is to the session, not to the person at the device.
Contemporaneous
Timestamps are computed server-side, not from the device clock, and written in the same transaction as the act.
Accurate
Before and after state are both recorded on the audit entry. The attestation does not bind to record contents.
Complete
Nothing in the application deletes an audit or attestation entry.
Enduring
No retention, archival or legal-hold capability exists in the product.
Available
Full export by administrators and managers, re-verifiable outside the product. Review tooling is limited as described above.
What we can supply for your validation
Validation support — supplier assessment materials, requirements documentation, IQ/OQ support, a traceability matrix — is scoped with each customer during onboarding, against the specific assets and risk profile involved. We would rather name what applies to your situation specifically than list a generic package.
What stays yours
Not a disclaimer — a statement of how leveraging actually works. Supplier deliverables may be leveraged in place of customer-generated deliverables where the supplier has been assessed as competent for the activity concerned, the deliverable has been reviewed and formally accepted by the regulated company, and the acceptance rationale is recorded. Leveraging reduces your execution effort; it does not transfer your accountability for the conclusion.
Authoring and approving the URS
Intended use is a statement about your GMP process, not ours.
Formally accepting the functional and design specifications
Acceptance is the mechanism that makes leveraging valid.
The functional risk assessment and every risk decision in it
It depends on your product, your process and your patient.
Executing PQ / UAT
It demonstrates your process, with your users and your data.
Authoring and approving the Validation Summary Report
Your QA signature is the one that counts.
Release for GxP use, SOPs and training records, and your data including return on termination
QA-only release; your operational ownership; and the Quality or Technical Agreement that says so.
Three deliverables are conspicuously absent from any credible vendor package, ours included: the Validation Plan, the Risk Assessment and the Validation Summary Report. That absence is diagnostic — none of the three can be supplied by a vendor without your intended use and your QA signature.
What we will not claim
Not “21 CFR Part 11 compliant”
Compliance is achieved by a regulated company through its procedures, its validation and its operation of a system.
Not “pre-validated”, “validated system” or “GxP ready”
A vendor cannot validate a system for your intended use.
No claim that a record cannot be altered
Tamper-evident: alteration is detectable, not prevented.
Not “electronic signature”
Attestation.
No certification badge of any kind
We hold no SOC 2 of either type, no ISO 27001, and we have had no third-party penetration test.
No citation of FDA’s Computer Software Assurance guidance
Final, dated September 2025, and scoped to medical device production under 21 CFR Part 820 — not pharmaceutical manufacturing under Parts 210 and 211.
No citation of FDA’s 2024 electronic records guidance
It is scoped to clinical investigations.
Frequently asked
Is MYREX 21 CFR Part 11 compliant?
No product is. MYREX is designed in alignment with 21 CFR Part 11 and EU GMP Annex 11: identity through your own Microsoft Entra directory, attestation by an identified user on completed work, and an audit trail secured by a SHA-256 hash chain.
Does MYREX support second-person verification or a countersignature?
No. There is no countersignature, reviewer signing or second-person verification of any kind in the product today. Where your procedure requires a double-check under 21 CFR 211.182, MYREX does not satisfy that requirement on its own.
What GAMP category is MYREX?
Category 4 — a configured product — with direct impact, and risk-based scoping of test effort. Any bespoke element built for you is a Category 5 element inside that system.
Can an audit entry be altered?
The trail is tamper-evident. Nothing in the application updates or deletes audit or attestation entries, and the chain detects alteration after the fact. Protection today is application convention plus detection, not database-level enforcement.
Can we verify the audit trail ourselves?
Yes. The export carries the signature hash, the previous hash and the hash version on every row, so the chain can be recomputed from the file without our application.
What is your data retention policy?
There is no retention or archival capability in the product today. What that means for your records is a written answer for your environment, and we would rather give you that than a paragraph here.
Do you hold SOC 2 or ISO 27001?
No, and no third-party penetration test. We name the controls we actually run on our security page, with the mechanism attached to each.
Does MYREX handle calibration records?
No, and we carve it out deliberately. Calibration records are product-decision data with a retroactive product-impact trigger; maintenance completion records are, in the base case, evidence of process compliance — different risk classes.
Does MYREX perform IQ/OQ/PQ on our equipment?
No. Equipment qualification is an exercise performed on the process equipment itself. MYREX holds the maintenance record that keeps qualified equipment in its qualified state.
What happens if a capture is out of date relative to the machine?
There is no capture-currency control, no procedure-to-asset binding test set, and no defined degraded mode when an anchor cannot resolve. Recapture today is triggered through your own change control — a significant physical change to the machine is the event that should prompt it. We expect your risk assessment to require all three, and it would be right to.
Sources
21 CFR 211.182, 211.180, 211.67 — eCFR
21 CFR Part 11, §11.10, §11.70, §11.200 — eCFR
FDA, Part 11 Scope and Application, September 2003
FDA, Data Integrity and Compliance With Drug CGMP Q&A, December 2018
EudraLex Volume 4, Annex 11, Revision 1, January 2011
European Commission Annex 11/Annex 22 consultation, July–October 2025 (closed, not adopted)
MHRA GXP Data Integrity Guidance, Revision 1, March 2018
ISPE GAMP 5, 2nd Edition, July 2022
ISPE Baseline Guide Volume 5, 2nd Edition, June 2019
Last reviewed: September 20, 2026
Ready to talk specifics?
Bring your assets and your risk profile. We will tell you exactly what applies.