Compliance frameworks are what a lab-management system exists for. If your samples end up in a court, a regulator’s inbox, or an accreditation audit, the LIMS has to be able to answer three questions in seconds: who did what, when, and can it be reproduced?
SENAITE was built with this as the working assumption, not as an afterthought. This post maps the concrete SENAITE features to the specific clauses of the two frameworks most laboratories care about: ISO/IEC 17025:2017 for testing and calibration laboratories, and 21 CFR Part 11 for laboratories operating under FDA jurisdiction.
Not every clause of either framework is software-solvable. A LIMS cannot make your staff qualified, cannot validate your instruments, and cannot force a supervisor to actually read the verification queue. What it can do is remove entire classes of risk from the manual side of the process. That is the boundary this post draws.
ISO/IEC 17025:2017
Clause references in this section are to the 2017 revision of the standard.
Clause 7.5 — Technical records
“Technical records shall be retained … for each activity that influences the result … in such a way that … any changes to the technical records can be tracked to previous versions or to the original observations.”
SENAITE’s answer is the workflow transition log on every
sample and every analysis. Every state change writes an entry
with the acting user, the timestamp (server time, not the
browser’s), the transition performed, and any comment the user
added. This log is append-only from the UI — there is no
“edit” button, no “delete” button. Results can be retracted
(a formal transition that returns the analysis to to_be_tested
and records the retraction in the log); they cannot be silently
overwritten.
Verified and published results are locked for edit. The
dispose and dispatch workflows
extend this locking to closed-out samples via the ILockingState
marker interface, so an integration cannot mutate an archived
sample’s results even through the JSON API.
Clause 7.11 — Control of data and information management
“A laboratory information management system used for the collection, processing, recording, reporting, storage, or retrieval of data shall be validated for functionality … Any changes … shall be authorized, documented, and validated before implementation.”
SENAITE is developed in the open on GitHub. Every change is a pull request with a reviewer, a description, tests, and a merge commit. That commit history is your change control record. A regulator asking “when did the analysis-locking behaviour change and who approved it?” gets a link to a specific PR with the answer.
For validation, we typically run two paths in parallel with customers:
- Installation and operational qualification (IQ/OQ) of the platform. We provide a documented test plan against a known SENAITE release, executed on the customer’s target environment.
- Performance qualification (PQ) of the customer’s specific configuration. Analysis services, calculations, workflow configuration, and report templates are tested against agreed acceptance criteria before go-live.
The SENAITE Enterprise VM exists partly to make the IQ side of this repeatable: same image, same version pins, same hardening every time.
Clause 6.2 — Personnel and 7.7 — Method verification
Personnel authorization to perform tasks (6.2.5) and sign-off on methods (7.7) both require a way to prove who is authorized to do what, and to demonstrate that they did it.
SENAITE’s answer is a role and permission model granular per
object, per transition, and per field. Roles like Analyst,
Verifier, LabManager, and Publisher map directly to the
functions a laboratory has, and the workflow enforces the
mapping. An analyst can submit a result; only a verifier (a
different user) can transition it to verified. A published
result can only be invalidated by a lab manager.
The full mapping of role to transition, state by state, is worked out in every workshop and will get its own reference post.
Clause 7.8 — Reporting of results
“Test reports and calibration certificates shall be issued accurately, clearly, unambiguously, and objectively.”
SENAITE’s report templates are configurable per client and per report type. The reporting engine handles per-lab logos, custom paper formats, and multi-report batches. Signatures on reports are tied to the SENAITE user account that published them, and the published PDF is stored against the sample so the exact document the client received is retrievable years later.
21 CFR Part 11
The FDA’s Part 11 rule covers electronic records and electronic signatures in regulated industries. Not every lab running SENAITE is Part 11 obligated (only labs supporting FDA- regulated products, roughly speaking), but for those that are, the compliance surface is well-defined.
§11.10(a) — Validation
“Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.”
Same story as ISO 17025 clause 7.11: documented IQ/OQ against the SENAITE release, PQ against the customer’s configuration. The advantage of an open-source LIMS is that the “black box you have to trust” is not a black box — source code is public, and validation evidence can include line-level reference to the specific commit under test.
§11.10(c) — Protection of records
“Protection of records to enable their accurate and ready retrieval throughout the records retention period.”
SENAITE stores every sample, analysis, worksheet, and report in
a single ZODB file (Data.fs). A retention period of ten years,
twenty years, or “forever until the customer says otherwise” is
a directory-copy problem, not a database-migration problem. Our
managed hosting tier runs daily off-site
backups with monthly restore verification, and the storage layer
does not care whether the sample was published yesterday or in
2015.
§11.10(d) — System access
“Limiting system access to authorized individuals.”
The same permission model that answers ISO 17025 clause 6.2. Users are managed inside SENAITE or via an external directory (LDAP, SSO); permissions are role-based and per-object.
§11.10(e) — Audit trails
“Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records.”
Two mechanisms answer this together.
The workflow transition log already covered under ISO 17025
records every state change with actor and timestamp. On top of
that, SENAITE keeps a snapshot audit log written by
subscribers on ObjectInitializedEvent, ObjectModifiedEvent,
and ObjectTransitionedEvent
(senaite.core.subscribers.auditlog). Each event serialises the
full field set of the object to JSON, attaches a metadata block
(actor, roles, review_state, active flag, server-time
timestamp, remote address, user agent, referer, comments), and
appends it to a per-object PersistentList annotation
(senaite.core.snapshots). Snapshots are indexed in a dedicated
AUDITLOG_CATALOG so they can be queried, diffed, and browsed
from the audit-log control panel.
The audit trail is server-generated, not user-editable, and
every entry carries the acting user and server-time timestamp.
When an object is removed, its snapshot log is frozen via the
IDoNotSupportSnapshots marker — no post-hoc rewrites,
even by staff with delete permission.
§11.50 and §11.70 — Signature manifestations and record linking
An electronic signature under Part 11 must be linked to its record in a way that cannot be excised or copied by ordinary means, and the signed record must display the printed name of the signer, the date and time of signing, and the meaning of the signature.
In SENAITE, the acting user’s identity is attached to every workflow transition, and the transition metadata is stored on the object itself. A published report displays the publisher’s name and the publication timestamp; a verified analysis carries the verifier’s name and the verification timestamp. Attempts to detach the signature from the record fail because they are the same record.
What SENAITE does not do for you
Compliance is a process. Software is one input to that process. SENAITE will not:
- Qualify your instruments. IQ/OQ/PQ of the instrument itself is your problem. SENAITE captures the results; the instrument’s own qualification is separate.
- Train your staff. Role assignments in SENAITE assume the staff assigned to those roles are actually competent. Training records and competency assessments live outside the LIMS (though many labs attach them to user records via a Plone content type extension).
- Substitute for an SOP. Standard operating procedures are documents, not software. SENAITE workflows can enforce that an SOP is followed; they cannot write the SOP.
- Validate itself in your specific environment. The general IQ/OQ evidence we provide is a starting point. The final validation record is against the customer’s actual server, their actual configuration, their actual data set.
What we do around this
If your compliance obligations are on the tighter end — FDA-regulated clinical trials, environmental monitoring for regulatory reporting, water quality against the EU Drinking Water Directive — the questions above stop being theoretical.
Our 3-day workshop includes a half-day session on mapping your specific regulatory obligations to SENAITE features, with concrete gaps flagged for the implementation phase. For labs with a scheduled audit or a validation deadline, we run this as a standalone engagement.
Everything above is verifiable in the code. Nothing here is a sales claim — SENAITE is open source, the code is on GitHub, and every mechanism cited in this post is grep-able against a specific file.