Security

Last updated: 15 September 2026

BatchPilot handles regulated manufacturing records, so security and data integrity are built into the product, not bolted on. Here is how it works.

Accounts and sign in

Every person has their own account. There are no shared logins. Passwords are stored only as a salted scrypt hash, never in readable form, and the hash records the settings it was made with so the cost can be raised later without locking anyone out.

Sessions use a strictly necessary, HTTP-only cookie with an expiry, so the session token is not readable by scripts in the browser. Only a hash of that token is stored on our side, so a copy of the database does not let anyone sign in as you. Expired sessions and spent sign-in codes are deleted rather than kept.

Anyone can turn on two-step sign in for their own account. After the password, we email a six-digit code that works once and expires in 10 minutes. Codes are stored only as a hash, and a small number of wrong guesses cancels the attempt.

Signing off a review requires the reviewer to re-enter their password at the moment of signing, so an electronic signature is tied to a verified person.

A forgotten password is reset through a link sent to the account email. The link works once and expires in an hour, and setting a new password signs that person out of every other session.

Roles and least privilege

Access is controlled by role, and each company configures what each role is allowed to do across a fixed set of capabilities (enter records, run the AI review, decide flags, sign off, manage deviations, manage the team). Every action is checked on the server, not just hidden in the interface.

Separation between companies

BatchPilot is multi-tenant. Each company's users, records, deviations, and audit trail are scoped to that company and checked on every request. One company cannot see or reach another company's data.

Audit trail and data integrity

Every meaningful action is written to an append-only audit trail. Each entry is linked to the previous one with a SHA-256 hash chain kept separately for each company, so altering an earlier entry breaks the chain and is detectable. Editing a batch record is a controlled event: it requires a reason, bumps the record's revision number, and is written to the audit trail with the fields that changed.

Browser protections

Pages are served with a content security policy, so the browser will run only scripts we have signed for that page and will not send data to another site. The app cannot be framed by another site, pages are marked not to be cached or indexed, and connections are told to stay on HTTPS.

Records leaving the system

Exporting or printing a review is itself written to the audit trail, with who did it, when, which revision, and a checksum of the record text. The entry records the fact of the export, never the content. Exports are also rate limited, and only a role that has been given the export capability can produce one.

A review can be exported as a PDF with the full machine-readable record embedded inside it, so the readable report and the data that supports it stay in one file.

Deleting a record

An administrator can permanently delete a batch record. It asks for a written reason and the person's password, and it removes the record, its reviews, its findings, and every stored earlier revision. The audit trail is kept, including an entry recording the deletion and the reason, because a deletion that erased its own evidence would defeat the point of keeping a trail.

Encryption

In transit, all traffic uses HTTPS/TLS, including the connection to our AI provider. In production, data at rest is stored on encrypted infrastructure. To be precise about what that does and does not cover: the protection at rest is provided by the managed database and its backups, not by a separate application-level encryption of the record text. Ask us if that distinction matters to your assessment.

AI data handling

The AI provider's API key is held only on the server and is never sent to the browser. Record text is sent to the provider only to generate a review, over an encrypted connection, and the provider does not use API content to train its models. The AI is advisory: a qualified person makes every decision.

Hosting, backups, and availability

BatchPilot runs on managed cloud infrastructure, with a managed Postgres database and regular encrypted backups. We are an early product and we will not overstate this: ask us for the current hosting provider, region, and backup and recovery arrangements, and we will confirm them in writing before you send us a real record.

Regulatory alignment

BatchPilot is designed to support the expectations of 21 CFR Part 11 and EU GMP Annex 11 (unique accounts, electronic signatures, and a tamper-evident audit trail) and to help you meet data-protection obligations under the GDPR and CCPA/CPRA. Formal computer system validation and any certifications are completed per deployment and are a shared responsibility with your quality organization.

Reporting a vulnerability

If you believe you have found a security issue, please email hello@batchpilot.net. We will acknowledge your report and work with you on a resolution. Please do not publicly disclose an issue until we have addressed it.

Your responsibilities

Keep credentials confidential, give each person their own account, grant only the permissions each role needs, and remove access promptly when someone leaves. Security is a shared effort.

See also our Privacy Policy.