Security

Each organisation’s data kept apart

Every table that holds an organisation’s records is protected by row-level security in PostgreSQL, forced even on the tables’ owner. The application connects as a role that cannot bypass it, so one organisation’s data is kept from another’s by the database itself, not only by the application’s own checks. Automated tests try to cross that line on every change.

Signing in

• Passwords of 12 characters or more, stored only as salted scrypt hashes.
• Authenticator codes (TOTP) required of owners and administrators, and available to everyone; passkeys can be added too.
• Single sign-on with an organisation’s own identity provider, over SAML or OpenID Connect.
• Sessions that end after eight hours without use, in cookies sent only over HTTPS and unreadable to scripts.
• Access by role, checked on every page, action and request, and reviewed in periodic access reviews.

Signatures and segregation of duties

Approvals that matter — publishing a process, paying a supplier, closing a month, accepting a risk — are electronic signatures: the signer enters their password and authenticator code again, and the signature is bound to a hash of exactly what was signed, as 21 CFR Part 11 asks. Whoever drafts or changes a record cannot approve it, and conflicting duties are refused unless a compensating control is recorded.

An audit trail that shows tampering

Every change is written to an append-only audit trail in the same database transaction as the change. Each entry carries a hash of the one before it, so altering or removing an entry breaks the chain, and anyone with access can verify it on demand. The application’s database role is not allowed to update or delete audit entries.

Encryption

• All traffic to this site is over HTTPS, with HSTS.
• Stored files are encrypted with a key per organisation, itself wrapped by a key the deployment holds outside the database.
• Authenticator secrets and recovery codes are encrypted; the most sensitive personnel assessments are sealed field by field.
• Outgoing mail requires TLS.

Files and the browser

• Every uploaded file is scanned for malware before it is kept; if the scanner cannot answer, the file is refused.
• File types are checked by their contents, not only their names.
• A strict Content Security Policy with a fresh nonce on every page, no third-party scripts, and headers that stop the site being framed or sniffed.

Self-hosted, with nothing sent out

BPT runs on its operator’s own servers. Its malware scanning, its AI model, its office editor, its maps and its route planning all run inside the same deployment, so documents and records are not sent to outside services to be processed. The few outside services involved are on the Subprocessors page.

Controls as code

Each control BPT implements is written down as a file in its source, mapped to the requirements of SOC 2, ISO 27001, NERC CIP, HIPAA and 21 CFR Part 11 that it answers, and tied to the automated tests that show it working. Thousands of tests run before any change is released.

Reporting a problem

If you believe you have found a vulnerability, please tell us as the Responsible disclosure page describes. We are grateful for every report made in good faith.