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 moves the analysis to a retracted
state 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, SENAITE gives you the pieces a validation programme needs but not a validation package in a box. Reproducible builds through pinned versions, an Enterprise VM image with the same hardening every time, and source you can reference at commit level in your evidence. The IQ, OQ, and PQ documents themselves are always scope of work in the engagement — against the customer’s actual environment, actual configuration, and actual acceptance criteria — not something we ship pre-written.
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. Only labs supporting FDA-regulated products are strictly obligated, but Part 11 is also the reference framework GxP-facing labs measure themselves against.
This section is honest about scope. SENAITE ships strong electronic-records machinery. It does not ship a Part 11 electronic-signature primitive out of the box. A lab under Part 11 obligation should treat SENAITE as an audit-trail foundation and plan for the signature layer and the formal validation programme separately.
§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), with binary attachments in a
paired blobstorage directory. 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; Plone’s LDAP plug-in works out of the box, other SSO paths need scoped integration work. 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.10(a), §11.10(g), §11.50, §11.70, §11.100, §11.200 — the honest gap
These clauses cover validation (§11.10(a)), authority checks (§11.10(g)), signature manifestations (§11.50), signature-to-record linking (§11.70), signature uniqueness (§11.100), and non-biometric two-component signing (§11.200). Together they define what a Part 11 electronic signature actually is: a distinct signing act, at the moment of a critical transition, with an explicit password re-prompt, a stated meaning of signature (“I verify these results”), and a permanent, inseparable link to the record.
SENAITE does not ship any of that. What SENAITE ships is session-based authentication, workflow transitions with actor metadata, and the audit-trail snapshot log. That constellation is an audit trail, not a Part 11 electronic signature. It satisfies §11.10(e). It does not, as-shipped, satisfy the signature clauses above.
For a Part 11 lab this is a scope conversation, not a blocker. The audit-trail foundation is the hard part and it is done. A Part 11 signature layer — password re-prompt at critical transitions, meaning declaration, non-repudiation binding to the snapshot — is well-defined custom work on top of SENAITE’s workflow engine, and the whole system is then formally validated as one against a written protocol. Plan for both explicitly, or choose a vertical LIMS that ships Part 11 pre-validated. Do not plan for out-of-the-box Part 11 conformance on SENAITE.
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.
- 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.
- Ship a Part 11 electronic-signature primitive. The audit-trail foundation is real. The distinct signing act with password re-prompt and meaning declaration is not. If you need Part 11 e-signatures, plan for a custom layer on top.
- Validate itself. SENAITE is validatable, not self-validating. A written protocol executed against your actual server, configuration, and data set is the artefact regulators want. It has to be produced.
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.
We are the core team behind the audit-trail machinery cited above. If your project needs a Part 11 signature layer, a formal validation programme, or a mapping of your specific regulatory obligations to SENAITE features with gaps flagged, that is a scoped engagement rather than something we ship in the base install. Start a conversation and we will tell you what the shape of that engagement looks like on your constraints.
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.
