Compliance & Validation

This page describes how Scifeon relates to the regulations and standards that laboratories most often ask about: GMP and 21 CFR Part 11, and ISO/IEC 17025. It also explains which Scifeon environments are validated, and who is responsible for what.

In short:

Standard Scifeon environments are not validated. They have the same data integrity controls as validated environments, but Scifeon does not qualify them or deliver validation documentation for them.
Validated environments are offered for GMP-regulated use. Scifeon qualifies the baseline platform and delivers a validation package with each validated version. The customer validates its own configuration.
ISO/IEC 17025 accredits laboratories, not software. Scifeon supports accredited laboratories, and the laboratory validates Scifeon for its intended use.

Standard and validated environments

Every customer gets single-tenant environments (see Security). An environment is either standard or validated:

	Standard environment	Validated environment (GMP)
Intended for	Research, development and non-GMP laboratories	GMP-regulated activities
Validated by Scifeon	No	Yes. Installation and Operational Qualification (IQ/OQ) of the baseline platform for each validated version
Validation documentation	User documentation and release notes	A validation package for each validated version
Updates	Scheduled release cycle	Only in coordination with, and approved by, the customer
Periodic review	None	Yearly status review of the environment
Audit trail, e-signatures, access control	Yes	Yes

The functionality is the same in both. What differs is the documented evidence that the system works as intended, and the control of changes to it. A standard environment must not be used for GMP-regulated activities.

Data integrity

All environments enforce the ALCOA+ data integrity principles:

Principle	How Scifeon supports it
Attributable	Every action is linked to a uniquely identified user. Scifeon never modifies customer data on behalf of a user.
Legible	Audit trail entries and record histories stay human-readable for the lifetime of the data.
Contemporaneous	Timestamps are generated by the system in UTC at the moment of the action and cannot be altered.
Original	Raw instrument files are stored unchanged in file storage and linked to the results derived from them.
Accurate	Calculations are system-controlled and versioned with the procedure they belong to. The customer verifies them for its intended use.
Complete, Consistent, Enduring, Available	Immutable audit trail, encrypted storage, automated backups and documented disaster recovery. See Security.

How Scifeon develops and tests the platform

The same development and release process applies to every environment, standard and validated. Customers can use this description in their supplier assessment, and to decide how much of their own testing can rely on Scifeon’s.

Change control

Every change to the platform is linked to a change request or an incident, so each release can be traced back to the reason for every change in it.
Every change is made in a pull request and must pass a required review check before it can be merged. Nothing is merged automatically; a person always performs the merge.
Changes to sensitive areas always require approval by a developer who reviewed the change: database upgrades, access control and row-level security, authentication, saving of data, and the build and deployment pipelines. The same applies to large changes, changes to code with a history of defects, and changes to logic without an accompanying test.
All other changes require at least an automated code review, and every review comment must be resolved before merge.

Automated testing

Every pull request is built, type-checked, and run through the backend and frontend unit test suites.
Builds of the release branches are deployed to an internal environment, where an automated end-to-end test suite exercises the application through the browser. Test results are kept with each build.

Releases and environments

Releases are built and deployed by automated pipelines from version-controlled definitions, so every environment is installed the same way. Infrastructure is defined as code.
Each customer has a separate test environment, where new configuration can be tried before it is used in production.
Standard environments are updated on a regular release cycle. Validated environments are updated only in coordination with the customer (see GMP and 21 CFR Part 11).
A failed deployment raises a critical incident and stops the pipeline.

Monitoring and incidents

Unexpected errors in the application are reported to Scifeon automatically as incidents, with the technical details needed to investigate them.
Incidents and their fixes are tracked, and an incident caused by an earlier change is linked to that change.
Third-party penetration tests and vulnerability scans are performed periodically. See Security.

GMP and 21 CFR Part 11

GMP-regulated customers use a validated environment. Scifeon validates the standard baseline platform, which is ELN and LIMS functionality without customer configuration. The customer performs the final validation of the configuration applied on top of it.

Shared responsibility

Scifeon provides	The customer is responsible for
IQ/OQ of the baseline platform	Defining its validation approach and user requirements for its intended use
Automated regression tests run for every platform release	Performance Qualification (PQ) or User Acceptance Testing (UAT) of configured workflows
User requirements, test cases and a traceability matrix for the baseline	Approving test results and maintaining the validation status
Versioned releases with release notes and change impact assessment	Assessing the impact of new releases on validated workflows
Updates only in coordination with the customer	SOPs, user training and access authorization
Technical support during the customer’s validation	Revalidation after significant configuration changes

Scifeon does not execute or approve the validation of a customer’s environment. This keeps the validation independent of the supplier. Configured workflows can be locked after validation to keep the validated state.

Validation package

Each validated platform version comes with a validation package that supports the customer’s vendor qualification and its own validation. It includes:

The Scifeon validation model and shared responsibility description.
The automated testing rationale, and the risk-based rationale for third-party calculation components.
IQ/OQ documentation.
User requirements, test cases, a bidirectional traceability matrix and the automated test report.
A 21 CFR Part 11 requirements traceability matrix.
The emergency update procedure, and the template for the yearly status review of the environment.

21 CFR Part 11

The platform includes the technical controls for electronic records and electronic signatures: an automatic, immutable audit trail, e-signatures that record the signer, the meaning of the signature and the time, two-factor authentication for signing, role-based access control, and controlled workflow state transitions. These controls are present in every environment.

Part 11 also requires the system to be validated (§11.10(a)), so Part 11 compliance applies to validated environments only. Written policies, training and identity management remain the customer’s responsibility. The Part 11 traceability matrix in the validation package maps each requirement to the platform control and the responsible party.

ISO/IEC 17025

ISO/IEC 17025:2017 General requirements for the competence of testing and calibration laboratories accredits laboratories, not software. No LIMS or ELN can be “17025 certified” on its own. What an accredited laboratory needs from its software is:

Functionality that lets it meet the requirements on records, traceability, review and reporting.
Validation of the software for its intended use (clause 7.11.2).
A supplier that controls changes to the system.

Validating Scifeon in a 17025 laboratory

ISO/IEC 17025 does not require a GMP-style validation, but clause 7.11.2 requires the laboratory to validate its LIMS for its intended use before using it, and after changes. A laboratory on a standard environment performs this validation itself. Typically it is a risk-based verification of the configured workflows and calculations the laboratory relies on, and an assessment of each release using the release notes.

The laboratory can base the extent of its own testing on an assessment of Scifeon as a supplier. See How Scifeon develops and tests the platform.

Because standard environments follow the scheduled release cycle, the laboratory should plan how it assesses new releases. Scifeon supports the laboratory with user documentation, release notes and technical clarification, but does not provide validation documentation for standard environments.

Clause mapping

The table maps the ISO/IEC 17025:2017 clauses that involve laboratory informatics to the standard Scifeon platform. Coverage is one of:

Built in - supported by the standard platform without customization.
Partial - the platform covers part of the requirement. The rest is handled by configuration, a customer-specific app, or the laboratory’s procedures.
Procedural - the requirement is met by the laboratory’s management system, not by Scifeon. This is common practice: complaints, corrective actions and environmental monitoring are normally kept in a dedicated quality management or monitoring system rather than in the LIMS.

Clauses not listed (for example sections 4 and 5 on impartiality and structure, and most of section 8 on the management system) are organisational and are met by the laboratory’s own procedures.

Clause	Requirement	Coverage	How Scifeon supports it
4.2	Confidentiality	Built in	Single-tenant environments, encryption at rest and in transit, role-based access and department or project level row security. See Security.
6.2	Personnel competence and authorization	Partial	Authorization is enforced by the system: roles and permissions restrict who may review, approve and sign, and each procedure’s configuration restricts which roles may run the method and create experiments from it. Training and competence records are kept in the laboratory’s own system.
6.3	Facilities and environmental conditions	Procedural	No dedicated environmental monitoring. Conditions can be recorded as form fields in an experiment step, or captured as instrument readings through the Scifeon Instrument Hub.
6.4	Equipment	Partial	Instruments are registered with barcode, location, status (Active, Out of service, Retired) and last and next service dates. Experiment steps record which instrument was used. Calibration history and blocking of overdue equipment are not part of the standard platform.
6.4, 6.6	Reagents, consumables and reference materials	Built in	Batches (lots) with supplier batch number, preparation and expiry date, storage conditions and location. Steps record which batch was used. See Inventory.
7.1	Review of requests, tenders and contracts	Partial	Customers and contact persons are registered, and analysis requests are routed to a department inbox with status tracking. Contract review is a procedural step. See Requesting sample analysis.
7.2	Selection, verification and validation of methods	Built in	Methods are Procedures with versions in Draft, Active and Retired status. Versions can be reviewed and approved before release, compared with each other, and locked. Every experiment is bound to the procedure version it was created from.
7.4	Handling of test or calibration items	Built in	Samples get a unique ID and barcode, and keep their full lineage: parent, root sample, the step that created them and the steps that used them.
7.5	Technical records	Built in	Every change is audit-logged with user, UTC timestamp, field, and value before and after. Completed steps cannot be modified, and approved records cannot be changed without withdrawing the approval first.
7.6	Evaluation of measurement uncertainty	Partial	Form fields can carry an uncertainty expression, and results can store standard deviation, %CV and number of replicates. The uncertainty budget itself is the laboratory’s method documentation.
7.7	Ensuring the validity of results	Partial	Form fields can have upper and lower limits, and results can be compared and charted across experiments and batches in Dashboards. Proficiency testing is procedural.
7.8.1	Review and authorization of results before release	Built in	Configurable approvals of experiments, steps and form fields, restricted to authorized roles. E-signatures record the signer, the meaning of the signature and a UTC timestamp, and can require two-factor authentication.
7.8.2 - 7.8.8	Reporting results	Partial	PDF reports of experiments and requests, and a report designer. The content of test reports, calibration certificates and statements of conformity, including the decision rule, is configured for each laboratory.
7.9	Complaints	Procedural	Handled in the laboratory’s quality management system. Scifeon’s traceability (see 7.10) supports the investigation of a complaint about a specific result.
7.10	Nonconforming work	Partial	Scifeon answers the question a nonconformance raises: which results and reports are affected. Sample lineage and the instrument and batch used in each step trace a faulty instrument, reagent lot or sample to every experiment and result that depends on it. Affected records can be rejected or sent back through approvals, and analyses can be repeated with a link to the original. The nonconformance case itself is managed in the laboratory’s quality management system.
7.11.2	Validation of the laboratory information management system	Procedural	The laboratory validates Scifeon for its intended use. Standard environments are not validated by Scifeon. See Validating Scifeon in a 17025 laboratory.
7.11.3	Protection from unauthorized access, integrity, recording of failures	Built in	Role-based access, sign-in with Microsoft Entra ID, user provisioning through SCIM, immutable audit trail, automated backups. Deactivated users keep their records. System failures are tracked as incidents by Scifeon.
7.11.5	Supplier-managed systems	Built in	Scifeon operates and maintains the environment as a SaaS supplier. See How Scifeon develops and tests the platform and Security.
7.11.6	Calculations and data transfers checked	Partial	Calculations in forms and spreadsheets are part of the versioned procedure, and the laboratory verifies them as part of its validation. Instrument data is imported without manual transcription, and the raw file is kept and linked to the result.
8.3	Control of management system documents	Partial	SOPs can be managed as versioned, approved procedures. The laboratory’s wider document control is procedural.
8.4	Control of records	Built in	Records are retained with their full audit history, stored encrypted and backed up. Records can be exported as PDF and CSV.
8.7	Corrective actions	Procedural	Handled in the laboratory’s quality management system.

Security - hosting, encryption and infrastructure.
Approvals & Review Comments - review, approval and signing.
Procedures - versioned workflow templates.