Security and compliance

Authentication and access

Authentication is handled by Auth0 on a custom domain (auth.neolumi.io). Access tokens are RS256-signed JSON Web Tokens, validated against the published key set on every request. Roles arrive as a custom claim and are enforced by the API rather than by the interface. The platform has two roles: customer administrator and customer user.

A session ends after thirty minutes without activity.

Electronic signatures under 21 CFR Part 11 require re-authentication at the moment of signing, with freshness checked against the authentication time. The signer's name, the timestamp and the meaning of the signature are recorded on the session and surfaced in the export, on the completion screen, and at a verification endpoint.

Hosting and network

The platform runs on Microsoft Azure, in the Central US region. Every secret resolves from Azure Key Vault through a managed identity, so credentials live in the vault alone and are read at runtime rather than held in application configuration or in a deployment pipeline.

Production egress is integrated with a virtual network and leaves through a NAT gateway holding a single static address. The PostgreSQL firewall admits that address and nothing else: there is no rule opening the database to Azure services at large, so traffic from another tenant's infrastructure cannot reach it even holding valid credentials. Every connection requires TLS.

Encryption

In transit, TLS throughout, with HTTP Strict Transport Security sent at a one-year max-age covering subdomains.

At rest, personal data is encrypted column by column: trainee addresses, user identifiers, learning-group membership, and the identity of the administrator who assigned a training. The cipher is AES-256-GCM under a key derived through HKDF-SHA256, with a fresh 96-bit nonce for every record. Ciphertext cannot be searched, so equality lookups run against an HMAC-SHA256 blind index held in a separate column under a separate key; erasure clears the ciphertext and the index together.

Sync credentials for SharePoint and Veeva Vault take the same cipher over a PBKDF2-HMAC-SHA256 key at 600,000 iterations with a per-record salt. The additional stretch is there because a stored credential is something an attacker can work on offline, which is not true of a random 32-byte master key.

Tenant isolation

The platform is multi-tenant, and every record carries an administrative scope that every query is filtered by. That is enforced by a dedicated test suite which gates the build rather than by convention in application code, so an endpoint that omits the scope does not reach production.

Administrators are additionally scoped by their identity-provider organisation, so a token issued for one customer names that customer and no other.

Records and the audit trail

The audit log is append-only across every route. The database role that writes it holds INSERT and nothing else, so a record cannot be amended or removed after the fact by the application that created it.

A training is bound to the exact source-file version it was generated from, under semantic versioning with hash-based change detection and an immutable archive of every version. A completion record names the version it was earned against. Deleting a source file captures a reason for the change, which is written into the trail with it.

The compliance report exports as PDF or CSV.

Personal data

The platform supports subject access export and erasure. Erasure runs end to end: it pseudonymises the addresses and identifiers held for that person across every tenant, removes their learning-group memberships, and deletes the corresponding user record at the identity provider through its management API. Completion records survive in pseudonymised form, because they are the customer's compliance evidence and carry nothing that can be attributed back to the person.

Soft-deleted data is purged against a per-tenant retention window by a scheduled job, which writes its own count into the audit trail. A data processing agreement is available on request, and how neolumi handles personal data on this website and in the platform is set out in the privacy policy.

Documents stay where they are controlled

Controlled documents are not migrated into neolumi. They stay in the system that owns their approval and version history, and neolumi synchronises from it — so document control, approval routing and the record of who released a revision remain where a regulator already expects to find them. What neolumi holds is the training generated from a named version of that document, and the evidence that it was completed.

How a change reaches production

Every change arrives through a pull request and a pipeline that runs what a deployment runs: dependency audits on both stacks, a secret scan on every commit, linting, type checking, and the compliance test suite covering authentication, tenancy, audit and data protection. The deployment is gated on all of it.

Database changes ship as reviewed migrations that carry their own permission grants, and a test fails the build if a new table reaches production with the wrong role holding rights on it.

Reporting a vulnerability

Send it to security@neolumi.io. The platform publishes the same address in a security.txt at /.well-known/security.txt, per RFC 9116. We will acknowledge the report and tell you what we found.

Documentation for reviewers

neolumi maintains a set of nine compliance documents, written by neolumi, and supplies them to vendor-qualification, CSV and security reviewers on request.

GxP validation documentation

Validation master plan, and the IQ, OQ and PQ position for the platform as a computerised system.

GxP supplier pack

The supplier-qualification evidence a quality unit asks for before a system is used in a regulated process, including the change-notification policy.

Compliance report

The control set as built, mapped to SOC 2, ISO 27001, 21 CFR Part 11 and GDPR, with the remaining work named and owned.

Data processing agreement

Article 28 terms, the approved sub-processors, and the transfer mechanism relied on for each.

Record of processing activities

The Article 30 register: what is processed, on what basis, where it goes and how long it stays.

ISMS policy manual

The information-security policies the rest of the set is written against — access, credentials, change, acceptable use.

Risk register

Identified risks with their scoring method, treatment plan and named owner.

Asset inventory

Systems, data stores and third parties in scope, with their classification tier and supplier assurance.

Incident response plan

Severity classification, detection sources, and the response phases from declaration through to notification and close.