Security

This page is the technical companion to /trust. It's intended for security and procurement teams who need concrete answers on infrastructure, encryption, sub-processors, audit logging and incident response. We will revise it as the platform evolves; the date below reflects the last review.

Last reviewed 2026-05-20 · No security incidents recorded to date

Hosting and infrastructure

Railflows runs on Cloudflare's edge platform. Application code executes in Cloudflare Workers; primary database is Cloudflare D1 (SQLite, replicated within Cloudflare's network); document storage is Cloudflare R2 (S3-compatible private object storage). There is no separately-managed VPS, no Kubernetes cluster and no long-lived application server — the attack surface is intentionally small.

Data residency

Cloudflare D1 currently runs in the EEUR region (Cloudflare's Eastern Europe data centres). Documents in R2 are uploaded without a specific region pin (Cloudflare R2 stores data across its global network). Both stores enforce encryption at rest and access is gated by Worker bindings, not by public URLs. If you have a specific data-residency requirement for an engagement, talk to us — we can scope it.

Sub-processors

Railflows uses the following third parties to deliver the service. Each is listed with the data it processes and its purpose.

Material changes to this list will be reflected here. Buyers under a Data Processing Addendum will be notified of new sub-processors before they go live.

Authentication and sessions

• Sign-in is by single-use magic link delivered over email. There are no passwords to crack, phish or reuse.
• Magic-link tokens are random 256-bit values, stored only as SHA-256 hashes at rest, single-use, expire after 15 minutes, and are scoped to a specific email address.
• Sessions are server-side rows in the database; the browser only holds an opaque session id in a HttpOnly; Secure; SameSite=Lax cookie. Sessions expire after 14 days. Users can sign out of every session from the account page.
• Sign-in requests are rate-limited: maximum 5 magic-link requests per email and 15 per source IP within any rolling 10-minute window. Requests against unknown email addresses also return the same response shape as known addresses, so the endpoint cannot be used to enumerate users.

Authorisation

All sensitive read and write paths are guarded server-side. The authorisation model is role-based (buyer, provider, admin) with organisation-scoped data access:

• Buyers can only read RFQs and documents owned by their organisation.
• Providers can only read anonymised RFQ summaries for matches assigned to their organisation.
• Provider document downloads enforce three checks per request: organisation ownership of the match, buyer-approved reveal status, and document-level disclosure scope.
• Admin actions are role-gated and logged with actor identity.

Encryption

• In transit: TLS 1.3 on every request. HTTP→HTTPS is enforced by Cloudflare. Custom domains use Cloudflare-managed certificates.
• At rest: Cloudflare D1 and R2 encrypt all data at rest by default (AES-256). Secret values (API keys, session-secrets) live in Worker secrets, not in the codebase.
• Sensitive token storage: magic-link tokens and any other one-time secrets are stored as SHA-256 hashes rather than plaintext.

Audit logging

Every sensitive action — RFQ submission, admin approval, provider match, provider response, reveal request, reveal approval, document download, outcome recording — is logged to the audit_events table with actor identity, organisation, target type/id, action and timestamp. Audit data is retained for the life of the engagement and accessible to admins for investigation.

Backups and disaster recovery

Cloudflare D1 ships with point-in-time recovery managed by Cloudflare; we can restore the database to any state within the platform's PITR window. Documents in R2 inherit Cloudflare's storage durability guarantees. We are working towards a documented RPO/RTO target as the platform matures — talk to us if your procurement process requires specifics.

Vulnerability disclosure

If you believe you have found a security issue, please email security@railflows.com. Please give us a reasonable window (we aim for an initial response within 2 business days) before public disclosure. We do not currently run a paid bug bounty programme; we will acknowledge confirmed reporters on request.

Incident response

On confirmed security incident, our process is:

1. Contain — revoke compromised credentials, isolate the affected surface.
2. Assess — determine what data was accessed and which parties are affected.
3. Notify — affected organisations are notified directly. Notification timing follows applicable law (GDPR Article 33 requires controller-side notification within 72 hours of becoming aware of a personal data breach).
4. Remediate — fix the underlying issue, deploy controls to prevent recurrence.
5. Document — write a post-mortem that we share with affected parties on request.

Data processing terms (DPA)

For EU/EEA buyers, our Data Processing Addendum is available at /dpa. It covers controller/processor roles, sub-processors, security measures and data subject rights.

Other

SOC 2 / ISO 27001

We do not hold a SOC 2 or ISO 27001 certification today. The platform is built with controls that aim at the spirit of those frameworks (least privilege, audit logging, encryption-by-default), and certification is on the roadmap as usage scales. If your procurement requires a current certification we can talk about timing.

Penetration testing

Independent penetration testing is planned for general availability. We will publish a summary letter (without findings detail) when complete.