Security & record integrity

Signing uses two identification components as 21 CFR §11.200 requires: the user's account plus a secret only they know, re-entered at the moment of signing rather than carried over from login. The client requests a single-use signing token that expires in ninety seconds and is bound to the meaning of that particular signature, so a token issued for a weighing step cannot be replayed to release a batch. Ordinarily that secret component is the account password or a dedicated signing PIN, either one: both are accepted values of the single “identification code and password” component § 11.200(a)(1) names, not two factors. The four meanings below are the exception: only the enrolled PIN is accepted, and the account password is refused. That follows how a shared shop-floor terminal actually gets used: a login password is typed once at the start of a shift and is easy for anyone standing there to see or already know, while a signing PIN is a separate secret the operator sets independently and types only at the moment of attesting, so watching someone log in is not enough to release a batch or clear a line as them. Enrolling a PIN takes one step from inside the same signing dialog (re-enter the account password, set the PIN) so an operator who has not enrolled yet loses a few seconds there, not the ability to work.

The four meanings that accept only the PIN are batch release, assay compensation, line clearance and weighing. Where a competency is defined for a step, signing is refused unless the operator currently holds it, which makes qualification a precondition of the record rather than a file in a drawer. Signature enforcement is applied at every endpoint that seals a GxP record; ask and I will send you the list with file and line, rather than a number you would have to take on trust.

The secret is deliberately kept out of named RPC parameters so it cannot end up in a request log, and the repository carries a static check that rejects any whitelisted endpoint declaring a password or PIN argument, including the evasion route of reading one out of the request body instead. Two endpoints are exempt by an explicit allowlist rather than by weakening the rule: the one that re-verifies your secret to issue a signing token, and the one where you enrol a new PIN. That check runs in the build, with its own tests: a change that breaks the rule does not go in.

Signature records are append-only. Modification and deletion are refused by the application, and each record carries a SHA-256 hash of its own content.

Every audit-trail entry is written in the same transaction as the act it records, so an entry exists exactly when its act was saved. Every five minutes the new entries are sealed into a SHA-256 chain: each seal carries a gap-free sequence number, the hash of its entry and the previous seal's hash, so removing or editing one entry breaks every seal after it. After each sealing run the number and hash of the last seal are written to object storage under a write-once lock (Compliance mode) that not even the account owner can delete before the retention period ends, and an RFC 3161 authority time-stamps the chain on a schedule. The anchor is not a plant setting: BatchGlow sets it up for every plant, and a plant cannot switch it off.

The chain is checked every day and in full every week, and quickly after every sealing run; a failed check opens a quality deviation. An inspector can be given an export of the chain and a script that checks it, outside BatchGlow, against the anchored objects. The boundary, stated plainly: someone able to write to the database directly could still alter what was sealed after the last anchor, or remove an entry before it is sealed; the anchor narrows that window to minutes. Tamper-evident, not tamper-proof.

Scope, stated plainly: the audit trail covers every GMP record BatchGlow keeps, and the core records that carry GMP data (batches, stock entries and reconciliations, receipts, delivery notes, work orders, BOMs, quality inspections, the GMP fields of items, user roles) for every act from creation through each save, submission, change, cancellation, rename and deletion, with the old and new value of each field. Every electronic signature and PIN event is in it, and the hash of each batch record at its release. It does not cover every row in the database. The framework's own version log is not part of the audit trail: it can be deleted, and it misses some acts entirely. Any vendor telling you that every transaction in their system is cryptographically chained is describing something narrower than it sounds.

For a contract manufacturer this is a security control. Formulas carry the customer who owns them, customer-supplied material carries title, and combining material belonging to two different owners into a single lot is refused outright.

Records are stored in a standard relational database, and one command takes the whole site out whenever you ask (batch records, signature events, audit history, lot genealogy, master data and attachments) in CSV and JSON, with the audit chain exported in a form a third party can check again from the files, and without password and PIN hashes or the site's keys; a dump of the database itself as well. Handing the instance over to you or to another provider is a documented procedure. For records you are required to keep for years, being able to leave is a security property, and it is written into the agreement rather than asserted on a web page.

Pilot deployments will be hosted on US-based infrastructure. BatchGlow is in active development and is not yet running in commercial production anywhere, so this is a commitment for pilot sites rather than a description of an existing fleet.

BatchGlow holds no third-party security certification: no SOC 2 report, no ISO 27001, no completed independent penetration test. This page describes architecture, not an audited attestation, and should be read that way. If your supplier qualification process requires an attestation today, BatchGlow will not pass it yet, and I would rather you learn that here than three weeks into a questionnaire.

Email founder@batchglow.com. Reports reach me directly, I will acknowledge within two business days, and I will not pursue anyone reporting a genuine issue in good faith.