Security & Data Protection

All production AI inference runs through Mistral AI, an EU-incorporated company based in France. Your batch data, sensor readings, and model outputs never leave the EU — not to the US, not to any non-EU jurisdiction. EU law, EU servers.

There are no US data transfers for production workloads. BatchCortex is GDPR Article 44 compliant by architecture. We chose Mistral AI specifically because they are EU-incorporated and guarantee full EU data residency.

Our database runs on Supabase infrastructure in Stockholm, Sweden. Your data lives in its own isolated container with point-in-time recovery enabled — so nothing is ever permanently lost.

If Mistral AI experiences an outage, BatchCortex continues to record sensor data and maintain audit trail integrity. AI inference pauses, but your production monitoring and data capture remain operational. When service resumes, inference catches up automatically.

The events_log table is append-only. Row Level Security policies prevent UPDATE and DELETE operations at the database level — not through application logic that could be bypassed, but through PostgreSQL RLS rules enforced by the database engine itself.

A SHA256 hash is generated and stored on every signature record. The hash covers the record ID, signer ID, timestamp, and meaning — so any modification to any field produces a different hash, making tampering detectable.

Every record is ALCOA+ compliant: attributed to a specific user or system actor, timestamped server-side (client timestamps are never trusted for audit purposes), and stored as the original unmodified capture.

What "tamper-evident" means in practice: if anyone modifies a record outside the application, the SHA256 hash will no longer match. During an audit, you can verify integrity by recomputing the hash from the record fields and comparing it to the stored hash. A mismatch means the record has been altered.

BatchCortex uses multi-role RBAC with four levels: Operator, QA, QP, and Admin. Each role has specific permissions enforced at both the application and database levels.

Session management runs through Supabase Auth with secure HTTP-only cookies. But session authentication alone is not sufficient for GMP operations — that's why password re-authentication is required at every electronic signature event.

Every sign-off captures and logs the signer's IP address, timestamp, full name, role, and a SHA256 hash of the signature event. This is a 21 CFR Part 11 requirement, and we enforce it at the application level with no override mechanism.

Our electronic signature implementation meets 21 CFR Part 11 requirements. At the moment of signing, the user must re-enter their password — session authentication is explicitly insufficient under Part 11.

Each signature record captures: the signer's full name, their role (QA Manager, QP, etc.), a UTC timestamp, the signer's IP address, the meaning of the signature (e.g. "approved", "reviewed"), and a SHA256 hash covering all these fields plus the record ID.

The hash proves that the signature was created with exactly these values at exactly this time. If any field were altered after signing, the hash would no longer match — providing cryptographic proof of tampering.

Session-based auth alone is insufficient because it cannot prove that the person who started the session is the same person who signed the document. Re-authentication at signing time closes this gap.

We take security seriously. If you discover a security issue in BatchCortex, please contact us directly at vilmer@batchcortex.com before disclosing publicly. We commit to responding within 48 hours.